idnits 2.17.1 draft-ietf-avtcore-rfc5764-mux-fixes-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 3292 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) ** 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 (~~), 4 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-02 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 . . . . . . . . . . . . . . 5 61 1.4. Demultiplexing Algorithm Test Order . . . . . . . . . . . 6 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. RFC 5764 Updates . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. STUN Methods . . . . . . . . . . . . . . . . . . . . . . 8 68 6.2. TLS ContentType . . . . . . . . . . . . . . . . . . . . . 9 69 6.3. TURN Channel Numbers . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . 11 75 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux- 76 fixes-01 and draft-ietf-avtcore-rfc5764-mux-fixes-00 . . 11 77 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux- 78 fixes-01 and draft-ietf-avtcore-rfc5764-mux-fixes-00 . . 11 79 A.3. Modifications between draft-ietf-avtcore-rfc5764-mux- 80 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux- 81 fixes-02 . . . . . . . . . . . . . . . . . . . . . . . . 12 82 A.4. Modifications between draft-petithuguenin-avtcore-rfc5764 83 -mux-fixes-00 and draft-petithuguenin-avtcore-rfc5764 84 -mux-fixes-01 . . . . . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Section 5.1.2 of Secure Real-time Transport Protocol (SRTP) Extension 90 for DTLS [RFC5764] defines a scheme for a Real-time Transport 91 Protocol (RTP) [RFC3550] receiver to demultiplex Datagram Transport 92 Layer Security (DTLS) [RFC6347], Session Traversal Utilities for NAT 93 (STUN) [I-D.ietf-tram-stunbis] and Secure Real-time Transport 94 Protocol (SRTP)/Secure Real-time Transport Control Protocol (SRTCP) 95 [RFC3711] packets that are arriving on the RTP port. Unfortunately, 96 this demultiplexing scheme has created problematic issues: 98 1. It implicitly allocated codepoints for new STUN methods without 99 an IANA registry reflecting these new allocations. 101 2. It implicitly allocated codepoints for new Transport Layer 102 Security (TLS) ContentTypes without an IANA registry reflecting 103 these new allocations. 105 3. It did not take into account the fact that the Traversal Using 106 Relays around NAT (TURN) usage of STUN can create TURN channels 107 that also need to be demultiplexed with the other packet types 108 explicitly mentioned in Section 5.1.2 of RFC 5764. 110 4. The current ranges are not efficiently allocated making it harder 111 to introduce new protocols that might require multiplexing. 113 These flaws in the demultiplexing scheme were unavoidably inherited 114 by other documents, such as [RFC7345] and 115 [I-D.ietf-mmusic-sdp-bundle-negotiation]. These will need to be 116 corrected with the updates this document provides. 118 1.1. Implicit Allocation of Codepoints for New STUN Methods 120 The demultiplexing scheme in [RFC5764] states that the receiver can 121 identify the packet type by looking at the first byte. If the value 122 of this first byte is 0 or 1, the packet is identified to be STUN. 123 The problem that arises as a result of this implicit allocation is 124 that this restricts the codepoints for STUN methods (as described in 125 Section 18.1 of [RFC5389]) to values between 0x000 and 0x07F, which 126 in turn reduces the number of possible STUN method codepoints 127 assigned by IETF Review (i.e., the range from (0x000 - 0x7FF) from 128 2048 to only 128 and entirely obliterating those STUN method 129 codepoints assigned by Designated Expert (i.e., the range 0x800 - 130 0xFFF). 132 To preserve the Designated Expert range, this document allocates the 133 value 2 and 3 to also identify STUN methods. 135 The IANA Registry for STUN methods is modified to mark the codepoints 136 from 0x100 to 0xFFF as Reserved. These codepoints can still be 137 allocated, but require IETF Review with a document that will properly 138 evaluate the risk of an assignment overlapping with other registries. 140 In addition, this document also updates the IANA registry such that 141 the STUN method codepoints assigned in the 0x080-0x0FF range are also 142 assigned via Designated Expert. The proposed changes to the STUN 143 Method Registry are: 145 OLD: 147 0x000-0x7FF IETF Review 148 0x800-0xFFF Designated Expert 150 NEW: 152 0x000-0x07F IETF Review 153 0x080-0x0FF Designated Expert 154 0x100-0xFFF Reserved 156 1.2. Implicit Allocation of New Codepoints for TLS ContentTypes 158 The demultiplexing scheme in [RFC5764] dictates that if the value of 159 the first byte is between 20 and 63 (inclusive), then the packet is 160 identified to be DTLS. The problem that arises is that this 161 restricts the TLS ContentType codepoints (as defined in Section 12 of 162 [RFC5246]) to this range, and by extension implicitly allocates 163 ContentType codepoints 0 to 19 and 64 to 255. Unlike STUN, TLS is a 164 mature protocol that is already well established and widely 165 implemented and thus we expect only relatively few new codepoints to 166 be assigned in the future. With respect to TLS packet 167 identification, this document simply explicitly reserves the 168 codepoints from 0 to 19 and from 64 to 255. These codepoints can 169 still be allocated, but require Standards Action with a document that 170 will properly evaluate the risk of an assignment overlapping with 171 other registries. The proposed changes to the TLS ContentTypes 172 Registry are: 174 OLD: 176 0-19 Unassigned 177 20 change_cipher_spec 178 21 alert 179 22 handshake 180 23 application_data 181 24 heartbeat 182 25-255 Unassigned 184 NEW: 186 0-19 Reserved (MUST be allocated with Standards Action) 187 20 change_cipher_spec 188 21 alert 189 22 handshake 190 23 application_data 191 24 heartbeat 192 25-63 Unassigned 193 64-255 Reserved (MUST be allocated with Standards Action) 195 1.3. Multiplexing of TURN Channels 197 When used with ICE [RFC5245], an RFC 5764 implementation can receive 198 packets on the same socket from three different paths, as shown in 199 Figure 1: 201 1. Directly from the source 203 2. Through a NAT 205 3. Relayed by a TURN server 207 +------+ 208 | TURN |<------------------------+ 209 +------+ | 210 | | 211 | +-------------------------+ | 212 | | | | 213 v v | | 214 NAT ----------- | | 215 | | +---------------------+ | | 216 | | | | | | 217 v v v | | | 218 +----------+ +----------+ 219 | RFC 5764 | | RFC 5764 | 220 +----------+ +----------+ 222 Figure 1: Packet Reception by an RFC 5764 Implementation 224 Even if the ICE algorithm succeeded in selecting a non-relayed path, 225 it is still possible to receive data from the TURN server. For 226 instance, when ICE is used with aggressive nomination the media path 227 can quickly change until it stabilizes. Also, freeing ICE candidates 228 is optional, so the TURN server can restart forwarding STUN 229 connectivity checks during an ICE restart. 231 TURN channels are an optimization where data packets are exchanged 232 with a 4-byte prefix, instead of the standard 36-byte STUN overhead 233 (see Section 2.5 of [RFC5766]). The problem is that the RFC 5764 234 demultiplexing scheme does not define what to do with packets 235 received over a TURN channel since these packets will start with a 236 first byte whose value will be between 64 and 127 (inclusive). If 237 the TURN server was instructed to send data over a TURN channel, then 238 the current RFC 5764 demultiplexing scheme will reject these packets. 239 Current implementations violate RFC 5764 for values 64 to 127 240 (inclusive) and they instead parse packets with such values as TURN. 242 In order to prevent future documents from assigning values from the 243 unused range to a new protocol, this document modifies the RFC 5764 244 demultiplexing algorithm to properly account for TURN channels by 245 allocating the values from 64 to 79 for this purpose. 247 An implementation that uses the source IP address and port to 248 identify TURN channel messages MAY not need to restrict the channel 249 numbers to the above range. 251 1.4. Demultiplexing Algorithm Test Order 253 This document also changes the demultiplexing algorithm by imposing 254 the order in which the first byte is tested against the list of 255 existing protocol ranges. This is done in order to ensure that all 256 implementations fail identically in the presence of a new range. 258 2. Terminology 260 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 261 in this document are to be interpreted as described in [RFC2119] when 262 they appear in ALL CAPS. When these words are not in ALL CAPS (such 263 as "must" or "Must"), they have their usual English meanings, and are 264 not to be interpreted as RFC 2119 key words. 266 3. RFC 5764 Updates 268 This document updates the text in Section 5.1.2 of [RFC5764] as 269 follows: 271 OLD TEXT 273 The process for demultiplexing a packet is as follows. The receiver 274 looks at the first byte of the packet. If the value of this byte is 275 0 or 1, then the packet is STUN. If the value is in between 128 and 276 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 277 RTP are being multiplexed over the same destination port). If the 278 value is between 20 and 63 (inclusive), the packet is DTLS. This 279 process is summarized in Figure 3. 281 +----------------+ 282 | 127 < B < 192 -+--> forward to RTP 283 | | 284 packet --> | 19 < B < 64 -+--> forward to DTLS 285 | | 286 | B < 2 -+--> forward to STUN 287 +----------------+ 289 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 290 Here the field B denotes the leading byte of the packet. 292 END OLD TEXT 294 NEW TEXT 296 The process for demultiplexing a packet is as follows. The receiver 297 looks at the first byte of the packet. If the value of this byte is 298 in between 0 and 3 (inclusive), then the packet is STUN. Then if the 299 value is between 20 and 63 (inclusive), the packet is DTLS. Then if 300 the value is between 64 and 79 (inclusive), the packet is TURN 301 Channel. Then if the value is in between 128 and 191 (inclusive), 302 then the packet is RTP (or RTCP, if both RTCP and RTP are being 303 multiplexed over the same destination port). Else if the value does 304 not match any known range then the packet MUST be dropped and an 305 alert MAY be logged. This process is summarized in Figure 3. When 306 new values or ranges are added, they MUST be tested in ascending 307 order. 309 +----------------+ 310 | [0..3] -+--> forward to STUN 311 | | 312 packet --> | [20..63] -+--> forward to DTLS 313 | | 314 | [64..79] -+--> forward to TURN Channel 315 | | 316 | [128..191] -+--> forward to RTP 317 +----------------+ 319 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 321 END NEW TEXT 323 4. Implementation Status 325 [[Note to RFC Editor: Please remove this section and the reference to 326 [RFC6982] before publication.]] 327 This section records the status of known implementations of the 328 protocol defined by this specification at the time of posting of this 329 Internet-Draft, and is based on a proposal described in [RFC6982]. 330 The description of implementations in this section is intended to 331 assist the IETF in its decision processes in progressing drafts to 332 RFCs. Please note that the listing of any individual implementation 333 here does not imply endorsement by the IETF. Furthermore, no effort 334 has been spent to verify the information presented here that was 335 supplied by IETF contributors. This is not intended as, and must not 336 be construed to be, a catalog of available implementations or their 337 features. Readers are advised to note that other implementations may 338 exist. 340 According to [RFC6982], "this will allow reviewers and working groups 341 to assign due consideration to documents that have the benefit of 342 running code, which may serve as evidence of valuable experimentation 343 and feedback that have made the implemented protocols more mature. 344 It is up to the individual working groups to use this information as 345 they see fit". 347 Note that there is currently no implementation declared in this 348 section, but the intent is to add RFC 6982 templates here from 349 implementers that support the modifications in this document. 351 5. Security Considerations 353 This document simply updates existing IANA registries and does not 354 introduce any specific security considerations beyond those detailed 355 in [RFC5764]. 357 6. IANA Considerations 359 6.1. STUN Methods 361 This specification contains the registration information for reserved 362 STUN Methods codepoints, as explained in Section 1.1 and in 363 accordance with the procedures defined in Section 18.1 of [RFC5389]. 365 Value: 0x100-0xFFF 367 Name: Reserved (MUST be allocated with IETF Review) 369 Reference: RFC5764, RFCXXXX 371 This specification also reassigns the ranges in the STUN Methods 372 Registry as follow: 374 Range: 0x000-0x07F 375 Registration Procedures: IETF Review 377 Range: 0x080-0x0FF 379 Registration Procedures: Designated Expert 381 6.2. TLS ContentType 383 This specification contains the registration information for reserved 384 TLS ContentType codepoints, as explained in Section 1.2 and in 385 accordance with the procedures defined in Section 12 of [RFC5246]. 387 Value: 0-19 389 Description: Reserved (MUST be allocated with Standards Action) 391 DTLS-OK: N/A 393 Reference: RFC5764, RFCXXXX 395 Value: 64-255 397 Description: Reserved (MUST be allocated with Standards Action) 399 DTLS-OK: N/A 401 Reference: RFC5764, RFCXXXX 403 6.3. TURN Channel Numbers 405 This specification contains the registration information for reserved 406 TURN Channel Numbers codepoints, as explained in Section 1.3 and in 407 accordance with the procedures defined in Section 18 of [RFC5766]. 409 Value: 0x5000-0xFFFF 411 Name: Reserved 413 Reference: RFCXXXX 415 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 416 document.] 418 7. Acknowledgements 420 The implicit STUN Method codepoint allocations problem was first 421 reported by Martin Thomson in the RTCWEB mailing-list and discussed 422 further with Magnus Westerlund. 424 Thanks to Simon Perreault, Colton Shields, Cullen Jennings, Colin 425 Perkins, Magnus Westerlund, Paul Jones, Jonathan Lennox, Varun Singh 426 and Justin Uberti for the comments, suggestions, and questions that 427 helped improve this document. 429 8. References 431 8.1. Normative References 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 437 Jacobson, "RTP: A Transport Protocol for Real-Time 438 Applications", STD 64, RFC 3550, July 2003. 440 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 441 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 442 RFC 3711, March 2004. 444 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 445 (ICE): A Protocol for Network Address Translator (NAT) 446 Traversal for Offer/Answer Protocols", RFC 5245, April 447 2010. 449 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 450 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 452 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 453 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 454 October 2008. 456 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 457 Security (DTLS) Extension to Establish Keys for the Secure 458 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 460 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 461 Relays around NAT (TURN): Relay Extensions to Session 462 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 464 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 465 Security Version 1.2", RFC 6347, January 2012. 467 8.2. Informative References 469 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 470 Code: The Implementation Status Section", RFC 6982, July 471 2013. 473 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 474 Transport Layer (UDPTL) over Datagram Transport Layer 475 Security (DTLS)", RFC 7345, August 2014. 477 [I-D.ietf-mmusic-sdp-bundle-negotiation] 478 Holmberg, C., Alvestrand, H., and C. Jennings, 479 "Negotiating Media Multiplexing Using the Session 480 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 481 negotiation-18 (work in progress), March 2015. 483 [I-D.ietf-tram-stunbis] 484 Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 485 D., Mahy, R., and P. Matthews, "Session Traversal 486 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-02 487 (work in progress), March 2015. 489 Appendix A. Release notes 491 This section must be removed before publication as an RFC. 493 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-01 and 494 draft-ietf-avtcore-rfc5764-mux-fixes-00 496 o Remove any discussion about SCTP until a consensus emerges in 497 TRAM. 499 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-01 and 500 draft-ietf-avtcore-rfc5764-mux-fixes-00 502 o Instead of allocating the values that are common on each registry, 503 the specification now only reserves them, giving the possibility 504 to allocate them in case muxing is irrelevant. 506 o STUN range is now 0-3m with 2-3 being Designated Expert. 508 o TLS ContentType 0-19 and 64-255 are now reserved. 510 o Add SCTP over UDP value. 512 o If an implementation uses the source IP address/port to separate 513 TURN channels packets then the whole channel numbers are 514 available. 516 o If not the prefix is between 64 and 79. 518 o First byte test order is now by incremental values, so failure is 519 deterministic. 521 o Redraw the demuxing diagram. 523 A.3. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-00 and 524 draft-petithuguenin-avtcore-rfc5764-mux-fixes-02 526 o Adoption by WG. 528 o Add reference to STUNbis. 530 A.4. Modifications between draft-petithuguenin-avtcore-rfc5764-mux- 531 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 533 o Change affiliation. 535 Authors' Addresses 537 Marc Petit-Huguenin 538 Impedance Mismatch 540 Email: marc@petit-huguenin.org 542 Gonzalo Salgueiro 543 Cisco Systems 544 7200-12 Kit Creek Road 545 Research Triangle Park, NC 27709 546 US 548 Email: gsalguei@cisco.com