Internet DRAFT - draft-eckel-aeon-problem-statement

draft-eckel-aeon-problem-statement







Internet Engineering Task Force                                 C. Eckel
Internet-Draft                                                  T. Reddy
Intended status: Informational                       Cisco Systems, Inc.
Expires: August 18, 2014                               February 14, 2014


Application Enabled Open Networking: Problem Statement and Requirements
                 draft-eckel-aeon-problem-statement-00

Abstract

   Identification and treatment of application flows are critical for
   the successful deployment and operation of applications.
   Historically, this functionality has been accomplished to the extent
   possible using heuristics, which inspect and infer flow
   characteristics.  Heuristics may be based on port ranges, network
   separation, or deep packet inspection (DPI).  But many application
   flows in current usages are dynamic, time-bound (short lived for some
   of them), possibly encrypted (TLS for signaling), peer-to-peer,
   possibly asymmetric, and used on non-dedicated devices, any
   combination of which renders such techniques less effective or
   results 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."

   This Internet-Draft will expire on August 18, 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



Eckel & Reddy            Expires August 18, 2014                [Page 1]

Internet-Draft       AEON Problem Statement and Req        February 2014


   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.  Typical Workflows . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Limitations of Existing Solutions . . . . . . . . . . . . . .   3
   4.  Efforts in Progress . . . . . . . . . . . . . . . . . . . . .   4
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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 demands on
   the network.

   Now more so than ever before, identification and treatment of
   application flows are critical for the successful deployment and
   operation of applications.  These applications are based on wide
   range of signaling protocols and deployed by a diverse set of
   application providers that is not necessarily affiliated with the
   network providers across which the applications are used.

   Historically, identification of application flows has been
   accomplished using heuristics, which inspect and infer flow
   characteristics.  Heuristics may be based on port ranges, network
   separation, or deep packet inspection (DPI).  Each of these
   techniques suffers from a set of limitations, particularly in the
   face of challenges on the network outlined previously.

   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 is
   computationally expensive and becomes a greater challenge with the
   wider adoption of encrypted signaling and secured media.  An
   additional drawback of DPI is that any insights are not available, or




Eckel & Reddy            Expires August 18, 2014                [Page 2]

Internet-Draft       AEON Problem Statement and Req        February 2014


   need to be recomputed, at network nodes further down the application
   flow path.

2.  Typical Workflows

   Various heuristic based approaches are used prevalently and
   successfully for two types of work flows:

   1.  Provide network operators with visibility into traffic for
       troubleshooting, capacity planning, accounting and billing, and
       other off network work flows.  This is done by exporting observed
       traffic analysis via protocols such as IPFIX and SNMP.

   2.  Provide differentiated network services for specific traffic
       according to network operator defined rule sets, including
       policing and shaping of traffic, providing admission control,
       impacting routing, and permitting passage of specific traffic
       (e.g. firewall functions).

3.  Limitations of Existing Solutions

   These typical work flows, visibility and differentiated network
   services, are critical in many networks.  However, their reliance on
   inspection and observation limits the ability to enable these work
   flows more widely.  Reasons for this include the following:

   o  Simple observation based 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 impossible, or
      much more complex, and sometimes at the expense of privacy or
      security (e.g. need to share encryption keys with intermediary
      performing DPI).

   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 can result in false negatives or
      false positives during inspection.

   o  Network services leveraging DPI traffic classification impact the
      application behavior by impacting its traffic, but they do not
      provide explicit feedback to the application.  This results in a




Eckel & Reddy            Expires August 18, 2014                [Page 3]

Internet-Draft       AEON Problem Statement and Req        February 2014


      lost opportunity for the application to gain insight and adjust
      its operation accordingly.

4.  Efforts in Progress

   There are a variety of existing and evolving signaling options that
   can provide explicit application to network signaling and serve the
   visibility and differentiated network services work flows where
   heuristics are currently being used.  It seems clear that there will
   be no single one-protocol-fits-all solution.  Every protocol is
   currently defined in its own silo, creating duplicate or inconsistent
   information models.  This results in duplicate work, more operational
   complexity and an inability to easily convert information between
   protocols to easily leverage the best protocol option for each
   specific use case.  Examples of existing and evolving signaling
   options include the following:

   o  RSVP is the original on path signaling protocol standardized by
      the IETF.  It operates on path out-of-band and could support any
      transport protocol traffic (it currently supports TCP and UDP).
      Its original goal was to provide admission control.  Arguably, its
      success was impacted by its reliance on router-alert because this
      often leads to RSVP packets being filtered by intervening
      networks.  To date, more lightweight signaling work flows
      utilizing RSVP have not been standardized within the IETF.

   o  NSIS (next Steps in Signaling) is the next iteration of RSVP-like
      signaling defined by the IETF.  Because it focused on the same
      fundamental work flow 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 style packet marking can help provide QoS in some
      environments but DSCP markings are often modified or removed at
      various points in the network or when crossing network boundaries.

   o  STUN is an on path, in-band signaling protocol that could easily
      be extended to provide signaling to on path network devices
      because it provides an easily inspected packet signature, at least
      for transport protocols such as UDP.  Through its extensions TURN
      and ICE, it is becoming quite popular in application signaling
      driven by the initial use-case of providing NAT and firewall
      traversal capabilities and determining the best local and remote
      addresses for peer-to-peer connectivity (ICE).

   o  Port Control Protocol (PCP) provides a mechanism to describe a
      flow to the network.  The primary driver for PCP has been creating
      port mappings on NAT and firewall devices.  When doing this, PCP



Eckel & Reddy            Expires August 18, 2014                [Page 4]

Internet-Draft       AEON Problem Statement and Req        February 2014


      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).  Unlike the prior protocols, it is not meant to
      be used on path end-to-end but rather independently on one "edge"
      of a traffic flow.  It is therefore an attractive alternative
      because it allows the introduction of application to network
      signaling without relying on the remote peer.  This is especially
      useful in multi-domain communications.

   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 its IP address.

5.  Requirements

   Rather than encourage independent, protocol specific solutions to
   this problem, this draft calls for a protocol and application
   independent solution that can be applied in a consistent fashion
   across a variety of protocols.  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.



Eckel & Reddy            Expires August 18, 2014                [Page 5]

Internet-Draft       AEON Problem Statement and Req        February 2014


   Req-7:  Provide mechanism to authenticate and authorize endpoints/
      applications to signal flow characteristics.

   Req-8:  Provide mechanism for integrity and replay protection of
      messages exchanged between the application and the network.

6.  Acknowledgements

   The authors thank Toerless Eckert, Reinaldo Penno, Dan Wing, Amine
   Choukir, and Paul Jones for their contributions to this draft.

Authors' Addresses

   Charles Eckel
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: eckelcu@cisco.com


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com





















Eckel & Reddy            Expires August 18, 2014                [Page 6]