Forwarding Label support in CCN Protocol

In , we discuss several reasons to distinguish application identifiers (AI) and network identifiers (NI). In the context of ICN/CCN, we define application identifier (AI) and network identifier (NI) as follows: Application Identifier (AI) is a persistent secure or non-secure flat-ID or a hierarchical name assigned to a content, device or service. If the AI is secure, then there is a direct relationship between the name and the key of the principal, else a binding is provided by a third party using the certificate mechanism or using the web-of-trust model. Generally this identifier space is managed by services and applications. Network Identifier (NI) is a topological name assigned to a network entity such as a network, router, host. Generally the NI space is assigned and managed by the network administrators. We discuss here first (i) the motivations behind the need for separation between a persistent AI and an NI in the Interest message, in the context of CCN, and then (ii) a proposal to achieve this. The notion of ID/Locator has been widely studied as part of many host-centric protocols such as HIP , ILNP , and LISP . Here we distinguish AI/NI from the ID/Locator notion due to the nature of ICN with respect to interdependency between naming and forwarding. Specifically, in the context of information-centric networks, any of these two names can be used contextually in the routing and forwarding plane to resolve content, service or host or even apply computation on the named data objects based on the application requirements. In this context, ICN architectures such as MobilityFirst and NetInf assume an explicit representation of AI and NI in its architecture, considering the use of non-aggregateable flat IDs, whereas CCN/NDN assumes the aggregate-ability of names within its architecture, thereby applying only the AI namespace on routing and forwarding. We have argued in the problems associated with (i) using name prefixes for routing, which include challenges related to scalability, (ii) loss of name aggregate-ability, when data and services are replicated, (iii) mobility handling, or (iv) situations where conversational sessions are required for service level authentication and authorization . These issues have also been argued quantitatively in , including the scenario, where there is an explosion in the namespace, when there are many different ways of naming an entity because of the rich context associated with it. Therefore, providing this distinct AI/NI separation in the ICN protocol offers the following advantages, which are also discussed in detail in : CCN applications request persistent AI of content, service or hosts, while their resolution is handled through per-hop name-based forwarding by a CCN forwarder using any of the unicast/anycast/broadcast mechanisms, with routing scalability being handled using name prefixes. This model can introduce problems when the named entity is mobile, migrated, or replicated, as the names have to be announced in the routing control plane, which can in turn introduce routing convergence issues and scalability challenges. Introducing an AI/NI namespace split in the architecture using a name resolution service shall address the routing challenges due to dynamic entities, while also improving the scalability by limiting the state in the core Internet routers to the set of topological names. AI and NI namespaces are managed by different entities. For instance, AIs are managed by applications and services, hence their scope is limited to the application layer, while the NI names are assigned to the networked entity, hence managed by a network administrator. In such case, NI maps to network domains or specific network elements, through which the AI is reachable. The relationship between the two is established during the namespace publishing phase, and managed by a separate name resolution service. AI/NI distinction in CCN allows applications to manage its own namespace and not be restricted by the naming rules imposed by the network. Allowing an AI/NI representation in an Interest message offers many advantages in CCN, especially when centralized control is applied, such as using a service orchestration framework for intelligent service and content placement based on available network resources and satisfying QoS requirements. This enables efficiency and flexibility through service-centric name resolution, routing, mobility and caching services. Considering the above requirements, we propose a forwarding label object (FLO), which includes an NI along with the security encapsulations and provide the flexibility to forward Interests on a name other than the one provided within the original Interest message, with the ability to terminate or swap it in the network. Handling the AI-to-NI mapping requires a control plane infrastructure and appropriate network layer security functions to prevent malicious misuse. Specific control plane or security mechanism of AI/NI mapping is out of the scope of this document as many techniques can be used towards achieving this. This draft presents various considerations towards FLO management such as: FLO insertion/modification/deletion, FLO processing by a CCN forwarder, PIT/CS implications for FLO carrying Interests, FLO Interest packet format, and security/trust considerations. We also discuss the application of FLO in various scenarios to illustrate its capabilities and advantages.

Following we discuss various aspects of the FLO related to its semantics and management.

FL objects include NI, service specific metadata, and security attributes for authentication. An NI like an AI can be hierarchically structured or flat, but with the characteristic of having a topological property. The security attributes are optional and may include validation payload and algorithm as discussed in .

A FLO can be inserted in an Interest message by the application requesting a named entity or by the network. In certain situations, the application may insert the FLO in addition to the AI in the Interest message or this action may also be triggered based on feedback received from the network, for instance, due to failure of routing the Interest message based on the AI, as in . In such situations, forwarders, which process traffic from applications outside the trust domain, require a way to validate the FLO. A possible approach to ensure trust in such situations is discussed in where a trust binding is provided between the AI and the NI as a link object which can be validated by the forwarder. To avoid the possibility of a misuse of a FLO, a default policy of the network may be to ignore it from untrusted applications and to only choose to route by the AI or by applying the next scenario. FLO can also be inserted by the network, in which case FLO insertion is triggered at the ingress (service edge) routers of the network domain. For instance, network may insert a FLO to an incoming Interest message, an action which can be triggered based on several considerations, some of which may include: 1) based on the interface, on which the Interest ingresses; 2) if the Interest message satisfies the flow service profiles that are imposed by the network administrator at the ingress routers; 2) a default behavior by the network, when it chooses to only route on NIs. The service profile matching actions may include matching an Interest name to a set of service prefixes or triggered by certain markings or metadata in the Interest such as context-ID (for example, service, network, trust, and location). FLO inserted within the trust domain may not require security validation.

A FLO can be swapped with another within the network, in the context of a given service, at designated points, such as the service edge routers. Future considerations can also include the case, where FLO can be potentially stacked based on the semantics of the current FLO.

FL objects are terminated by a forwarder, when the NI in it matches the forwarder's own NI. Here, we assume a forwarder to possibly have many NIs such as domain-IDs, router-IDs or Interface-IDs. For example, a forwarder (in a domain) identified as /att/santaclara can process a FLO with its NI set to this router's domain name or to a forwarder ID such as /att/santaclara/pop-x. Whenever a FLO is terminated by the forwarder, depending on the network service context, the forwarder can attach a new FLO, or conduct additional processing on the request (e.g., re-resolution of the name to a new FLO) based on the Interest parameters. The FLO can also include optional policy metadata based on which FL objects can be swapped within the network.

As a FLO is swappable in the network, it is proposed as a hop-by-hop field in the optional body of the fixed header as shown in Figure 1. The optional FLO includes attribute of type FL-Object, which contains a name TLV identifying the NI (Figure 2). NI is a hierarchically structured variable length name as defined in . In addition to the NI, optional FL metadata includes contextual information on the application or the service to aid the network for invoking an appropriate FL processing, such as trust validation of the FLO. Optional security attributes, such as authentication information, can be included depending on the specific use case scenarios, such as secure name delegation information as discussed in , or signature of the consumer.

| / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = FL-Object | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NI TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional FLO Metadata / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional FLO Security Attributes / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Interest Message Body / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Interest message with hop-by-hop Optional Forwarding Label TLV ]]>

The following discussion is based on the assumption that all forwarders must process the optional header fields. In the context of CCN packet processing, FLO is only relevant when the decision to forward the Interest message is to be made. In this draft, a default policy applied by all CCN routers is to route using FLO if it exists in the Interest message. Based on this, following considerations apply: When an Interest with a FLO arrives at a CCN router, if the FLO is trusted and the lookup based on NI in the FLO succeeds, the router first checks if the NI matches any of its network names. If it does, it is treated as a terminating flow. In this case, name based lookup is conducted, which may return another FLO, or results in a next hop forwarding face for the Interest packet. For the non-terminating flow, the NI FIB lookup results in a next hop, towards which the Interest is forwarded. If NI based on the FLO lookup fails, then the router can try to forward the Interest based on the Interest AI. However if routing based on the Interest AI fails, then the router could raise an error condition and feedback the message to the previous hop with the appropriate error code. The validation of FLO depends on the trust context, which is indicated by the information inserted in the FLO by the ingress domain router. In trusted networking scenarios, where the applications and the network are managed by the same authority, the ingress and the core routers can bypass the FLO validation. In untrusted networking scenarios, the edge router may only validate the FLO that is inserted by the sender and avoid re-validations by successive forwarders.

FLO is only a routing directive, hence shouldn't affect the functionality of the PIT in normal situations. However, including FLO in the Interest could raise new questions, which need to be answered. One such case is when there is a strong binding between an AI and the NI either by the application or the network, which may correspond to situations when multiple Interests arrive at a router for the same AI but with different NIs. One possible approach in this case is to treat each such (AI,NI) combination differently, thereby saving them in the PIT, and by requiring the CO to piggyback the NI to ensure proper matching. In the case, when the FLO is swapped by an intermediate router, its PIT should save both the incoming and the outgoing NI, and also the CO should be updated with the appropriate NI to ensure matching of the PIT entries along the previous hops. These considerations are similar to those elaborated in

The caching function shouldn't be affected by this draft proposal. Even if a FLO is included in the CO as discussed earlier, this is expected to be removed before caching the content, as it only relates to forwarding function.

In wide area network scenarios, Interests can cross multiple domains. If a FLO is only trusted within the domain boundaries, then the FLO is removed before the Interest is forwarded to the next domain, which then upon entry, by the ingress of the next domain, inserts a new FLO with the associated security attributes. However, if trust exists between the neighboring domains to use the FLO inserted by the previous domain (such as one through a trusted third party, and validated based on the FLO security binding), then the intermediate domains can avoid further FLO processing and use the FLO passed on by the previous domains.

FLO security is related to the purpose it is used for and the control plane mechanism used to manage it. Depending on the use case scenario of the FL, appropriate security mechanisms should be applied to secure the control and data planes to avoid exploitation of this feature. Generally, the major threat against the FLO approach is to manipulate the relationship between the name and the FLO. Such manipulations can happen in various scenarios, some of which are listed as follows: (i) a malicious interceptor (who is acting as a publisher) intentionally injects an incorrect mapping into the name resolution system; (ii) a malicious interceptor (between the edge router and the resolution server) manipulates the mapping sent back from the name resolution system, when the edge router queries the mapping system; (iii) a compromised intermediate router maliciously changes the FLO, e.g., with the wrong FLO or an out-dated FLO; (iv) an untrusted application injects an invalid FLO into the Interest message. To achieve network level FLO security, appropriate mechanisms should be applied to provide mapping provenance, mapping integrity and to prevent replay attack to address these issues. The security mechanisms applicable to the above discussed scenarios (i) and (ii) are similar to the ones applied to secure other mapping systems such as LISP and DNS . Scenario (iii) requires new security mechanisms, and one such way is to enable a domain level trust infrastructure so that the mapping between the name and the FLO can be authenticated by the successive routers. In untrusted environments, when a FLO is inserted in the Interest message by the end hosts, appropriate authentication information should also be included in the FLO to allow ingress routers to optionally validate the delegation of the Interest AI to NI . Furthermore, additional security policies can be enabled by the network to handle FL objects outside its trust domain.

Here we provide the discussions related to using FLOs in different scenarios.

In the literature, the different techniques to handle producer mobility can be classified into the following two types: Application-based approach, where the application takes the responsibility for announcing its reachability to the network and triggering a network state change to enable Interest routing towards the mobile producer. Most of the current proposals fall under this category, and these include the following two approaches: 1)The Kite proposal implements an anchor based approach where consumers and producers agree on an anchor point based on external mechanisms and uses application initiated (traced and tracing) Interests to handle the producer mobility; 2)The anchor-less proposal is another application-based approach wherein enhanced name-based routing and forwarding is used to track the mobile producer. While these approaches allow consumers and producers to work on a single name space, it raises scalability concerns with increasing number of mobile nodes and number of applications signaling into the network. As these approaches introduce more signaling in the network, the operational efficiency of packet forwarding is negatively affected due to the state changes that have to be applied to ensure optimized Interest routing towards the mobile producer. Another potential security issue with these approaches is that it can be prone to flooding attacks by malicious applications targeting specific application names and impeding their normal operation. Network-based approach uses the late-binding technique , wherein the reachability of the mobile node is handled by the network. In this case, applications can explicitly request mobility for a given namespace , with the network handling the mobility by tracking its latest location in the network through a name resolution system. At the same time, through coordination of the old and new point-of-attachments (PoA) and in-band signaling one can achieve minimal loss for a given Interest flow. The late-binding technique uses AI/NI split that is only applied at the PoAs, thereby avoiding challenges related to routing convergence in the network due to producer mobility, while offering better scalability when the number of mobile producers increases. Here, the user entity (UE) registers a name prefix that requires mobility with its current point-of-attachment (PoA). The PoA then registers the mapping between the name prefix and the PoA's NI in its local name resolution system. The domain then updates the UE's home domain name resolution system with its current domain LID. When a correspondent node expresses Interest for the name, it is first resolved to the current UE domain by the home domain. When the Interest enters the domain offering mobility service, it is resolved again to the UE's current location. Furthermore PoA-to-PoA signaling can be enabled to offer seamless forwarding of Interests whenever a UE changes its PoA. In addition to correcting the path stretch, the Interests re-routed from the old PoA can be marked and re-routed to the new PoA with the new FL. On the return path, the COs are also marked, this in-band marking is used by the ingress PoA at the consumer's end to re-resolve the mobile prefix to a new forwarding NI that would correct the path stretch.

As ICN operates in a PULL mode, consumers operating over unreliable wireless interfaces or during mobility-triggered events (such as handovers) can recover from a lost Interest or Data response by re-expressing it. There are some challenges associated with this approach: (1) without appropriate cross-layer signaling between the MAC and the ICN layer on the transient lower layer interface state or network events such as handover, it is difficult to re-express Interest in a timely manner; alternately ICN or the applications rely on default Interest timeout value supplied by the application which can be very inefficient, particularly for applications with real-time requirements; (2) even in the case of a desired scenario, where cross-layer signaling is enabled and an ICN Interest is re-expressed soon after a loss is identified, the ability to retrieve the content from a nearby cache depends on the engineered cache resources in the ICN network, such as its size in the edge vs. core routers and the cache management algorithms that exploit features such as content popularity to offer the best user experience. In the worst case scenario, these re-expressed Interests can only be satisfied by the producer. Note that, this scenario is mostly true for a large set of unpopular content types or for conversational applications, where caching may be of no significant use. The above concerns can be addressed using FLO to support seamless consumer mobility. The process is similar to producer mobility, but in this situation, FLO is used to redirect Data objects from the previous PoA to the new PoA. The trigger for this redirection requires to identify the set of Interests in the PIT, which have been affected by the consumer mobility. To support this, the PIT state at the PoAs are expanded to save the ID of the UE which is signaled in the Interest. However, this ID is not carried beyond the PoA. In addition, the PIT state is also associated with the attachment state of the consumer device to the current PoA. During the handover, consumer UE signals to the previous PoA information about the new PoA (such as the NI associated with the new PoA), which is then applied to the PIT entries associated with this consumer along with the change of the attachment state. When the Data objects requested by a previously connected consumer, which performed handover to attach to another PoA, arrives at the previous PoA, the NI information in the PIT is used to create the FLO, which is then appended to the Data header and forwarded like an Interest using the FIB. These Data objects are also marked, so that the set of routers along the path towards the new PoA are able to distinguish between these packets and regular Data objects. These Data objects could pass through a path segment that it has already passed through in the reverse direction prior to arriving at the previous PoA. In that case they should not be cached by any router belonging to that path segment, but can be cached in the routers that are part of the path segment receiving this Data object for the first time, by first removing the FLO and subjecting it to the local caching policies. When this Data arrives at the current PoA, it is cached applying prioritized caching policies considering its arrival as a result of a handover, which is then used to respond to a re-expressed Interest. Alternately, the Data objects forwarded from the previous PoA can also include the consumer ID, which can then be used by the current PoA to PUSH it to the consumer UE, similar to how it would be at the previous PoA had the consumer still connected to it.

The FL objects can also be used to support the retrieval of nameless objects . Using the current manifest proposal a consumer receives a manifest with the ContentObjectHashIDs and their respective NI information. A consuming application uses the NI as a routeable content name, while the ContentObjectHashID is used as a HashID restriction parameter. Multiplexing the Interest name field as an AI and also as an NI has the following consequences: (1) a forwarder cannot distinguish between Interest packets containing AI or NI in the name field, as the protocol doesn't differentiate these two names; (2) it complicates Interest processing where two different Interest processing logic needs to be applied with Interests with or without the hash-id. In this situation, routers should first checks for the presence of ContentObjectHashID and uses it to index the Interest based on it rather than using it as a NI; (3) more complications arise if an Interest packet arrives with two IDs i.e. a ContentObjectHashID as the hash restriction and the ID as the content name, in which case, one of them should seek precedence over the other. The above issues can be avoided through the use of the ContentObjectHashID as the content name and the NI in the FLO. In this case, a forwarder will always index the pending Interest table or the cache as expected on the content name. The routing decision then would be based on the FLO depending on the routing policy in the forwarder. This also avoids the situation of dealing with two IDs in the Interest packet, i.e. the application has to choose either ID or ContentObjectHashID as the content ID. A possible high level forwarding logic for the edge/core router to support nameless objects based on the above discussion is presented in Figure 3. Here edge router can also be a gateway node.

We discuss security implications of using AI and FLO in the Interest message depending on the ID type. Case 1 - ContentObjectHashId with FLO: This use case is a straightforward simplification of what is being proposed in . Here, the NI is included within the FLO and the ContentObjectHashId is used as the name, so this shouldn't introduce any new security concerns. This holds good for both application and network based FLO insertion. Case 2 - Routeable AI with FLO: For UE based FLO insertion, this scenario can cause cache poisoning in the absence of a signature check enforcement in the forwarders. For the case when FLO is managed within a trusted domain, the security implications are discussed in Section 8.

FLO can be used to bind a service AI to a given location in the network, so that the consumer's session is correctly directed to the service instance keeping state of the conversation, e.g. . Using AI-based anycast routing cannot guarantee this, as the name prefix state used for forwarding would treat all possible instances equally. One way to mitigate this, while compromising efficiency, would be to introduce a load balancer, through which all such Interest flows are routed.

Networks, which host their own or third party contents/services can benefit from the ability to handle Interest routing logic in its domain opportunistically. When an Interest seeking a specific content or service enters a network domain, the ingress router can redirect the Interest to the closest cache point or service location.

As discussed in , NI based routing can address routing scalability, as the number of ASs are many orders less than the number of information objects. This reduces the forwarding table in the DFZ to the order of number of ASs in the Internet. In addition, unlike , this proposal offers the feature of swapping FLO and late-binding offering more flexibility and efficiency towards scalability and routing optimization.

The security implication of having FLO in the Interest message has been discussed in .

Following the discussion in , this draft proposes extensions to the CCN protocol to introduce NI namespace in the Interest message which can offer several benefits which include routing optimization and scalability, off path caching benefits, handling both consumer and producer mobility and service affinity for conversational communications.