idnits 2.17.1 draft-ietf-avtcore-rfc5764-mux-fixes-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5764, updated by this document, for RFC5378 checks: 2007-07-03) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1, 2016) is 2794 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 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-32 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: March 5, 2017 September 1, 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-11 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), Traversal Using Relays 17 around NAT (TURN), and ZRTP packets are multiplexed on a single 18 receiving socket. It overrides the guidance from RFC 5764 ("SRTP 19 Extension for DTLS"), which suffered from four issues described and 20 fixed in this document. 22 This document updates RFC 5764. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 5, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Implicit Allocation of Codepoints for New STUN Methods . . . 4 73 4. Multiplexing of ZRTP . . . . . . . . . . . . . . . . . . . . 5 74 5. Implicit Allocation of New Codepoints for TLS ContentTypes . 5 75 6. Multiplexing of TURN Channels . . . . . . . . . . . . . . . . 6 76 7. RFC 5764 Updates . . . . . . . . . . . . . . . . . . . . . . 8 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 9.1. STUN Methods . . . . . . . . . . . . . . . . . . . . . . 9 80 9.2. TLS ContentType . . . . . . . . . . . . . . . . . . . . . 10 81 9.3. Traversal Using Relays around NAT (TURN) Channel Numbers 10 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 11.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . 12 87 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux- 88 fixes-11 and draft-ietf-avtcore-rfc5764-mux-fixes-10 . . 12 89 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux- 90 fixes-10 and draft-ietf-avtcore-rfc5764-mux-fixes-09 . . 13 91 A.3. Modifications between draft-ietf-avtcore-rfc5764-mux- 92 fixes-09 and draft-ietf-avtcore-rfc5764-mux-fixes-08 . . 13 93 A.4. Modifications between draft-ietf-avtcore-rfc5764-mux- 94 fixes-08 and draft-ietf-avtcore-rfc5764-mux-fixes-07 . . 13 95 A.5. Modifications between draft-ietf-avtcore-rfc5764-mux- 96 fixes-07 and draft-ietf-avtcore-rfc5764-mux-fixes-06 . . 13 98 A.6. Modifications between draft-ietf-avtcore-rfc5764-mux- 99 fixes-06 and draft-ietf-avtcore-rfc5764-mux-fixes-05 . . 13 100 A.7. Modifications between draft-ietf-avtcore-rfc5764-mux- 101 fixes-05 and draft-ietf-avtcore-rfc5764-mux-fixes-04 . . 13 102 A.8. Modifications between draft-ietf-avtcore-rfc5764-mux- 103 fixes-04 and draft-ietf-avtcore-rfc5764-mux-fixes-03 . . 13 104 A.9. Modifications between draft-ietf-avtcore-rfc5764-mux- 105 fixes-03 and draft-ietf-avtcore-rfc5764-mux-fixes-02 . . 14 106 A.10. Modifications between draft-ietf-avtcore-rfc5764-mux- 107 fixes-02 and draft-ietf-avtcore-rfc5764-mux-fixes-01 . . 14 108 A.11. Modifications between draft-ietf-avtcore-rfc5764-mux- 109 fixes-01 and draft-ietf-avtcore-rfc5764-mux-fixes-00 . . 14 110 A.12. Modifications between draft-ietf-avtcore-rfc5764-mux- 111 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux- 112 fixes-02 . . . . . . . . . . . . . . . . . . . . . . . . 14 113 A.13. Modifications between draft-petithuguenin-avtcore-rfc5764 114 -mux-fixes-00 and draft-petithuguenin-avtcore-rfc5764 115 -mux-fixes-01 . . . . . . . . . . . . . . . . . . . . . . 15 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 118 1. Introduction 120 Section 5.1.2 of Secure Real-time Transport Protocol (SRTP) Extension 121 for DTLS [RFC5764] defines a scheme for a Real-time Transport 122 Protocol (RTP) [RFC3550] receiver to demultiplex Datagram Transport 123 Layer Security (DTLS) [RFC6347], Session Traversal Utilities for NAT 124 (STUN) [RFC5389] and Secure Real-time Transport Protocol 125 (SRTP)/Secure RTP Control Protocol (SRTCP) [RFC3711] packets that are 126 arriving on the RTP port. Unfortunately, this demultiplexing scheme 127 has created problematic issues: 129 1. It implicitly allocated codepoints for new STUN methods without 130 an IANA registry reflecting these new allocations. 132 2. It did not take into account the fact that ZRTP [RFC6189] also 133 needs to be demultiplexed with the other packet types explicitly 134 mentioned in Section 5.1.2 of RFC 5764. 136 3. It implicitly allocated codepoints for new Transport Layer 137 Security (TLS) ContentTypes without an IANA registry reflecting 138 these new allocations. 140 4. It did not take into account the fact that the Traversal Using 141 Relays around NAT (TURN) usage of STUN can create TURN channels 142 that also need to be demultiplexed with the other packet types 143 explicitly mentioned in Section 5.1.2 of RFC 5764. 145 Having overlapping ranges between different IANA registries becomes 146 an issue when a new codepoint is allocated in one of these registries 147 without carefully analyzing the impact it could have on the other 148 registries when that codepoint is demultiplexed. Among other 149 downsides of the bad design of the demultiplexing algorithm detailed 150 in [RFC5764], it creates a requirement for coordination between 151 codepoint assignments where none should exist, and that is 152 organizationally and socially undesirable. However, RFC 5764 has 153 been widely deployed so there must be an awareness of this issue and 154 how it must be dealt with. Thus, even if the feature related to a 155 codepoint is not initially thought to be useful in the context of 156 demultiplexing, the respective IANA registry expert should at least 157 raise a flag when the allocated codepoint irrevocably prevents 158 multiplexing. 160 The first goal of this document is to make sure that future 161 allocations in any of the affected protocols are done with the full 162 knowledge of their impact on multiplexing. This is achieved by 163 updating [RFC5764], which includes modifying the IANA registries with 164 instructions for coordination between the protocols at risk. 166 A second goal is to permit the addition of new protocols to the list 167 of existing multiplexed protocols in a manner that does not break 168 existing implementations. 170 At the time of this writing, the flaws in the demultiplexing scheme 171 were unavoidably inherited by other documents, such as [RFC7345] and 172 [I-D.ietf-mmusic-sdp-bundle-negotiation]. So in addition, these and 173 any other affected documents will need to be corrected with the 174 updates this document provides. 176 2. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 3. Implicit Allocation of Codepoints for New STUN Methods 184 The demultiplexing scheme in [RFC5764] states that the receiver can 185 identify the packet type by looking at the first byte. If the value 186 of this first byte is 0 or 1, the packet is identified to be STUN. 187 The problem that arises as a result of this implicit allocation is 188 that this restricts the codepoints for STUN methods (as described in 189 Section 18.1 of [RFC5389]) to values between 0x000 and 0x07F, which 190 in turn reduces the number of possible STUN method codepoints 191 assigned by IETF Review (i.e., the range from (0x000 - 0x7FF) from 192 2048 to only 128 and eliminating the possibility of having STUN 193 method codepoints assigned by Designated Expert (i.e., the range 194 0x800 - 0xFFF). 196 To preserve the Designated Expert range, this document allocates the 197 value 2 and 3 to also identify STUN methods. 199 The IANA Registry for STUN methods is modified to mark the codepoints 200 from 0x100 to 0xFFF as Reserved. These codepoints can still be 201 allocated, but require IETF Review with a document that will properly 202 evaluate the risk of an assignment overlapping with other registries. 204 In addition, this document also updates the IANA registry such that 205 the STUN method codepoints assigned in the 0x080-0x0FF range are also 206 assigned via Designated Expert. The proposed changes to the STUN 207 Method Registry are: 209 OLD: 211 0x000-0x7FF IETF Review 212 0x800-0xFFF Designated Expert 214 NEW: 216 0x000-0x07F IETF Review 217 0x080-0x0FF Designated Expert 218 0x100-0xFFF Reserved 220 4. Multiplexing of ZRTP 222 ZRTP [RFC6189] is a protocol for media path Diffie-Hellman exchange 223 to agree on a session key and parameters for establishing unicast 224 Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP 225 (VoIP) applications. The ZRTP protocol is media path keying because 226 it is multiplexed on the same port as RTP and does not require 227 support in the signaling protocol. 229 In order to prevent future documents from assigning values from the 230 unused range to a new protocol, this document modifies the [RFC5764] 231 demultiplexing algorithm to properly account for ZRTP [RFC6189] by 232 allocating the values from 16 to 19 for this purpose. 234 5. Implicit Allocation of New Codepoints for TLS ContentTypes 236 The demultiplexing scheme in [RFC5764] dictates that if the value of 237 the first byte is between 20 and 63 (inclusive), then the packet is 238 identified to be DTLS. For DTLS 1.0 [RFC4347] and DTLS 1.2 [RFC6347] 239 that first byte corresponds to the TLS ContentType field. 240 Considerations must be taken into account when assigning additional 241 ContentTypes in the code point ranges 0 to 19 and 64 to 255 so this 242 does not prevent demultiplexing when this functionality is desirable. 243 Note that [RFC5764] describes a narrow use of DTLS that works as long 244 as the specific DTLS version used abides by the restrictions on the 245 demultiplexing byte (the ones that this document imposes on the TLS 246 ContentType Registry). Any extension or revision to DTLS that causes 247 it to no longer meet these constraints should consider what values 248 may occur in the first byte of the DTLS message and what impact it 249 would have on the multiplexing that [RFC5764] describes. 251 With respect to TLS packet identification, this document explicitly 252 adds a warning to the codepoints from 0 to 19 and from 64 to 255 253 indicating that allocations in these ranges require coordination, as 254 described in this document. The proposed changes to the TLS 255 ContentType Registry are: 257 OLD: 259 0-19 Unassigned 260 20 change_cipher_spec 261 21 alert 262 22 handshake 263 23 application_data 264 24 heartbeat 265 25-255 Unassigned 267 NEW: 269 0-19 Unassigned (Requires coordination, see RFCXXXX) 270 20 change_cipher_spec 271 21 alert 272 22 handshake 273 23 application_data 274 24 heartbeat 275 25-63 Unassigned 276 64-255 Unassigned (Requires coordination, see RFCXXXX) 278 6. Multiplexing of TURN Channels 280 When used with ICE [RFC5245], an RFC 5764 implementation can receive 281 packets on the same socket from three different paths, as shown in 282 Figure 1: 284 1. Directly from the source 286 2. Through a NAT 288 3. Relayed by a TURN server 289 +------+ 290 | TURN |<------------------------+ 291 +------+ | 292 | | 293 | +-------------------------+ | 294 | | | | 295 v v | | 296 NAT ----------- | | 297 | | +---------------------+ | | 298 | | | | | | 299 v v v | | | 300 +----------+ +----------+ 301 | RFC 5764 | | RFC 5764 | 302 +----------+ +----------+ 304 Figure 1: Packet Reception by an RFC 5764 Implementation 306 Even if the ICE algorithm succeeded in selecting a non-relayed path, 307 it is still possible to receive data from the TURN server. For 308 instance, when ICE is used with aggressive nomination the media path 309 can quickly change until it stabilizes. Also, freeing ICE candidates 310 is optional, so the TURN server can restart forwarding STUN 311 connectivity checks during an ICE restart. 313 TURN channels are an optimization where data packets are exchanged 314 with a 4-byte prefix, instead of the standard 36-byte STUN overhead 315 (see Section 2.5 of [RFC5766]). The problem is that the RFC 5764 316 demultiplexing scheme does not define what to do with packets 317 received over a TURN channel since these packets will start with a 318 first byte whose value will be between 64 and 127 (inclusive). If 319 the TURN server was instructed to send data over a TURN channel, then 320 the current RFC 5764 demultiplexing scheme will reject these packets. 321 Current implementations violate RFC 5764 for values 64 to 127 322 (inclusive) and they instead parse packets with such values as TURN. 324 In order to prevent future documents from assigning values from the 325 unused range to a new protocol, this document modifies the RFC 5764 326 demultiplexing algorithm to properly account for TURN channels by 327 allocating the values from 64 to 79 for this purpose. This 328 modification restricts the TURN channel space to a more limited set 329 of possible channels when the TURN client does the channel binding 330 request in combination with the demultiplexing scheme described in 331 [RFC5764]. 333 7. RFC 5764 Updates 335 This document updates the text in Section 5.1.2 of [RFC5764] as 336 follows: 338 OLD TEXT 340 The process for demultiplexing a packet is as follows. The receiver 341 looks at the first byte of the packet. If the value of this byte is 342 0 or 1, then the packet is STUN. If the value is in between 128 and 343 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 344 RTP are being multiplexed over the same destination port). If the 345 value is between 20 and 63 (inclusive), the packet is DTLS. This 346 process is summarized in Figure 3. 348 +----------------+ 349 | 127 < B < 192 -+--> forward to RTP 350 | | 351 packet --> | 19 < B < 64 -+--> forward to DTLS 352 | | 353 | B < 2 -+--> forward to STUN 354 +----------------+ 356 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 357 Here the field B denotes the leading byte of the packet. 359 END OLD TEXT 361 NEW TEXT 363 The process for demultiplexing a packet is as follows. The receiver 364 looks at the first byte of the packet. If the value of this byte is 365 in between 0 and 3 (inclusive), then the packet is STUN. If the 366 value is between 16 and 19 (inclusive), then the packet is ZRTP. If 367 the value is between 20 and 63 (inclusive), then the packet is DTLS. 368 If the value is between 64 and 79 (inclusive), then the packet is 369 TURN Channel. If the value is in between 128 and 191 (inclusive), 370 then the packet is RTP (or RTCP, if both RTCP and RTP are being 371 multiplexed over the same destination port). If the value does not 372 match any known range then the packet MUST be dropped and an alert 373 MAY be logged. This process is summarized in Figure 3. 375 +----------------+ 376 | [0..3] -+--> forward to STUN 377 | | 378 | [16..19] -+--> forward to ZRTP 379 | | 380 packet --> | [20..63] -+--> forward to DTLS 381 | | 382 | [64..79] -+--> forward to TURN Channel 383 | | 384 | [128..191] -+--> forward to RTP/RTCP 385 +----------------+ 387 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 389 END NEW TEXT 391 8. Security Considerations 393 This document updates existing IANA registries and adds a new range 394 for TURN channels in the demuxing algorithm. 396 These modifications do not introduce any specific security 397 considerations beyond those detailed in [RFC5764]. 399 9. IANA Considerations 401 9.1. STUN Methods 403 This specification contains the registration information for reserved 404 STUN Methods codepoints, as explained in Section 3 and in accordance 405 with the procedures defined in Section 18.1 of [RFC5389]. 407 Value: 0x100-0xFFF 409 Name: Reserved (MUST be allocated with IETF Review. For DTLS-SRTP 410 multiplexing collision avoidance see RFCXXXX) 412 Reference: RFC5764, RFCXXXX 414 This specification also reassigns the ranges in the STUN Methods 415 Registry as follow: 417 Range: 0x000-0x07F 419 Registration Procedures: IETF Review 421 Range: 0x080-0x0FF 422 Registration Procedures: Designated Expert 424 9.2. TLS ContentType 426 This specification contains the registration information for reserved 427 TLS ContentType codepoints, as explained in Section 5 and in 428 accordance with the procedures defined in Section 12 of [RFC5246]. 430 Value: 0-19 432 Description: Unassigned (Requires coordination, see RFCXXXX) 434 DTLS-OK: N/A 436 Reference: RFC5764, RFCXXXX 438 Value: 64-255 440 Description: Unassigned (Requires coordination, see RFCXXXX)) 442 DTLS-OK: N/A 444 Reference: RFC5764, RFCXXXX 446 9.3. Traversal Using Relays around NAT (TURN) Channel Numbers 448 This specification contains the registration information for reserved 449 Traversal Using Relays around NAT (TURN) Channel Numbers codepoints, 450 as explained in Section 6 and in accordance with the procedures 451 defined in Section 18 of [RFC5766]. 453 Value: 0x5000-0xFFFF 455 Name: Reserved (For DTLS-SRTP multiplexing collision avoidance see 456 RFCXXXX) 458 Reference: RFCXXXX 460 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number assigned 461 to this document (for all instances where this convention is used 462 throughout this draft).] 464 10. Acknowledgements 466 The implicit STUN Method codepoint allocations problem was first 467 reported by Martin Thomson in the RTCWEB mailing-list and discussed 468 further with Magnus Westerlund. 470 Thanks to Simon Perreault, Colton Shields, Cullen Jennings, Colin 471 Perkins, Magnus Westerlund, Paul Jones, Jonathan Lennox, Varun Singh, 472 Justin Uberti, Joseph Salowey, Martin Thomson, Ben Campbell, Stephen 473 Farrell, Alan Johnston, Mehmet Ersue, Matt Miller, Spencer Dawkins, 474 Joel Halpern and Paul Kyzivat for the comments, suggestions, and 475 questions that helped improve this document. 477 11. References 479 11.1. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, 483 DOI 10.17487/RFC2119, March 1997, 484 . 486 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 487 Jacobson, "RTP: A Transport Protocol for Real-Time 488 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 489 July 2003, . 491 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 492 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 493 RFC 3711, DOI 10.17487/RFC3711, March 2004, 494 . 496 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 497 (ICE): A Protocol for Network Address Translator (NAT) 498 Traversal for Offer/Answer Protocols", RFC 5245, 499 DOI 10.17487/RFC5245, April 2010, 500 . 502 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 503 (TLS) Protocol Version 1.2", RFC 5246, 504 DOI 10.17487/RFC5246, August 2008, 505 . 507 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 508 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 509 DOI 10.17487/RFC5389, October 2008, 510 . 512 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 513 Security (DTLS) Extension to Establish Keys for the Secure 514 Real-time Transport Protocol (SRTP)", RFC 5764, 515 DOI 10.17487/RFC5764, May 2010, 516 . 518 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 519 Relays around NAT (TURN): Relay Extensions to Session 520 Traversal Utilities for NAT (STUN)", RFC 5766, 521 DOI 10.17487/RFC5766, April 2010, 522 . 524 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 525 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 526 January 2012, . 528 11.2. Informative References 530 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 531 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 532 . 534 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 535 Media Path Key Agreement for Unicast Secure RTP", 536 RFC 6189, DOI 10.17487/RFC6189, April 2011, 537 . 539 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 540 Transport Layer (UDPTL) over Datagram Transport Layer 541 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 542 2014, . 544 [I-D.ietf-mmusic-sdp-bundle-negotiation] 545 Holmberg, C., Alvestrand, H., and C. Jennings, 546 "Negotiating Media Multiplexing Using the Session 547 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 548 negotiation-32 (work in progress), August 2016. 550 Appendix A. Release notes 552 This section must be removed before publication as an RFC. 554 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-11 and 555 draft-ietf-avtcore-rfc5764-mux-fixes-10 557 o Addressed comments from AD review (editorial). 559 o Addressed comments from Gen-ART, Sec-Dir and OPS-Dir reviews. 561 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-10 and 562 draft-ietf-avtcore-rfc5764-mux-fixes-09 564 o Removed Implementation Status section. 566 o Updated based on Magnus Westerlund's LC review comments. 568 o On advice of EKR changed boilerplate to pre5378Trust200902. 570 A.3. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-09 and 571 draft-ietf-avtcore-rfc5764-mux-fixes-08 573 o Added ZRTP awareness to demultiplexing logic. 575 A.4. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-08 and 576 draft-ietf-avtcore-rfc5764-mux-fixes-07 578 o Minor update to Security Considerations section. 580 A.5. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-07 and 581 draft-ietf-avtcore-rfc5764-mux-fixes-06 583 o Addresses Martin Thomson, Ben Campbell and Stephen Farrell's 584 review comments about TLS ContentType registrations. 586 A.6. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-06 and 587 draft-ietf-avtcore-rfc5764-mux-fixes-05 589 o Addresses Colin's WGLC review comments 591 A.7. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-05 and 592 draft-ietf-avtcore-rfc5764-mux-fixes-04 594 o Removed some remnants of the ordering from Section 6 596 o Moved Terminology from Section 5 to Section 2 598 A.8. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-04 and 599 draft-ietf-avtcore-rfc5764-mux-fixes-03 601 o Removed Section on "Demultiplexing Algorithm Test Order" 603 o Split the Introduction into separate sections 605 A.9. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-03 and 606 draft-ietf-avtcore-rfc5764-mux-fixes-02 608 o Revert to the RFC 5389, as the stunbis reference was needed only 609 for STUN over SCTP. 611 A.10. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-02 and 612 draft-ietf-avtcore-rfc5764-mux-fixes-01 614 o Remove any discussion about SCTP until a consensus emerges in 615 TRAM. 617 A.11. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-01 and 618 draft-ietf-avtcore-rfc5764-mux-fixes-00 620 o Instead of allocating the values that are common on each registry, 621 the specification now only reserves them, giving the possibility 622 to allocate them in case muxing is irrelevant. 624 o STUN range is now 0-3m with 2-3 being Designated Expert. 626 o TLS ContentType 0-19 and 64-255 are now reserved. 628 o Add SCTP over UDP value. 630 o If an implementation uses the source IP address/port to separate 631 TURN channels packets then the whole channel numbers are 632 available. 634 o If not the prefix is between 64 and 79. 636 o First byte test order is now by incremental values, so failure is 637 deterministic. 639 o Redraw the demuxing diagram. 641 A.12. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-00 and 642 draft-petithuguenin-avtcore-rfc5764-mux-fixes-02 644 o Adoption by WG. 646 o Add reference to STUNbis. 648 A.13. Modifications between draft-petithuguenin-avtcore-rfc5764-mux- 649 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 651 o Change affiliation. 653 Authors' Addresses 655 Marc Petit-Huguenin 656 Impedance Mismatch 658 Email: marc@petit-huguenin.org 660 Gonzalo Salgueiro 661 Cisco Systems 662 7200-12 Kit Creek Road 663 Research Triangle Park, NC 27709 664 US 666 Email: gsalguei@cisco.com