idnits 2.17.1 draft-ietf-avtcore-rfc5764-mux-fixes-09.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 (June 15, 2016) is 2872 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 4347 (Obsoleted by RFC 6347) ** 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-23 Summary: 7 errors (**), 0 flaws (~~), 3 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: December 17, 2016 June 15, 2016 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-09 12 Abstract 14 This document defines how Datagram Transport Layer Security (DTLS), 15 Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), 16 Session Traversal Utilities for NAT (STUN), and Traversal Using 17 Relays around NAT (TURN) packets are multiplexed on a single 18 receiving socket. It overrides the guidance from SRTP Extension for 19 DTLS [RFC5764], which suffered from three issues described and fixed 20 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 December 17, 2016. 39 Copyright Notice 41 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Implicit Allocation of Codepoints for New STUN Methods . . . 4 59 4. Multiplexing of ZRTP . . . . . . . . . . . . . . . . . . . . 5 60 5. Implicit Allocation of New Codepoints for TLS ContentTypes . 5 61 6. Multiplexing of TURN Channels . . . . . . . . . . . . . . . . 6 62 7. RFC 5764 Updates . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 10.1. STUN Methods . . . . . . . . . . . . . . . . . . . . . . 9 67 10.2. TLS ContentType . . . . . . . . . . . . . . . . . . . . 10 68 10.3. TURN Channel Numbers . . . . . . . . . . . . . . . . . . 10 69 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 12.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . 13 74 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux- 75 fixes-09 and draft-ietf-avtcore-rfc5764-mux-fixes-08 . . 13 76 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux- 77 fixes-08 and draft-ietf-avtcore-rfc5764-mux-fixes-07 . . 13 78 A.3. Modifications between draft-ietf-avtcore-rfc5764-mux- 79 fixes-07 and draft-ietf-avtcore-rfc5764-mux-fixes-06 . . 13 80 A.4. Modifications between draft-ietf-avtcore-rfc5764-mux- 81 fixes-06 and draft-ietf-avtcore-rfc5764-mux-fixes-05 . . 13 82 A.5. Modifications between draft-ietf-avtcore-rfc5764-mux- 83 fixes-05 and draft-ietf-avtcore-rfc5764-mux-fixes-04 . . 13 84 A.6. Modifications between draft-ietf-avtcore-rfc5764-mux- 85 fixes-04 and draft-ietf-avtcore-rfc5764-mux-fixes-03 . . 13 86 A.7. Modifications between draft-ietf-avtcore-rfc5764-mux- 87 fixes-03 and draft-ietf-avtcore-rfc5764-mux-fixes-02 . . 13 88 A.8. Modifications between draft-ietf-avtcore-rfc5764-mux- 89 fixes-02 and draft-ietf-avtcore-rfc5764-mux-fixes-01 . . 14 90 A.9. Modifications between draft-ietf-avtcore-rfc5764-mux- 91 fixes-01 and draft-ietf-avtcore-rfc5764-mux-fixes-00 . . 14 92 A.10. Modifications between draft-ietf-avtcore-rfc5764-mux- 93 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux- 94 fixes-02 . . . . . . . . . . . . . . . . . . . . . . . . 14 95 A.11. Modifications between draft-petithuguenin-avtcore-rfc5764 96 -mux-fixes-00 and draft-petithuguenin-avtcore-rfc5764 97 -mux-fixes-01 . . . . . . . . . . . . . . . . . . . . . . 14 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 Section 5.1.2 of Secure Real-time Transport Protocol (SRTP) Extension 103 for DTLS [RFC5764] defines a scheme for a Real-time Transport 104 Protocol (RTP) [RFC3550] receiver to demultiplex Datagram Transport 105 Layer Security (DTLS) [RFC6347], Session Traversal Utilities for NAT 106 (STUN) [RFC5389] and Secure Real-time Transport Protocol 107 (SRTP)/Secure RTP Control Protocol (SRTCP) [RFC3711] packets that are 108 arriving on the RTP port. Unfortunately, this demultiplexing scheme 109 has created problematic issues: 111 1. It implicitly allocated codepoints for new STUN methods without 112 an IANA registry reflecting these new allocations. 114 2. It did not take into account the fact that ZRTP [RFC6189] also 115 needs to be demultiplexed with the other packet types explicitly 116 mentioned in Section 5.1.2 of RFC 5764. 118 3. It implicitly allocated codepoints for new Transport Layer 119 Security (TLS) ContentTypes without an IANA registry reflecting 120 these new allocations. 122 4. It did not take into account the fact that the Traversal Using 123 Relays around NAT (TURN) usage of STUN can create TURN channels 124 that also need to be demultiplexed with the other packet types 125 explicitly mentioned in Section 5.1.2 of RFC 5764. 127 Having overlapping ranges between different IANA registries becomes 128 an issue when a new codepoint is allocated in one of these registries 129 without carefully analyzing the impact it could have on the other 130 registries when that codepoint is demultiplexed. Among other 131 downsides of the bad design of the demultiplexing algorithm detailed 132 in [RFC5764], it creates a requirement for coordination between 133 codepoint assignments where none should exist, and that is 134 organizationally and socially undesirable. However, RFC 5764 has 135 been widely deployed so there must be an awareness of this issue and 136 how it must be dealt with. Thus, even if a codepoint is not 137 initially thought to be useful, the respective IANA registry expert 138 should at least raise a flag when the allocated codepoint irrevocably 139 prevents multiplexing. 141 The first goal of this document is to make sure that future 142 allocations in any of the affected protocols are done with the full 143 knowledge of their impact on multiplexing. This is achieved by 144 modifying the IANA registries with instructions for coordination 145 between the protocols at risk. 147 A second goal is to permit the addition of new protocols to the list 148 of existing multiplexed protocols in a manner that does not break 149 existing implementations. 151 The flaws in the demultiplexing scheme were unavoidably inherited by 152 other documents, such as [RFC7345] and 153 [I-D.ietf-mmusic-sdp-bundle-negotiation]. So in addition, these and 154 any other affected documents will need to be corrected with the 155 updates this document provides. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 160 in this document are to be interpreted as described in [RFC2119] when 161 they appear in ALL CAPS. When these words are not in ALL CAPS (such 162 as "must" or "Must"), they have their usual English meanings, and are 163 not to be interpreted as RFC 2119 key words. 165 3. Implicit Allocation of Codepoints for New STUN Methods 167 The demultiplexing scheme in [RFC5764] states that the receiver can 168 identify the packet type by looking at the first byte. If the value 169 of this first byte is 0 or 1, the packet is identified to be STUN. 170 The problem that arises as a result of this implicit allocation is 171 that this restricts the codepoints for STUN methods (as described in 172 Section 18.1 of [RFC5389]) to values between 0x000 and 0x07F, which 173 in turn reduces the number of possible STUN method codepoints 174 assigned by IETF Review (i.e., the range from (0x000 - 0x7FF) from 175 2048 to only 128 and eliminating the possibility of having STUN 176 method codepoints assigned by Designated Expert (i.e., the range 177 0x800 - 0xFFF). 179 To preserve the Designated Expert range, this document allocates the 180 value 2 and 3 to also identify STUN methods. 182 The IANA Registry for STUN methods is modified to mark the codepoints 183 from 0x100 to 0xFFF as Reserved. These codepoints can still be 184 allocated, but require IETF Review with a document that will properly 185 evaluate the risk of an assignment overlapping with other registries. 187 In addition, this document also updates the IANA registry such that 188 the STUN method codepoints assigned in the 0x080-0x0FF range are also 189 assigned via Designated Expert. The proposed changes to the STUN 190 Method Registry are: 192 OLD: 194 0x000-0x7FF IETF Review 195 0x800-0xFFF Designated Expert 197 NEW: 199 0x000-0x07F IETF Review 200 0x080-0x0FF Designated Expert 201 0x100-0xFFF Reserved 203 4. Multiplexing of ZRTP 205 ZRTP [RFC6189] is a protocol for media path Diffie-Hellman exchange 206 to agree on a session key and parameters for establishing unicast 207 Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP 208 (VoIP) applications. The ZRTP protocol is media path keying because 209 it is multiplexed on the same port as RTP and does not require 210 support in the signaling protocol. 212 In order to prevent future documents from assigning values from the 213 unused range to a new protocol, this document modifies the [RFC5764] 214 demultiplexing algorithm to properly account for ZRTP [RFC6189] by 215 allocating the values from 16 to 19 for this purpose. 217 5. Implicit Allocation of New Codepoints for TLS ContentTypes 219 The demultiplexing scheme in [RFC5764] dictates that if the value of 220 the first byte is between 20 and 63 (inclusive), then the packet is 221 identified to be DTLS. For DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347] 222 that first byte corresponds to the TLS ContentType field. 223 Considerations must be taken into account when assigning additional 224 ContentTypes in the code point ranges 0 to 19 and 64 to 255 so this 225 does not prevent demultiplexing when this functionality is desirable. 226 Note that [RFC5764] describes a narrow use of DTLS that works as long 227 as the specific DTLS version used abides by the restrictions on the 228 demultiplexing byte (the ones that this document imposes on the TLS 229 ContentType Registry). Any extension or revision to DTLS that causes 230 it to no longer meet these constraints should consider what values 231 may occur in the first byte of the DTLS message and what impact it 232 would have on the multiplexing that [RFC5764] describes. 234 With respect to TLS packet identification, this document explicitly 235 adds a warning to the codepoints from 0 to 19 and from 64 to 255 236 indicating that allocations in these ranges require coordination, as 237 described in this document. The proposed changes to the TLS 238 ContentType Registry are: 240 OLD: 242 0-19 Unassigned 243 20 change_cipher_spec 244 21 alert 245 22 handshake 246 23 application_data 247 24 heartbeat 248 25-255 Unassigned 250 NEW: 252 0-19 Unassigned (Requires coordination, see RFCXXXX) 253 20 change_cipher_spec 254 21 alert 255 22 handshake 256 23 application_data 257 24 heartbeat 258 25-63 Unassigned 259 64-255 Unassigned (Requires coordination, see RFCXXXX) 261 6. Multiplexing of TURN Channels 263 When used with ICE [RFC5245], an RFC 5764 implementation can receive 264 packets on the same socket from three different paths, as shown in 265 Figure 1: 267 1. Directly from the source 269 2. Through a NAT 271 3. Relayed by a TURN server 272 +------+ 273 | TURN |<------------------------+ 274 +------+ | 275 | | 276 | +-------------------------+ | 277 | | | | 278 v v | | 279 NAT ----------- | | 280 | | +---------------------+ | | 281 | | | | | | 282 v v v | | | 283 +----------+ +----------+ 284 | RFC 5764 | | RFC 5764 | 285 +----------+ +----------+ 287 Figure 1: Packet Reception by an RFC 5764 Implementation 289 Even if the ICE algorithm succeeded in selecting a non-relayed path, 290 it is still possible to receive data from the TURN server. For 291 instance, when ICE is used with aggressive nomination the media path 292 can quickly change until it stabilizes. Also, freeing ICE candidates 293 is optional, so the TURN server can restart forwarding STUN 294 connectivity checks during an ICE restart. 296 TURN channels are an optimization where data packets are exchanged 297 with a 4-byte prefix, instead of the standard 36-byte STUN overhead 298 (see Section 2.5 of [RFC5766]). The problem is that the RFC 5764 299 demultiplexing scheme does not define what to do with packets 300 received over a TURN channel since these packets will start with a 301 first byte whose value will be between 64 and 127 (inclusive). If 302 the TURN server was instructed to send data over a TURN channel, then 303 the current RFC 5764 demultiplexing scheme will reject these packets. 304 Current implementations violate RFC 5764 for values 64 to 127 305 (inclusive) and they instead parse packets with such values as TURN. 307 In order to prevent future documents from assigning values from the 308 unused range to a new protocol, this document modifies the RFC 5764 309 demultiplexing algorithm to properly account for TURN channels by 310 allocating the values from 64 to 79 for this purpose. 312 7. RFC 5764 Updates 314 This document updates the text in Section 5.1.2 of [RFC5764] as 315 follows: 317 OLD TEXT 318 The process for demultiplexing a packet is as follows. The receiver 319 looks at the first byte of the packet. If the value of this byte is 320 0 or 1, then the packet is STUN. If the value is in between 128 and 321 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 322 RTP are being multiplexed over the same destination port). If the 323 value is between 20 and 63 (inclusive), the packet is DTLS. This 324 process is summarized in Figure 3. 326 +----------------+ 327 | 127 < B < 192 -+--> forward to RTP 328 | | 329 packet --> | 19 < B < 64 -+--> forward to DTLS 330 | | 331 | B < 2 -+--> forward to STUN 332 +----------------+ 334 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 335 Here the field B denotes the leading byte of the packet. 337 END OLD TEXT 339 NEW TEXT 341 The process for demultiplexing a packet is as follows. The receiver 342 looks at the first byte of the packet. If the value of this byte is 343 in between 0 and 3 (inclusive), then the packet is STUN. If the 344 value is between 16 and 19 (inclusive), then the packet is ZRTP. If 345 the value is between 20 and 63 (inclusive), then the packet is DTLS. 346 If the value is between 64 and 79 (inclusive), then the packet is 347 TURN Channel. If the value is in between 128 and 191 (inclusive), 348 then the packet is RTP (or RTCP, if both RTCP and RTP are being 349 multiplexed over the same destination port). If the value does not 350 match any known range then the packet MUST be dropped and an alert 351 MAY be logged. This process is summarized in Figure 3. 353 +----------------+ 354 | [0..3] -+--> forward to STUN 355 | | 356 | [16..19] -+--> forward to ZRTP 357 | | 358 packet --> | [20..63] -+--> forward to DTLS 359 | | 360 | [64..79] -+--> forward to TURN Channel 361 | | 362 | [128..191] -+--> forward to RTP/RTCP 363 +----------------+ 365 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 367 END NEW TEXT 369 8. Implementation Status 371 [[Note to RFC Editor: Please remove this section and the reference to 372 [RFC6982] before publication.]] 374 This section records the status of known implementations of the 375 protocol defined by this specification at the time of posting of this 376 Internet-Draft, and is based on a proposal described in [RFC6982]. 377 The description of implementations in this section is intended to 378 assist the IETF in its decision processes in progressing drafts to 379 RFCs. Please note that the listing of any individual implementation 380 here does not imply endorsement by the IETF. Furthermore, no effort 381 has been spent to verify the information presented here that was 382 supplied by IETF contributors. This is not intended as, and must not 383 be construed to be, a catalog of available implementations or their 384 features. Readers are advised to note that other implementations may 385 exist. 387 According to [RFC6982], "this will allow reviewers and working groups 388 to assign due consideration to documents that have the benefit of 389 running code, which may serve as evidence of valuable experimentation 390 and feedback that have made the implemented protocols more mature. 391 It is up to the individual working groups to use this information as 392 they see fit". 394 Note that there is currently no implementation declared in this 395 section, but the intent is to add RFC 6982 templates here from 396 implementers that support the modifications in this document. 398 9. Security Considerations 400 This document updates existing IANA registries and adds a new range 401 for TURN channels in the demuxing algorithm. 403 These modifications do not introduce any specific security 404 considerations beyond those detailed in [RFC5764]. 406 10. IANA Considerations 408 10.1. STUN Methods 410 This specification contains the registration information for reserved 411 STUN Methods codepoints, as explained in Section 3 and in accordance 412 with the procedures defined in Section 18.1 of [RFC5389]. 414 Value: 0x100-0xFFF 415 Name: Reserved (MUST be allocated with IETF Review. For DTLS-SRTP 416 multiplexing collision avoidance see RFC XXXX) 418 Reference: RFC5764, RFCXXXX 420 This specification also reassigns the ranges in the STUN Methods 421 Registry as follow: 423 Range: 0x000-0x07F 425 Registration Procedures: IETF Review 427 Range: 0x080-0x0FF 429 Registration Procedures: Designated Expert 431 10.2. TLS ContentType 433 This specification contains the registration information for reserved 434 TLS ContentType codepoints, as explained in Section 5 and in 435 accordance with the procedures defined in Section 12 of [RFC5246]. 437 Value: 0-19 439 Description: Unassigned (Requires coordination, see RFCXXXX) 441 DTLS-OK: N/A 443 Reference: RFC5764, RFCXXXX 445 Value: 64-255 447 Description: Unassigned (Requires coordination, see RFCXXXX)) 449 DTLS-OK: N/A 451 Reference: RFC5764, RFCXXXX 453 10.3. TURN Channel Numbers 455 This specification contains the registration information for reserved 456 TURN Channel Numbers codepoints, as explained in Section 6 and in 457 accordance with the procedures defined in Section 18 of [RFC5766]. 459 Value: 0x5000-0xFFFF 461 Name: Reserved (For DTLS-SRTP multiplexing collision avoidance see 462 RFC XXXX) 464 Reference: RFCXXXX 466 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 467 document.] 469 11. Acknowledgements 471 The implicit STUN Method codepoint allocations problem was first 472 reported by Martin Thomson in the RTCWEB mailing-list and discussed 473 further with Magnus Westerlund. 475 Thanks to Simon Perreault, Colton Shields, Cullen Jennings, Colin 476 Perkins, Magnus Westerlund, Paul Jones, Jonathan Lennox, Varun Singh, 477 Justin Uberti, Joseph Salowey, Martin Thomson, Ben Campbell, Stephen 478 Farrell, Alan Johnston and Paul Kyzivat for the comments, 479 suggestions, and questions that helped improve this document. 481 12. References 483 12.1. Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, 487 DOI 10.17487/RFC2119, March 1997, 488 . 490 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 491 Jacobson, "RTP: A Transport Protocol for Real-Time 492 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 493 July 2003, . 495 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 496 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 497 RFC 3711, DOI 10.17487/RFC3711, March 2004, 498 . 500 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 501 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 502 . 504 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 505 (ICE): A Protocol for Network Address Translator (NAT) 506 Traversal for Offer/Answer Protocols", RFC 5245, 507 DOI 10.17487/RFC5245, April 2010, 508 . 510 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 511 (TLS) Protocol Version 1.2", RFC 5246, 512 DOI 10.17487/RFC5246, August 2008, 513 . 515 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 516 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 517 DOI 10.17487/RFC5389, October 2008, 518 . 520 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 521 Security (DTLS) Extension to Establish Keys for the Secure 522 Real-time Transport Protocol (SRTP)", RFC 5764, 523 DOI 10.17487/RFC5764, May 2010, 524 . 526 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 527 Relays around NAT (TURN): Relay Extensions to Session 528 Traversal Utilities for NAT (STUN)", RFC 5766, 529 DOI 10.17487/RFC5766, April 2010, 530 . 532 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 533 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 534 January 2012, . 536 12.2. Informative References 538 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 539 Media Path Key Agreement for Unicast Secure RTP", 540 RFC 6189, DOI 10.17487/RFC6189, April 2011, 541 . 543 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 544 Code: The Implementation Status Section", RFC 6982, 545 DOI 10.17487/RFC6982, July 2013, 546 . 548 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 549 Transport Layer (UDPTL) over Datagram Transport Layer 550 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 551 2014, . 553 [I-D.ietf-mmusic-sdp-bundle-negotiation] 554 Holmberg, C., Alvestrand, H., and C. Jennings, 555 "Negotiating Media Multiplexing Using the Session 556 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 557 negotiation-23 (work in progress), July 2015. 559 Appendix A. Release notes 561 This section must be removed before publication as an RFC. 563 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-09 and 564 draft-ietf-avtcore-rfc5764-mux-fixes-08 566 o Added ZRTP awareness to demultiplexing logic. 568 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-08 and 569 draft-ietf-avtcore-rfc5764-mux-fixes-07 571 o Minor update to Security Considerations section. 573 A.3. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-07 and 574 draft-ietf-avtcore-rfc5764-mux-fixes-06 576 o Addresses Martin Thomson, Ben Campbell and Stephen Farrell's 577 review comments about TLS ContentType registrations. 579 A.4. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-06 and 580 draft-ietf-avtcore-rfc5764-mux-fixes-05 582 o Addresses Colin's WGLC review comments 584 A.5. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-05 and 585 draft-ietf-avtcore-rfc5764-mux-fixes-04 587 o Removed some remnants of the ordering from Section 6 589 o Moved Terminology from Section 5 to Section 2 591 A.6. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-04 and 592 draft-ietf-avtcore-rfc5764-mux-fixes-03 594 o Removed Section on "Demultiplexing Algorithm Test Order" 596 o Split the Introduction into separate sections 598 A.7. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-03 and 599 draft-ietf-avtcore-rfc5764-mux-fixes-02 601 o Revert to the RFC 5389, as the stunbis reference was needed only 602 for STUN over SCTP. 604 A.8. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-02 and 605 draft-ietf-avtcore-rfc5764-mux-fixes-01 607 o Remove any discussion about SCTP until a consensus emerges in 608 TRAM. 610 A.9. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-01 and 611 draft-ietf-avtcore-rfc5764-mux-fixes-00 613 o Instead of allocating the values that are common on each registry, 614 the specification now only reserves them, giving the possibility 615 to allocate them in case muxing is irrelevant. 617 o STUN range is now 0-3m with 2-3 being Designated Expert. 619 o TLS ContentType 0-19 and 64-255 are now reserved. 621 o Add SCTP over UDP value. 623 o If an implementation uses the source IP address/port to separate 624 TURN channels packets then the whole channel numbers are 625 available. 627 o If not the prefix is between 64 and 79. 629 o First byte test order is now by incremental values, so failure is 630 deterministic. 632 o Redraw the demuxing diagram. 634 A.10. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-00 and 635 draft-petithuguenin-avtcore-rfc5764-mux-fixes-02 637 o Adoption by WG. 639 o Add reference to STUNbis. 641 A.11. Modifications between draft-petithuguenin-avtcore-rfc5764-mux- 642 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 644 o Change affiliation. 646 Authors' Addresses 648 Marc Petit-Huguenin 649 Impedance Mismatch 651 Email: marc@petit-huguenin.org 652 Gonzalo Salgueiro 653 Cisco Systems 654 7200-12 Kit Creek Road 655 Research Triangle Park, NC 27709 656 US 658 Email: gsalguei@cisco.com