idnits 2.17.1 draft-thomson-mux-principles-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7983, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 03, 2017) is 2334 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6347 (ref. 'DTLS') (Obsoleted by RFC 9147) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-02 -- Obsolete informational reference (is this intentional?): RFC 5389 (ref. 'STUN') (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5766 (ref. 'TURN') (Obsoleted by RFC 8656) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Updates: 7983 (if approved) December 03, 2017 5 Intended status: Informational 6 Expires: June 6, 2018 8 Principles for Multiplexing of UDP-based Protocols 9 draft-thomson-mux-principles-00 11 Abstract 13 The existence of protocols that rely on multiplexing of different 14 protocols could be used to justify the imposition of constraints on 15 the operation of other protocols. The existence of a multiplexed 16 protocol does not inherently justify constraints on protocols that 17 participate or might participate in the protocol. 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 https://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 June 6, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 (https://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 1. Introduction 53 The use of multiple protocols that share a 5-tuple is possible in 54 unordered transport like UDP. Multiplexing in this fashion creates a 55 meta-protocol that is comprised of the set of protocols that are 56 multiplexed. 58 A specific example of such a meta-protocol is documented in RFC 7983 59 [RT-MUX]. This protocol comprises up to 5 different protocols: STUN 60 [STUN], ZRTP [ZRTP], DTLS [DTLS], TURN channels [TURN], and RTP 61 [RTP]. The meta-protocol that is composed from this set of protocols 62 is commonly deployed for use in real-time communications. Of 63 particular note is the STUN protocol [STUN], which is specifically 64 designed to be multiplexed with another protocol. 66 The existence of a multiplexed meta-protocol can be used to justify 67 constraints on the definition of new protocols, or the addition of 68 changes to protocols that participate. These constraints should be 69 considered in the context of the protocol in use. A protocol design 70 for use outside of a multiplexed context should not be unduly 71 constrained by the limitations of a chosen multiplexing scheme. 73 2. Multiplexing is Almost Always Possible 75 Any protocol that includes integrity checks can be multiplexed with 76 any other protocol. A sufficiently strong checksum or cryptographic 77 authentication tag allows arriving datagrams to be rejected by any 78 protocol that the datagram was not intended for with high 79 probability. 81 New protocols often require confidentiality and integrity and so use 82 a solution like TLS [TLS]. Other protocols benefit greatly from 83 being robust against errors in the relatively weak checksum 84 [CHECKSUM] provided by internet protocols [CHECKSUM-FAIL]. Thus, the 85 inclusion of strong integrity checks is beneficial for any internet 86 protocol, which makes the protocol highly likely to be classified by 87 a recipient as intended. 89 Note: This does not mean that protocols are distinguishable to 90 intermediaries. Protocols that include use keyed integrity checks 91 will not be identifiable to entities that do not have access to 92 keys. 94 Relying on an integrity check also probabilistic, meaning that 95 shorter integrity checks increase the chance that a datagram could be 96 incorrectly classified by a recipient. While the probability of 97 collision is negligible for a protocol that uses an integrity check 98 with 128 bits or more of redundancy, a shorter integrity check could 99 be vulnerable to collisions and mis-classification. 101 As long as no more than one participating protocol lacks an integrity 102 check of sufficient strength, protocols can be demultiplexed with 103 high reliability. However, this form of demultiplexing can be 104 grossly inefficient, as every datagram needs to be validated once for 105 each potential protocol that is in use. 107 3. Multiplexing Considerations 109 Practical multiplexing schemes rely on simpler and more direct 110 differences between protocols. For instance, RFC 7983 [RT-MUX] 111 separates protocols based on the value of the first octet. While 112 this scheme is cheap and effective, it has the drawback of using a 113 limited space of potential values. Of the 256 possible values for 114 the first octet, RFC 7983 consumes 132 values. Adding more protocols 115 to the set that can be multiplexed would reduce the available space 116 further. 118 The design in RFC 7983 was initially opportunistic in nature. The 119 original set of protocols that were selected included only DTLS, 120 SRTP, and STUN. Since then, compatibility with that scheme has 121 constrained the design of other protocols so that they fit within 122 this scheme. This is not an indefinitely sustainable posture. 124 The need to multiplex can create unwanted constraints on the designs 125 of protocols, particularly as protocols evolve. For a protocol that 126 is used exclusively or predominantly in a multiplexed meta-protocol, 127 this does not present a significant burden, but protocols that have 128 uses in other contexts are different. 130 For instance, DTLS 1.3 [DTLS13] defines a record layout that uses the 131 first octet in a very different fashion to earlier versions; this 132 design is constrained by the need to remain compatible with the 133 scheme in RFC 7983 [RT-MUX]. 135 Multiplexing should not be a primary consideration in design of new 136 protocols that might be multiplexed. Similary, the design of 137 extensions or revisions to protocols should not be constrained by the 138 potential for multiplexing. Multiplexing considerations might be 139 paid greater attention depending on how likely it is that the 140 protocol will be used together with other protocols. 142 For example, a new version of RTP [RTP] might consider setting the 143 version field to 3. While this space in the multiplexing scheme in 145 [RT-MUX] is currently unallocated, changing the RTP version greatly 146 reduces the space available for other protocols. Because RTP is 147 frequently used in a multiplexed context, changing the RTP header is 148 best avoided. 150 3.1. Alternative Multiplexing Designs 152 Protocol multiplexing works most efficiently when the protocol in use 153 for any given packet can be identified using only the contents of the 154 packet. Stateful multiplexing - where multiplexing rules change 155 based on protocol state - is possible, but is best avoided. 157 A protocol that intends to multiplex several protocols can avoid this 158 sort of pressure by adding an explicit multiplexing protocol layer. 159 The simplest multiplexing protocol is a shim of a small number of 160 octets that is added to the start or end of every datagram. The 161 value of these octets is then used to identify the protocol. 163 For a scheme like that in [RT-MUX], it is possible to use a shim for 164 only some protocols, whether other protocols are multiplexed based on 165 their inherent observable properties. 167 Expanding the size of datagrams can have implications for protocol 168 operation. Trivially, it reduces the space in the path maximum 169 transfer unit (PMTU) [PMTUv4], [PMTUv6] available to the multiplexed 170 meta-protocol. 172 More substantially, the addition of octets to a protocol datagram - 173 especially at the start - can also mean that the apparent format of 174 datagrams changes. If a multiplexed meta-protocol adds octets to the 175 start of payloads, this reduces the degree to which the multiplexed 176 meta-protocol can be identified correctly. Some middleboxes have 177 been shown to observe and discriminate based on the content of flows, 178 even when large parts of a flow is encrypted and therefore 179 inaccessible to the middlebox. Octets added to the start of a 180 datagram could cause middleboxes to apply different treatment to a 181 protocol when it is multiplexed than when it is not. 183 4. No Expectation of Successful Multiplexing 185 A multiplexing scheme that relies on certain properties of a protocol 186 cannot expect those properties to remain fixed as that protocol 187 changes. 189 It's possible that the designers of a protocol will explicitly 190 guarantee that certain properties won't change over time, such as the 191 invariants defined in [QUIC-INVARIANTS], in which case a multiplexing 192 scheme could be designed based on those guarantees. 194 Choosing a multiplexing scheme that relies on properties of a 195 protocol remaining constant can either impose unwanted constraints on 196 the design of a protocol that is selected for multiplexing, or it can 197 cause some or all features of that protocol to be unusable in the 198 multiplexed context when that protocol changes. 200 5. Security Considerations 202 The ability to use new protocol features can have a material impact 203 on security if access to updated or added security-related features 204 is prevented by an incompatibility with a chosen multiplexing scheme. 206 6. IANA Considerations 208 This document has no IANA actions. 210 7. Informative References 212 [CHECKSUM] 213 Braden, R., Borman, D., and C. Partridge, "Computing the 214 Internet checksum", RFC 1071, DOI 10.17487/RFC1071, 215 September 1988, . 217 [CHECKSUM-FAIL] 218 Stone, J. and C. Partridge, "When the CRC and TCP checksum 219 disagree", Proceedings of the conference on Applications, 220 Technologies, Architectures, and Protocols for Computer 221 Communication - SIGCOMM '00, DOI 10.1145/347059.347561, 222 2000. 224 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 225 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 226 January 2012, . 228 [DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 229 Datagram Transport Layer Security (DTLS) Protocol Version 230 1.3", draft-ietf-tls-dtls13-02 (work in progress), October 231 2017. 233 [PMTUv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 234 DOI 10.17487/RFC1191, November 1990, 235 . 237 [PMTUv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 238 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 239 DOI 10.17487/RFC8201, July 2017, 240 . 242 [QUIC-INVARIANTS] 243 Thomson, M., "Version-Independent Properties of QUIC", 244 draft-thomson-quic-invariants-00 (work in progress), 245 November 2017. 247 [RT-MUX] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 248 Updates for Secure Real-time Transport Protocol (SRTP) 249 Extension for Datagram Transport Layer Security (DTLS)", 250 RFC 7983, DOI 10.17487/RFC7983, September 2016, 251 . 253 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 254 Jacobson, "RTP: A Transport Protocol for Real-Time 255 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 256 July 2003, . 258 [STUN] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 259 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 260 DOI 10.17487/RFC5389, October 2008, 261 . 263 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 264 (TLS) Protocol Version 1.2", RFC 5246, 265 DOI 10.17487/RFC5246, August 2008, 266 . 268 [TURN] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 269 Relays around NAT (TURN): Relay Extensions to Session 270 Traversal Utilities for NAT (STUN)", RFC 5766, 271 DOI 10.17487/RFC5766, April 2010, 272 . 274 [ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 275 Media Path Key Agreement for Unicast Secure RTP", 276 RFC 6189, DOI 10.17487/RFC6189, April 2011, 277 . 279 Author's Address 281 Martin Thomson 282 Mozilla 284 Email: martin.thomson@gmail.com