| Internet-Draft | ICN Reflexive Forwarding | March 2023 |
| Oran & Kutscher | Expires 27 September 2023 | [Page] |
Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an Interest-Data exchange in the case of the two protocols noted above). A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint. This specification proposes a Reflexive Forwarding extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 September 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Current ICN protocols such as CCNx [RFC8569] and NDN [NDN] have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response. These ICN architectures use the terms "consumer" and "producer" for the respective roles of the requester and the responder, and the protocols directly capture the mechanics of the two-way exchange through the "Interest message" carrying the request, and the "Data message" carrying the response. Through these constructs, the protocols are heavily biased toward a pure pull-based interaction model where requests are small (carrying little or no user-supplied data other than the name of the requested data object), and responses are relatively large - up to an architecture-defined maximum transmission unit (MTU) on the order of kilobytes or tens of kilobytes.¶
A number of important applications however require interaction models more complex than individual request/response interactions in the same direction (i.e. between the same consumer and one or more producers). Among these we identify three important classes which are the target of the proposed enhancements defined in this specification. These are described in the following paragraphs.¶
All of the above application interaction models present interesting challenges, as neither relaxing the architecture to support pushing large amounts of data, nor introducing substantial complexities through multiple independent Interest-Data exchanges is an attractive approach. The following subsections provide further background and justification for why push and/or independent exchanges are problematical.¶
There are two substantial problems with the simple approach of just allowing arbitrary amounts of data to be included with requests. These are:¶
These problems also exist in pure datagram transport protocols such as those used for legacy RMI applications like NFS [RFC7530]. More usual are application protocols like HTTP(s) which rely on the TCP or QUIC 3-way handshake to establish a session and then have congestion control and segmentation provided as part of the transport protocol, further allowing sessions to be rejected before large amounts of data are transmitted or significant computational resources expended.¶
In order to either complete a three-way handshake, or fetch data via a pull from the original requestor, the role of consumer and producer need to be reversed and an Interest/Data exchange initiated in the direction opposite of the initiating exchange. When done with an independent Interest/Data request and response, a number of complications ensue. Among them are:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
This specification defines a Reflexive Forwarding extension to CCNx and NDN that avoids the problems enumerated in Sections 1.1 and 1.2. It straightforwardly exploits the hop-by-hop state and symmetric routing properties of the current protocols.¶
Figure 1 below illustrates a canonical NDN/CCNx forwarder with its conceptual data structures of the Content Store (CS), Pending Interest Table (PIT) and Forwarding Information Base (FIB). The key observation involves the relation between the PIT and the FIB. Upon arrival of an Interest, a PIT entry is created which contains state recording the incoming interface on which the Interest was received on. If the Interest is not immediately satisfied by cached data in the CS, the forwarder looks up the name in the FIB to ascertain the next-hop to propagate the Interest onward upstream toward the named producer. Therefore, a chain of forwarding state is established during Interest forwarding that couples the PIT entries of the chain of forwarders together conceptually as breadcrumbs. These are used to forward the returning Data Message over the inverse path through the chain of forwarders until the Data message arrives at the originating consumer. The state in the PITs is unwound by destroying it as each PIT entry is satisfied. This behavior is critical to the feasibility of the reflexive forwarding design we propose.¶
+-----------------------------------------------------------------+ | ICN Node | | Send data to all ======== | | interfaces that | | requested it | | YES +------------------+ | <------------------------| Pending Interest | <--------------------- | | | Table (PIT) | Data | | | +------------------+ 1) Find (Signed) | | | 2) Save | Name | | V Data | NO in | | +---------------+ | PIT? | | | Content Store | | | | | (CS) | | | | +---------------+ | | | | | | V | | Drop Data | | | +-----------------------------------------------------------------+
+-----------------------------------------------------------------+ | ICN Node | | ======== | | | | +====================+| | |Forwarding Strategy || | +====================+| | | | 1) Find name 2) Matching 3) Find matching | | in CS? name in PIT? entry in FIB? | | NO NO YES| | +---------------+ +----------------+ +-------------------+ | | | Content Store | | Pending | | Forwarding | | --->| (CS) |-->| Interest |-->| Information Base |--> | | | | Table (PIT) | | ( FIB) | | | +---------------+ +----------------+ +-------------------+ | | Return | YES YES | NO NO | | | Data | Add | Add | Drop | | | Incoming | new | or | | <------| Itf. | Interest | NACK | | V V | | | +-----------------------------------------------------------------+
Given the above forwarding properties for Interests, it should be clear that while an Interest is outstanding and ultimately arrives at a producer who can respond to it, there is sufficient state in the chain of forwarders to route not just a returning Data message, but potentially another Interest directed through the inverse path to the unique consumer who issued the original Interest. (Section 6.1.3 describes how Interest aggregation of requests to the same target name from multiple consumers interacts with this scheme.) The key question therefore is how to access this state in a way that it can be used to forward Interests.¶
In order to achieve this Reflexive Interest forwarding on the inverse path recorded in the PIT of each forwarder, we need a few critical design elements:¶
The following sections provide the normative details on each of these design elements.¶
For general ICN-related terms, we adopt the terms defined in [RFC8793]. For CCNx-specific terms, we use the terms defined in [RFC8609]. This specification defines the following additional terms:¶
The overall interaction flow for reflexive forwarding is illustrated below in Figure 2.¶
+-----------+ +-----------+ +-----------+
| Consumer | | Forwarder | | Producer |
+-----------+ +-----------+ +-----------+
| | |
| I1 | |
|------------------------->| |
| -------------\ | |
| | Record RNP |-| |
| | in PIT(I1) | | |
| |------------| | |
| | --------------------\ |
| |-| Add FPT to I1.FPT | |
| | |-------------------| |
| | |
| | I1 |
| |---------------------------->|
| | | ------------\
| | |-| Check |
| | | | prefix, |
| | | | creating |
| | | | Reflexive |
| | | | Interest |
| | | | state |
| | | |-----------|
| | ------------------\ |
| | | I1.FPT->RI1.RPT |-|
| | |-----------------| |
| | |
| | RI1 |
| |<----------------------------|
| | ----------------------\ |
| |-| use RI1.RPT to find | |
| | | PIT(I1), | |
| | | check match | |
| | | of PIT(I1).RNP | |
| | | create PIT(RI1), | |
| | | forward RI1 | |
| | |---------------------| |
|------------------------\ | |
|| add I1.RPT and I2.FPT |-| |
|| to PIT(I2) | | |
||-----------------------| | |
| | |
| RI1 | |
|<-------------------------| |
| | |
| RD1 obj | |
|------------------------->| |
|------------------------\ | |
|| consume PIT(I2) entry |-| |
|| and forward RD1 | | |
||-----------------------| | |
| -------------------\ | |
| | RI1.FPT->RD1.RPT |-| |
| |------------------| | |
| | -------------------\ |
| |-| satisfy PIT(RI1) | |
| | |------------------| |
| | |
| | RD1 |
| |---------------------------->|
| | | -------------\
| | |-| all |
| | | | parameters |
| | | | received, |
| | | | answer I1 |
| | | |------------|
| | |
| | D1 object |
| |<----------------------------|
| -------------------\ | |
| | satisfy PIT(I1), |-| |
| | forward D1 | | |
| |------------------| | |
| -----------------\ | |
| | I1.FPT->D1.RPT |-| |
| |----------------| | |
| | |
| D1 | |
|<-------------------------| |
| | |
Legend:
I1: Interest #1 containing the Reflexive Name Prefix TLV
RI1: Reflexive Interest with Reflexive Name Prefix Segment
RNP: Reflexive Name Prefix
FPT: Forward Direction PIT Token
RPT: Reverse Direction PIT Token
D1: Data message, answering initiating I1 Interest
RD1: Data message, answering RI
A consumer that wants to employ Reflexive Forwarding MUST create an Interest (I1) with a Reflexive Name Prefix (RNP) TLV that is used by the producer when issuing Reflexive Interests (RI) back to the consumer. Upon receiving a Reflexive Interest (e.g. RI1 in Figure 2) from a Producer in response to the Interest whose first name segment is the RNP supplied earlier, the consumer SHOULD perform a name match against the object specified in the Reflexive Name, and return that object to the producer in a conventional Data message, (e.g. RD1 in Figure 2).¶
A consumer may have one or more objects for the producer to fetch, and therefore needs to communicate enough information in its initial Interest to allow the producer to construct properly formed Reflexive Interest names. For some applications the set of full names (see the ICN Terminology RFC [RFC8793]) is known a priori, for example through compile time bindings of arguments in an interface definition or by the architectural definition of a simple sensor reading. In other cases, the full names of the individual objects must be communicated via the RNP in the original Interest message.¶
We define a new typed name segment, identified by a registered name segment type in the IANA registry for [RFC8609]. We call this the Reflexive Interest Name Segment type. It MUST be the first (i.e. high order) name segment of any Reflexive Interest issued by a producer. Its value is a random 128 bit quantity, assigned by the consumer, which provides the entropy required to uniquely identify the issuing consumer for the duration of any outstanding Interest-Data exchange. We suggest using a UUID as specified in [RFC4122] but any scheme that meets the randomness and entropy requirements can suffice. The consumer SHOULD choose a different random value for each Interest message it constructs because:¶
This initial name segment is either communicated by itself through a Reflexive Name Prefix TLV in the originating Interest, or prepended to any object names the consumer wishes the producer to fetch explicitly where there is more than one object needed by the producer for the current Interest-Data interaction. There are four cases to consider:¶
The last of the four options above, while not explicitly outlawed, SHOULD NOT be used. This is because it results in a longer Interest message and requires extra PIT resources. Hence, it is more likely a forwarder will reject the Interest for lack of resources. A forwarder MAY optimize for the case of a single Reflexive Name TLV at the expense of those with more than one.¶
A producer, upon receiving an Interest with one or more Reflexive Name Prefix TLVs, may decide it needs to retrieve the associated data object(s). It therefore can issue one or more Reflexive Interests by appending the necessary name segments needed to form valid full names of the associated objects present at the originating consumer. These in fact comprise conventional Interest-Data exchanges, with no alteration of the usual semantics with regard to signatures, caching, expiration, etc. When the producer has retrieved the required objects to complete the original Interest-Data exchange, it can issue its Data response, which unwinds all the established state at the producer, the consumer, and the intermediate forwarders.¶
A producer that has received an Interest with a Reflexive Name Prefix (RNP) MUST store the supplied RNP and the Forward PIT Token (FPT) from the received Interest for subsequent (optional, depending on application semantics) Reflexive Interest sending.¶
When sending a Reflexive Interest back to the consumer, the producer MUST construct a corresponding Interest name based on the RNP and insert the received Forward PIT Token (FPT) as the Reverse PIT Token (RPT) TLV in the reflexive Interest.¶
The forwarder operation for CCNx and/or NDN is changed in the following respects when supporting Reflexive Interests. The requirements are slightly different for a simple forwarder meeting the mandatory aspects of the specification, versus a forwarder designed for high-performance, as discussed later in Section 6.1.1. The main differences are in how PIT lookups are done, and whether the forwarder only does the steps necessary to process the PIT Tokens supplied by upstream and downstream forwarders, or whether it also generates and processes its own PIT Tokens.¶
Upon receiving an Interest containing a Reflexive Name Prefix (RNP) TLV a forwarder MAY check its CS for a matching Data Object. if a match is found, the corresponding Data is returned and the Reflexive Interest is considered satisfied. If no match is found, proceed with the following steps.¶
Note: Given that reflexive interests initiate exchanges constrained by the Interest Lifetime of the enclosing Interest/Data exchange, the value of caching the Data responses in forwarders is for short-term recovery from lost packets as opposed to optimizing longer term caching gain. For this reason we avoid mandating or strongly recommending the CS check for reflexive interests.¶
Look up the ingress face from the originating Interest's PIT entry, forward the Reflexive Interest on this face, with the following modifications:¶
The PIT entry for the Reflexive Interest is consumed per regular Interest/Data message forwarding requirements. The PIT entry for the originating Interest (that communicated the Reflexive Interest Name) is also consumed by a final Data message from the producer to the original consumer.¶
This section provides some pseudocode examples to further explain the details of forwarder operation. It has separate code paths for minimal forwarder operations and those needed by high-performance forwarders as is further discussed in Section 6.1.1.¶
Create PIT entry for Interest;
IF interest contains FPT
Record FPT along with ingress face to use as RPT later;
Record RNP in PIT entry;
EITHER
Create entry in an RNP look-aside table with RNP value;
OR
Generate a FPT for this PIT entry and add to Interest;
Forward Interest upstream;
¶
IF Interest contains an RPT
use RPT to lookup up PIT entry for original interest;
ELSE
Use RNP of Interest's Name TLV to lookup original Interest PIT entry;
IF PIT entry of original Interest not is found
Issue an Interest Return with "No Route" error back to the producer;
RETURN;
ELSE
Create PIT entry for Reflexive Interest;
IF RNP of Reflexive Interest matches RNP in PIT entry
BEGIN
Extract FPT from Original Interest PIT entry (if any);
Add FPT to Reflexive interest as RPT for downstream forwarder;
Optionally, generate and add FPT for the Reflexive Interest for returning Data
END;
ELSE
Process as a normal Interest;
¶
A consumer that wishes to use this scheme MUST utilize one of the reflexive naming options defined in Section 4.4 and include it in the corresponding Interest message. The Reflexive Name TLV and the full name of the requested data object (that identifies the producer) identify the common state shared by the consumer and the producer. When the producer responds by sending Interests with a Reflexive Name Prefix, the original consumer therefore has sufficient information to map these Interests to the ongoing Interest-Data exchange.¶
The exchange is finished when the producer who received the original Interest message responds with a Data message (or an Interest Return message in the case of error) answering the original Interest. After sending this Data message, the producer SHOULD destroy the corresponding shared state. It MAY decide to use a timer that will trigger a later state destruction. After receiving this Data message, the originating consumer MUST destroy the corresponding Interest-Data exchange state.¶
RICE (Remote Method Invocation in ICN) [Krol2018] used a similar Reflexive Interest Forwarding scheme that inspired the design specified in this document (similar to the original design captured in Appendix A.1).¶
In RICE, the original Interest denotes the remote method (plus potential parameters) to be invoked at a producer (server). Before committing any computing resources, the server can then request authentication credentials and (optional) parameters using reflexive Interest-Data exchanges.¶
When the server has obtained the necessary credentials and input parameters, it can decide to commit computing resources, starts the compute process, and returns a handle ("Thunk") in the final Data message to the original consumer (client).¶
The client would later request the computation results using a regular Interest-Data exchange (outside the Reflexive-Interest transaction), using the Thunk as a name for the computation result.¶
Figure 3 depicts an abstract message diagram for RICE. In addition to the 4-way Reflexive Forwarding Handshake (see Figure 2 for the details of the interaction), RICE adds another (standard) ICN Interest/Data exchange for transmitting the RMI result. The Thunk name is provided to the consumer in the D1 DATA message (answering the initial I1 Interest).¶
+-----------+ +-----------+
| Consumer | | Producer |
+-----------+ +-----------+
| |
| I1 |
|------------------------->|
| | ---------------------\
| |-| Requesting request |
| | | parameters |
| | | and credentials |
| | |--------------------|
| |
| RI1 |
|<-------------------------|
| |
| RD1 |
|------------------------->|
| | --------------------\
| |-| Commit compute |
| | | resources, |
| | | return Thunk name |
| | |-------------------|
| |
| D1 |
|<-------------------------|
| | ----------------\
| |-| Invoke Remote |
| | | Method |
| | |---------------|
| -------------------\ |
|-| After some time, | |
| | request result | |
| |------------------| |
| |
| I2 |
|------------------------->|
| |
| D2 |
|<-------------------------|
| |
Legend:
I1: Interest #1 containing the Reflexive Name Prefix TLV
D1: Data message, answering initiating I1 Interest,
returning Thunk name
RI1: Reflexive Interest issued by producer
RD1: Data message, answering RI (parameters, credentials)
I2: Regular Interest for Thunk (compute result)
D2: Data message, answering I2
In todays HTTP-based web, RESTful (Representational State Transfer) web interactions are realized by sending requests in a client/server interaction, where the requests provides the application context (or a reference to it). It has been noted in [Moiseenko2014] that corresponding requests often exceed the response messages in size, and that this raises the problems noted in Section 1.1 when attempting to map such exchanges directly to CCNx/NDN.¶
Another reason not to include all request parameters in a (possibly encrypted) Interest message is the fact that a server (that is serving thousands of clients) would be obliged to receive, possibly decrypt and parse the complete requests before being able to determine whether the requestor is authorized, whether the request can be served etc. Many non-trivial requests could thus lead to computational overload attacks.¶
Using Reflexive Interest Forwarding for RESTful Web Interactions would encode the REST request in the original request, together with a Reflexive Interest Prefix that the server could then use to get back to the client for authentication credentials and request parameters, such as cookies. The request result (response message) could either be transmitted in the Data message answering the original request, or — in case of dynamic, longer-running computations — in a seperate Interest/Data exchange, potentially leveraging the Thunk scheme described in Section 5.1.¶
Unlike approaches where clients have to signal a globally routable prefix to the network, this approach would not require the client (original consumer) to expose its identity to the network (the network only sees the temporary Reflexive Name Prefix), but it would still be possible to authenticate the client at the server.¶
An initial design for achieving RESTful ICN that employs reflexive forwarding is presented in [Kutscher2022].¶
An oft-cited use case for ICN network architectures is Internet of Things (IoT), where the sources of data are limited-resource sensor/actuators. Many approaches have been tried (e.g. [Baccelli2014], [Lindgren2016], [Gundogan2018]) with varying degrees of success in addressing the issues outlined in Section 1.1. The reflexive forwarding extension may substantially ameliorate the documented difficulties by allowing a different model for the basic interaction of sensors with the ICN network.¶
Instead of simply acting as a producer (either directly to the Internet or indirectly through the use of some form of application-layer gateway), the IoT device need only act as a consumer to initiate commuhication. When it has data to provide, it issues a "phone-home" Interest message to a pre-configured rendezvous name (e.g. an application-layer gateway or ICN Repo [Chen2015]) and provides a reflexive name prefix TLV for the data it wishes to publish. The target producer may then issue the necessary reflexive Interest message(s) to fetch the data. Once fetched, validated, and stored, the producer then responds to the original Interest message with a success indication, possibly containing a Data object if needed to allow the originating device to modify its internal state. Alternatively, the producer might choose to not respond and allow the original Interest to time out, although this is NOT RECOMMENDED except in cases where the extra message transmission bandwith is at a premium compared to the persistence of stale state in the forwarders. We note that this interaction approach mirrors the earlier efforts using Interest-Interest-Data designs.¶
Figure 4 depicts this interaction with the (optional) D1 message. See Figure 2 for the details of the general Reflexive Forwarding interaction.¶
+-----------+ +-----------+
| Consumer | | Producer |
+-----------+ +-----------+
------------\ | |
| new IoT |-| |
| data item | | |
| produced | | |
|-----------| | |
---------------\ | |
| "phone home" |-| |
| by notifying | | |
| producer | | |
|--------------| | |
| |
| I1 |
|-------------------->|
| | --------------------\
| |-| generate Interest |
| | | for IoT data |
| | |-------------------|
| |
| RI1 |
|<--------------------|
-----------------\ | |
| send requested |-| |
| data object | | |
|----------------| | |
| |
| RD1 |
|-------------------->|
| | -----------------------\
| |-| finalize interaction |
| | | with optional |
| | | Data message |
| | |----------------------|
| |
| D1 (optional) |
|<--------------------|
| |
Legend:
I1: Interest #1 containing the Reflexive Name Prefix TLV
D1: Data message (OPTIONAL), finalizing interaction
RI1: Reflexive Interest requesting the IoT data
RD1: Data message, answering RI, returning IoT data object
D1: (optional) Data answering I1
There are two approaches that the IoT device can use for its response to a reflexive Interest. It can simply construct a Data Message bound through the usual ICN hash name to the reflexive Interest name. Since the scope of any data object bound in this way is only the duration of the enclosing Interest-Data exchange (see Section 6.2) the producer would need to itself construct any persistent Data object, name it, and sign it. This is sometimes the right approach, as for some applications the identity of the originating IoT device is not important from an operational or security point of view; in contrast the identity of the gateway or Repo is what matters.¶
If alternatively, the persistent Data object should be bound from a naming and security point of view to the originating IoT device, this can be easily accomplished. Instead of directly placing the content in a Data object responding to the reflexive Interest as above, the consumer encapsulates a complete CCNx/NDN Data message (which includes the desired name of the data) in the response to the reflexive Interest message.¶
The interaction model described above brings a number potential advantages, some obvious, some less so. We enumerate a few of them as follows:¶
There are a number of important aspects to the reflexive forwarding design which affect correctness and performance of existing forwarder, consumer, and producer implementations desiring to support it. This section discusses the effect of each of these elements on the CCNx/NDN protocol architecture.¶
Reflexive Interests are designed specifically to be no different from any other Interest other than the use of the Reflexive Name Segment type as their high-order name segment. This means that a forwarder does not have to have special handling in terms of creation, and destruction, and other Interest processing needs such as timeouts, Interest satisfaction, and caching of returning data in the CS if desired. However, this design does require additional processing for Reflexive Interests not needed in the absence of reflexive forwarding. The most significant requirements are:¶
There are a few additional considerations to highlight for high-speed forwarders however; these are discussed in the following paragraphs.¶
In order to achieve forwarding scalability, high speed forwarders need to exploit available parallelism in both CPU (through multiple cores) and memory (through multiport DRAM and limiting accesses to both DRAM and L3 caches). One commonly-used technique is PIT sharding, where the forwarder-global PIT is partitoned among cores such that all processing of both Interest and Data for a given Name is directed at the same core, optimizing both L1 I-cache utilization and L2/L3/DRAM throughput and latency. This is achieved in a number of implementations (e.g. [So2013]) by hashing the fullname in the Interest or Data and using that hash to select the assigned processing core (and associated memory banks). This efficiently distributes the load and minimizes the number of memory accesses other than to bytes of the input packet.¶
Straightforward input name hashing to achieve a sharded PIT has one potentially undesirable side effect: the original Interest containing the Reflexive Name Prefix TLV and any resultant reflexive Interests issued by the producer will likely hash to different PIT shards, making any pointers that need to be traversed across shards or cross-shard updates expensive, possibly dramatically so. One could either optimize those accesses (as, for example, suggested in the discussion of Interest Lifetime in Section 6.1.2) or add special input handling of reflexive interests to steer them to the same shard as the original interest. This latter technique is what we have specified by making the use of PIT Tokens similar to those in [Shi2020] an important element of the design.¶
If and when a producer decides to fetch data from the consumer using one or more reflexive Interest-Data exchanges, the total latency for the original Interest-Data exchange is inflated, potentially by multiple RTTs. It is difficult for a consumer to predict the inflation factor when issuing the original Interest, and hence there can be a substantial hazard of that Interest lifetime expiring before completion of the full multi-way exchange. This can result in persistent failures, which is obviously highly undesirable.¶
There is a fairly straightforward technique that can be employed by forwarders to avoid these "false" Interest lifetime expirations. In the absence of a superior alternative technique, it is RECOMMENDED that all forwarders implement the following algorithm.¶
If and when a reflexive Interest arrives matching the original Interest's PIT entry, the forwarder examines the Interest lifetime of the arriving reflexive Interest. Call this value ILr. The forwarder computes MAX(ILt, (ILr * 1.5)), and replaces ILt with this value. This in effect ensures that the remaining Interest lifetime of the original Interest accounts for the additional 1.5 RTTs that may occur as a result of the reflexive Interest-Data exchange.¶
While the above approach of inflating the interest lifetime of the original Interest to accommodate the additional RTTs of reflexive Interest-Data exchanges avoids the timeout problem, this does introduce a new vulnerability that must be dealt with. A Producer, either through a bug or malicious intent, could keep an originating Interest-Data exchange alive by continuing to send reflexive Interests back to the consumer, while the consumer had no way to terminate the enclosing interaction (there is no "cancel Interest" function in either NDN nor CCNx). To eliminate this hazard, if the consumer rejects a reflexive interest with a T_RETURN_PROHIBITED error, the forwarder(s), in addition to satisfying the coresponding PIT entry, MUST also delete the RNP from the original Interest's PIT entry, thereby preventing any further reflexive Interests from reaching the consumer. This allows the enclosing Interest-Data exchange to either time out or be correctly ended with a Data message or Interest Return from the Producer.¶
As with numerous other situations where multiple Interests for the same named object arrive containing different parameters (e.g. Interest Lifetime, QoS, payload hash) the same phenomenon occurs for the reflexive Name Prefix TLV. If Interests with different reflexive name prefix TLVs collide, the forwarder MUST NOT aggregate these Interest messages and instead MUST create a separate PIT entry for each. This in turn means that a different Forward PIT-Token (FPT) will be placed in the individual forwarded Interests.¶
Forwarders supporting multi-path forwarding may of course exploit this capability for Interests with identical reflexive name prefix TLVs, like any other Interests. There are two sub-cases of multi-next hop behavior; regular multi-path (where the split traffic reconverges further upstream) and multi-destination (where it doesn’t and the Interest reaches multiple producers).¶
For multi-path, since the Interests that converge upstream carry identical reflexive Interest name TLVs, they will get aggregated. The forwarder might, just as for any other Interest, decide to either do single or multi-path forwarding of that reflexive Interest. If sent multi-path in parallel, these also will reconverge on the inverse path and get aggregated. The inclusion of the Forward PIT-Token (FPT) in the forwarded Interest is unaffected by multi-path since it is only used on returning Data messages or Reflexive Interests to access the correct PIT entry.¶
For multi-destination, reflexive Interests might get issued by multiple producers, but they will carry the same reflexive name prefix and hence be forwarded using the ingress face of the same original Interest PIT entry until reaching the join point, at which they will get aggregated and thus handled identically to any other Interest(s) subject to aggregation.¶
The Data objects returned to the producer in response to a reflexive Interest are normal CCNx/NDN data objects. The object returned in response to a reflexive Interest is named with its hash as the trailing segment of the reflexive Interest name, and hence the scope of the object is under most circumstances meaningful only for the duration of the enclosing Interest-Data interaction. This property is ideal for naming and securing data that is "part of" the enclosing interaction — things like method arguments, authenticators, and key exchange parameters, but not for the creation and naming of objects intended to survive outside the current interaction's scope (c.f. Section 5.3, which describes how to provide globally-named objects using encapsulation). In general, the consumer should use the following guidelines in creating Data messages in response to reflexive Interest messages from the producer.¶
A consumer may wish to stop receiving reflxive Interests due to possible erors or malicious behavior on the part of the producer. Therefore, if the consumer receives an unwanted reflexive Interest, it SHOULD reject that interest with a T_RETURN_PROHIBITED error (See section 10.3.6 of [RFC8609] ). This will provoke the forwarders to prevent further reflexive Interests from reaching the consumer, as described above in Section 6.1.2, Paragraph 5.¶
The reflexive named objects provide "local", temporary names that are only defined for one specific interaction between a consumer and a producer. Corresponding Data objects MUST NOT be shared among multiple consumers (violating this would require special gyrations by the producer since the reflexive Name utilizes per-consumer/per-interaction random values). A producer MUST NOT issue an Interest message for any reflexive name after it has sent the final Data message answering the original Interest.¶
Forwarders MAY still cache reflexive Data objects for retransmissions within a transactions, but they MUST invalidate or remove them from the content store when they forward the final Data message answering the original Interest.¶
Producers receiving an Interest with a Reflexive Name Segment, MAY decide to issue Reflexive Interests for the corresponding Data objects. All Reflexive Interest messages that a producer sends MUST be sent over the face that the original Interest was received on.¶
This extension represents a substantial enhancement to the CCNx/NDN protocol architecture and hence has important forward and backward compatibility consequences. The most important of these is that correct operation of the scheme requires an unbroken chain of forwarders between the consumer and the desired producer that support the Reflexive Name Prefix TLV, the Forward and Backward PIT-Token TLVs and the corresponding forwarder capabilities specified in Section 4.6. When this invariant is not satisfied, some means is necessary to detect and hopefully recover from the error. We have identified three possible approaches to handling the lack of universal deployment of forwarders supporting the reflexive forwarding scheme.¶
The first approach simply lets the producer detect the error by getting a "no route to destination" error when trying to send an Interest to a reflexive name. This will catch the error, but only after forwarding resources are tied up and the producer has done some work on the original Interest message. Further, the producer would need a bit of smarts to determine that this is a permanent error and not a transient to be retried. In order for the consumer to attempt recovery, there might be a need for some explicit error returned for the original interest to tell the consumer what the likely problem is. This approach does not enable an obvious recovery path for the consumer either, since if the producer cannot easily detect the error, the consumer has no way to know if a retry has any chance of succeeding.¶
A second approach is to bump the CCNx/NDN protocol version to explicitly indicate the lack of compatability. Such Interests would be rejected by forwarders not supporting these protocol extensions. A consumer wishing to use the Reflexive Name Prefix TLV together with Reverse PIT-Tokens, would use the higher protocol version on those Interest messages (but could of course continue to use the current version number on other Interest messages). This is a big hammer, but may be called for in this situation because:¶
A third option is to, as a precondition to utilizing the protocol in a deployment, create and deploy a neighbor capability exchange protocol which will tell a downstream forwarder if the upstream can handle the new TLV. This might avoid the large hammer of updating the protocol version, but of course this puts a pretty strong dependency on somebody actually designing and publishing such a protocol! On the other hand, a neighbor capability exchange protocol for CCNx/NDN would have a number of other substantial benefits, which makes it worth seriously considering anyway.¶
For CCNx[RFC8609] this specification defines one new Name Segment TLV type, and two hop-by-hop option TLVs.¶
| Abbrev | Name | Description |
|---|---|---|
| T_REFLEXIVE_NAME | Reflexive Name Segment | Name segment to use as name prefix in Reflexive Interest Messages |
| Abbrev | Name | Description |
|---|---|---|
| T_FPT | Forward PIT TOKEN | 1-32 byte value chosen by the forwarder for a PIT entry communicated upstream toward a producer |
| T_RPT | Reverse PIT TOKEN | 1-32 byte value placed in either a Data packet or a Reflexive Interest packet by a producer or forwarder to allow the downstream forwarder to access the PIT entry identified by a received forward PIT Token (FPT) |
These are proposed assignments based on [NDNTLV]. Suggestions from the NDN team would be greatly appreciated.¶
The NDN Name component TLVs needs to have a new component type added with type RNP (for reflexive name prefix). We suggest something like: TBD¶
The Reflexive Name Prefix TLV needs to be added to the NDN Interest packet format. We suggest using [RFC4122], hence something like:¶
| RNP ::= | RNP-TYPE | TLV-LENGTH(=16) BYTE8) |
The current NDN Link Protocol current has an assignment for the PIT Token mechanism pioneered in [Shi2020]. That approach only needed a single field, since PIT Tokens are only used to express one "direction" — for consumer-to-producer Interests and producer-to-consumer Data messages. This specification employs PIT Tokens not only on enclosing Interest-Data exchanges, but also on Reflexive Interests to locate the PIT entry of an enclosing Interest on reception by a forwarder. Therefore we suggest that the existing NDNLPv2 assignment of¶
| LpHeaderField | PitToken |
| PitToken | PIT-TOKEN-TYPE TLV-LENGTH 1*32OCTET> |
be renamed to indicate its use in the forward direction of consumer to producer Interests and returning Data, and a second allocation be done for a Reverse PIT Token specifically for inclusion in Reflexive Interests as follows:¶
| LpHeaderField | ReversePitToken |
| ReversePitToken | PIT-TOKEN-TYPE TLV-LENGTH 1*32OCTET> |
Please add the T_REFLEXIVE_NAME segment TLV type to the CCNx Name Segment Types TLV types registry of [RFC8609] (see https://www.iana.org/assignments/ccnx/ccnx.xhtml#ccnx-name-segment-types), with Length 16 bytes and type of 128 bit random value.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_REFLEXIVE_NAME | 16 |
+---------------+---------------+---------------+---------------+
| |
| 128 bit value randomly assigned by consumer |
+-------------------------------+-------------------------------+
Please add the T_FPT and T_RPT TLVs to the CCNx Hop-by-Hop Type Registry of [RFC8609] (see https://www.iana.org/assignments/ccnx/ccnx.xhtml#ccnx-hop-by-hop-types), with Length 1-32 bytes and type of random value.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_FPT | 1-32 |
+---------------+---------------+---------------+---------------+
| |
| 1-32 byte value randomly assigned by forwarder |
+-------------------------------+-------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_RPT | 1-32 |
+---------------+---------------+---------------+---------------+
| |
| 1-32 byte value randomly assigned by forwarder |
+-------------------------------+-------------------------------+
One of the major motivations for the reflexive forwarding extension specified in this document is in fact to enable better security and privacy characteristics for ICN networks. The main considerations are presented in Section 1, but we briefly recapitulate them here:¶
As a major protocol extension however, this design brings its own potential security issues, which are discussed in the following subsections.¶
Reflexive Interest names are constructed using 128-bit random numbers. This is intended to ensure an off-path attacker cannot easily manufacture a matching reflexive Interest and either masquerade as the producer, or mount a denial of service attack on the consumer. It also limits tracking through the linkability of Interests containing a re-used random value.¶
Therefore consumers MUST utilize a robust means of generating these random values, and it is RECOMMENDED that the [RFC4122] format be used, with a pseudo-random number generator (PRNG) approved for use with cryptographic protocols.¶
Normal Interest message processing in CCNx and NDN needs to consider effect of various resource depletion attacks on the PIT, particularly in the form of Interest flooding attacks (see [Gasti2012] for a good overview of DoS and DDoS mitigation on ICN networks). Interest messages utilizing this reflexive forwarding extension can place additional resource pressure on the PIT.¶
While this does not represent a new DoS/DDoS attack vector, the ability of a malicious consumer to utilize this extension in an attack does represent an increased risk of resource depletion, especially if such Interests are given unfair access to PIT and FIB resources. Implementers SHOULD therefore protect PIT and FIB resources by weighing requests for reflexive forwarding resources appropriately relative to other Interests.¶
By including PIT Tokens in the CCNx or NDN protocol, an attacker has the opportunity to manipulate these values by either replacement or elision. So far we do not have enough experimental data nor formal security analysis to assess whether useful attacks against the protocol via the PIT Tokens can be mounted. The fields are carried differently in CCNx and NDN, but in both cases they are outside the cryptographic integrity envelope and not encrypted for confidentiality as part of the base protocols.¶
For both cases however, the potential vulnerabilities can be foiled, at least for point-to-point communication over an L2 hop, by employing either link-layer encryption (in the case of CCNx), or by encrypting the NDNLPv2 protocol, which carries these fields for NDN.¶
ICN architectures like CCNx and NDN provide a rich tapestry of interesting privacy issues, which have been extensively explored in the research literature. The fundamental tradeoffs for privacy concern the risk of exposing the names of information objects to the forwarding elements of the network, which is a necessary property of any name-based routing and forwarding design. Numerous approaches have been explored with varying degrees of success, such as onion routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), and name obfuscation ([Arianfar2011]) among others.¶
Reflexive forwarding does not change the overall landscape of privacy tradeoffs, nor seem to introduce additional hazards. In fact, the privacy exposures are confined to the inverse path of forwarders from the producer to the consumer, through which the original Interest forwarding may have already exposed names on path. Similar name privacy techniques to those cited above may be equally applied to the names in reflexive Interests.¶
While the individual reflexive Interest-Data exchanges have similar properties to those in any NDN or CCNx exchange, the target usages by applications may have interaction patterns that are subject to relatively straightforward fingerprinting by adversaries. For example, a particular remote method invocation may fingerprint simply through the count of arguments fetched by the producer and their sizes. The attacker must however be on path, which somewhat ameliorates the exposure hazards.¶
During development of this specification, a number of alternative designs were considered and at least partially documented. This appendix explains them for historical purposes, and explains why these were considered inferior to the design we settled on to carry forward.¶
The original draft specification employed the use of dynamically-created FIB entries for forwarding Reflexive Interests. In this approach, at each forwarder along the inverse path from producer to consumer, a FIB entry must be present that matches this name via Longest Name Prefix Match (LNPM), so that when the reflexive interest arrives, the forwarder can forward it downstream toward the originating consumer. This FIB entry would point directly to the incoming interface on which the corresponding original Interest arrived. The FIB entry needs to be created as part of the forwarding of the original Interest so that it is available in time to catch any reflexive Interest issued by the producer. It would usually make sense to destroy this FIB entry when the Data message satisfying the original Interest arrives since this avoids any dangling stale state. Given the design details discussed below, stale FIB state would not represent a correctness hazard and hence could be done lazily if desired in an implementation.¶
In this scheme, the forwarder operates as follows:¶
There are a number of additional considerations with this design that need to be dealt with.¶
When processing an Interest containing the reflexive name TLV and creating the necessary FIB entry, the forwarder also creates a back pointer from that FIB entry to the PIT entry for the Interest message that created it. This PIT entry contains the current value of the remaining Interest lifetime or alternatively a value from which the remaining Interest lifetime can be easily computed. Call this value ILt.¶
The forwarder input thread could key off the high-order name segment type (one byte) and if reflexive, do a reflexive FIB lookup instead of a full name hash. The reflexive FIB entry would contain the shard identity of the matching Interest (concretely, the core id servicing the shard) and steer the reflexive interest there. The reflexive name prefix FIB lookup would have to be competitive performance-wise with a full-name hash for this to win, however. Experimentation is needed to further evaluate such implementation tradeoffs for input packet load balancing in high-speed forwarders.¶
The FIB is a performance-critical data structure in any forwarder, as it needs to support relatively expensive longest name prefix match (LNPM) lookup algorithms. A number of well-known FIB data structures are heavily optimized for read access, since for normal Interest message processing the FIB changes slowly — only after topological changes or routing protocol updates. Support for reflexive names using dynamic FIB entries changes this, as FIB entries would be created and destroyed rapidly as Interest messages containing reflexive name TLVs are processed and the corresponding Data messages come back.¶
While it may be feasible, especially in low-end forwarders handling a low packet forwarding rate to ignore this problem, for high-speed forwarders there are a number of hazards, including:¶
There are any number of alternative FIB implementations that can work adequately. The most straightforward would be to simply implement a "special" FIB for just reflexive name lookups. This is feasible because reflexive names deterministically contain the distinguished high-order name segment type of T_REFLEXIVE_NAME, whose content is a 64-bit value that can be easily hashed to a FIB entry directly, avoiding the more expensive LNPM lookup. Inserts and deletes then devolve to the well-understood problem of hash table maintenance.¶
If Interest lifetime handling is implemented naively, it may run afoul of a sharded PIT forwarder implementation, since the PIT entry for the reflexive Interest and the PIT entry for the original Interest may be in different shards. Therefore, if the update is done cross-shard on each reflexive Interest arrival, performance may suffer, perhaps dramatically. Instead, the following approach to updating the Interest lifetime after computing the new value is would be needed by this FIB-based design for sharded-PIT forwarders.¶
When creating the reflexive FIB entry as above in Appendix A.1.1, copy the remaining Interest lifetime from the PIT entry. Do the PIT update if and only if this value is about to expire, thus paying the cross-shard update cost only if the original Interest is about to expire. A further optimization at the cost of modest extra complexity is to instead queue the update to the core holding the shard of the original PIT entry rather than doing the update directly. If the PIT entry expires or is satisfied, instead of removing it the associated core checks the update queue and does the necessary update.¶
We also considered leveraging Path Steering [I-D.oran-icnrg-pathsteering] Path Labels that inform the forwarder at each hop which outgoing face to use for for forwarding the Reflexive Interest. In this approach, the producer, when creating and issuing the Reflexive Interest with the Reflexive Name Prefix includes a Path Label to strictly steer the forwarding at all hops from the producer to the consumer (strict mode Path Steering). This means, the Reflexive Interest carries the Reflexive Name Prefix, but forwarders do not apply LNPM or any other outgoing face selection based on the name. It also eliminates the need for dynamic FIB entries as discussed above in Appendix A.1. Instead the forwarding is strictly steered by the Path Label using regular Path Steering semantics.¶
The message flow using Path Steering would look like the following:¶
+-----------+ +-----------+ +-----------+
| Consumer | | Forwarder | | Producer |
+-----------+ +-----------+ +-----------+
| -----------------------------\ | |
|-| Create I1 with additional, | | |
| | emptyPath Label | | |
| | data structure | | |
| | for reverse discovery | | |
| |----------------------------| | |
| | |
| I1 with Path Label | |
| and RNP TLV | |
|----------------------------------->| |
| | -----------------\ |
| |-| Add path label | |
| | | for adjacency | |
| | | to Consumer | |
| | |----------------| |
| | |
| | I1 |
| |-------------------------->|
| | ------------------\ |
| | | Create RI state |-|
| | |-----------------| |
| | |
| | RI with RNP |
| | and path label |
| | (strict mode) |
| |<--------------------------|
| --------------------------\ | |
| | perform path label |-| |
| | switching (no FIB info) | | |
| |-------------------------| | |
| | |
| RI with RNP | |
|<-----------------------------------| |
| | |
| D2 (RNP) | |
|----------------------------------->| |
| | --------------------\ |
| |-| regular PIT-based | |
| | | forwarding | |
| | |-------------------| |
| | |
| | D2 (RNP) |
| |-------------------------->|
| | -----------------\ |
| | | all parameters |-|
| | | received, | |
| | | answer orig. | |
| | | I1 Interest | |
| | |----------------| |
| | |
| | D1 |
| |<--------------------------|
| --------------------\ | |
| | regular PIT-based |-| |
| | forwarding | | |
| |-------------------| | |
| | |
| D1 | |
|<-----------------------------------| |
| | |
Legend:
I1: Interest #1 containing the Reflexive Name Prefix TLV
RI: Reflexive Interest with Reflexive Name Prefix Segment
RNP: Reflexive Name Prefix
D1: Data message, answering initiating I1 Interest
D2: Data message, answering RI
Path Steering uses Path Label data structures on the downstream path (from producer to consumer) to discover and collect hop-by-hop forwarding information so that consumers can then specify selected paths for subsequent Interests. Reflexive Forwarding would use the same data structure, but for "reverse discovery", i.e., in the upstream direction from consumer to producer.¶
From an operational perspective the path-steering approach does not exhibit good properties with respect to backward compatibility. Without a complete path of forwarders between consumer and producer that support path steering, reflexive interests cannot reach the intended consumer. While we might envision a way to steer a subsequent Interest onto a working path as proposed in [I-D.oran-icnrg-pathsteering], there is no capability to force Interest routing away from an otherwise working path not supporting the reflexive name TLV.¶