idnits 2.17.1 draft-ietf-avtcore-rfc5764-mux-fixes-01.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 3320 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-01 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), 17 Traversal Using Relays around NAT (TURN), and Stream Control 18 Transmission Protocol (SCTP) over UDP packets are multiplexed on a 19 single receiving socket. It overrides the guidance from SRTP 20 Extension for DTLS [RFC5764], which suffered from three issues 21 described and fixed in this document. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 25, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Implicit Allocation of Codepoints for New STUN Methods . 3 59 1.2. Multiplexing Byte Allocation for SCTP over UDP . . . . . 4 60 1.3. Implicit Allocation of New Codepoints for TLS 61 ContentTypes . . . . . . . . . . . . . . . . . . . . . . 4 62 1.4. Multiplexing of TURN Channels . . . . . . . . . . . . . . 5 63 1.5. Demultiplexing Algorithm Test Order . . . . . . . . . . . 6 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. RFC 5764 Updates . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. STUN Methods . . . . . . . . . . . . . . . . . . . . . . 8 70 6.2. TLS ContentType . . . . . . . . . . . . . . . . . . . . . 9 71 6.3. TURN Channel Numbers . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 8.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . 11 77 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux- 78 fixes-01 and draft-ietf-avtcore-rfc5764-mux-fixes-00 . . 11 79 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux- 80 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux- 81 fixes-02 . . . . . . . . . . . . . . . . . . . . . . . . 12 82 A.3. 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) [RFC5389] and Secure Real-time Transport Protocol 94 (SRTP)/Secure Real-time Transport Control Protocol (SRTCP) [RFC3711] 95 packets that are arriving on the RTP port. Unfortunately, this 96 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. Multiplexing Byte Allocation for SCTP over UDP 158 [I-D.ietf-tram-stunbis] defines two new transports for STUN, SCTP 159 over UDP and SCTP over DTLS over UDP. This document allocates the 160 value 5 as to multiplex SCTP over STUN. This value restricts the 161 source and destination port numbers that can be used by SCTP over 162 UDP. 164 1.3. Implicit Allocation of New Codepoints for TLS ContentTypes 166 The demultiplexing scheme in [RFC5764] dictates that if the value of 167 the first byte is between 20 and 63 (inclusive), then the packet is 168 identified to be DTLS. The problem that arises is that this 169 restricts the TLS ContentType codepoints (as defined in Section 12 of 170 [RFC5246]) to this range, and by extension implicitly allocates 171 ContentType codepoints 0 to 19 and 64 to 255. Unlike STUN, TLS is a 172 mature protocol that is already well established and widely 173 implemented and thus we expect only relatively few new codepoints to 174 be assigned in the future. With respect to TLS packet 175 identification, this document simply explicitly reserves the 176 codepoints from 0 to 19 and from 64 to 255. These codepoints can 177 still be allocated, but require Standards Action with a document that 178 will properly evaluate the risk of an assignment overlapping with 179 other registries. The proposed changes to the TLS ContentTypes 180 Registry are: 182 OLD: 184 0-19 Unassigned 185 20 change_cipher_spec 186 21 alert 187 22 handshake 188 23 application_data 189 24 heartbeat 190 25-255 Unassigned 192 NEW: 194 0-19 Reserved (MUST be allocated with Standards Action) 195 20 change_cipher_spec 196 21 alert 197 22 handshake 198 23 application_data 199 24 heartbeat 200 25-63 Unassigned 201 64-255 Reserved (MUST be allocated with Standards Action) 203 1.4. Multiplexing of TURN Channels 205 When used with ICE [RFC5245], an RFC 5764 implementation can receive 206 packets on the same socket from three different paths, as shown in 207 Figure 1: 209 1. Directly from the source 211 2. Through a NAT 213 3. Relayed by a TURN server 215 +------+ 216 | TURN |<------------------------+ 217 +------+ | 218 | | 219 | +-------------------------+ | 220 | | | | 221 v v | | 222 NAT ----------- | | 223 | | +---------------------+ | | 224 | | | | | | 225 v v v | | | 226 +----------+ +----------+ 227 | RFC 5764 | | RFC 5764 | 228 +----------+ +----------+ 230 Figure 1: Packet Reception by an RFC 5764 Implementation 232 Even if the ICE algorithm succeeded in selecting a non-relayed path, 233 it is still possible to receive data from the TURN server. For 234 instance, when ICE is used with aggressive nomination the media path 235 can quickly change until it stabilizes. Also, freeing ICE candidates 236 is optional, so the TURN server can restart forwarding STUN 237 connectivity checks during an ICE restart. 239 TURN channels are an optimization where data packets are exchanged 240 with a 4-byte prefix, instead of the standard 36-byte STUN overhead 241 (see Section 2.5 of [RFC5766]). The problem is that the RFC 5764 242 demultiplexing scheme does not define what to do with packets 243 received over a TURN channel since these packets will start with a 244 first byte whose value will be between 64 and 127 (inclusive). If 245 the TURN server was instructed to send data over a TURN channel, then 246 the current RFC 5764 demultiplexing scheme will reject these packets. 247 Current implementations violate RFC 5764 for values 64 to 127 248 (inclusive) and they instead parse packets with such values as TURN. 250 In order to prevent future documents from assigning values from the 251 unused range to a new protocol, this document modifies the RFC 5764 252 demultiplexing algorithm to properly account for TURN channels by 253 allocating the values from 64 to 79 for this purpose. 255 An implementation that uses the source IP address and port to 256 identify TURN channel messages MAY not need to restrict the channel 257 numbers to the above range. 259 1.5. Demultiplexing Algorithm Test Order 261 This document also changes the demultiplexing algorithm by imposing 262 the order in which the first byte is tested against the list of 263 existing protocol ranges. This is done in order to ensure that all 264 implementations fail identically in the presence of a new range. 266 2. Terminology 268 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 269 in this document are to be interpreted as described in [RFC2119] when 270 they appear in ALL CAPS. When these words are not in ALL CAPS (such 271 as "must" or "Must"), they have their usual English meanings, and are 272 not to be interpreted as RFC 2119 key words. 274 3. RFC 5764 Updates 276 This document updates the text in Section 5.1.2 of [RFC5764] as 277 follows: 279 OLD TEXT 281 The process for demultiplexing a packet is as follows. The receiver 282 looks at the first byte of the packet. If the value of this byte is 283 0 or 1, then the packet is STUN. If the value is in between 128 and 284 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 285 RTP are being multiplexed over the same destination port). If the 286 value is between 20 and 63 (inclusive), the packet is DTLS. This 287 process is summarized in Figure 3. 289 +----------------+ 290 | 127 < B < 192 -+--> forward to RTP 291 | | 292 packet --> | 19 < B < 64 -+--> forward to DTLS 293 | | 294 | B < 2 -+--> forward to STUN 295 +----------------+ 297 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 298 Here the field B denotes the leading byte of the packet. 300 END OLD TEXT 302 NEW TEXT 304 The process for demultiplexing a packet is as follows. The receiver 305 looks at the first byte of the packet. If the value of this byte is 306 in between 0 and 3 (inclusive), then the packet is STUN. Then if the 307 value is 5, then the packet is SCTP. Then if the value is between 20 308 and 63 (inclusive), the packet is DTLS. Then if the value is between 309 64 and 79 (inclusive), the packet is TURN Channel. Then if the value 310 is in between 128 and 191 (inclusive), then the packet is RTP (or 311 RTCP, if both RTCP and RTP are being multiplexed over the same 312 destination port). Else if the value does not match any known range 313 then the packet MUST be dropped and an alert MAY be logged. This 314 process is summarized in Figure 3. When new values or ranges are 315 added, they MUST be tested in ascending order. 317 +----------------+ 318 | [0..3] -+--> forward to STUN 319 | | 320 | 5 -+--> forward to SCTP 321 | | 322 packet --> | [20..63] -+--> forward to DTLS 323 | | 324 | [64..79] -+--> forward to TURN Channel 325 | | 326 | [128..191] -+--> forward to RTP 327 +----------------+ 329 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 331 END NEW TEXT 333 4. Implementation Status 335 [[Note to RFC Editor: Please remove this section and the reference to 336 [RFC6982] before publication.]] 338 This section records the status of known implementations of the 339 protocol defined by this specification at the time of posting of this 340 Internet-Draft, and is based on a proposal described in [RFC6982]. 341 The description of implementations in this section is intended to 342 assist the IETF in its decision processes in progressing drafts to 343 RFCs. Please note that the listing of any individual implementation 344 here does not imply endorsement by the IETF. Furthermore, no effort 345 has been spent to verify the information presented here that was 346 supplied by IETF contributors. This is not intended as, and must not 347 be construed to be, a catalog of available implementations or their 348 features. Readers are advised to note that other implementations may 349 exist. 351 According to [RFC6982], "this will allow reviewers and working groups 352 to assign due consideration to documents that have the benefit of 353 running code, which may serve as evidence of valuable experimentation 354 and feedback that have made the implemented protocols more mature. 355 It is up to the individual working groups to use this information as 356 they see fit". 358 Note that there is currently no implementation declared in this 359 section, but the intent is to add RFC 6982 templates here from 360 implementers that support the modifications in this document. 362 5. Security Considerations 364 This document simply updates existing IANA registries and does not 365 introduce any specific security considerations beyond those detailed 366 in [RFC5764]. 368 6. IANA Considerations 370 6.1. STUN Methods 372 This specification contains the registration information for reserved 373 STUN Methods codepoints, as explained in Section 1.1 and in 374 accordance with the procedures defined in Section 18.1 of [RFC5389]. 376 Value: 0x100-0xFFF 378 Name: Reserved (MUST be allocated with IETF Review) 380 Reference: RFC5764, RFCXXXX 381 This specification also reassigns the ranges in the STUN Methods 382 Registry as follow: 384 Range: 0x000-0x07F 386 Registration Procedures: IETF Review 388 Range: 0x080-0x0FF 390 Registration Procedures: Designated Expert 392 6.2. TLS ContentType 394 This specification contains the registration information for reserved 395 TLS ContentType codepoints, as explained in Section 1.3 and in 396 accordance with the procedures defined in Section 12 of [RFC5246]. 398 Value: 0-19 400 Description: Reserved (MUST be allocated with Standards Action) 402 DTLS-OK: N/A 404 Reference: RFC5764, RFCXXXX 406 Value: 64-255 408 Description: Reserved (MUST be allocated with Standards Action) 410 DTLS-OK: N/A 412 Reference: RFC5764, RFCXXXX 414 6.3. TURN Channel Numbers 416 This specification contains the registration information for reserved 417 TURN Channel Numbers codepoints, as explained in Section 1.4 and in 418 accordance with the procedures defined in Section 18 of [RFC5766]. 420 Value: 0x5000-0xFFFF 422 Name: Reserved 424 Reference: RFCXXXX 426 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 427 document.] 429 7. Acknowledgements 431 The implicit STUN Method codepoint allocations problem was first 432 reported by Martin Thomson in the RTCWEB mailing-list and discussed 433 further with Magnus Westerlund. 435 Thanks to Simon Perreault, Colton Shields, Cullen Jennings, Colin 436 Perkins, Magnus Westerlund, Paul Jones, Jonathan Lennox, Varun Singh 437 and Justin Uberti for the comments, suggestions, and questions that 438 helped improve this document. 440 8. References 442 8.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 448 Jacobson, "RTP: A Transport Protocol for Real-Time 449 Applications", STD 64, RFC 3550, July 2003. 451 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 452 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 453 RFC 3711, March 2004. 455 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 456 (ICE): A Protocol for Network Address Translator (NAT) 457 Traversal for Offer/Answer Protocols", RFC 5245, April 458 2010. 460 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 461 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 463 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 464 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 465 October 2008. 467 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 468 Security (DTLS) Extension to Establish Keys for the Secure 469 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 471 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 472 Relays around NAT (TURN): Relay Extensions to Session 473 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 475 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 476 Security Version 1.2", RFC 6347, January 2012. 478 8.2. Informative References 480 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 481 Code: The Implementation Status Section", RFC 6982, July 482 2013. 484 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 485 Transport Layer (UDPTL) over Datagram Transport Layer 486 Security (DTLS)", RFC 7345, August 2014. 488 [I-D.ietf-mmusic-sdp-bundle-negotiation] 489 Holmberg, C., Alvestrand, H., and C. Jennings, 490 "Negotiating Media Multiplexing Using the Session 491 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 492 negotiation-18 (work in progress), March 2015. 494 [I-D.ietf-tram-stunbis] 495 Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 496 D., Mahy, R., and P. Matthews, "Session Traversal 497 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-02 498 (work in progress), March 2015. 500 Appendix A. Release notes 502 This section must be removed before publication as an RFC. 504 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-01 and 505 draft-ietf-avtcore-rfc5764-mux-fixes-00 507 o Instead of allocating the values that are common on each registry, 508 the specification now only reserves them, giving the possibility 509 to allocate them in case muxing is irrelevant. 511 o STUN range is now 0-3m with 2-3 being Designated Expert. 513 o TLS ContentType 0-19 and 64-255 are now reserved. 515 o Add SCTP over UDP value. 517 o If an implementation uses the source IP address/port to separate 518 TURN channels packets then the whole channel numbers are 519 available. 521 o If not the prefix is between 64 and 79. 523 o First byte test order is now by incremental values, so failure is 524 deterministic. 526 o Redraw the demuxing diagram. 528 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-00 and 529 draft-petithuguenin-avtcore-rfc5764-mux-fixes-02 531 o Adoption by WG. 533 o Add reference to STUNbis. 535 A.3. Modifications between draft-petithuguenin-avtcore-rfc5764-mux- 536 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 538 o Change affiliation. 540 Authors' Addresses 542 Marc Petit-Huguenin 543 Impedance Mismatch 545 Email: marc@petit-huguenin.org 547 Gonzalo Salgueiro 548 Cisco Systems 549 7200-12 Kit Creek Road 550 Research Triangle Park, NC 27709 551 US 553 Email: gsalguei@cisco.com