| ICN Research Group | R. Ravindran |
| Internet-Draft | A. Chakraborti |
| Intended status: Informational | A. Azgin |
| Expires: September 6, 2018 | Huawei Technologies |
| March 5, 2018 |
Forwarding Label support in CCN Protocol
draft-ravi-icnrg-ccn-forwarding-label-02
The objective of this proposal is to enable application identifier (AI) and network identifier (NI) split in the CCN protocol that has several applications such as towards Interest routing optimization, mobility, conversational session support, handling indirections in manifests, and routing scalability. We enable this through the notion of forwarding label object (FLO), which is an optional hop-by-hop payload in the Interest message with a topological name which identifies a network domain, router or a host. FLO can be inserted by the end user applications or by the network. FLO is processed by the network resulting in either terminating it or swapping it with a new FLO based on the network service context. Furthermore, depending on the application and trust context, a FLO can be subjected to policy based actions by the forwarders such as invoking security verification or enabling other FLO management actions.
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 September 6, 2018.
Copyright (c) 2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
In [1], 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: [6], ILNP [7], and LISP [8]. 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 [23] and NetInf [12] 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 [1] 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 [2]. These issues have also been argued quantitatively in [14], 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 [1]:
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
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 [3].
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 [15]. 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 [15] 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 [5]. 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 [15], or signature of the consumer.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CCN Fixed Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Optional Hop-by-Hop TLVs> |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+----------------------+------------------+-----------------+
| Forwarding Label | Meaning | Value |
+----------------------+------------------+-----------------+
| NI TLV | Identifies an | Name TLV |
| | AS-ID/Gateway-ID/| |
| | Host-ID/Interface| |
| | -ID | |
+----------------------+------------------+-----------------+
Figure 2: Network Identifier(NI) Definition
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:
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 [21]
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 [9] and DNS [11]. 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 [15]. 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:
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 [17]. Using the current manifest proposal [10] 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.
Begin
if Edge_Router
If Interest arrives on a face with a flat AI
Then check for the presence of FLO
If FLO is present
Then use the NI in the FLO for Interest forwarding
Else (If there is no FLO)
If policy allows, resolve the flat AI with an NRS to obtain a FLO
Use the FLO to route the Interest
End
End
End
If the Interest arrives with a routeable AI
If FLO is present
Then use the AI for forwarding and Remove the FLO
Else (if there is no FLO)
Match Interest AI with name policy for e.g. mobility or interest routing optimization
If a name policy for resolution exists
Then network resolution service is invoked on the AI, which returns a FLO
Use the FLO to direct the Interest to the appropriate next hop
End
End
End
End
if Core_Router
if Interest arrives with a FLO
Use the NI for forwarding
Else if Interest is with a Routeable AI
Use the name for forwarding
End
End
Figure 3: Forwarding logic to support flat and routeable AI at the edge router
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.
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. [2]. 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 [15], 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 [15], 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 Section 8.
Following the discussion in [1], 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.