Application Enabled Collaborative Networking: Problem Statement and Requirements
draft-conet-aeon-problem-statement-00

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,
              <http://standards.ieee.org/getieee802/download/
              802.1Q-2005.pdf>.

   [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]