Internet Engineering Task Force P. Fan Internet-Draft H. Deng Intended status: Informational China Mobile Expires: November 22, 2014 M. Boucadair France Telecom T. Reddy C. Eckel Cisco Systems, Inc. May 21, 2014 Application Enabled Collaborative Networking: Problem Statement and Requirements draft-conet-aeon-problem-statement-00 Abstract Identification and treatment of application flows are important to many application providers and network operators. They often rely on these capabilities to deploy and/or support a wide range of applications. These applications, and the packet flows they generate and consume, may have specific connectivity requirements that can be met if made known to the network. Historically, this functionality has been implemented to the extent possible using heuristics, which inspect and infer flow characteristics. Heuristics may be based on port ranges, network separation (e.g. subnets or VLANs, Deep Flow Inspection (DFI), or Deep Packet Inspection (DPI). But many application flows in current usages are dynamic, adaptive, time- bound, encrypted, peer-to-peer, asymmetric, used on multipurpose devices, and have different priorities depending on direction of flow, user preferences, and other factors. Any combination of these properties renders heuristic based techniques less effective and may result in compromises to application security or user privacy. 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." Fan, et al. Expires November 22, 2014 [Page 1] Internet-Draft AEON/CONET Problem Statement and Req May 2014 This Internet-Draft will expire on November 22, 2014. Copyright Notice Copyright (c) 2014 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 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 2.1. Types of Signaling . . . . . . . . . . . . . . . . . . . 3 3. Typical Workflows . . . . . . . . . . . . . . . . . . . . . . 4 4. Limitations of Heuristic Based Solutions . . . . . . . . . . 4 5. Limitations of Existing Signaling Mechanisms . . . . . . . . 5 6. Efforts in Progress . . . . . . . . . . . . . . . . . . . . . 6 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Networks today, whether public or private, are challenged with demands to support rapidly increasing amounts of traffic. New channels for creating and consuming rich media are deployed at a rapid pace. Pervasive video and access on demand are becoming second nature to consumers. Communication applications make extensive use of rich media, placing unprecedented quality of experience expectation on the underlying network. These trends present challenges for network forecast and planning operations. Now more so than ever before, identification and treatment of application flows are critical for the successful deployment and operation of a growing number of business and household applications. These applications are based on wide range of signaling protocols and deployed by a diverse set of application providers that is not Fan, et al. Expires November 22, 2014 [Page 2] Internet-Draft AEON/CONET Problem Statement and Req May 2014 necessarily affiliated with the network providers across which the applications are used. Historically, identification of application flows has been accomplished using heuristics, which infer flow characteristics based on port ranges, network separation, or inspection of the flow itself. Inspection techniques include DPI, which matches against characteristic signatures (e.g. key string, binary sequence, etc.) and DFI, which analyzes statistical characteristics and connection behavior of flows. Each of these techniques suffers from a set of limitations, particularly in the face of the challenges on the network outlined previously. Heuristic-based approaches may not be efficient and require continuous updates of application signatures. Port based solutions suffer from port overloading and inconsistent port usage. Network separation techniques like IP subnetting are error prone and increase network management complexity. DPI and DFI are computationally expensive, prone to error, and become more challenging with greater adoption of encrypted signaling and secured media. An additional drawback of DPI and DFI is that any insights are not available, or need to be recomputed, at network nodes further down the application flow path. As the IETF establishes default behaviors that thwart pervasive surveillance (e.g. [RFC7258]), it will be important to provide mechanisms for applications that want to have the network provide differential flow treatment for their data. The intent is to have applications protect the contents of their flows, yet have the ability to opt-in to information exchanges that provide a more precise allocation of network resources and thus a better user experience. 2. Definitions and Terminology 2.1. Types of Signaling The following terms describe the relationship between signaling and the media to which it is associated. o off-path: signaling along a different network path than the media flow o on-path: signaling along the same network path as the media flow * in-band: signaling on the same port as the media flow * out-of-band: signaling on a different port than the media flow Fan, et al. Expires November 22, 2014 [Page 3] Internet-Draft AEON/CONET Problem Statement and Req May 2014 3. Typical Workflows Various heuristic based approaches are used prevalently and successfully for the following workflows: 1. Provide network operators with visibility of traffic usage and patterns for troubleshooting, capacity planning, and other off network workflows. This is done by exporting observed traffic analysis via standard protocols such as IPFIX [RFC7011] and SNMP [RFC3416]as well as by proprietary protocols and methods. 2. Provide network operators with visibility of application and data usage for accounting and billing. 3. Provide differentiated network services for specific traffic according to network operator defined policies, including traffic classification, policing and shaping (e.g. [RFC2475]), providing admission control (e.g. [RFC6601]), impacting routing, and permitting passage of specific traffic (e.g. firewall functions). 4. Limitations of Heuristic Based Solutions These typical workflows, visibility and differentiated network services, are critical in many networks. However, their reliance on inspection and observation limits the ability to enable these workflows more widely. Reasons for this include the following: o Identification based on IP address lists is difficult to manage. The addresses may be numerous and may change, or they may be dynamic, private, or otherwise not meant to be exposed. With Content Delivery Network InterConnection (CDNI) [RFC6770], content could be served either from an upstream CDN (uCDN) or any of a number of downstream CDNs (dCDN), and it will not be possible to manually track the IP addresses of all the CDN surrogates. Even in cases where identification by IP addresses is possible, more granular identification of individual flows is not possible (e.g. audio vs. video vs. data). o Classification based on TCP/UDP port numbers often result in incorrect results due to port overloading (i.e. ports used by applications other than those claiming the port with IANA). o More and more traffic is encrypted, rendering DPI and DFI impossible, inefficient, or much more complex, and sometimes at the expense of privacy or security (e.g. need to share encryption keys with intermediary proxy performing DPI/DFI). Fan, et al. Expires November 22, 2014 [Page 4] Internet-Draft AEON/CONET Problem Statement and Req May 2014 o Visibility generally requires inspecting the signaling traffic of applications. This traffic may flow through a different network path than the actual application data traffic. Impacting the traffic behavior is ineffective in those scenarios. o Extensions to signaling protocols and changes in the ways application use them can result in false negatives or false positives during inspection. o Inspection techniques are completely non-standard, so the ability and accuracy to identify traffic varies across vendors, and different implementation are likely to give different results for the same traffic. o Inspection techniques that require parsing the payload of packets (e.g. DPI) impact performance due to additional processing, and impact memory due to the growing number and size of signatures to identify new protocols. o Network services leveraging heuristic based classification impact the application behavior by impacting its traffic, but they do not provide explicit feedback to the application. This results in a lost opportunity for the application to gain insight and adjust its operation accordingly. 5. Limitations of Existing Signaling Mechanisms The IETF has standardized several mechanisms involving explicit signaling between applications and the network that may be used to support visibility and differentiated network services workflows. Unfortunately, none of these has experienced widespread deployment success, nor are they well suited for the applications usages described previously. Existing signaling options include the following: o RSVP [RFC2205] is the original on-path signaling protocol standardized by the IETF. It is transported out-of-band and could be used to signal information about any transport protocol traffic (it currently supports TCP and UDP). Its original goal was to provide admission control. Its requirement for explicit reservation of resources end to end proved too heavy for most network environments. Its success was further impacted by its reliance on router-alert, which often leads to RSVP packets being filtered by intervening networks, and by its requirement for access to a raw socket, something that is generally not available to applications running in user space. To date, more lightweight signaling workflows utilizing RSVP have not been standardized within the IETF. Fan, et al. Expires November 22, 2014 [Page 5] Internet-Draft AEON/CONET Problem Statement and Req May 2014 o NSIS (next Steps in Signaling) [RFC5978] is the next iteration of RSVP-like signaling defined by the IETF. It focused on the same fundamental workflow as RSVP admission control as its main driver, and because it did not provide significant enough use-case benefits over RSVP, it has seen even less adoption than RSVP. o DiffServ [RFC4594] and VAN Tagging [IEEE-802.1Q] style packet marking can help provide QoS in some environments, but such markings are often modified or removed at various points in the network or when crossing network boundaries. There are additional limitations when using DiffServ with real-time communications applications, and the DART working group has been chartered to write a document that explains the limitations that exist with DiffServ when used with RTP in general as well in the specific RTCWeb use cases [I-D.ietf-rtcweb-use-cases-and-requirements]. 6. Efforts in Progress Not surprisingly, there are several evolving proposals that aim to address the visibility and differentiated network services workflows where existing approaches are not sufficient. Protocol specific extensions are being defined, creating duplicate or inconsistent information models. This results operational complexity and a need to convert information between protocols to leverage the best protocol option for each specific use case. Examples of evolving signaling options include the following: o STUN [RFC5389] is an on-path, in-band signaling protocol that could be extended to provide signaling to on-path network devices. It provides an easily inspected packet signature, at least for transport protocols such as UDP. Through its extensions TURN [RFC5766] and ICE [RFC5245], it is becoming prevalent in application signaling driven by the initial use-case of providing NAT and firewall traversal capabilities and detecting local and remote candidates for peer-to-peer media sessions. The TRAM working group is chartered to update TURN and STUN to make them more suitable for WebRTC. o Port Control Protocol (PCP) [RFC6887] provides a mechanism to describe a flow to the network. The primary driver for PCP is creating port mappings on NAT and firewall devices. When doing this, PCP pushes flow information from the host into the network (specifically to the network's NAT or firewall device), and receives information back from the network (from the NAT or firewall device). It is not meant to be used end-to-end but rather independently on one "edge" of a flow. It is therefore an attractive alternative because it allows the introduction of Fan, et al. Expires November 22, 2014 [Page 6] Internet-Draft AEON/CONET Problem Statement and Req May 2014 application to network signaling without relying on the remote peer. This is especially useful in multi-domain communications. o RESTCONF [I-D.ietf-netconf-restconf] is a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF [RFC6241]. It is meant to provide a standard mechanism for web applications to access the configuration data, operational data, data-model specific protocol operations, and notification events within a networking device, in a modular and extensible manner. o Interface to the Routing System (I2RS) is a working group chartered to provide interfaces for management applications, network controllers, and user applications to make specific demands on the network. o Abstraction and Control of Transport Networks (ACTN) is a non- working group mailing list intended to enable discussion of the architecture, use-cases, and requirements that provide abstraction and virtual control of transport networks to various applications/ clients. o Prefix coloring has been proposed for use in HOMENET and 6MAN working groups to provide differentiated services to applications based on IP address. o RTP Media Congestion Avoidance Techniques (RMCAT) has been chartered to address the lack of generally accepted congestion control mechanisms for interactive real-time media, which is often carried via sets of flows using RTP over UDP. Explicit exchanges of flow characteristics and congestion information between applications and the network could play an important role in such mechanisms. o Transport Services (TAPS) is an effort to create a working group to define transport services that are exposed to internet applications. A TAP enabled application identifies its needs of the locally available transports services via an API. Some of the information provided is the same as what AEON proposes to have the application communicate to the network. Furthermore, the transport services of TAPS could benefit from this communication with the network. o Service Function Chaining (SFC) is a working group chartered to address issues associated with the deployment of service functions (e.g. firewalls, load balancers) in large-scale environments. Service function chaining is the definition and instantiation of an ordered set of instances of such service functions, and the Fan, et al. Expires November 22, 2014 [Page 7] Internet-Draft AEON/CONET Problem Statement and Req May 2014 subsequent "steering" of traffic flows through those service functions. Flow characteristics communicated via AEON could be used as input into an SFC classifier and it could be transported as SFC metadata. 7. Requirements Rather than encourage independent, protocol specific solutions to this problem, this document advocates a protocol and application independent information model and individual data models that can be applied in a consistent fashion across a variety of protocols to enable explicit communication between applications and the networks on which they are used. The requirements are: Req-1: Allow applications to explicitly signal their flow characteristics to the network. Req-2: Provide network nodes visibility to application flow characteristics. Req-3: Enable network nodes to contribute to application flow descriptions. Req-4: Allow applications to receive resulting flow descriptions as feedback from the network. Req-5: Complement existing heuristic based mechanisms. Req-6: Provide differentiated service for both directions of a flow, including flows that cross administrative boundaries. Req-7: Provide mechanism to authenticate and authorize endpoints/ applications to signal flow characteristics, including 3rd party authentication and authorization for over-the-top (OTT) applications. Req-8: Provide mechanism for integrity protection and replay protection of messages exchanged between the application and the network. 8. Acknowledgements The authors thank Toerless Eckert, Reinaldo Penno, Dan Wing, Amine Choukir, Paul Jones, and Bill VerSteeg for their contributions to this document. Fan, et al. Expires November 22, 2014 [Page 8] Internet-Draft AEON/CONET Problem Statement and Req May 2014 9. Informative References [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work in progress), March 2014. [I-D.ietf-rtcweb-use-cases-and-requirements] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use-cases and Requirements", draft- ietf-rtcweb-use-cases-and-requirements-14 (work in progress), February 2014. [IEEE-802.1Q] "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", IEEE 802.1Q, 2005, . [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Fan, et al. Expires November 22, 2014 [Page 9] Internet-Draft AEON/CONET Problem Statement and Req May 2014 [RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks", RFC 6601, April 2012. [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013. [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014. Authors' Addresses Peng Fan China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 P.R. China Email: fanpeng@chinamobile.com Hui Deng China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 P.R. China Email: denghui@chinamobile.com Fan, et al. Expires November 22, 2014 [Page 10] Internet-Draft AEON/CONET Problem Statement and Req May 2014 Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com Charles Eckel Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: eckelcu@cisco.com Fan, et al. Expires November 22, 2014 [Page 11]