diff options
Diffstat (limited to 'doc/rfc/rfc7941.txt')
| -rw-r--r-- | doc/rfc/rfc7941.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc7941.txt b/doc/rfc/rfc7941.txt new file mode 100644 index 0000000..a420fe7 --- /dev/null +++ b/doc/rfc/rfc7941.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Westerlund +Request for Comments: 7941 B. Burman +Category: Standards Track Ericsson +ISSN: 2070-1721 R. Even + Huawei Technologies + M. Zanaty + Cisco Systems + August 2016 + + + RTP Header Extension for + the RTP Control Protocol (RTCP) Source Description Items + +Abstract + + Source Description (SDES) items are normally transported in the RTP + Control Protocol (RTCP). In some cases, it can be beneficial to + speed up the delivery of these items. The main case is when a new + synchronization source (SSRC) joins an RTP session and the receivers + need this source's identity, relation to other sources, or its + synchronization context, all of which may be fully or partially + identified using SDES items. To enable this optimization, this + document specifies a new RTP header extension that can carry SDES + items. + +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/rfc7941. + + + + + + + + + + + + + +Westerlund, et al. Standards Track [Page 1] + +RFC 7941 RTP HE for RTCP SDES August 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5 + 4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 6 + 4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6 + 4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6 + 4.2.1. One-Byte or Two-Byte Headers . . . . . . . . . . . . 6 + 4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7 + 4.2.3. Transmission Considerations . . . . . . . . . . . . . 8 + 4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9 + 4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 10 + 4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10 + 4.2.7. RTP Header Compression . . . . . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11 + 5.2. Creation of the "RTP SDES Compact Header Extensions" + Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3. Registration of SDES Item . . . . . . . . . . . . . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 7.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + + + + + + +Westerlund, et al. Standards Track [Page 2] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + +1. Introduction + + This specification defines an RTP header extension [RFC3550][RFC5285] + that can carry RTCP Source Description (SDES) items. Normally, the + SDES items are carried in their own RTCP packet type [RFC3550]. By + including selected SDES items in a header extension, the + determination of relationship and synchronization context for new RTP + streams (SSRCs) in an RTP session can be optimized. Which + relationship and what information depends on the SDES items carried. + This becomes a complement to using only RTCP for SDES item delivery. + + It is important to note that not all SDES items are appropriate to + transmit using RTP header extensions. Some SDES items perform + binding or identify synchronization contexts with strict timeliness + requirements, while many other SDES items do not have such + requirements. In addition, security and privacy concerns for the + SDES item information need to be considered. For example, the Name + and Location SDES items are highly sensitive from a privacy + perspective and should not be transported over the network without + strong security. No use case has identified that such information is + required when the first RTP packets arrive. A delay of a few seconds + before such information is available to the receiver appears + acceptable. Therefore, only appropriate SDES items, such as CNAME, + will be registered for use with this header extension. + + Requirements language and terminology are defined in Section 2. + Section 3 describes why this header extension is sometimes required + or at least provides a significant improvement compared to waiting + for regular RTCP packet transmissions of the information. Section 4 + provides a specification of the header extension and usage + recommendations. Section 5 defines a subspace of the header + extension URN to be used for existing and future SDES items and + registers the appropriate existing SDES items. + +2. Definitions + +2.1. Requirements Language + + 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 RFC 2119 [RFC2119]. + + + + + + + + + + +Westerlund, et al. Standards Track [Page 3] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + +2.2. Terminology + + This document uses terminology defined in "A Taxonomy of Semantics + and Mechanisms for Real-Time Transport Protocol (RTP) Sources" + [RFC7656]. In particular, the following terms are used: + + Media Source + + RTP Stream + + Media Encoder + + Participant + +3. Motivation + + SDES items are associated with a particular SSRC and thus with a + particular RTP stream. The Source Description items provide various + metadata associated with the SSRC. How important it is to have this + data no later than when the first RTP packets is received depends on + the item itself. The CNAME item is one item that is commonly needed + either at reception of the first RTP packet for this SSRC or at least + by the time the first media can be played out. If it is not + available, the synchronization context cannot be determined; thus, + any related streams cannot be correctly synchronized. Therefore, + this is a valuable example for having this information early when a + new RTP stream is received. + + The main reason for new SSRCs in an RTP session is when media sources + are added. This can be because either an endpoint is adding a new + actual media source or additional participants in a multi-party + session are added to the session. Another reason for a new SSRC can + be an SSRC collision that forces both colliding parties to select new + SSRCs. + + For the case of rapid media synchronization, one may use the RTP + header extension for rapid synchronization of RTP flows [RFC6051]. + This header extension carries the clock information present in the + RTCP sender report (SR) packets. However, it assumes that the CNAME + binding is known, which can be provided via signaling [RFC5576] in + some cases, but not all. Thus, an RTP header extension for carrying + SDES items like CNAME is a powerful combination to enable rapid + synchronization in all cases. + + The "Rapid Synchronisation of RTP Flows" specification [RFC6051] does + provide an analysis of the initial synchronization delay for + different sessions depending on the number of receivers as well as on + session bandwidth (Section 2.1 of [RFC6051]). These results are also + + + +Westerlund, et al. Standards Track [Page 4] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + applicable for other SDES items that have a similar time dependency + until the information can be sent using RTCP. These figures can be + used to determine the benefit of reducing the initial delay before + information is available for some use cases. + + [RFC6051] also discusses the case of late joiners and defines an RTCP + Feedback format to request synchronization information, which is + another potential use case for SDES items in the RTP header + extension. It would, for example, be natural to include a CNAME SDES + item with the header extension containing the NTP-formatted reference + clock to ensure synchronization. + + The ongoing work on bundling Session Description Protocol (SDP) media + descriptions [SDP-BUNDLE] has identified a new SDES item that can + benefit from timely delivery. A corresponding RTP SDES compact + header extension is therefore also defined and registered in that + document: + + MID: This is a media description identifier that matches the value + of the SDP [RFC4566] a=mid attribute [RFC5888], to associate RTP + streams multiplexed on the same transport with their respective + SDP media description. + +4. Specification + + This section first specifies the SDES item RTP header extension + format, followed by some usage considerations. + +4.1. SDES Item Header Extension + + An RTP header extension scheme allowing for multiple extensions is + defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. + That specification defines both short and long item headers. The + short headers (one byte) are restricted to 1 to 16 bytes of data, + while the long format (two bytes) supports a data length of 0 to 255 + bytes. Thus, the RTP header extension formats are capable of + supporting any SDES item from a data length perspective. + + The ID field, independent of a short or long format, identifies both + the type of RTP header extension and, in the case of the SDES item + header extension, the type of SDES item. The mapping is done in + signaling by identifying the header extension and SDES item type + using a URN, which is defined in Section 5 ("IANA Considerations") + for the known SDES items appropriate to use. + + + + + + + +Westerlund, et al. Standards Track [Page 5] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + +4.1.1. One-Byte Format + + The one-byte header format for an SDES item extension element + consists of the one-byte header (defined in Section 4.2 of + [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length + field (len) that identifies the number of data bytes (len value +1) + following the header. The data part consists of len+1 bytes of UTF-8 + [RFC3629] text. The type of text and its mapping to the SDES item + type are determined by the ID field value. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID | len | SDES item text value ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1 + +4.1.2. Two-Byte Format + + The two-byte header format for an SDES item extension element + consists of the two-byte header (defined in Section 4.3 of + [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length + field (len) that identifies the number of data bytes following the + header. The data part consists of len bytes of UTF-8 text. The type + of text and its mapping to the SDES item type are determined by the + ID field value. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID | len | SDES item text value ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2 + +4.2. Usage of the SDES Item Header Extension + + This section discusses various usage considerations: which form of + the header extension to use, the packet expansion, and when to send + SDES items in the header extension. + +4.2.1. One-Byte or Two-Byte Headers + + The RTP header extensions for SDES items MAY use either the one-byte + or two-byte header formats, depending on the text value size for the + used SDES items and the requirement from any other header extensions + used. The one-byte header SHOULD be used when all non-SDES item + + + +Westerlund, et al. Standards Track [Page 6] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + header extensions support the one-byte format and all SDES item text + values contain at most 16 bytes. Note that the RTP header extension + specification [RFC5285] does not allow mixing one-byte and two-byte + headers for the same RTP stream (SSRC), so if any SDES item requires + the two-byte header, then all other header extensions MUST also use + the two-byte header format. + + For example, if using CNAMEs that are generated according to + "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names + (CNAMEs)" [RFC7022], if using short-term persistent values, and if + 96-bit random values prior to base64 encoding are sufficient, then + they will fit into the one-byte header format. + + An RTP middlebox needs to take care choosing between one-byte headers + and two-byte headers when creating the first packets for an outgoing + stream (SSRC) with header extensions. First of all, it needs to + consider all the header extensions that may potentially be used. + Second, it needs to know the size of the SDES items that are going to + be included and use two-byte headers if any are longer than 16 bytes. + An RTP middlebox that forwards a stream, i.e., not mixing it or + combining it with other streams, may be able to base its choice on + the header size in incoming streams. This is assuming that the + middlebox does not modify the stream or add additional header + extensions to the stream it sends, in which case it needs to make its + own decision. + +4.2.2. MTU and Packet Expansion + + The RTP packet size will clearly increase when a header extension is + included. How much depends on the type of header extensions and + their data content. The SDES items can vary in size. There are also + some use cases that require transmitting multiple SDES items in the + same packet to ensure that all relevant data reaches the receiver. + An example of that is when CNAME, a MID, and the rapid time + synchronization extension from RFC 6051 are all needed. Such a + combination is quite likely to result in at least 16+3+8 bytes of + data plus the headers, which will be another 7 bytes for one-byte + headers, plus two bytes of header padding to make the complete header + extension 32-bit word aligned, thus 36 bytes in total. + + If the packet expansion cannot be taken into account when producing + the RTP payload, it can cause an issue. An RTP payload that is + created to meet a particular IP-level Maximum Transmission Unit + (MTU), taking the addition of IP/UDP/RTP headers but not RTP header + extensions into account, could exceed the MTU when the header + extensions are present, thus resulting in IP fragmentation. IP + fragmentation is known to negatively impact the loss rate due to + middleboxes unwilling or not capable of dealing with IP fragments, as + + + +Westerlund, et al. Standards Track [Page 7] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + well as increasing the target surface for other types of packet + losses. + + As this is a real issue, the media encoder and payload packetizer + should be flexible and be capable of handling dynamically varying + payload size restrictions to counter the packet expansion caused by + header extensions. If that is not possible, some reasonable worst- + case packet expansion should be calculated and used to reduce the RTP + payload size of all RTP packets the sender transmits. + +4.2.3. Transmission Considerations + + The general recommendation is to only send header extensions when + needed. This is especially true for SDES items that can be sent in + periodic repetitions of RTCP throughout the whole session. Thus, the + different usages (Section 4.2.4) have different recommendations. The + following are some general considerations for getting the header + extensions delivered to the receiver: + + 1. The probability for packet loss and burst loss determine how many + repetitions of the header extensions will be required to reach a + targeted delivery probability and, if burst loss is likely, what + distribution would be needed to avoid getting all repetitions of + the header extensions lost in a single burst. + + 2. If a set of packets are all needed to enable decoding, there is + commonly no reason for including the header extension in all of + these packets, as they share fate. Instead, at most one instance + of the header extension per independently decodable set of media + data would be a more efficient use of the bandwidth. + + 3. How early the SDES item information is needed, from the first + received RTP data or only after some set of packets are received, + can guide if the header extension(s) should be in all of the + first N packets or be included only once per set of packets, for + example, once per video frame. + + 4. The use of RTP-level robustness mechanisms, such as RTP + retransmission [RFC4588] or forward error correction [RFC5109], + may treat packets differently from a robustness perspective, and + SDES header extensions should be added to packets that get a + treatment corresponding to the relative importance of receiving + the information. + + As a summary, the number of header extension transmissions should be + tailored to a desired probability of delivery, taking the receiver + population size into account. For the very basic case, N repetitions + of the header extensions should be sufficient but may not be optimal. + + + +Westerlund, et al. Standards Track [Page 8] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + N is selected so that the header extension target delivery + probability reaches 1-P^N, where P is the probability of packet loss. + For point-to-point or small receiver populations, it might also be + possible to use feedback, such as RTCP, to determine when the + information in the header extensions has reached all receivers and to + stop further repetitions. Feedback that can be used includes the + RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which + indicates successful delivery of particular packets. If the RTP/AVPF + transport-layer feedback message for generic NACK [RFC4585] is used, + it can indicate the failure to deliver an RTP packet with the header + extension, thus indicating the need for further repetitions. The + normal RTCP report blocks can also provide an indicator of successful + delivery, if no losses are indicated for a reporting interval + covering the RTP packets with the header extension. Note that loss + of an RTCP packet reporting on an interval where RTP header extension + packets were sent does not necessarily mean that the RTP header + extension packets themselves were lost. + +4.2.4. Different Usages + +4.2.4.1. New SSRC + + A new SSRC joins an RTP session. As this SSRC is completely new for + everyone, the goal is to ensure, with high probability, that all RTP + session participants receive the information in the header extension. + Thus, header extension transmission strategies that allow some + margins in the delivery probability should be considered. + +4.2.4.2. Late Joiner + + In a multi-party RTP session where one or a small number of receivers + join a session where the majority of receivers already have all + necessary information, the use of header extensions to deliver + relevant information should be tailored to reach the new receivers. + The trigger to send header extensions can, for example, be either + RTCP from a new receiver(s) or an explicit request like the Rapid + Resynchronization Request defined in [RFC6051]. In centralized + topologies where an RTP middlebox is present, it can be responsible + for transmitting the known information, possibly stored, to the new + session participant only and not repeat it to all the session + participants. + +4.2.4.3. Information Change + + If the SDES information is tightly coupled with the RTP data, and the + SDES information needs to be updated, then the use of the RTP header + extension is superior to RTCP. Using the RTP header extension + ensures that the information is updated on reception of the related + + + +Westerlund, et al. Standards Track [Page 9] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + RTP media, ensuring synchronization between the two. Continued use + of the old SDES information can lead to undesired effects in the + application. Thus, header extension transmission strategies with + high probability of delivery should be chosen. + +4.2.5. SDES Items in RTCP + + The RTP header extension information, i.e., SDES items, can and will + be sent also in RTCP. Therefore, it is worth making some reflections + on this interaction. As an alternative to the header extension, it + is possible to schedule a non-regular RTCP packet transmission + containing important SDES items, if one uses an RTP-/AVPF-based RTP + profile. Depending on the mode in which one's RTCP feedback + transmitter is working, extra RTCP packets may be sent as immediate + or early packets, enabling more timely SDES information delivery. + + There are, however, two aspects that differ between using RTP header + extensions and any non-regular transmission of RTCP packets. First, + as the RTCP packet is a separate packet, there is no direct relation + and also no fate sharing between the relevant media data and the SDES + information. The order of arrival for the packets will matter. With + a header extension, the SDES items can be ensured to arrive if the + media data to play out arrives. Second, it is difficult to determine + if an RTCP packet is actually delivered, as the RTCP packets lack + both a sequence number and a mechanism providing feedback on the RTCP + packets themselves. + +4.2.6. Update Flaps + + The SDES item may arrive both in RTCP and in RTP header extensions, + potentially causing the value to flap back and forth at the time of + updating. There are at least two reasons for these flaps. The first + one is packet reordering, where a pre-update RTP or RTCP packet with + an SDES item is delivered to the receiver after the first RTP/RTCP + packet with the updated value. The second reason is the different + code paths for RTP and RTCP in implementations. An update to the + sender's SDES item parameter can take a different time to propagate + to the receiver than the corresponding media data. For example, an + RTCP packet with the SDES item included that may have been generated + prior to the update can still reside in a buffer and be sent + unmodified. The update of the item's value can, at the same time, + cause RTP packets to be sent including the header extension, prior to + the RTCP packet being sent. + + However, most of these issues can be avoided by the receiver + performing some checks before updating the receiver's stored value. + To handle flaps caused by reordering, SDES items received in RTP + packets with the same or a lower extended sequence number than the + + + +Westerlund, et al. Standards Track [Page 10] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + last change MUST NOT be applied, i.e., discard items that can be + determined to be older than the current one. For compound RTCP + packets, which will contain an SR packet (assuming an active RTP + sender), the receiver can use the RTCP SR timestamp field to + determine at what approximate time it was transmitted. If the + timestamp is earlier than the last received RTP packet with a header + extension carrying an SDES item, and especially if carrying a + previously used value, the SDES item in the RTCP SDES packet can be + ignored. Note that media processing and transmission pacing can + easily cause the RTP header timestamp field as well as the RTCP SR + timestamp field to not match with the actual transmission time. + +4.2.7. RTP Header Compression + + When Robust Header Compression (ROHC) [RFC5225] is used with RTP, the + RTP header extension [RFC5285] data itself is not part of what is + being compressed and thus does not impact header compression + performance. The extension indicator (X) bit in the RTP header is, + however, compressed. It is classified as rarely changing, which may + no longer be true for all RTP header extension usage, in turn leading + to lower header compression efficiency. + +5. IANA Considerations + + This section details the following updates made by IANA: + + o Creation of a new sub-registry reserved for RTCP SDES items with + the URN subspace "urn:ietf:params:rtp-hdrext:sdes:" in the "RTP + Compact Header Extensions" registry. + + o Registration of the SDES items appropriate for use with the RTP + header extension defined in this document. + +5.1. Registration of an SDES Base URN + + IANA has registered the following entry in the "RTP Compact Header + Extensions" registry: + + Extension URI: urn:ietf:params:rtp-hdrext:sdes + Description: Reserved as base URN for RTCP SDES items that are also + defined as RTP compact header extensions. + Contact: Authors of RFC 7941 + Reference: RFC 7941 + + The reason to register a base URN for an SDES subspace is that the + name represents an RTCP Source Description item, for which a + specification is strongly recommended [RFC3550]. + + + + +Westerlund, et al. Standards Track [Page 11] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + +5.2. Creation of the "RTP SDES Compact Header Extensions" Sub-Registry + + IANA has created a sub-registry to the "RTP Compact Header + Extensions" registry, with the same basic requirements, structure, + and layout as the "RTP Compact Header Extensions" registry. + + o Registry name: RTP SDES Compact Header Extensions + + o Specification: RFC 7941 + + o Information required: Same as for the "RTP Compact Header + Extensions" registry [RFC5285] + + o Review process: Same as for the "RTP Compact Header Extensions" + registry [RFC5285], with the following requirements added to the + Expert Review [RFC5226]: + + 1. Any registration using an extension URI that starts with + "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also + have a registered Source Description item in the "RTP SDES + item types" registry. + + 2. Security and privacy considerations for the SDES item MUST be + provided with the registration. + + 3. Information MUST be provided on why this SDES item requires + timely delivery, motivating it to be transported in a header + extension rather than as RTCP only. + + o Size and format of entries: Same as for the "RTP Compact Header + Extensions" registry [RFC5285]. + + o Initial assignments: See Section 5.3 of this document. + +5.3. Registration of SDES Item + + IANA has registered the following SDES item in the newly formed "RTP + SDES Compact Header Extensions" registry: + + Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname + Description: Source Description: Canonical End-Point Identifier + (SDES CNAME) + Contact: Authors of RFC 7941 + Reference: RFC 7941 + + + + + + + +Westerlund, et al. Standards Track [Page 12] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + +6. Security Considerations + + Source Description items may contain data that are sensitive from a + security perspective. There are SDES items that are or may be + sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, + PHONE, LOC, and H323-CADDR. Some may contain sensitive information, + like NOTE and PRIV, while others may be sensitive from profiling + implementations for vulnerability or other reasons, like TOOL. The + CNAME sensitivity can vary depending on how it is generated and what + persistence it has. A short-term CNAME identifier generated using a + random number generator [RFC7022] may have minimal security + implications, while a CNAME of the form user@host has privacy + concerns, and a CNAME generated from a Media Access Control (MAC) + address has long-term tracking potentials. + + In RTP sessions where any type of confidentiality protection is + enabled for RTCP, the SDES item header extensions MUST also be + protected. This implies that to provide confidentiality, users of + the Secure Real-time Transport Protocol (SRTP) need to implement and + use encrypted header extensions per [RFC6904]. SDES items carried as + RTP header extensions MUST then use commensurate strength algorithms + and SHOULD use the same cryptographic primitives (algorithms, modes) + as applied to RTCP packets carrying corresponding SDES items. If the + security level is chosen to be different for an SDES item in RTCP and + an RTP header extension, it is important to justify the exception and + to consider the security properties as the worst in each aspect for + the different configurations. It is worth noting that the current + SRTP [RFC3711] only provides protection for the next trusted RTP/RTCP + hop, which is not necessarily end to end. + + The general RTP header extension mechanism [RFC5285] does not itself + contain any functionality that is a significant risk for a + denial-of-service attack, neither from processing nor from storage + requirements. The extension for SDES items defined in this document + can potentially be a risk. The risk depends on the received SDES + item and its content. If the SDES item causes the receiver to + perform a large amount of processing, create significant storage + structures, or emit network traffic, such a risk does exist. The + CNAME SDES item in the RTP header extension is only a minor risk, as + reception of a CNAME item will create an association between the + stream carrying the SDES item and other RTP streams with the same + SDES item. This usually results in time synchronizing the media + streams; thus, some additional processing is performed. However, the + application's media quality is likely more affected by an erroneous + or changing association and media synchronization than the + application quality impact caused by the additional processing. + + + + + +Westerlund, et al. Standards Track [Page 13] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + As the SDES items are used by the RTP-based application to establish + relationships between RTP streams or between an RTP stream and + information about the originating participant, there SHOULD be strong + integrity protection and source authentication of the header + extensions. If not, an attacker can modify the SDES item value to + create erroneous relationship bindings in the receiving application. + For information regarding options for securing RTP, see [RFC7201]. + +7. References + +7.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, + <http://www.rfc-editor.org/info/rfc2119>. + + [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, <http://www.rfc-editor.org/info/rfc3550>. + + [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP + Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July + 2008, <http://www.rfc-editor.org/info/rfc5285>. + + [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure + Real-time Transport Protocol (SRTP)", RFC 6904, + DOI 10.17487/RFC6904, April 2013, + <http://www.rfc-editor.org/info/rfc6904>. + +7.2. Informative References + + [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., + "RTP Control Protocol Extended Reports (RTCP XR)", + RFC 3611, DOI 10.17487/RFC3611, November 2003, + <http://www.rfc-editor.org/info/rfc3611>. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, <http://www.rfc-editor.org/info/rfc3629>. + + [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, + <http://www.rfc-editor.org/info/rfc3711>. + + + + + +Westerlund, et al. Standards Track [Page 14] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <http://www.rfc-editor.org/info/rfc4566>. + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, + DOI 10.17487/RFC4585, July 2006, + <http://www.rfc-editor.org/info/rfc4585>. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + DOI 10.17487/RFC4588, July 2006, + <http://www.rfc-editor.org/info/rfc4588>. + + [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error + Correction", RFC 5109, DOI 10.17487/RFC5109, December + 2007, <http://www.rfc-editor.org/info/rfc5109>. + + [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression + Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and + UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, + <http://www.rfc-editor.org/info/rfc5225>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific + Media Attributes in the Session Description Protocol + (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, + <http://www.rfc-editor.org/info/rfc5576>. + + [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description + Protocol (SDP) Grouping Framework", RFC 5888, + DOI 10.17487/RFC5888, June 2010, + <http://www.rfc-editor.org/info/rfc5888>. + + [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP + Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, + <http://www.rfc-editor.org/info/rfc6051>. + + [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, + "Guidelines for Choosing RTP Control Protocol (RTCP) + Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, + September 2013, <http://www.rfc-editor.org/info/rfc7022>. + + + + +Westerlund, et al. Standards Track [Page 15] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + <http://www.rfc-editor.org/info/rfc7201>. + + [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and + B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms + for Real-Time Transport Protocol (RTP) Sources", RFC 7656, + DOI 10.17487/RFC7656, November 2015, + <http://www.rfc-editor.org/info/rfc7656>. + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Westerlund, et al. Standards Track [Page 16] + +RFC 7941 RTP HE for RTCP SDES August 2016 + + +Acknowledgments + + The authors would like to thank the following individuals for + feedback and suggestions: Colin Perkins, Ben Campbell, and Samuel + Weiler. + +Authors' Addresses + + Magnus Westerlund + Ericsson + Farogatan 6 + SE-164 80 Stockholm + Sweden + + Phone: +46 10 714 82 87 + Email: magnus.westerlund@ericsson.com + + + Bo Burman + Ericsson + Gronlandsgatan 31 + Stockholm 16480 + Sweden + + Email: bo.burman@ericsson.com + + + Roni Even + Huawei Technologies + Tel Aviv + Israel + + Email: roni.even@mail01.huawei.com + + + Mo Zanaty + Cisco Systems + 7100 Kit Creek + RTP, NC 27709 + United States of America + + Email: mzanaty@cisco.com + + + + + + + + + +Westerlund, et al. Standards Track [Page 17] + |