ICN Research Group R. Ravindran Internet-Draft A. Chakraborti Intended status: Informational Huawei Technologies Expires: September 10, 2015 March 9, 2015 Forwarding-Label support in CCN Protocol draft-ravi-ccn-forwarding-label-00 Abstract This document motivates the need for a forwarding-label which is another name that can be used in forwarding, in addition to the mandatory name in a CCNx Interest message. Forwarding-label once inserted by a edge router can be modified en-route towards the producer. Forwarding-label can be used for several purposes such as to support routing scalability, producer mobility, multi-protocol support, or for fast forwarding. We describe its encoding format, and rules followed by a forwarder while processing it. We also illustrate its use by applying it towards producer mobility. This draft scopes the use of forwarding-label within a closed trusted domain, while the use of it by applications is not ruled out. 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 http://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 10, 2015. Copyright Notice Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) in effect on the date of Ravindran & ChakrabortiExpires September 10, 2015 [Page 1] Internet-Draft Forwarding-label support in CCN March 2015 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. Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Forwarding-Label Management . . . . . . . . . . . . . . . . . 3 3. On the Wire . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Forwarding Label Processing Rules . . . . . . . . . . . . . . 4 5. PIT Processing Implications . . . . . . . . . . . . . . . . . 5 6. Caching Implications . . . . . . . . . . . . . . . . . . . . 6 7. Multiple Domain Scenario . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 6 9.1. Handling Producer Mobility . . . . . . . . . . . . . . . 7 9.1.1. Mobility as Network Service . . . . . . . . . . . . . 7 9.1.2. Differentiating Mobile Flows . . . . . . . . . . . . 7 9.1.3. Using Forwarding-Label . . . . . . . . . . . . . . . 7 9.1.4. Name Resolution System . . . . . . . . . . . . . . . 8 9.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 8 9.1.6. Securing Forwarding-Label . . . . . . . . . . . . . . 9 10. Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Motivation Forwarding-label provides flexibility to forward Interests on a name other than the one in the Interest message, and they are modifiable in the network. There are many situations when a forwarding-label can be used. o To handle producer mobility wherein efficient routing can be achieved through late-binding mechanism enabled as part of the mobility service handled by the network. o To address routing scalability, the forwarding-label allows to forward the Interests on a smaller set of locater names leading to domains capable of forwarding over location independent names. o To conduct service indirection, where service Interests can be handled in an opportunistic manner, for e.g. routing optimization. Ravindran & ChakrabortiExpires September 10, 2015 [Page 2] Internet-Draft Forwarding-label support in CCN March 2015 o To enable multi-protocol support, wherein overlaid applications with different Interest/Data semantics can be forwarded through a CCN network fabric. o For fast forwarding Interest packets, to mitigate the cost of lookup on variable sized hierarchical names in the FIB. Each of these use cases requires a control plane infrastructure to use the forwarding-label feature appropriately and avoid malicious usage, we provide a discussion of its use in the case of producer mobility in Section 9. 2. Forwarding-Label Management Forwarding-label is used in scenarios where routing by Interest name is not efficient or scalable. Hence its use should be strictly controlled to avoid exploitation. In this draft the discussion assumes such closed trusted environments like provider networks, where forwarding-label are inserted, swapped, or removed at designated points in the network. Forwarding-label being a network feature, edge routers shouldn't anticipate Interests with forwarding-label over its user-to-network interface (UNI). If it does, the network policy dictates if it trusts such re-directions or not. At the same time we don't exclude the case of use of forwarding-label by end applications. 3. On the Wire Forwarding-label is modifiable by the network, hence proposed as a hop-by-hop field in the optional body of the fixed header as shown in Figure 1. A new forwarding-label optional header of type Locater- Name is assigned to support this. Locater-Name (Figure 2) is a hierarchically structured variable length ID [1]. A locater-name implies an indirection point such as an AS-, Gateway-, or Service- ID. In addition to the Name TLV, security attributes such as authentication information can be included as well depending on specific use case scenarios. Ravindran & ChakrabortiExpires September 10, 2015 [Page 3] Internet-Draft Forwarding-label support in CCN March 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fixed Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T_LOCATER_NAME | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (Name TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Attributes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Optional TLV to Allow Forwarding Label As forwarding-labels can be used for other purposes too, future extensions may introduce more such types of forwarding-labels. +----------------------+------------------+-----------------+ | Forwarding-Label | Meaning | Value | +----------------------+------------------+-----------------+ | Locater-Name | Identifies an | Name TLV | | | AS-ID/Gateway/ | | | | Service Point | | +----------------------+------------------+-----------------+ Figure 2: Locater-Name Definition 4. Forwarding Label Processing Rules The following discussion is based on the assumption that all forwarders must process optional header fields, and rules of processing when it encounters a forwarding-label of type locater- name. o During Interest packet processing when the forwarding decision is being made, if a locater-name is available then it should be preferred to the name in the Interest message for forwarding, even if there is an entry to forward the Interest based on the name in the Interest message. o If the lookup based on locater-name succeeds then two possibilities exist: for non-terminating flows, the FIB lookup results in a next hop and the Interest is forwarded ; for Ravindran & ChakrabortiExpires September 10, 2015 [Page 4] Internet-Draft Forwarding-label support in CCN March 2015 terminating flows, if the locater-name matches the name of a local service, the service either re-resolves the Interest name to another locater-name or can decide to remove it and subject the Interest to regular processing based on the name in the Interest message. o If the FIB lookup based on the locater-name fails, then the router can try to forward it based on the Interest message name. If the latter fails, then the router could raise a error condition and feedback the message to the previous hop with appropriate error code. o This draft doesn't address the case when a forwarder encounters Interests with multiple forwarding-labels, even though there may be services that can use this feature to leverage multi-path route towards the producer(s). A forwarder treats this case as an error condition and notifies the previous hop. This issue can also be addressed at the first router inserting the forwarding-label, i.e. if the router performing the Interest name to forwarding-label mapping has a set of labels to choose from, it only inserts one of them considering routing policies or other service requirements. 5. PIT Processing Implications To maintain simplicity of forwarding logic the purpose of forwarding- label should be to guide the Interest to the producer, hence only be used for forwarding decision and not required for content object processing, however there may be other usage scenarios which may use it for content object processing too. We present both these scenarios. If forwarding-label is decoupled from the Interest name, consideration here is towards Interests for the same name arriving with different forwarding-labels. To handle this situation, PIT is required to save the forwarding-label along with the Interest message attributes. While processing such Interests, even though they can be aggregated as usual, the recent Interest should be forwarded to serve the purpose of the forwarding-label. Also in this case the returning content object needn't include the forwarding-label, as it is not used to match the pending Interests in the reverse path. There may be scenarios when it is required to insulate the choice of one Interest's forwarding-label from another. In this case, the returning content object should carry back the forwarding-label and match it against the pending PIT entry before forwarding to the previous hop. Also if the forwarding-label is swapped by intermediate routers, then the content object should be appended with Ravindran & ChakrabortiExpires September 10, 2015 [Page 5] Internet-Draft Forwarding-label support in CCN March 2015 the right forwarding-label to ensure the PIT match, these considerations are similar to those elaborated in [7]. 6. Caching Implications The considerations here follows from our discussion in the previous section. If usage of forwarding-label is decoupled from the Interest name, then the content object doesn't contain the forwarding-label and this information is not used against the incoming Interests. If there is a implicit security binding between the Interest name and the forwarding-label then the forwarding-label state is saved along with the content object, and should be matched against the incoming Interests before the cached content object is returned. 7. Multiple Domain Scenario In wide area network scenarios, Interests cross multiple domains. If forwarding-label is only trusted within domain boundaries, then the forwarding-label is removed before forwarding the Interest to the next domain, or this can also be performed by ingress node of the domain, which then inserts a new forwarding label with associated security attributes. The domain level scope of the labels also comes at a cost of performing Interest name to forwarding-label lookup in each domain. But if sufficient trust exists between domains to use the forwarding- label inserted by the previous domain, then the intermediate domains could avoid name lookup to determine the appropriate forwarding- label. 8. Security Considerations In general hop-by-hop fields are exposed to security threats emanating from threats like router compromise; however the exploitation of the forwarding-label is also related to the purpose it is used for and the control plane mechanism used to manage them. Depending on the use case scenario of the forwarding-label appropriate security mechanisms should be applied to secure the control and data planes to avoid exploitation of this feature. We elaborate this in the case of producer mobility in Section 9. 9. Use Case Scenarios Here we provide the discussions related to using forwarding-label in different scenarios. Ravindran & ChakrabortiExpires September 10, 2015 [Page 6] Internet-Draft Forwarding-label support in CCN March 2015 9.1. Handling Producer Mobility In this scenario we show the use of forwarding-label to handle producer mobility [4][6]. 9.1.1. Mobility as Network Service Forwarding-label based proposal [4] stresses on routing efficiency achieved by network-based mobility service using a name resolution system. The proposal supports inter- session/domain mobility, while intra-session mobility can be supported through signaling between the attachment points and using the forwarding-label to re-direct the flow to the new attachment point. 9.1.2. Differentiating Mobile Flows Supporting mobility service incurs cost in terms of control and data plane overhead. Hence means to identify flows that require mobility support is required to avoid the default case of treating all Interest flows failing the FIB lookup to be treated as requiring mobility support. This can be can be inferred in multiple ways: 1) consuming application explicitly identifying it in the Interest packet, either through fixed header marking or through metadata attributes in the Interest message; 2 ) by a certain prefix component in the Interest name indicating the use of the mobility service. 9.1.3. Using Forwarding-Label A high level description of using the forwarding-label for producer mobility is given below. o For Interest which require the use of mobility service, the edge service router invokes the name resolution system querying it with the name in the Interest payload. The result of name resolution is a locater-name. o This name is inserted as a forwarding-label TLV in the Interest packet and used in the FIB decision process. o Once the Interest reaches the router owning the locater-name, the mobility service logic is invoked to check if the Interest name is a locally registered prefix (only true if the Interest arrives at the mobile device's attachment point). If so, the forwarding- label is removed and the Interest is forwarded based on the FIB; else another name resolution lookup is performed and a new locater-name is inserted in the Interest and forwarded to the next hop using the new forwarding-label. Ravindran & ChakrabortiExpires September 10, 2015 [Page 7] Internet-Draft Forwarding-label support in CCN March 2015 o The resolved names can be cached locally in the router, so that future Interests belonging to the same flow can be resolved locally instead of performing a name resolution lookup. o Forwarding-label enables re-direction of Interest to producer's latest location enabling mobility for devices within a domain or between domains. While name resolution system updates are effective to handle mobility at longer timescales; forwarding- label can be used to late-bind Interests when the device hand- overs from one attachment point to another, enabling seamless mobility during the current session. 9.1.4. Name Resolution System A name resolution system is required to map the persistent name to the locater-name. The system could be a global name resolution system or a decentralized system. The discussion here is based on a decentralized name resolution system. Compared to flat-ID, human readable name semantic can be used to derive the name of the home-domain's resolution controller where the names of the mobile entities can be resolved. For e.g., /enterprise/alice/phone can be resolved by contacting the domain controller managed by alice's enterprise, whose name could be /enterprise/mobility-controller. The registration of a mobile prefix is done by the attachment-point receiving the prefix-registration request from the mobile node (MN) i.e. the producer. The attachment- point then registers the prefix to the name resolution system. When ever the MN moves to another domain, the domain's mobility controller updates the home controller about the MN's latest location. 9.1.5. Example This example is discussed considering a decentralized name resolution system, considering ATT as the service provider. We assume the mobility of device mP is handled by attachment point AP-x which is the first CCN hop from mP. mP desires to register a prefix /Att/mP/Shared-Video/ for mobility support. It sends a prefix registration message to AP-x, which registers it with its local name resolution system and also as an entry in its own FIB. The mapping information in the local domain controller maps service name /Att/mP/ Shared-Video/ to the forwarding-label /Att/mobility. /Att/mobility is assumed to be served by a set of border nodes in the Att domain. Routing optimization can be achieved by creating further hierarchy of this prefix. Ravindran & ChakrabortiExpires September 10, 2015 [Page 8] Internet-Draft Forwarding-label support in CCN March 2015 When consumer C requests for content from this service, assuming the Interest is marked as a mobile flow, the edge service router in C1's domain requests resolution of /Att/mP/Shared-Video/ to its own domain controller. C's domain controller determines Att as its home domain and forwards the request to /Att/mobility-controller for resolution. When the edge service router in C's domain receives the forwarding- label response, i.e. /Att/mobility, it is appended to the Interest message for forwarding. If the domains trusts the forwarding-label from its neighboring domains, /Att/mobility is enough to forward the Interest to Att border router(s) servicing mobile entities. Else, the forwarding-label is popped and pushed by the border nodes at the inter-domain boundary. Once the Interest arrives at the border routers servicing the prefix /Att/mobility, the service further resolves the name through its local domain controller to the current attachment point, in this case /AP-x. The forwarding-label is updated by the border router and forwarded towards AP-x. If the mobile prefix is still actively registered at AP-x, it is forwarded to mP, else AP-x can attach another forwarding-label to forward the Interest to the new AP-y, this handles the case of seamless mobility. 9.1.6. Securing Forwarding-Label Generally, the major threats against the forwarding label approach is to manipulate the mapping between the name and the forwarding-label. Such manipulations can happen in various scenarios, some of which are listed as follows: (i) a malicious interceptor (acting as a publisher) intentionally injects incorrect mapping into the name resolution system; (ii) the 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 ; or (iii) compromised intermediate routers maliciously change the forwarding-label, e.g., with the wrong forwarding-label or out-dated forwarding-label. Appropriate security mechanisms should be applied to provide mapping provenance, mapping integrity and anti-replay attack to address these issues. The security mechanisms applicable to (i) and (ii) are similar to ones applied to secure other mapping systems such as LISP [2],DNS[3], (iii) requires new security mechanisms, one such way is to enable a domain level trust infrastructure so that the mapping between the name and the forwarding-label can be authenticated by successive routers. Ravindran & ChakrabortiExpires September 10, 2015 [Page 9] Internet-Draft Forwarding-label support in CCN March 2015 10. Informative References [1] CCN Wire format, CCNX1., "http://www.ietf.org/id/ draft-mosko-icnrg-ccnxmessages-00.txt.", 2013. [2] LISP-Security, LISP-SEC., "https://tools.ietf.org/html/ draft-ietf-lisp-sec-07.", 2014. [3] DNS Security Introduction and Requirements, DNS-SEC., "http://www.ietf.org/rfc/rfc4033.txt.", 2005. [4] Azgin, A., Ravindran, R., and G. Wang, "A Scalable Mobility-Centric Architecture for Named Data Networking.", ICCCN (Scene Workshop) , 2014. [5] Cisco System Inc., CISCO., "Cisco visual networking index: Global mobile data traffic forecast update.", 2009-2014. [6] Zhang, Y., Zhang, H., and L. Zhang, "Kite: A Mobility Support Scheme for NDN.", NDN, Technical Report NDN-0020 , 2014. [7] CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/ ccnx-mosko-labelforwarding-01.txt.", 2013. Authors' Addresses Ravishankar Ravindran Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Email: ravi.ravindran@huawei.com Asit Chakraborti Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Email: asit.chakraborti@huawei.com Ravindran & ChakrabortiExpires September 10, 2015 [Page 10]