Reflexive Forwarding for CCNx and NDN Protocols

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 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 8 December 2022.¶

Copyright Notice

Copyright (c) 2022 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.¶

Table of Contents

1. Introduction

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.¶

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 [Krol2018] 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 [Carzaniga2011], where an Interest is sent containing the desired request as encapsulated data. CCNx-1.0 Bidirectional Streams [Mosko2017] 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-know 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.¶

3. Overview of the Reflexive Forwarding design

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 10.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:¶

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 Section 1.2, Paragraph 2, Item 2.¶
2. Each forwarder along the inverse 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 the PIT entry associated with the original Interest message, since that contains the state necessary to identify the ingress face of the original Interest, which is the unique (modulo aggregation) output face 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 an expensive and complicated lookup procedure. In order to make this lookup both simple and efficient, we adopt an extended version of the "PIT-Token" scheme pioneered by the high-speed NIST NDN forwarder [Shi2020]. In this specification, we are using Forward Direction PIT Tokens (FPTs) that nodes attach to forwarded Interests in the upstream direction, and Reverse Direction PIT Tokens (RPTs) that nodes attach to Reflexive Interests (as well as regular Data messages) in the downstream direction. We describe the specific processing requirements in more detail below.¶
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.¶

The following sections provide the normative details on each of these design elements. 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->I2.RPT |-|
      |                          |        |----------------| |
      |                          |                           |
      |                          |                       RI1 |
      |                          |<--------------------------|
      |                          | --------------------\     |
      |                          |-| use I2.RPTto find |     |
      |                          | | PIT(I1),          |     |
      |                          | | check match       |     |
      |                          | | of PIT(I1).RNP    |     |
      |                          | | create PIT(I2),   |     |
      |                          | | forward I2        |     |
      |                          | |-------------------|     |
      |------------------------\ |                           |
      || add I1.RPT and I2.FPT |-|                           |
      || to PIT(I2)            | |                           |
      ||-----------------------| |                           |
      |                          |                           |
      |                       I2 |                           |
      |<-------------------------|                           |
      |                          |                           |
      | D2 obj                   |                           |
      |------------------------->|                           |
      |------------------------\ |                           |
      || consume PIT(I2) entry |-|                           |
      || and forward D2        | |                           |
      ||-----------------------| |                           |
      |       -----------------\ |                           |
      |       | I2.FPT->D2.RPT |-|                           |
      |       |----------------| |                           |
      |                          | ------------------\       |
      |                          |-| satisfy PIT(I2) |       |
      |                          | |-----------------|       |
      |                          |                           |
      |                          | D2                        |
      |                          |-------------------------->|
      |                          |                           | -------------\
      |                          |                           |-| 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
    RI: Reflexive Interest with Reflexive Name Prefix Component
    RNP: Reflexive Name Prefix
    FPT: Forward Direction PIT Token
    RPT: Reverse Direction PIT Token
    D1: Data message, answering initiating I1 Interest
    D2: Data message, answering RI

4. Consumer Operation

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 component 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. D2 in Figure 2).¶

5. 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 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 interface definitions or by the architectural definition of a simple sensor reading. In other cases, the full names of the individual objects must be communicated in the original Interest message.¶

We define a new typed name component, identified by a registered name component type in the IANA registry for [RFC8569]. We call this the Reflexive Interest Name Component type. It MUST be the first (i.e. high order) name component 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:¶

1. If there is insufficient randomness, a name collision on the Reflexive Names could occur at any of the intermediate forwarders which would result in the same mutability problems generated by poor name selection in other contexts; 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.¶

This initial name component 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:¶

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 [I-D.irtf-icnrg-flic] 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 (1) above because the use of a Manifest implies multiple reflexive Interest/Data exchanges with the consumer.¶
4. Multiple reflexive name TLVs MAY be included in the Interest message if none of the above 3 options covers the desired use case.¶

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 FIB 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 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 components 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.¶

6. Producer Operation

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.¶

7. Forwarder Operation

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 10.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.¶

1. Upon receiving an Interest containing a Reflexive Name Prefix (RNP) TLV the forwarder MUST record the RNP as an element of the PIT entry for that Interest. (For interactions with Interest aggregation, also see Section 10.1.3).¶
2. When forwarding an Interest with a Reflexive Name Prefix (RNP) TLV, the forwarder MAY generate a Forward PIT Token (FPT) and append it to the forwarded Interest to be processed by the next hop.¶
3. If an Interest contains a Reverse PIT Token (RPT), the forwarder MAY use that value to access the corresponding PIT entry, or do a direct lookup based on the Reflexive Interest Name Prefix.¶
4. The forwarders MUST check that the high-order Name component of the Interest is of type RNP. If not, while this could strictly speaking be considered an error, 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 consumer to producer Interest, so execute the following steps.¶
5. Create a new PIT entry for the Reflexive Interest (if resources are sufficient). Also, see Section 10.1.1 for how PIT sharding interacts with the location and creation of PIT entries on high-speed forwarders.¶
6. Record the Forward PIT-Token (FPT), if any, in this PIT entry, as would be done for any received Interest containing an FTP TLV.¶

7. Look up the ingress face from the originating Interest's PIT entry, forward the Reflexive Interest on this face, with the following changes:¶

   • Append the the RPT from the ingress face information of the original Interest's PIT entry, if any¶
   • If the downstream forwarder desires the upstream forwarder to supply an RPT in any returning Data Packet for this Reflexive interest, optionally append a FPT TLV to the Interest.¶

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.¶

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;

8. State coupling between producer and consumer

A consumer that wishes to use this scheme MUST utilize one of the reflexive naming options defined in Section 5 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 the 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.¶

10. 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 CCNx/NDN protocol architecture.¶

11. Operational Considerations

This extension represents a substantial enhancement to the CCNx/NDN protocol architecture and hence has important forward and backward compatibility effects. 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 TLV, the Forward and Backward PIT-Token TLVs and the corresponding forwarder capabilities specified in Section 7. 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 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)

it detects the problem immediately and deterministically, and¶

(b)

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 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.¶

12. Mapping to CCNx and NDN packet encodings

13. IANA Considerations

                     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             |
+-------------------------------+-------------------------------+

                     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          |
+-------------------------------+-------------------------------+

14. 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 Section 1, 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. The means 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 enlisting 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.¶

Appendix A. 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.¶

+-----------+                        +-----------+               +-----------+
| 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 Component
    RNP: Reflexive Name Prefix
    D1: Data message, answering initiating I1 Interest
    D2: Data message, answering RI

Authors' Addresses