Network Systems Research and Design

4 Shady Hill Square Cambridge MA 02138 USA daveoran@orandom.net

HKUST(GZ)

Guangzhou China ietf@dkutscher.net https://dirk-kutscher.info

National Institute of Information and Communications Technology

4-2-1 Nukui-Kitamachi Koganei Tokyo 184-8795 Japan asaeda@nict.go.jp

University of Kentucky

289 Rose Street Lexington KY 40506-0495 USA calvert@netlab.uky.edu

ICNRG ICN Information-centric Networking forwarding 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.

Status of This Memo 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 . 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 17 September 2025.

Copyright Notice Copyright (c) 2025 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 () 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.

Table of Contents

• .  Introduction
  • .  Problems with pushing data
  • .  Problems with utilizing independent exchanges
• .  Terminology
  • .  Definitions
• .  Overview of the Reflexive Forwarding design
• .  Detailed Specification of Reflexive Forwarding
  • .  Generic Forwarder Design
  • .  Interaction Flow for Reflexive Forwarding: An Example
  • .  Naming of Reflexive Interests
    • .  How to represent/encode the Reflexive Name Prefix in the Trigger Interest
    • .  Naming of multiple Reflexive Interests
    • .  Recursive Reflexive Interest invocation
  • .  Consumer Operation
  • .  Producer Operation
  • .  Forwarder Operation
    • .  Forwarder algorithms in pseudocode
      • .  Processing of a Trigger Interest containing a Reflexive Name Prefix
      • .  Processing of a Reflexive Interest
  • .  State coupling between producer and consumer
• .  Use cases for Reflexive Interests
  • .  Achieving Remote Method Invocation with Reflexive Interests
  • .  RESTful Web Interactions
  • .  Achieving simple data pull from consumers with reflexive Interests
• .  Implementation Considerations
  • .  Forwarder implementation considerations
    • .  Interactions with Input Processing of Interest and Data packets
    • .  Interactions with Interest Lifetime
    • .  Interactions with Interest aggregation and multi-path/multi-destination forwarding
  • .  Consumer Implementation Considerations
    • .  Data objects returned by the consumer to reflexive name Interests arriving from a producer
    • .  Terminating unwanted reflexive Interest exchanges
    • .  Interactions with caching
  • .  Producer Implementation Considerations
• .  Operational Considerations
• .  Mapping to CCNx and NDN packet encodings
  • .  Packet encoding for CCNx
  • .  Packet encoding for NDN
    • .  Reflexive Name Component Type
    • .  Reflexive Name Prefix TLV
• .  IANA Considerations
  • .  CCNx Name Segment Type Registry
  • .  CCNx Validation-Dependent Data Types Registry
• . Security Considerations
  • .  Collisions of reflexive Interest names
  • .  Additional resource pressure on PIT and FIB
  • .  Privacy Considerations
• . Normative References
• . Informative References
• .  Alternative Designs Considered
  • .  Handling reflexive interests using dynamic FIB entries
    • .  Design complexities and performance issues with FIB-based design
    • .  Interactions between FIB-based design and Interest Lifetime
  • .  Reflexive forwarding using Path Steering
  • .  Multiple RNPs in a Trigger Interest
• .  NDN Implementation
  • .  Reflexive Name Segment
  • .  Processing Reflexive Interests>
• Authors' Addresses

Introduction Current ICN 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. 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.

Remote Method Invocation (RMI, aka RPC):

When invoking a remote method, it is common for the method to require arguments supplied by the caller. In conventional TCP/IP style protocols like CORBA or HTTP "Post", these are pushed to the server as part of the message or messages that comprise the request. In ICN-style protocols there is an unattractive choice between inflating the request initiation with pushed arguments, or arranging to have one or more independent request/response pairs in the opposite direction for the server to fetch the arguments. Both of these approaches have substantial disadvantages. Recently, a viable alternative emerged through the work on RICE which pioneered the main design elements proposed in this specification.

Phone-Home scenario:

Applications in sensing, Internet-of-things (IoT) and other types where data is produced unpredictably and needs to be pushed somewhere create a conundrum for the pure pull-based architectures considered here. If instead one eschews relaxing the size asymmetry between requests and responses, some additional protocol machinery is needed. Earlier efforts in the ICN community have recognized this issue and designed methods to provoke a cooperating element to issue a request to return the data the originator desires to push, essentially "phoning home" to get the responder to fetch the data. One that has been explored to some extent is the Interest-Interest-Data exchange , where an Interest is sent containing the desired request as encapsulated data. CCNx-1.0 Bidirectional Streams are also based on a scheme where an Interest is used to signal a name prefix that a consumer has registered for receiving Interests from a peer in a bidirectional streaming session.

Peer state synchronization:

A large class of applications, typified by those built on top of reliable order-preserving transport protocols, require initial state synchronization between the peers. This is accomplished with a three-way (or longer) handshake, since employing a two-way handshake as provided in the existing NDN and CCNx protocols exposes a number of well-known hazards, such as half-open connections. When attempted for security-related operations such as key exchange, additional hazards such as man-in-the-middle attacks become trivial to mount. Existing alternatives, similar to those used in the two examples above, instead utilize either overlapping Interest-Data exchanges in opposite directions (resulting in a four-way handshake) or by adding initialization data to the initial request and employing an Interest-Interest-Data protocol extension as noted in the Phone-home scenarios above.

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.

Problems with pushing data There are two substantial problems with the simple approach of just allowing arbitrary amounts of data to be included with requests. These are:

1. In ICN protocols such as NDN and CCNx, Interest messages are intended to be small, on the order the size of a TCP ACK, as opposed to the size of a TCP data segment. This is because the hop-by-hop congestion control and forwarder state management requires Interest messages to be buffered in expectation of returning data, and possibly retransmitted hop-by-hop as opposed to end-to-end. In addition, the need to create and manage state on a per-Interest basis is substantially complicated if requests in Interest messages are larger than a Path MTU (PMTU) and need to be fragmented hop-by-hop.
2. If the payload data of a request is used for invoking a computation (as in the RMI case described above) then substantial bandwidth can be wasted if the computation is either refused or abandoned for any number of reasons, including the requestor failing an authorization check, or the responder not having sufficient resources to execute the associated computation.

These problems also exist in pure datagram transport protocols such as those used for legacy RMI applications like NFS. 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.

Problems with utilizing independent exchanges 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:

1. The originating consumer needs to have a routable name prefix that can be used for the exchange. This means the consumer must arrange to have its name prefix propagated in the ICN routing system with sufficient reach that the producer issuing the interest can be assured it is routed appropriately. While some consumers are generally online and act as application servers, justifying the maintenance of this routing information, many do not. Further, in mobile environments, a pure consumer that does not need to have a routable name prefix can benefit from the inherent consumer mobility support in the CCNx and NDN protocols. By requiring a routable name prefix, extra mobile routing machinery is needed, such as that proposed in KITE or MAPME.
2. The consumer name prefix in item above must be communicated to the producer as a payload, name suffix, or other field of the initiating Interest message. Since this name in its entirety is chosen by the consumer, it is highly problematic from a security standpoint, as it can recruit the producer to mount a reflection attack against the consumer's chosen victim.
3. The correlation between the exchanges in opposite directions must be maintained by both the consumer and the producer as independent state, as opposed to being architecturally tied together as would be the case with a conventional 3-way handshake finite state machine. While this can of course be accomplished with care by both parties, experience has shown that it is error prone (for example see the checkered history of interactions between the SIP and SDP Offer-Answer) protocols. When employed as the wrapper for a key management protocol such as with TLS state management errors can be catastrophic for security.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Definitions For general ICN-related terms, we adopt the terms defined in . For CCNx-specific terms, we use the terms defined in and . This specification defines the following additional terms:

Reflexive Interest (RI)

An interest message sent from a producer back towards a consumer to fetch data needed to satisfy the original interest.

Reflexive Data (RD)

a Data message rteurned to a producer in response to a Reflexive Interest sent from the producer to the consumer

Trigger Interest (TI)

An interest message sent from a consumer to a producer to potentially trigger one or more Reflexive Interests sent by the producer back to the consumer.

Trigger Data (TD)

The data message returned by the producer in response to a Trigger Interest sent by the consumer, which completes a possibly multi-message Reflexive Forwarding exchange

Reflexive Name Segment

A typed name segment which, when present as the initial (highest-order) name segment identifies an Interest as being a Reflexive Interest instead of a normal Interest.

Reflexive Name Prefix (RNP)

A value carried in an Interest message to indicate to a producer that it may fetch data from the sending consumer by issuing one or more corresponding Reflexive Interests. It consists of a Name prefix whose high-order (i.e. first) name segment is a Reflexive Name Segment as defined above. It acts as a nonce, distinguishing Reflexive Interests related to a specific Trigger Interest from others in the same space-time vicinity of the network.

Overview of the Reflexive Forwarding design This specification defines a Reflexive Forwarding extension to CCNx and NDN that avoids the problems enumerated in Sections and . It straightforwardly exploits the hop-by-hop state and path symmetry properties of the current protocols. 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. 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 reverse 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 forwarder structure +-----------------------------------------------------------------+ | 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 reverse path to the unique consumer who issued the original Interest. ( 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 from the producer back to the consumer. In order to achieve this Reflexive Interest forwarding on the reverse path recorded in the PIT of each forwarder, we need a few critical design elements:

1. The Reflexive Interest needs to have a Name. This name is what the originating consumer will use to match against the Data object (or multiple Data objects — more on this later) that the producer may request by issuing the Reflexive Interest. This cannot be just any name, but needs to essentially name the state already recorded in the PIT and not allow the consumer to manufacture an arbitrary name and mount a reflection attack as pointed out in .
2. Each forwarder along the reverse path from producer to consumer must be able to forward the Reflexive Interest towards the direction of the Consumer without relying on global routing information, as the Reflexive Name Prefixes are only valid while the originating Interest/Data exchange state is present at the forwarders. Essential to this operation is the ability to access state created by the PIT entry associated with the Trigger Interest message since that is the state necessary to identify the ingress face of the Trigger Interest. This is the unique output face (modulo interest aggregation) over which the Reflexive Interest needs to be forwarded. The Name assigned by the consumer for Reflexive Name Prefix in theory is adequate to the task, but entails a potentially expensive and complicated lookup procedure.
3. There has to be coupling of the state between the originating Interest-Data exchange and the enclosed Reflexive Interest-Data exchange at both the consumer and the producer. In our design, this is accomplished by the way Reflexive Interest names are chosen.

Detailed Specification of Reflexive Forwarding The following sections provide the normative details on each of these design elements.

Generic Forwarder Design The following describes the operation of a CCNx or NDN forwarder enhanced to accommodate reflexive forwarding via Trigger Interests, Reflexive Interests, Reflexive Data and Trigger Data messages. This description likely adequate for most implementation approaches. However, there are possible performance bottlenecks for reflexive forwarding that employ highly parallel forwarding schemes using multi-core server systems. Such systems may use PIT Sharding across cores, and therefore benefit from additional optional protocol enhancements, such as the "PIT Token" protocol elements pioneered in . Alternatively, techniques such as those employed by the Cefore forwarder from NICT may be employed.

Interaction Flow for Reflexive Forwarding: An Example Based on the implementation approach in Cefore , an example of the overall interaction flow for reflexive forwarding for CCNx is presented below and illustrated in . Other implementation approaches are of course equally valid as long as the protocol semantics are maintained. Forwarder operation for CCNx is enhanced in the following respects when supporting Reflexive Interests.

• When a forwarder receives a Trigger Interest (TI) that will be sent toward the producer, in addition to the normal PIT entry created on receipt of a new Interest message, the forwarder creates a "template" PIT entry (t-PIT) for the possible later receipt of a Reflexive Interest
• This template PIT entry has the Reflexive Name Prefix from the Trigger Interest as its Name field, and the incoming face list of the trigger interest as the potential output face(s) for any subsequent Reflexive Interest received.
• On receipt of a Reflexive Interest matching the Reflexive Name Prefix of a template PIT entry, a full PIT entry is created from the template entry and normal PIT processing ensues (e.g. also including recording the incoming face(s) of the Reflexive Interest).
• The Reflexive Interest is forwarded over the recorded outgoing face(s) from the PIT as opposed to examining the FIB to find an appropriate next hop for that Reflexive Interest.

Overview of Reflexive Forwarding in CCNx +-----------+ +-----------+ +-----------+ | Consumer | | Forwarder | | Producer | +-----------+ +-----------+ +-----------+ | | | | TI | | |---------------------->| | | ------------------\ | | | | Record fullname |-| | | | in PIT(TI) | | | | |-----------------| | | | | | | | TI1 | | |------------------------->| | | -------------------\ | | |-| Create t-PIT(RI) | | | | | from PIT(TI) | | | | |------------------| | | | | ------------\ | | |-| Check | | | | | prefix, | | | | | creating | | | | | Reflexive | | | | | Interest | | | | | state | | | | |-----------| | | | | | RI | | |<-------------------------| | | ------------------\ | | |-| match t-PIT(RI) | | | | | create PIT(RI), | | | | | forward RI | | | | |-----------------| | | | | | RI | | |<----------------------| | | | | | RD obj | | |---------------------->| | | | -------------------\ | | |-| satisfy PIT(RI), | | | | | forward RD via | | | | | PIT(RI) | | | | |------------------| | | | | | | RD | | |------------------------->| | | | -------------\ | | |-| all | | | | | parameters | | | | | received, | | | | | answer TI | | | | |------------| | | | | | TD object | | |<-------------------------| | | -------------------\ | | |-| satisfy PIT(TI), | | | | | forward TD | | | | |------------------| | | | | | TD | | |<----------------------| | |---------------------\ | | || remove PIT(TI) and |-| | || t-PIT(RI) | | | ||--------------------| | | | | | Legend: TI: Trigger Interest containing Reflexive Name Prefix RI: Reflexive Interest with Reflexive Name Prefix RNP: Reflexive Name Prefix t-PIT: A template PIT entry created from the TI PIT entry RD: Data message, answering RI TD: Data message, answering TI

There are a number of reasons to maintain both a template RI-PIT and (possibly) multiple RI-PIT entries for reflexive forwarding. Among them are:

• There may be multiple chunks requested using a sequence of Reflexive Interests.
• Multiple Reflexive Interests may be issued by the producer to fetch arguments in the remote invocation use case described in .

This is further discussed in on how to handle multiple reflexive interests sent in the context of a single Trigger Interest / Trigger Data interaction.

Naming of Reflexive Interests A consumer may have one or more objects for the producer to fetch, and therefore needs to communicate enough information in its initial Trigger 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) 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 (or inferred) via the Reflexive Name Prefix (RNP) in the Trigger Interest message. We define a new name segment type, the Reflexive Name Segment which holds the Reflexive Name Prefix in Reflexive Interest and Reflexive Data messages. The Reflexive Name Segment MUST be the first (i.e. high order) name segment of any Reflexive Interest issued by a producer. In CCNx, the Reflexive Name Segment type value will be registered in the IANA registry for when approved (see ). The value of any Reflexive Name Prefix is assigned by the consumer. The selected value MUST provide sufficient entropy to uniquely identify the issuing consumer for the duration of any outstanding Trigger Interest-Trigger Data exchange. Any scheme that provides sufficient randomness and entropy can suffice, but the consumer SHOULD choose a different random value for each Reflexive Name Prefix it constructs because:

1. A collision of Reflexive Name Prefixes at any of the intermediate forwarders would result in the same mutability problems generated by poor name selection in other contexts, such as mis-routing of Reflexive Interests; and
2. Re-use of the same reflexive interest name over multiple interactions might reveal linkability information that could be used by surveillance adversaries for tracking purposes.

A UUID, which is a randomly generated 128 bit quantity specified in can be used for the value of the Reflexive Name Segment. This initial name segment in the Reflexive Interest is prepended to any object names the consumer wishes the producer to fetch. More than one object may be needed by the producer for the current Interest-Data interaction. There are three cases to consider:

1. The reflexive fullname of a single object to fetch.
2. A single reflexive name prefix out of which the producer can (by application-specific means) construct a number of fullnames of the objects it may want to fetch.
3. The reflexive fullname of a FLIC Manifest enumerating the suffixes that may be used by the producer to construct the necessary names. We distinguish this from the single object fetch in case above because the use of a Manifest implies multiple Reflexive Interest/Data exchanges with the consumer.

A producer, upon receiving a Trigger Interest with a Reflexive Name Prefix, 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.

How to represent/encode the Reflexive Name Prefix in the Trigger Interest While the design is firm on how to represent the Reflexive Name Prefix (RNP) in Reflexive Interests (and, by extension in the corresponding Reflexive Data response) by using a Reflexive Name Segment as the highedt-order name segment of the Reflexive Interest, we have studied two reasonable approaches to how the RNP should be represented in Trigger Interests. These are:

1. as a Reflexive Name Segment of the Trigger Interest Name. This is the same registered name segment type as used for Reflexive Interests, but present as the last (i.e. trailing) name segment.
2. as a separately defined and IANA registered message-level TLV in the Trigger Interest.

There are tradeoffs in the choice of encoding. We outline the ones we are aware of below. Further experimentation with implementing the protocol and using it will inform a final decision on which approach to codify.

• Approach likely limits the ability to make use of caching for Trigger Data responses. This is because no two TIs from different consumers would carry the same name - at least within the lifetime of the TI-TD pair. It is however unclear whether that is a significant problem. In many, perhaps most, applications where RI is needed (e.g., remote method invocation, access to paywalled content) the returned Trigger Data is unlikely to be usefully cacheable (e.g., because it is encrypted with a subscriber-specific key/watermark).
• Approach requires a separate check to avoid incorrect interest aggregation, since trigger interests with different RNP TLVs should not be aggregated. Approach “just works” since the names are different and won’t be aggregated. However, this may be of little consequence since interest aggregation checks already require a forwarder to examine other optional Interest message fields such as Interest Payload. See Section 2.4.2 for more information.
• Approach doesn’t have to echo back the value in the finishing Trigger Data response, making it smaller. That might matter a bit in the sensor phone-home use case (), but it’s likely not a big deal given that RNPs allocated according to the UUID scheme are only 128 bits and hence unlikely to make that much of a difference.

Naming of multiple Reflexive Interests As noted in the general description of , a given use case may require multiple RI/RD exchanges within the scope of a single TI/TD exchange. One example is an object to be returned via reflexive data that requires multiple chunks. Following are some examples of the names without/with chunk information enclosed in TI and RIs:

Responses without/with multiple chunks using Reflexive Interests TI: ccnx:/Name=example.com/RNP=RNP1 RI: ccnx:/RNP=RNP1 TI: ccnx:/Name=example.com/RNP=RNP1 RI_1: ccnx:/RNP=RNP1/Chunk=0 --- RI_2: ccnx:/RNP=RNP1/Chunk=1 EndChunkNumber=2 RI_3: ccnx:/RNP=RNP1/Chunk=2 EndChunkNumber=2

The RI-PIT entry MAY include a chunk number to the RNP, while a template RI-PIT entry does not. Like an ordinary PIT entry, RI-PIT is erased whenever the corresponding RD is forwarded through the downstream face, while a template RI-PIT entry is erased when the TI-PIT lifetime expires or Trigger Data (TD) is received and forwarded at the forwarder. A second common use case is argument fetch for remote method invocation.

Recursive Reflexive Interest invocation There is no explicit prohibition in this version of the specification to use a Reflexive Interest as a Trigger Interest to recursively create a multi-way handshake protocol. It is not yet clear if there are any compelling use cases for this or if there are undiscovered hazards by permitting it. However, we are confident that we do have sufficient protections against resource depletion attacks that could be attempted through this technique.

Signed RNP Signed RNP validates that it is the name signed by the consumer's secret key. It does not only guarantee the uniqueness of RNP, but also provides the secure schema as it can be validated whether the RNP is securely created by the legitimate consumer. More detail explanation will be TODO.

-->

Consumer Operation A consumer wishing to employ Reflexive Forwarding MUST include a Reflexive Name Prefix (RNP) in the Interest, which causes it to be treated as a Trigger Interest by Forwarders and Producers. The producer can subsequently craft Reflexive Interests with names using the RNP as a Reflexive Name Segment. Upon receiving a Reflexive Interest (e.g. RI in ) from a producer in response to the Interest whose first name segment is the RNP supplied earlier, the consumer SHOULD perform a full name match against the object specified in the RI, and return that object to the producer in a conventional Data message, (e.g. RD in ).

Producer Operation A producer that has received an Trigger Interest with a Reflexive Name Prefix (RNP) keeps the supplied RNP from the Trigger 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 in the reflexive Interest.

Forwarder Operation The forwarder performs the following operations.

1. Upon receiving an Interest containing a Reflexive Name Segment as its highest-order name segment, the Interest is interpreted as a Reflexive Interest. 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. [HA] If Trigger Data is cached in CS, the next Trigger Interest whose name is the same of the previous one may not reach to the producer, and hence the producer cannot send Reflexive Interest to make the consumer push the data. It is not a wrong behavior because caching the TD implies that the pushed data (RD) was previously sent to the producer and it is not necessary to send the same RD to the producer again. However, it may be an unexpected behavior for the consumer because the consumer cannot push the data to the publisher until the caches in the network are perfectly expired/removed. This explanation (attention) must be clearly mentioned here or some place. --> Note: Given that reflexive interests initiate exchanges constrained by the Interest Lifetime of the enclosing Trigger Interest/Data exchange, the value of caching the Reflexive 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.
2. The forwarder MUST check for the existence of a matching template PIT entry (i.e., one containing the RNP in this Interest's Name). If no matching template PIT entry is found, it could, strictly speaking, be considered an error, but the forwarder SHOULD simply process the Interest as a normal non-reflexive Interest and skip the steps below. A match indicates that this is a Reflexive Interest corresponding to the original Trigger Interest, so execute the following steps.
3. Create a new PIT entry for the Reflexive Interest (if resources are sufficient). In the case of this is accomplished by cloning the new PIT entry from the template PIT entry created earlier by receipt of the Trigger Interest. (For interactions with Interest aggregation, also see )
4. Record the Forward PIT-Token (FPT), if any, in this PIT entry, as would be done for any received Interest containing an FPT TLV.
-->
5. Look up the ingress face from the originating Trigger Interest's PIT entry, and forward the Reflexive Interest on this face. In the case of the face to forward on would have already been populated in the Reflexive Interest's PIT entry.

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.

Forwarder algorithms in pseudocode 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 .

Processing of a Trigger Interest containing a Reflexive Name Prefix Create PIT entry for Interest; Optionally create a template PIT entry for any potential Reflexive Interests expected to match the RNP in the Trigger Interest; Forward Interest upstream;

Processing of a Reflexive Interest Use Reflexive Name Segment of Reflexive Interest's Name to look up the Trigger Interest PIT entry; IF PIT entry of original Interest not is found Issue an Interest Return with "No Route" error back to the producer; ELSE Create PIT entry for Reflexive Interest (or optionally clone it from the template PIT entry that was created together with the Trigger Interest PIT entry); Process as a normal Interest; RETURN

State coupling between producer and consumer A consumer that wishes to use this scheme MUST utilize one of the reflexive naming options defined in and include it in the corresponding Interest message. The Reflexive Name Prefix 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 Trigger Interest message responds with a Data message (or an Interest Return message in the case of error) answering the Trigger 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.

Use cases for Reflexive Interests

Achieving Remote Method Invocation with Reflexive Interests RICE (Remote Method Invocation in ICN) used a similar Reflexive Interest Forwarding scheme that inspired the design specified in this document (similar to the original design captured in ). 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, start the compute process, and return 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. depicts an abstract message diagram for RICE. In addition to the 4-way Reflexive Forwarding Handshake 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).

RICE Message Flow +-----------+ +-----------+ | 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

RESTful Web Interactions 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 that corresponding requests often exceed the response messages in size, and that this raises the problems noted in 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 . 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 .

Achieving simple data pull from consumers with reflexive Interests 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. , , ) with varying degrees of success in addressing the issues outlined in . 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" Trigger Interest message to a pre-configured (or discovered) rendezvous name (e.g. an application-layer gateway or ICN Repo) and provides a reflexive name prefix 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 Trigger 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 Trigger 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. depicts this interaction with the (optional) TD message.

"Phone Home" Message Flow +-----------+ +-----------+ | Consumer | | Producer | +-----------+ +-----------+ ------------\ | | | new IoT |-| | | data item | | | | produced | | | |-----------| | | ---------------\ | | | "phone home" |-| | | by notifying | | | | producer | | | |--------------| | | | | | TI | |-------------------->| | | --------------------\ | |-| generate Interest | | | | for IoT data | | | |-------------------| | | | RI1 | |<--------------------| -----------------\ | | | send requested |-| | | data object | | | |----------------| | | | | | RD1 | |-------------------->| | | -----------------------\ | |-| finalize interaction | | | | with optional | | | | Data message | | | |----------------------| | | | TD (optional) | |<--------------------| | | Legend: TI: Trigger Interest containing the Reflexive Name Prefix RI1: Reflexive Interest requesting the IoT data RD1: Data message, answering RI, returning IoT data object TD: (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 ) 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:

• By not requiring the IoT device to be actively listening for Interests, it can sleep and only wake up if it has something to communicate. Conversely, parties interested in obtaining data from the device do not need to be constantly polling in order to ascertain if there is new data available.
• No forwarder resources are tied up with state apart from the actual reflexive forwarding interactions. All that is needed is enough routing state in the FIB to be able to forward the "phone home" Interest to an appropriate target producer. While this model does not provide all the richness of a full Pub/Sub system (like that described in ) we argue it is adequate for a large subclass of such applications.
• The Reflexive interest, through either a name suffix or Interest payload, can give the IoT device useful context from which to craft its Data object in response. One highly useful parameter would be a robust clock value for the device to use as a timestamp of the data, possibly as part of its name, to correctly place it in a time seres of sensor readings. This substantially alleviates the need for low-end devices to have a robust time base, as long as they trust the producer they contact to provide it.

Implementation Considerations 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 protocol architecture.

Forwarder implementation considerations

Interactions with Input Processing of Interest and Data packets 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:

• In order to locate the matching RNP from the Trigger Interest, the forwarder's packet input processing needs to be able to efficiently access a PIT entry storing the RNP of the corresponding Trigger Interest.
• Ensure that the highest order name segment of the Reflexive Interest is a Reflexive Name Segment that matches the RNP stored in that PIT entry.

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. ) 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 Trigger Interest containing the Reflexive Name Prefix 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 ) or add special input handling of reflexive interests to steer them to the same shard as the original interest.

Interactions with Interest Lifetime 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 Trigger 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 Trigger Interest's RNP, the forwarder examines the Interest lifetime of the arriving Reflexive Interest. Call this value IL_r. The forwarder computes MAX(IL_t, (IL_r * 1.5)), and replaces IL_t with this value. This in effect ensures that the remaining Interest lifetime of the Trigger 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 Trigger 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 corresponding PIT entry, MUST also delete the RNP from the Trigger Interest's PIT entry, thereby preventing any further Reflexive Interests from reaching the consumer. This in turn allows the enclosing Interest-Data exchange to either time out or be correctly ended with a Data message or Interest Return from the Producer.

Interactions with Interest aggregation and multi-path/multi-destination forwarding 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. If Trigger Interests with different Reflexive Name Prefixes collide, the forwarder MUST NOT aggregate these Interest messages and instead MUST create a separate PIT entry for each. Forwarders supporting multi-path forwarding may of course exploit this capability for Trigger Interests with identical Reflexive Name Prefixes, 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 Name Prefixes, they will get aggregated. The forwarder might, just as for any other Interest, decide to either do single or multi-path forwarding of that Interest. If sent multi-path in parallel, these also will reconverge on the reverse path and get aggregated. For multi-destination, Reflexive Interests might get issued by multiple producers, but they will carry the same Reflexive Name Segment and hence be forwarded using the ingress face of the same Trigger 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.

Consumer Implementation Considerations

Data objects returned by the consumer to reflexive name Interests arriving from a producer 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. , 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.

1. Set the recommended cache time (T_CACHETIME) either to zero, or a value no greater than the Interest lifetime (T_INTLIFE) of the Trigger Interest message.
2. Set the payload type (T_PAYLDTYPE) according to the type of object being returned (e.g. object, link, manifest)
3. Set the expiry time (T_EXPIRY) to a value greater than now, and less than or equal to the now + Interest lifetime (T_INTLIFE) of the original Interest message.

Terminating unwanted reflexive Interest exchanges A consumer may wish to stop receiving Reflexive Interests due to possible errors 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 ). This will provoke the forwarders to prevent further reflexive Interests from reaching the consumer, as described above in .

Interactions with caching 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 unique values generated randomly as described in ). 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 Trigger Interest.

Producer Implementation Considerations 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 Trigger Interest was received on.

Operational Considerations Reflexive forwarding 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 Reflexive Name Prefixes and the corresponding forwarder capabilities specified in . 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 Trigger Interest message. Further, the producer would need a bit of smarts to determine that this is a permanent error and not a transient error to be retried. In order for the consumer to attempt recovery, there might be a need for some explicit error returned for the Trigger 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 Reflexive Name Prefixes 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:

1. it detects the problem immediately and deterministically, and
2. one could assume an ICN routing protocol that would only forward to a next hop that supports the updated protocol version number. The supported forwarder protocol versions would have been communicated in the routing protocol ahead of time.

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 protocol elements. 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.

Mapping to CCNx and NDN packet encodings

Packet encoding for CCNx For CCNx , this specification defines one new Name Segment type for the Reflexive Name Prefix. Reflexive Name Segment

Abbrev	Name	Description
T_REFLEXIVE_NAME	Reflexive Name Segment	Name segment to use as name prefix in Reflexive Interest Messages

Reflexive Name Prefix 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 +---------------+---------------+---------------+---------------+ | Type (=T_REFLEXIVE_NAME) | Length | +---------------+---------------+---------------+---------------+ / Reflexive Name Prefix / +---------------+---------------+---------------+---------------+

Type:

Format of the Value field. For the Reflexive Name Segment, the type value MUST be T_REFLEXIVE_NAME in the current specification. 16 bit length.

Length:

Length of Value field in octets. 16 bit length.

Reflexive Name Prefix

Reflexive Name Prefix (RNP) assigned by consumer. Variable length.

For Trigger Interests, if approach from is chosen, then a second registered type is needed. The same format as used above for the Name Segment Type will be registered by IANA as an Interest Message TLV. Reflexive Name Prefix TLV

Abbrev	Name	Description
T_REFLEXIVE_NAME_PREFIX	Reflexive Name Prefix TLV	Interest message field to use as name prefix in Trigger Interest Messages

Packet encoding for NDN These are proposed assignments based on . Suggestions from the NDN team would be greatly appreciated.

Reflexive Name Component Type 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

Reflexive Name Prefix TLV For Trigger Interests, if approach from is chosen, The Reflexive Name Prefix TLV needs to be added to the NDN Interest packet format. We suggest using , hence something like: Proposed Reflexive Name Prefix TLV for NDN Interest Packet

RNP ::=

RNP-TYPE

TLV-LENGTH(=16) BYTE8)

IANA Considerations As per , this section makes an assignment in two existing registries in the "Content-Centric Networking (CCNx)" registry group. The registration procedure is "RFC Required", which requires only that this document be published as an RFC.

CCNx Name Segment Type Registry As shown in , this document defines Name Segment type, T_REFLEXIVE_NAME, whose suggested value is %x0005.

CCNx Validation-Dependent Data Types Registry As shown in , this document defines one CCNx Validation-Dependent Data Type, T_REFLEXIVE_NAME, whose suggested value is %x0008.

Security Considerations 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 , but we briefly recapitulate them here:

• Current approaches to authentication and data transfer often use payloads in Interest messages, which are clumsy to secure (Interest messages must be signed) and as a consequence make it very difficult to ensure consumer privacy. Reflexive forwarding moves all sensitive data to the Data messages sent in response to reflexive Interests, which are secured in the same manner as all other Data messages in the CCNx and NDN protocol designs.
• In many scenarios, consumers are forced to also act as producers so that data may be fetched by either a particular, or arbitrary other party. Therefore the consumer must arrange to have a routable name prefix and that prefix be disseminated by the routing protocol or other means. This represents both a privacy hazard (by revealing possible important information about the consumer) and a security concern as it opens up the consumer to the full panoply of flooding and crafted Interest Denial of Service attacks.
• In order to achieve multi-way handshakes, in current designs a consumer wishing a producer to communicate back must inform the producer of what (globally routable) name to use. This gives the consumer a convenient means to mount a variety of reflection attacks by recruiting the producer to send Interests to desired victims.

As a major protocol extension however, this design brings its own potential security issues, which are discussed in the following subsections.

Collisions of reflexive Interest names Reflexive Interest names need to be constructed with sufficient randomness 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. Doing so 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 format be used, with a pseudo-random number generator (PRNG) approved for use with cryptographic protocols.

Additional resource pressure on PIT and FIB 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 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.

Privacy Considerations 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 (), name encryption (), and name obfuscation () 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 reverse path of forwarders from the producer to the consumer, through which the original Trigger 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.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest. This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification. Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification. This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification. Informative References This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. Work in Progress This document describes how to encode an application data objet into a structured _manifest_ using Information Centric Networking (ICN) data objects, creating a File-Like ICN Collection (FLIC). The manifest is an "index table" of objects that make up the manifest itself and the application data. It records the hash value (content object hash) of each item so a consumer using the manifest may request each piece by a complete hash name. The manifest is hierarchical and may be encoded into realtively small ICN objects to fit within network MTU sizes. FLIC has several methods to guide a consumer in constructing appropriate Interest names based on the manifest. It also supports encryption of the manifest data. FLIC may be used in CCNx or Named Data Networking, or other ICNs. Work in Progress This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. This document is not an Internet Standards Track specification; it is published for informational purposes. The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG). Path steering is a mechanism to discover paths to the producers of Information-Centric Networking (ICN) Content Objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multi-path congestion control algorithms and for network measurement and management. This specification derives directly from the design published in "Path Switching in Content Centric and Named Data Networks" (4th ACM Conference on Information-Centric Networking) and, therefore, does not recapitulate the design motivations, implementation details, or evaluation of the scheme. However, some technical details are different, and where there are differences, the design documented here is to be considered definitive. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). It is not an IETF product and is not an Internet Standard. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122.

Alternative Designs Considered 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.

Handling reflexive interests using dynamic FIB entries The original draft specification employed the use of dynamically-created FIB entries for forwarding Reflexive Interests. In this approach, at each forwarder along the reverse 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:

1. The forwarder creates short-lifetime FIB entries for any Reflexive Interest Name prefixes communicated in an Interest message. If the forwarder does not have sufficient resources to do so, it rejects the Interest with the T_RETURN_NO_RESOURCES error — the same error used if the forwarder were lacking sufficient PIT resources to process the Interest message.
2. Those FIB entries are queried whenever an Interest message arrives whose first name segment is of the type Reflexive Name Segment (RNP)
3. The FIB entry gets removed eventually, after the corresponding Data message has been forwarded. One option would be to remove the FIB directly after the Data message has been forwarded. However, the forwarder might choose do lazy cleanup.

There are a number of additional considerations with this design that need to be dealt with.

Design complexities and performance issues with FIB-based design 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 IL_t. 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:

1. If the entire FIB needs to be locked in order to insert or remove entries, this could cause inflated forwarding delays or in extreme cases, forwarding performance collapse.
2. A number of high-speed forwarder implementations employ a sharded PIT scheme (see ) to better parallelize forwarding across processing cores. The FIB, however, is still a shared data structure which is either read without read locks across cores, or explicitly copied such that there is a separate copy of the FIB for each PIT shard. Clearly, a high update rate without read locks and/or updating many copies of the FIB are unattractive implementation options. (Note: unlike the adopted scheme in the main specification, by just depending on a dynamic FIB it is not feasible to force reflexive interests to be hashed or be otherwise directed to the PIT shard holding the original Interest state).

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.

Interactions between FIB-based design and Interest Lifetime 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 , 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.

Reflexive forwarding using Path Steering We also considered leveraging Path Steering 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 . 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:

Message Flow Overview using Path Steering +-----------+ +-----------+ +-----------+ | Consumer | | Forwarder | | Producer | +-----------+ +-----------+ +-----------+ | ------------------------------\ | | |-| Create I1 with | | | | | additional empty Path 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 , there is no capability to force Interest routing away from an otherwise working path not supporting the reflexive name TLV.

Multiple RNPs in a Trigger Interest Early versions of the specification has an option to permit multiple Reflexive Name Prefixes in a Trigger Interest message if none of the other 3 options in covered the desired use case. The current specification does not permit this, because:

• It inflates the Trigger interest size, and would also inflate the trigger Data reponse size if the RNP is encoded as a name segment in the trigger interest name.
• It is more likely a forwarder will reject the Interest for lack of resources.
• No compelling use case has been found, at least so far

NDN Implementation An implementation of Reflexive Forwarind in NDN is available at https://github.com/nflsjxc/Reflexive-Forwarding-NDN-demo/tree/master. It differs from this specification in the following ways:

Reflexive Name Segment Currently Reflexive Name Component is the suffix instead of the prefix for the Reflexive Names. This is easier for prefix matching in NFD.

Processing Reflexive Interests> Currently we omit the RNP checking of Reflexive Interest with RNP in PIT entry because NFD now uses name-based PITs. Generally speaking there are 2 types of interests in the message flow:

1. Reflexive Interest (Consumer -> Producer)
2. Reflexive Interest (Producer -> Consumer)

Currently the two types of Interests are identified by the Reflexive Name value, if RN=9999, then it is the Reflexive Interest from Producer to Consumer.

Authors' Addresses Network Systems Research and Design

4 Shady Hill Square Cambridge MA 02138 USA daveoran@orandom.net

HKUST(GZ)

Guangzhou China ietf@dkutscher.net https://dirk-kutscher.info

National Institute of Information and Communications Technology

4-2-1 Nukui-Kitamachi Koganei Tokyo 184-8795 Japan asaeda@nict.go.jp

University of Kentucky

289 Rose Street Lexington KY 40506-0495 USA calvert@netlab.uky.edu