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]