Internet DRAFT - draft-hardie-spud-use-cases
draft-hardie-spud-use-cases
Network Working Group T. Hardie
Internet-Draft Google
Intended status: Informational February 12, 2015
Expires: August 16, 2015
Use Cases for SPUD
draft-hardie-spud-use-cases-01
Abstract
SPUD is a prototype for grouping UDP packets together. This grouping
allows on-path network devices, especially middleboxes such as NATs
or firewalls, to understand some basic semantics and potentially
to offer salient information about their functions or the path to the
endpoints. This document describes basic use cases for sharing that
semantic and for using the information shared.
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 15, 2015.
Copyright Notice
Copyright (c) 2015 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
Hardie Expires August 15, 2015 [Page 1]
Internet-Draft SPUD-uses February 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Application to Path Use Cases . . . . . . . . . . . . . . . . 2
3. Path to Application Use Cases . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
SPUD [draft-hildebrand-spud-prototype] is a prototype for grouping
UDP packets together. This grouping allows on-path network devices,
especially middleboxes such as NATs or firewalls, to understand basic
session semantics and potentially to offer salient information about
their functions or the path to the endpoints. This document
describes basic use cases for sharing that semantic and for using the
information shared
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STuPiD
implementations.
2. Application to Path Use Cases
The primary use case for application to path signaling is the
indication of which packets traveling between two endpoints make up a
an application-layer group, along with basic related semantics (start
and stop). By explicitly signaling start and stop semantics, a flow
allows middleboxes to use those signals for setting up and tearing
down their relevant state (NAT bindings, firewall pinholes), rather
than requiring the middlebox to infer this state from continued
traffic. At best, this would allow the application to refrain from
sending heartbeat traffic, which might result in reduced radio
utilization (and thus greater battery life) on mobile platforms.
Hardie Expires August 15, 2015 [Page 2]
Internet-Draft SPUD-uses February 2015
A use case suitable for experimentation might be the management of
multiple UDP flows going between the same two endpoints. This
occurs, for example, in WebRTC. There the application may be willing
to disclose which UDP flows are media traffic rather than data
channel traffic. Now middleboxes may now have to examine multiple
encrypted packets in the SRTP packet train to infer which flows are
media, so having an explicit indication might speed appropriate
treatment by the network.
An application may also be willing to indicate ordinal priority among
those flows which are not bundled, if it believes the network
assigned priority might be inappropriate (bundling all media above
all data may not, after all, match the application semantics for
games or other applications). A more complex example would be the
browser signaling whether it is using a particular congestion control
algorithm (future RMCAT work vs. the "circuit breaker" baseline.)
Note that in none of these cases is the signaling between the
application path mandatory; if elements along the path do not
understand or choose to ignore these signals, the flow proceeds as
before.
3. Path to Application Use Cases
The primary use case for path to application signaling is parallel to
the use of ICMP [ICMP], in that it describes a set of conditions
(including errors) that applies to the datagrams as they traverse the
path. This usage is, however, not a pure replacement for ICMP but a
"5-tuple ICMP". Since policy may cause different middleboxes to be
on path for different application, the path for different
applications may have both different elements and different
constraints; this signaling would enable these different constraints
to be transmitted to the sending application. A minimal set of such
ICMP-like messages would be: the moral equivalent of "packet too
big"; something like the "next-hop MTU" message; a notification of
(near) congestion similar to ECN[RFC3168]; and an address-family
conversion message.
A use case suitable for further experimentation might be the
signaling of known network constraints. An on-path router or access
point might, for example, indicate the upstream bandwidth when it
would be surprising (e.g. when cellular backhaul is used).
Note again that in none of these cases is the signaling mandatory; if
elements along the path do not send or the application choose to
ignore these signals, the flow proceeds as before.
Hardie Expires August 15, 2015 [Page 3]
Internet-Draft SPUD-uses February 2015
Because of the risk that an attacker with access to the path may send
spurious signals, applications should in general "trust but verify"
data received from the path. That is, the information received may
form the basis of tests that confirm network conditions like the
reported MTU.
4. Security Considerations
In addition to the security risks associated with spurious messages
inserted by attackers noted above, it is important to note that the
failure of this substrate should never result in a fallback to
plaintext. For encrypted flows, if this substrate fails to perform
correctly, the correct fallback is to fully encrypted flows like
those carried by DTLS [RFC6347]
The privacy objective here is to enable UDP-based transports whose
payload is fully encrypted to have very simple semantics exposed to
the path elements which might otherwise required access to plaintext.
Obviously, any exposure beyond the standard 5-tuple involves some
information sharing which is not required for packet delivery. There
are potential attacks that use start and stop semantics to infer
known plain text for a common protocol, those they require
cryptographic attacks or failures which are not common. Later
versions of this document will explore the cases in which use of SPUD
to expose those semantics is not appropriate.
5. IANA Considerations
This document makes no requests of IANA.
6. Acknowledgements
This document arose out of the IAB SEMI workshop. In particular, Joe
Hildebrand and Brian Trammel guided the shape of the document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[ICMP] Postel, J., "Internet Control Message Protocol", September
1981, <https://tools.ietf.org/html/rfc792>.
Hardie Expires August 15, 2015 [Page 4]
Internet-Draft SPUD-uses February 2015
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[draft-hildebrand-spud-prototype]
Trammel, B., "Session Protocol for User Datagrams
Prototype", February 2015, <https://tools.ietf.org/html/
draft-hildebrand-spud-prototype-01>.
Author's Address
Ted Hardie
Google
Email: ted.ietf@gmail.com
Hardie Expires August 15, 2015 [Page 5]
