From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7983.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc7983.txt (limited to 'doc/rfc/rfc7983.txt') diff --git a/doc/rfc/rfc7983.txt b/doc/rfc/rfc7983.txt new file mode 100644 index 0000000..a915656 --- /dev/null +++ b/doc/rfc/rfc7983.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Petit-Huguenin +Request for Comments: 7983 Impedance Mismatch +Updates: 5764 G. Salgueiro +Category: Standards Track Cisco Systems +ISSN: 2070-1721 September 2016 + + + Multiplexing Scheme Updates + for Secure Real-time Transport Protocol (SRTP) Extension + for Datagram Transport Layer Security (DTLS) + +Abstract + + This document defines how Datagram Transport Layer Security (DTLS), + Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), + Session Traversal Utilities for NAT (STUN), Traversal Using Relays + around NAT (TURN), and ZRTP packets are multiplexed on a single + receiving socket. It overrides the guidance from RFC 5764 ("SRTP + Extension for DTLS"), which suffered from four issues described and + fixed in this document. + + This document updates RFC 5764. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7983. + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 1] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Implicit Allocation of Codepoints for New STUN Methods . . . 4 + 4. Multiplexing of ZRTP . . . . . . . . . . . . . . . . . . . . 5 + 5. Implicit Allocation of New Codepoints for TLS ContentTypes . 5 + 6. Multiplexing of TURN Channels . . . . . . . . . . . . . . . . 7 + 7. Updates to RFC 5764 . . . . . . . . . . . . . . . . . . . . . 8 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 9.1. STUN Methods . . . . . . . . . . . . . . . . . . . . . . 10 + 9.2. TLS ContentType . . . . . . . . . . . . . . . . . . . . . 10 + 9.3. Traversal Using Relays around NAT (TURN) Channel Numbers 11 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 10.2. Informative References . . . . . . . . . . . . . . . . . 12 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 2] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + +1. Introduction + + Section 5.1.2 of "Datagram Transport Layer Security (DTLS) Extension + to Establish Keys for the Secure Real-time Transport Protocol (SRTP)" + [RFC5764] defines a scheme for a Real-time Transport Protocol (RTP) + [RFC3550] receiver to demultiplex DTLS [RFC6347], Session Traversal + Utilities for NAT (STUN) [RFC5389], and Secure Real-time Transport + Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP) + [RFC3711] packets that are arriving on the RTP port. Unfortunately, + this demultiplexing scheme has created problematic issues: + + 1. It implicitly allocated codepoints for new STUN methods without + an IANA registry reflecting these new allocations. + + 2. It did not take into account the fact that ZRTP [RFC6189] also + needs to be demultiplexed with the other packet types explicitly + mentioned in Section 5.1.2 of RFC 5764. + + 3. It implicitly allocated codepoints for new Transport Layer + Security (TLS) ContentTypes without an IANA registry reflecting + these new allocations. + + 4. It did not take into account the fact that the Traversal Using + Relays around NAT (TURN) usage of STUN can create TURN channels + that also need to be demultiplexed with the other packet types + explicitly mentioned in Section 5.1.2 of RFC 5764. + + Having overlapping ranges between different IANA registries becomes + an issue when a new codepoint is allocated in one of these registries + without carefully analyzing the impact it could have on the other + registries when that codepoint is demultiplexed. Among other + downsides of the bad design of the demultiplexing algorithm detailed + in [RFC5764], it creates a requirement for coordination between + codepoint assignments where none should exist, and that is + organizationally and socially undesirable. However, RFC 5764 has + been widely deployed, so there must be an awareness of this issue and + how it must be dealt with. Thus, even if the feature related to a + codepoint is not initially thought to be useful in the context of + demultiplexing, the respective IANA registry expert should at least + raise a flag when the allocated codepoint irrevocably prevents + multiplexing. + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 3] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + + The first goal of this document is to make sure that future + allocations in any of the affected protocols are done with the full + knowledge of their impact on multiplexing. This is achieved by + updating [RFC5764], which includes modifying the IANA registries with + instructions for coordination between the protocols at risk. + + A second goal is to permit the addition of new protocols to the list + of existing multiplexed protocols in a manner that does not break + existing implementations. + + At the time of this writing, the flaws in the demultiplexing scheme + were unavoidably inherited by other documents, such as [RFC7345] and + [SDP-BUNDLE]. So in addition, these and any other affected documents + will need to be corrected with the updates this document provides. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Implicit Allocation of Codepoints for New STUN Methods + + The demultiplexing scheme in [RFC5764] states that the receiver can + identify the packet type by looking at the first byte. If the value + of this first byte is 0 or 1, the packet is identified to be STUN. + The problem with this implicit allocation is that it restricts the + codepoints for STUN methods (as described in Section 18.1 of + [RFC5389]) to values between 0x000 and 0x07F, which in turn reduces + the number of possible STUN method codepoints assigned by IETF Review + (i.e., the range 0x000 - 0x7FF) from 2048 to only 128 and eliminates + the possibility of having STUN method codepoints assigned by + Designated Expert (i.e., the range 0x800 - 0xFFF). + + To preserve the Designated Expert range, this document allocates the + values 2 and 3 to also identify STUN methods. + + The IANA Registry for STUN methods has been modified to mark the + codepoints from 0x100 to 0xFFF as Reserved. These codepoints can + still be allocated, but require IETF Review with a document that will + properly evaluate the risk of an assignment overlapping with other + registries. + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 4] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + + In addition, this document also updates the IANA registry such that + the STUN method codepoints assigned in the 0x080-0x0FF range are also + assigned via Designated Expert. The "STUN Methods" registry has been + changed as follows: + + OLD: + + 0x000-0x7FF IETF Review + 0x800-0xFFF Designated Expert + + NEW: + + 0x000-0x07F IETF Review + 0x080-0x0FF Designated Expert + 0x100-0xFFF Reserved + +4. Multiplexing of ZRTP + + ZRTP [RFC6189] is a protocol for media path Diffie-Hellman exchange + to agree on a session key and parameters for establishing unicast + SRTP sessions for Voice over IP (VoIP) applications. The ZRTP + protocol is media path keying because it is multiplexed on the same + port as RTP and does not require support in the signaling protocol. + + In order to prevent future documents from assigning values from the + unused range to a new protocol, this document modifies the [RFC5764] + demultiplexing algorithm to properly account for ZRTP [RFC6189] by + allocating the values from 16 to 19 for this purpose. + +5. Implicit Allocation of New Codepoints for TLS ContentTypes + + The demultiplexing scheme in [RFC5764] dictates that if the value of + the first byte is between 20 and 63 (inclusive), then the packet is + identified to be DTLS. For DTLS 1.0 [RFC4347] and DTLS 1.2 + [RFC6347], that first byte corresponds to the TLS ContentType field. + Considerations must be taken into account when assigning additional + ContentTypes in the codepoint ranges 0 to 19 and 64 to 255, so this + does not prevent demultiplexing when this functionality is desirable. + Note that [RFC5764] describes a narrow use of DTLS that works as long + as the specific DTLS version used abides by the restrictions on the + demultiplexing byte (the ones that this document imposes on the "TLS + ContentType Registry"). Any extension or revision to DTLS that + causes it to no longer meet these constraints should consider what + values may occur in the first byte of the DTLS message and what + impact it would have on the multiplexing that [RFC5764] describes. + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 5] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + + With respect to TLS packet identification, this document explicitly + adds a warning to the codepoints from 0 to 19 and from 64 to 255 + indicating that allocations in these ranges require coordination, as + described in this document. The "TLS ContentType Registry" has been + changed as follows: + + OLD: + + 0-19 Unassigned + 20 change_cipher_spec + 21 alert + 22 handshake + 23 application_data + 24 heartbeat + 25-255 Unassigned + + NEW: + + 0-19 Unassigned (Requires coordination; see RFC 7983) + 20 change_cipher_spec + 21 alert + 22 handshake + 23 application_data + 24 heartbeat + 25-63 Unassigned + 64-255 Unassigned (Requires coordination; see RFC 7983) + + + + + + + + + + + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 6] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + +6. Multiplexing of TURN Channels + + When used with Interactive Connectivity Establishment (ICE) + [RFC5245], an implementation of RFC 5764 can receive packets on the + same socket from three different paths, as shown in Figure 1: + + 1. Directly from the source + + 2. Through a NAT + + 3. Relayed by a TURN server + + +------+ + | TURN |<------------------------+ + +------+ | + | | + | +-------------------------+ | + | | | | + v v | | + NAT ----------- | | + | | +---------------------+ | | + | | | | | | + v v v | | | + +----------+ +----------+ + | RFC 5764 | | RFC 5764 | + +----------+ +----------+ + + Figure 1: Packet Reception by an Implementation of RFC 5764 + + Even if the ICE algorithm succeeded in selecting a non-relayed path, + it is still possible to receive data from the TURN server. For + instance, when ICE is used with aggressive nomination, the media path + can quickly change until it stabilizes. Also, freeing ICE candidates + is optional, so the TURN server can restart forwarding STUN + connectivity checks during an ICE restart. + + TURN channels are an optimization where data packets are exchanged + with a 4-byte prefix instead of the standard 36-byte STUN overhead + (see Section 2.5 of [RFC5766]). The problem is that the RFC 5764 + demultiplexing scheme does not define what to do with packets + received over a TURN channel since these packets will start with a + first byte whose value will be between 64 and 127 (inclusive). If + the TURN server was instructed to send data over a TURN channel, then + the demultiplexing scheme specified in RFC 5764 will reject these + packets. Current implementations violate RFC 5764 for values 64 to + 127 (inclusive) and they instead parse packets with such values as + TURN. + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 7] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + + In order to prevent future documents from assigning values from the + unused range to a new protocol, this document modifies the + demultiplexing algorithm in RFC 5764 to properly account for TURN + channels by allocating the values from 64 to 79 for this purpose. + This modification restricts the TURN channel space to a more limited + set of possible channels when the TURN client does the channel + binding request in combination with the demultiplexing scheme + described in [RFC5764]. + +7. Updates to RFC 5764 + + This document updates the text in Section 5.1.2 of [RFC5764] as + follows: + + OLD TEXT + + The process for demultiplexing a packet is as follows. The receiver + looks at the first byte of the packet. If the value of this byte is + 0 or 1, then the packet is STUN. If the value is in between 128 and + 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and + RTP are being multiplexed over the same destination port). If the + value is between 20 and 63 (inclusive), the packet is DTLS. This + process is summarized in Figure 3. + + +----------------+ + | 127 < B < 192 -+--> forward to RTP + | | + packet --> | 19 < B < 64 -+--> forward to DTLS + | | + | B < 2 -+--> forward to STUN + +----------------+ + + Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. + Here the field B denotes the leading byte of the packet. + + END OLD TEXT + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 8] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + + NEW TEXT + + The process for demultiplexing a packet is as follows. The receiver + looks at the first byte of the packet. If the value of this byte is + in between 0 and 3 (inclusive), then the packet is STUN. If the + value is between 16 and 19 (inclusive), then the packet is ZRTP. If + the value is between 20 and 63 (inclusive), then the packet is DTLS. + If the value is between 64 and 79 (inclusive), then the packet is + TURN Channel. If the value is in between 128 and 191 (inclusive), + then the packet is RTP (or RTCP, if both RTCP and RTP are being + multiplexed over the same destination port). If the value does not + match any known range, then the packet MUST be dropped and an alert + MAY be logged. This process is summarized in Figure 3. + + +----------------+ + | [0..3] -+--> forward to STUN + | | + | [16..19] -+--> forward to ZRTP + | | + packet --> | [20..63] -+--> forward to DTLS + | | + | [64..79] -+--> forward to TURN Channel + | | + | [128..191] -+--> forward to RTP/RTCP + +----------------+ + + Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. + + END NEW TEXT + +8. Security Considerations + + This document updates existing IANA registries and adds a new range + for TURN channels in the demultiplexing algorithm. + + These modifications do not introduce any specific security + considerations beyond those detailed in [RFC5764]. + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 9] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + +9. IANA Considerations + +9.1. STUN Methods + + This specification contains the registration information for reserved + STUN Methods codepoints, as explained in Section 3 and in accordance + with the procedures defined in Section 18.1 of [RFC5389]. + + Value: 0x100-0xFFF + + Name: Reserved (For DTLS-SRTP multiplexing collision avoidance, see + RFC 7983. Cannot be made available for assignment without IETF + Review.) + + Reference: RFC 5764, RFC 7983 + + This specification also reassigns the ranges in the STUN Methods + Registry as follows: + + Range: 0x000-0x07F + + Registration Procedures: IETF Review + + Range: 0x080-0x0FF + + Registration Procedures: Designated Expert + +9.2. TLS ContentType + + This specification contains the registration information for reserved + TLS ContentType codepoints, as explained in Section 5 and in + accordance with the procedures defined in Section 12 of [RFC5246]. + + Value: 0-19 + + Description: Unassigned (Requires coordination; see RFC 7983) + + DTLS-OK: N/A + + Reference: RFC 5764, RFC 7983 + + Value: 64-255 + + Description: Unassigned (Requires coordination; see RFC 7983) + + DTLS-OK: N/A + + Reference: RFC 5764, RFC 7983 + + + +Petit-Huguenin & Salgueiro Standards Track [Page 10] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + +9.3. Traversal Using Relays around NAT (TURN) Channel Numbers + + This specification contains the registration information for reserved + codepoints in the "Traversal Using Relays around NAT (TURN) Channel + Numbers" registry, as explained in Section 6 and in accordance with + the procedures defined in Section 18 of [RFC5766]. + + Value: 0x5000-0xFFFF + + Name: Reserved (For DTLS-SRTP multiplexing collision avoidance, see + RFC 7983.) + + Reference: RFC 7983 + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, . + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + . + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, + DOI 10.17487/RFC5245, April 2010, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + DOI 10.17487/RFC5389, October 2008, + . + + + +Petit-Huguenin & Salgueiro Standards Track [Page 11] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + + [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer + Security (DTLS) Extension to Establish Keys for the Secure + Real-time Transport Protocol (SRTP)", RFC 5764, + DOI 10.17487/RFC5764, May 2010, + . + + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using + Relays around NAT (TURN): Relay Extensions to Session + Traversal Utilities for NAT (STUN)", RFC 5766, + DOI 10.17487/RFC5766, April 2010, + . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + +10.2. Informative References + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, + . + + [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: + Media Path Key Agreement for Unicast Secure RTP", + RFC 6189, DOI 10.17487/RFC6189, April 2011, + . + + [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP + Transport Layer (UDPTL) over Datagram Transport Layer + Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August + 2014, . + + [SDP-BUNDLE] + Holmberg, C., Alvestrand, H., and C. Jennings, + "Negotiating Media Multiplexing Using the Session + Description Protocol (SDP)", Work in Progress, + draft-ietf-mmusic-sdp-bundle-negotiation-32, August 2016. + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 12] + +RFC 7983 Multiplexing Scheme Updates for RFC 5764 September 2016 + + +Acknowledgements + + The implicit STUN Method codepoint allocations problem was first + reported by Martin Thomson in the RTCWEB mailing list and discussed + further with Magnus Westerlund. + + Thanks to Simon Perreault, Colton Shields, Cullen Jennings, Colin + Perkins, Magnus Westerlund, Paul Jones, Jonathan Lennox, Varun Singh, + Justin Uberti, Joseph Salowey, Martin Thomson, Ben Campbell, Stephen + Farrell, Alan Johnston, Mehmet Ersue, Matt Miller, Spencer Dawkins, + Joel Halpern, and Paul Kyzivat for the comments, suggestions, and + questions that helped improve this document. + +Authors' Addresses + + Marc Petit-Huguenin + Impedance Mismatch + + Email: marc@petit-huguenin.org + + + Gonzalo Salgueiro + Cisco Systems + 7200-12 Kit Creek Road + Research Triangle Park, NC 27709 + United States of America + + Email: gsalguei@cisco.com + + + + + + + + + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 13] + -- cgit v1.2.3