ICN Research Group R. Ravindran Internet-Draft A. Chakraborti Intended status: Informational Huawei Technologies Expires: January 7, 2016 M. Mosko I. Solis PARC July 6, 2015 Support for Notifications in CCN draft-ravi-ccn-notification-00 Abstract This draft proposes a new packet primitive called Notification for CCN. Notification is a PUSH primitive and can be unicast or multicast to multiple listening points. Notifications do not expect a Content Object response hence only requires the use of FIB state in the CCN forwarder. Emulating Notification as a PULL has performance and forwarding implications. The draft proposes a new fixed header primitive called Notification and a CCN message encoding using Content Object primitive to transport Notifications. These discussions are presented in the context of CCNx1.0 [1] proposal. 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 January 7, 2016. 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 Ravindran, et al. Expires January 7, 2016 [Page 1] Internet-Draft Interest Notification July 2015 (http://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. Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notification Primitive in CCN . . . . . . . . . . . . . . . . 2 3. Notification Message Encoding . . . . . . . . . . . . . . . . 3 4. Notification Processing . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Motivation Notification is an important primitive in the Internet today widely used in many IoT and social applications. The nature of notifications varies with application scenario, ranging from being mission critical to one that is best effort. Notifications can be unicast or multicast depending on whether the notification service is aware of all the consumers or not. A notification service is preceded by a consumer subscribing to a specific event; a good example is subscription to hash-tag feeds, health emergency notification service, temperature sensor reading from a room in a building, following this subscription the service pushes notifications to consuming entities. It has to be noted that certain IoT applications expects notification end-to-end latency of few milliseconds [2]. Industrial IoT applications have more stringent requirement in terms of QoS, timeliness, and reliability of message delivery. Though we term it as a Notification, this primitive can also be used for transactional exchange between two points. 2. Notification Primitive in CCN CCN/NDN operates on PULL primitive catering primarily to content distribution applications. Emulating PUSH operation over PULL has following issues: 1) it is a mismatch between application intent to PUSH data and PULL API currently available; 2) unless marked distinctly, such packets may undergo PIT/CS processing and also subjected to similar routing policies as PULL which is inefficient, a good example is when PUSH and PULL shares similar routing prefix; 3) another concern of treating PUSH as PULL is with respect to the Ravindran, et al. Expires January 7, 2016 [Page 2] Internet-Draft Interest Notification July 2015 affect of local strategy layer routing policies, where the intent to experiment with multiple faces applied to fetch content is not desirable for notification messages. Currently notifications in CCN/NDN is supported by overloading the Interest primitive by setting its lifetime to zero [1]. Overloading lifetime to convey notifications is not desirable. Depending on the implementation, this approach may not avoid unnecessary processing of the notification traffic incurring packet processing delay in each CCN router. Also associated issues on PIT aggregation may arise if Interest with the same name arrives with non-zero lifetime, opening up the possibility of new attack vectors. Treating notifications as a separate class of traffic allows forwarder to apply appropriate processing , routing and forwarding logic for such type of traffic. Other approaches have been proposed such as modification to CCN transport applying new data structures as in [6], which complements the notification primitive proposed in this draft. Also it is important to note that other FIA architectures such as MobilityFirst [8] and XIA [9] supports both PUSH and PULL primitive. To address these concerns we propose a new primitive called Notifications. Notification is a new type of packet hence can be subjected to different processing logic by a forwarder. By definition a notification message is a PUSH primitive which doesn't expect any Content Object response, hence should not be subjected to PIT/CS processing. This primitive can also be used by any other transactional or content distribution application applied towards authentication or for exchanging contextual information. 3. Notification Message Encoding The Notification wire packet format is shown in Fig. 1 and Fig. 2. Fig. 1 shows its fixed header considering CCNx1.0 encoding, and Fig. 2 shows the CCN Notification message to transport the notification data. We next discuss these two packet segments of the Notification message. Ravindran, et al. Expires January 7, 2016 [Page 3] Internet-Draft Interest Notification July 2015 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 +---------------+---------------+---------------+--------------+ | Version | PacketType | PacketLength | +---------------+---------------+---------------+--------------+ | HopLimit | Reserved | Flags | HeaderLength | +---------------+---------------+---------------+--------------+ / Optional Hop-by-hop header TLVs / +---------------+---------------+---------------+--------------+ / CCN Notification Message / +---------------+---------------+---------------+--------------+ Figure 1: Notification fixed header 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 +---------------+---------------+---------------+--------------+ |MessageType = Content Object | MessageLength | +---------------+---------------+---------------+--------------+ | Name TLV | +---------------+---------------+---------------+--------------+ | Optional MetaData TLVs | +---------------+---------------+---------------+--------------+ | Message Payload Type | Message Type Length | +---------------+---------------+---------------+--------------+ | Optional Content Object | +---------------+---------------+---------------+--------------+ / Optional CCNx ValidationAlgorithm TLV / +---------------+---------------+---------------+--------------+ / Optional CCNx ValidationPayload TLV (ValidationAlg required) / +---------------+---------------+---------------+--------------+ Figure 2: CCN Notification Message Notification Fixed Header: The fields in the fixed header that have new meaning in the context of the notifications are discussed next, the other fields follow the definition in [1]. o Packet Type: This new type code identifies that the packet is of type Notification [TBD]. o Optional Hop-by-hop header TLVs : Encodes any new hop-by-hop headers relevant to notifications [TBD]. o PacketPayload TLV: This encodes the CCN notification message. Ravindran, et al. Expires January 7, 2016 [Page 4] Internet-Draft Interest Notification July 2015 CCN Notification message: The CCN Notification message is a Content Object as in [1], which optionally encapsulates another Content Object. The name in the top level Content Object is used for routing. The need for an encapsulated Content Object is application driven. If the Notification only includes the top level Content Object, the interpretation is that the producer and consumer agrees on the same name to transport the notification data. With an encapsulated Content Object the meaning is that notification producers and consumers operate on different name space. A good application of the encapsulation format is a PUB/SUB service, where the consumers learns about the notification service name offline, and the producers who are decoupled from the consumers generate new Content Objects using its own name and pushes it to the consumers. The interpretation of the fields shown in Fig. 2 are as follows: o MessageType : The CCN message type is of type Content Object. o Name TLV : Name TLV in the Content Object is used to route the Notification. o Optional Metadata TLV: These TLVs carry metadata used to describe the Notification payload. o Payload Type: This is of type T_PAYLOADTYPE defined in CCNx.1.0 or a new encapsulation type (T_ENCAP) that indicates the presence of another encapsulated Content Object [TBD]. o Optional Encapsulated Content Object: This is an optional encapsulated Content Object newly defined for the Notification primitive. The name in the encapsulated Content Object corresponds to the producer, or anything else based on the application logic. The rational for an encapsulated Content Object was discussed earlier. o Optional Security Validation data: The Content Object optionally carries security validation payload as per CCNx1.0. 4. Notification Processing The following steps are followed by a CCN forwarder processing Notification packet. o Notification packet type is identified in the fixed header of a CCN packet with a new type code. The Notification carries a Content Object, whose name is used for routing. This name is matched against the FIB entries to determine the next hop(s). Ravindran, et al. Expires January 7, 2016 [Page 5] Internet-Draft Interest Notification July 2015 Novel strategy layer routing techniques catering to the notification traffic can be applied here. o Optional metadata associated with the Notification meant for the network is processed by the forwarder, for e.g., mission critical notifications can be given priority over all other traffic. o As suggested earlier, Content Objects in the notifications shouldn't be cached by the intermediate forwarders. 5. Security Considerations The proposed processing logic of Notifications bypassing the PIT/CS has following security implications: Flow Balance : The PIT state maintains per-hop flow balance over all faces by enforcing one Content Object for an Interest send over a face. Bypassing PIT processing compromises this flow balancing property. For scenarios where the notification traffic volume is not high such as for IoT applications, the impact may not be significant. This may not be the case considering the plethora of social networking and emerging IoT applications in a general Internet scenario. This flow balance tradeoff has to be understood considering application intent to PUSH data and latency introduced due to processing such traffic if PULL primitive is used. Also PIT offers a natural defense mechanism by throttling traffic at the network edge considering the provisioned PIT size, bypassing it could exacerbate DDOS attacks on producing end points. Cache Poisoning: This draft doesn't recommend the caching of the Content Object in the Notification payload, though doing this helps in increasing the availability of notification information in the network. We leave this possibility of applying policy based caching of Notification Content Objects for future exploration. The recommendation for not caching these Content Object is that, in a regular Interest/Content Object exchange content arrives at the forwarder and is cached as a result of per-hop active Interest expression. Unsolicited Content Objects, as in the case of the Notification, violates this rule, which could be exploited by malicious producers to generate DDOS attack against the cache resource of a CCN infrastructure. 6. Use Case Scenarios Here we provide the discussions related to the use of Notification in different scenarios. Ravindran, et al. Expires January 7, 2016 [Page 6] Internet-Draft Interest Notification July 2015 7. Informative References [1] CCN Wire format, CCNX1., "http://www.ietf.org/id/ draft-mosko-icnrg-ccnxmessages-00.txt.", 2013. [2] Osseiran, A., "Scenarios for 5G Mobile and Wireless Communications: The Vision of the METIS Project.", IEEE Communication Magazine , 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] Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K. Ramakrishnan, "COPS: An Efficient Content Oriented Publish/Subscribe System.", ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS 2011) , 2011. [7] CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/ ccnx-mosko-labelforwarding-01.txt.", 2013. [8] NSF FIA project, MobilityFirst., "http://www.nets-fia.net/", 2010. [9] NSF FIA project, XIA., "https://www.cs.cmu.edu/~xia/", 2010. Authors' Addresses Ravishankar Ravindran Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Email: ravi.ravindran@huawei.com Ravindran, et al. Expires January 7, 2016 [Page 7] Internet-Draft Interest Notification July 2015 Asit Chakraborti Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Email: asit.chakraborti@huawei.com Marc Mosko PARC Palo Alto, California 94304 USA Phone: +01 650-812-4405 Email: marc.mosko@parc.com Ignacio Solis PARC Palo Alto, California 94304 USA Phone: +01 650-812-4405 Email: ignacio.solis@parc.com Ravindran, et al. Expires January 7, 2016 [Page 8]