GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7941

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7941.txt · Last modified: 2016/09/01 01:14 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki