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

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 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:

• 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).
• 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).
• 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.
• Extensions to signaling protocols can result in false negatives or false positives during inspection.
• 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 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:

• 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.
• 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.
• 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.
• 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).
• 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 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.
• 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.
• 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.
• 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.

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.

7. References

Authors' Addresses