idnits 2.17.1 draft-ietf-avtcore-rfc5764-mux-fixes-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 abstract seems to contain references ([RFC5764]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5764, but the abstract doesn't seem to directly say this. It does mention RFC5764 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. (Using the creation date from RFC5764, updated by this document, for RFC5378 checks: 2007-07-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 24, 2015) is 3321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-tram-stunbis' is defined on line 443, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-18 == Outdated reference: A later version (-21) exists of draft-ietf-tram-stunbis-02 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE M. Petit-Huguenin 3 Internet-Draft Impedance Mismatch 4 Updates: 5764 (if approved) G. Salgueiro 5 Intended status: Standards Track Cisco Systems 6 Expires: September 25, 2015 March 24, 2015 8 Multiplexing Scheme Updates for Secure Real-time Transport Protocol 9 (SRTP) Extension for Datagram Transport Layer Security (DTLS) 10 draft-ietf-avtcore-rfc5764-mux-fixes-00 12 Abstract 14 This document defines how Datagram Transport Layer Security (DTLS), 15 Real-time Transport Protocol (RTP), Real-time Transport Control 16 Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and 17 Traversal Using Relays around NAT (TURN) packets are multiplexed on a 18 single receiving socket. It overrides the guidance from SRTP 19 Extension for DTLS [RFC5764], which suffered from three issues 20 described and fixed in this document. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 25, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Implicit Allocation of Codepoints for New STUN Methods . 3 58 1.2. Implicit Allocation of New Codepoints for TLS 59 ContentTypes . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3. Multiplexing of TURN Channels . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. RFC 5764 Updates . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. STUN Methods . . . . . . . . . . . . . . . . . . . . . . 8 67 6.2. TLS ContentType . . . . . . . . . . . . . . . . . . . . . 8 68 6.3. TURN Channel Numbers . . . . . . . . . . . . . . . . . . 9 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 8.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . 10 74 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux- 75 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux- 76 fixes-02 . . . . . . . . . . . . . . . . . . . . . . . . 11 77 A.2. Modifications between draft-petithuguenin-avtcore-rfc5764 78 -mux-fixes-00 and draft-petithuguenin-avtcore-rfc5764 79 -mux-fixes-01 . . . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 Section 5.1.2 of Secure Real-time Transport Protocol (SRTP) Extension 85 for DTLS [RFC5764] defines a scheme for a Real-time Transport 86 Protocol (RTP) [RFC3550] receiver to demultiplex Datagram Transport 87 Layer Security (DTLS) [RFC6347], Session Traversal Utilities for NAT 88 (STUN) [RFC5389] and Secure Real-time Transport Protocol 89 (SRTP)/Secure Real-time Transport Control Protocol (SRTCP) [RFC3711] 90 packets that are arriving on the RTP port. Unfortunately, this 91 demultiplexing scheme has created three problematic issues: 93 1. It implicitly allocated codepoints for new STUN methods without 94 an IANA registry reflecting these new allocations. 96 2. It implicitly allocated codepoints for new Transport Layer 97 Security (TLS) ContentTypes without an IANA registry reflecting 98 these new allocations. 100 3. It did not take into account the fact that the Traversal Using 101 Relays around NAT (TURN) usage of STUN can create TURN channels 102 that also need to be demultiplexed with the other packet types 103 explicitly mentioned in Section 5.1.2 of RFC 5764. 105 These flaws in the demultiplexing scheme were unavoidably inherited 106 by other documents, such as [RFC7345] and 107 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These will need to be 108 corrected with the updates this document provides when it become 109 normative. 111 1.1. Implicit Allocation of Codepoints for New STUN Methods 113 The demultiplexing scheme in [RFC5764] states that the receiver can 114 identify the packet type by looking at the first byte. If the value 115 of this first byte is 0 or 1, the packet is identified to be STUN. 116 The problem that arises as a result of this implicit allocation is 117 that this restricts the codepoints for STUN methods (as described in 118 Section 18.1 of [RFC5389]) to values between 0x000 and 0x07F, which 119 in turn reduces the number of possible STUN method codepoints 120 assigned by IETF Review (i.e., the range from (0x000 - 0x7FF) from 121 2048 to only 128 and entirely obliterating those STUN method 122 codepoints assigned by Designated Expert (i.e., the range 0x800 - 123 0xFFF). In fact, RFC 5764 implicitly (and needlessly) allocated a 124 very large range of STUN methods, but at a minimum the IANA STUN 125 Methods registry should properly reflect this. 127 There are only a few STUN method codepoints currently allocated. For 128 this reason, simply marking the implicit allocations made by RFC 5764 129 in the STUN Method registry may create a shortage of codepoints at a 130 time when interest in STUN and STUN Usages (especially TURN) is 131 growing rapidly. Consequently, this document also changes the RFC 132 5764 packet identification algorithm to expand the range assigned to 133 the STUN protocol from 0 - 1 to 0 - 19, as the values 2-19 are 134 unused. 136 In addition to explicitly allocating STUN methods codepoints from 137 0x500 to 0xFFF as Reserved values, this document also updates the 138 IANA registry such that the STUN method codepoints assigned via IETF 139 Review are in the 0x000-0x27F range and those assigned via Designated 140 Expert are in the 0x280-0x4FF range. The proposed changes to the 141 STUN Method Registry is: 143 OLD: 145 0x000-0x7FF IETF Review 146 0x800-0xFFF Designated Expert 148 NEW: 150 0x000-0x27F IETF Review 151 0x280-0x4FF Designated Expert 152 0x500-0xFFF Reserved 154 1.2. Implicit Allocation of New Codepoints for TLS ContentTypes 156 The demultiplexing scheme in [RFC5764] dictates that if the value of 157 the first byte is between 20 and 63 (inclusive), then the packet is 158 identified to be DTLS. The problem that arises is that this 159 restricts the TLS ContentType codepoints (as defined in Section 12 of 160 [RFC5246]) to this range, and by extension implicitly allocates 161 ContentType codepoints 0 to 19 and 64 to 255. Unlike STUN, TLS is a 162 mature protocol that is already well established and widely 163 implemented and thus we expect only relatively few new codepoints to 164 be assigned in the future. With respect to TLS packet 165 identification, this document simply explicitly reserves the 166 codepoints from 0 to 19 and from 64 to 255 so they are not 167 inadvertently assigned in the future. 169 1.3. Multiplexing of TURN Channels 171 When used with ICE [RFC5245], an RFC 5764 implementation can receive 172 packets on the same socket from three different paths, as shown in 173 Figure 1: 175 1. Directly from the source 177 2. Through a NAT 179 3. Relayed by a TURN server 180 +------+ 181 | TURN |<------------------------+ 182 +------+ | 183 | | 184 | +-------------------------+ | 185 | | | | 186 v v | | 187 NAT ----------- | | 188 | | +---------------------+ | | 189 | | | | | | 190 v v v | | | 191 +----------+ +----------+ 192 | RFC 5764 | | RFC 5764 | 193 +----------+ +----------+ 195 Figure 1: Packet Reception by an RFC 5764 Implementation 197 Even if the ICE algorithm succeeded in selecting a non-relayed path, 198 it is still possible to receive data from the TURN server. For 199 instance, when ICE is used with aggressive nomination the media path 200 can quickly change until it stabilizes. Also, freeing ICE candidates 201 is optional, so the TURN server can restart forwarding STUN 202 connectivity checks during an ICE restart. 204 TURN channels are an optimization where data packets are exchanged 205 with a 4-byte prefix, instead of the standard 36-byte STUN overhead 206 (see Section 2.5 of [RFC5766]). The problem is that the RFC 5764 207 demultiplexing scheme does not define what to do with packets 208 received over a TURN channel since these packets will start with a 209 first byte whose value will be between 64 and 127 (inclusive). If 210 the TURN server was instructed to send data over a TURN channel, then 211 the current RFC 5764 demultiplexing scheme will reject these packets. 212 Current implementations violate RFC 5764 for values 64 to 127 213 (inclusive) and they instead parse packets with such values as TURN. 214 In order to prevent future documents from assigning values from the 215 unused range to a new protocol, this document modifies the RFC 5764 216 demultiplexing algorithm to properly account for TURN channels. 218 2. Terminology 220 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 221 in this document are to be interpreted as described in [RFC2119] when 222 they appear in ALL CAPS. When these words are not in ALL CAPS (such 223 as "must" or "Must"), they have their usual English meanings, and are 224 not to be interpreted as RFC 2119 key words. 226 3. RFC 5764 Updates 228 This document updates the text in Section 5.1.2 of [RFC5764] as 229 follows: 231 OLD TEXT 233 The process for demultiplexing a packet is as follows. The receiver 234 looks at the first byte of the packet. If the value of this byte is 235 0 or 1, then the packet is STUN. If the value is in between 128 and 236 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 237 RTP are being multiplexed over the same destination port). If the 238 value is between 20 and 63 (inclusive), the packet is DTLS. This 239 process is summarized in Figure 3. 241 +----------------+ 242 | 127 < B < 192 -+--> forward to RTP 243 | | 244 packet --> | 19 < B < 64 -+--> forward to DTLS 245 | | 246 | B < 2 -+--> forward to STUN 247 +----------------+ 249 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 250 Here the field B denotes the leading byte of the packet. 252 END OLD TEXT 254 NEW TEXT 256 The process for demultiplexing a packet is as follows. The receiver 257 looks at the first byte of the packet. If the value of this byte is 258 in between 0 and 19 (inclusive), then the packet is STUN. If the 259 value is in between 128 and 191 (inclusive), then the packet is RTP 260 (or RTCP, if both RTCP and RTP are being multiplexed over the same 261 destination port). If the value is between 20 and 63 (inclusive), 262 the packet is DTLS. If the value is between 64 and 127 (inclusive), 263 the packet is TURN Channel. This process is summarized in Figure 3. 265 +----------------+ 266 | 127 < B < 192 -+--> forward to RTP 267 | | 268 | 63 < B < 128 -+--> forward to TURN Channel 269 packet --> | | 270 | 19 < B < 64 -+--> forward to DTLS 271 | | 272 | B < 20 -+--> forward to STUN 273 +----------------+ 275 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 276 Here the field B denotes the leading byte of the packet. 278 END NEW TEXT 280 [[Note: we may want to use "<=" instead of "<" to make it easier on 281 implementers.]] 283 4. Implementation Status 285 [[Note to RFC Editor: Please remove this section and the reference to 286 [RFC6982] before publication.]] 288 This section records the status of known implementations of the 289 protocol defined by this specification at the time of posting of this 290 Internet-Draft, and is based on a proposal described in [RFC6982]. 291 The description of implementations in this section is intended to 292 assist the IETF in its decision processes in progressing drafts to 293 RFCs. Please note that the listing of any individual implementation 294 here does not imply endorsement by the IETF. Furthermore, no effort 295 has been spent to verify the information presented here that was 296 supplied by IETF contributors. This is not intended as, and must not 297 be construed to be, a catalog of available implementations or their 298 features. Readers are advised to note that other implementations may 299 exist. 301 According to [RFC6982], "this will allow reviewers and working groups 302 to assign due consideration to documents that have the benefit of 303 running code, which may serve as evidence of valuable experimentation 304 and feedback that have made the implemented protocols more mature. 305 It is up to the individual working groups to use this information as 306 they see fit". 308 Note that there is currently no implementation declared in this 309 section, but the intent is to add RFC 6982 templates here from 310 implementers that support the modifications in this document. 312 5. Security Considerations 314 This document simply updates existing IANA registries and does not 315 introduce any specific security considerations beyond those detailed 316 in [RFC5764]. 318 6. IANA Considerations 320 6.1. STUN Methods 322 This specification contains the registration information for 2816 323 STUN Methods codepoints, as explained in Section 1.1 and in 324 accordance with the procedures defined in Section 18.1 of [RFC5389]. 326 Value: 0x500-0xFFF 328 Name: Reserved 330 Reference: RFC5764, RFCXXXX 332 This specification also reassigns the ranges in the STUN Methods 333 Registry as follow: 335 Range: 0x000-0x27F 337 Registration Procedures: IETF Review 339 Range: 0x280-0x4FF 341 Registration Procedures: Designated Expert 343 6.2. TLS ContentType 345 This specification contains the registration information for 212 TLS 346 ContentType codepoints, as explained in Section 1.2 and in accordance 347 with the procedures defined in Section 12 of [RFC5246]. 349 Value: 0-19 351 Description: Reserved 353 DTLS-OK: N/A 355 Reference: RFC5764, RFCXXXX 357 Value: 64-255 359 Description: Reserved 360 DTLS-OK: N/A 362 Reference: RFC5764, RFCXXXX 364 6.3. TURN Channel Numbers 366 This specification contains the registration information for 32768 367 TURN Channel Numbers codepoints, as explained in Section 1.3 and in 368 accordance with the procedures defined in Section 18 of [RFC5766]. 370 Value: 0x8000-0xFFFF 372 Name: Reserved 374 Reference: RFCXXXX 376 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 377 document.] 379 7. Acknowledgements 381 The implicit STUN Method codepoint allocations problem was first 382 reported by Martin Thomson in the RTCWEB mailing-list and discussed 383 further with Magnus Westerlund. 385 Thanks to Simon Perreault, Colton Shields and Cullen Jennings for the 386 comments, suggestions, and questions that helped improve this 387 document. 389 8. References 391 8.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 397 Jacobson, "RTP: A Transport Protocol for Real-Time 398 Applications", STD 64, RFC 3550, July 2003. 400 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 401 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 402 RFC 3711, March 2004. 404 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 405 (ICE): A Protocol for Network Address Translator (NAT) 406 Traversal for Offer/Answer Protocols", RFC 5245, April 407 2010. 409 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 410 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 412 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 413 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 414 October 2008. 416 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 417 Security (DTLS) Extension to Establish Keys for the Secure 418 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 420 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 421 Relays around NAT (TURN): Relay Extensions to Session 422 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 424 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 425 Security Version 1.2", RFC 6347, January 2012. 427 8.2. Informative References 429 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 430 Code: The Implementation Status Section", RFC 6982, July 431 2013. 433 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 434 Transport Layer (UDPTL) over Datagram Transport Layer 435 Security (DTLS)", RFC 7345, August 2014. 437 [I-D.ietf-mmusic-sdp-bundle-negotiation] 438 Holmberg, C., Alvestrand, H., and C. Jennings, 439 "Negotiating Media Multiplexing Using the Session 440 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 441 negotiation-18 (work in progress), March 2015. 443 [I-D.ietf-tram-stunbis] 444 Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 445 D., Mahy, R., and P. Matthews, "Session Traversal 446 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-02 447 (work in progress), March 2015. 449 Appendix A. Release notes 451 This section must be removed before publication as an RFC. 453 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-00 and 454 draft-petithuguenin-avtcore-rfc5764-mux-fixes-02 456 o Adoption by WG. 458 o Add reference to STUNbis. 460 A.2. Modifications between draft-petithuguenin-avtcore-rfc5764-mux- 461 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 463 o Change affiliation. 465 Authors' Addresses 467 Marc Petit-Huguenin 468 Impedance Mismatch 470 Email: marc@petit-huguenin.org 472 Gonzalo Salgueiro 473 Cisco Systems 474 7200-12 Kit Creek Road 475 Research Triangle Park, NC 27709 476 US 478 Email: gsalguei@cisco.com