idnits 2.17.1 draft-hardie-spud-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2015) is 3355 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie 3 Internet-Draft Google 4 Intended status: Informational February 11, 2015 5 Expires: August 15, 2015 7 Use Cases for SPUD 8 draft-hardie-spud-use-cases-00 10 Abstract 12 SPUD is a prototype for grouping UDP packets together in a session. 13 This grouping allows on-path network devices, especially middleboxes 14 such as NATs or firewalls, to understand basic session semantics and 15 potentially to offer salient information about their functions or the 16 path to the endpoints. This document describes basic use cases for 17 sharing that session semantic and for using the information shared. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 15, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Application to Path Use Cases . . . . . . . . . . . . . . . . 2 56 3. Path to Application Use Cases . . . . . . . . . . . . . . . . 3 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 7.2. Informative References . . . . . . . . . . . . . . . . . 4 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 SPUD [draft-hildebrand-spud-prototype] is a prototype for grouping 68 UDP packets together in a session. This grouping allows on-path 69 network devices, especially middleboxes such as NATs or firewalls, to 70 understand basic session semantics and potentially to offer salient 71 information about their functions or the path to the endpoints. This 72 document describes basic use cases for sharing that session semantic 73 and for using the information shared 75 1.1. Terminology 77 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 78 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 79 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 80 [RFC2119] and indicate requirement levels for compliant STuPiD 81 implementations. 83 2. Application to Path Use Cases 85 The primary use case for application to path signaling is the 86 indication of which packets traveling between two endpoints make up a 87 session, along with basic session semantics (start and stop). By 88 explicitly signaling session start and stop, a flow allows 89 middleboxes to use those signals for setting up and tearing down 90 their relevant state (NAT bindings, firewall pinholes), rather than 91 requiring the middlebox to infer this state from continued traffic. 92 At best, this would allow the application to refrain from sending 93 heartbeat traffic, which might result in reduced radio utilization 94 (and thus greater battery life) on mobile platforms. 96 A use case suitable for experimentation might be the management of 97 multiple UDP flows going between the same two endpoints. This 98 occurs, for example, in WebRTC. There the application may be willing 99 to disclose which UDP flows are media traffic rather than data 100 channel traffic. Now middleboxes may now have to examine multiple 101 encrypted packets in the SRTP packet train to infer which flows are 102 media, so having an explicit indication might speed appropriate 103 treatment by the network. 105 An application may also be willing to indicate ordinal priority among 106 those flows which are not bundled, if it believes the network 107 assigned priority might be inappropriate (bundling all media above 108 all data may not, after all, match the application semantics for 109 games or other applications). A more complex example would be the 110 browser signaling whether it is using a particular congestion control 111 algorithm (future RMCAT work vs. the "circuit breaker" baseline.) 113 Note that in none of these cases is the signaling between the 114 application path mandatory; if elements along the path do not 115 understand or choose to ignore these signals, the flow proceeds as 116 before. 118 3. Path to Application Use Cases 120 The primary use case for path to application signaling is parallel to 121 the use of ICMP [ICMP], in that it describes a set of conditions 122 (including errors) that applies to the datagrams as they traverse the 123 path. This usage is, however, not a pure replacement for ICMP but a 124 "5-tuple ICMP". Since policy may cause different middleboxes to be 125 on path for different application, the path for different 126 applications may have both different elements and different 127 constraints; this signaling would enable these different constraints 128 to be transmitted to the sending application. A minimal set of such 129 ICMP-like messages would be: the moral equivalent of "packet too 130 big"; something like the "next-hop MTU" message; a notification of 131 (near) congestion similar to ECN[RFC3168]; and an address-family 132 conversion message. 134 A use case suitable for further experimentation might be the 135 signaling of known network constraints. An on-path router or access 136 point might, for example, indicate the upstream bandwidth when it 137 would be surprising (e.g. when cellular backhaul is used). 139 Note again that in none of these cases is the signaling mandatory; if 140 elements along the path do not send or the application choose to 141 ignore these signals, the flow proceeds as before. 143 Because of the risk that an attacker with access to the path may send 144 spurious signals, applications should in general "trust but verify" 145 data received from the path. That is, the information received may 146 form the basis of tests that confirm network conditions like the 147 reported MTU. 149 4. Security Considerations 151 In addition to the security risks associated with spurious messages 152 inserted by attackers noted above, it is important to note that the 153 failure of this substrate should never result in a fallback to 154 plaintext. For encrypted flows, if this substrate fails to perform 155 correctly, the correct fallback is to fully encrypted flows like 156 those carried by DTLS [RFC6347] 158 The privacy objective here is to enable UDP-based transports whose 159 payload is fully encrypted to have very simple session semantics 160 exposed to the path elements which might otherwise required access to 161 plaintext. Obviously, any exposure beyond the standard 5-tuple 162 involves some information sharing which is not required for packet 163 delivery. There are potential attacks that use session start and 164 stop semantics to infer known plain text for a common protocol, those 165 they require cryptographic attacks or failures which are not common. 166 Later versions of this document will explore the cases in which use 167 of SPUD to expose those session semantics is not appropriate. 169 5. IANA Considerations 171 This document makes no requests of IANA. 173 6. Acknowledgements 175 This document arose out of the IAB SEMI workshop. In particular, Joe 176 Hildebrand and Brian Trammel guided the shape of the document. 178 7. References 180 7.1. Normative References 182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, March 1997. 185 7.2. Informative References 187 [ICMP] Postel, J., "Internet Control Message Protocol", September 188 1981, . 190 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 191 of Explicit Congestion Notification (ECN) to IP", RFC 192 3168, September 2001. 194 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 195 Security Version 1.2", RFC 6347, January 2012. 197 [draft-hildebrand-spud-prototype] 198 Trammel, B., "Session Protocol for User Datagrams 199 Prototype", February 2015, . 202 Author's Address 204 Ted Hardie 205 Google 207 Email: ted.ietf@gmail.com