Use Cases for SPUD
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Network Working Group T. Hardie Internet-Draft Google Intended status: Informational February 11, 2015 Expires: August 15, 2015 Use Cases for SPUD draft-hardie-spud-use-cases-00 Abstract SPUD is a prototype for grouping UDP packets together in a session. 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 session 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 in a session. 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 session 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 session, along with basic session semantics (start and stop). By explicitly signaling session start and stop, 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 session 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 session 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 session 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-00>. Author's Address Ted Hardie Google Email: email@example.com Hardie Expires August 15, 2015 [Page 5]