draft-ietf-avtext-sdes-hdr-ext-05.txt   draft-ietf-avtext-sdes-hdr-ext-06.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft B. Burman Internet-Draft B. Burman
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: September 3, 2016 R. Even Expires: October 28, 2016 R. Even
Huawei Technologies Huawei Technologies
M. Zanaty M. Zanaty
Cisco Systems Cisco Systems
March 2, 2016 April 26, 2016
RTP Header Extension for RTCP Source Description Items RTP Header Extension for RTCP Source Description Items
draft-ietf-avtext-sdes-hdr-ext-05 draft-ietf-avtext-sdes-hdr-ext-06
Abstract Abstract
Source Description (SDES) items are normally transported in RTP Source Description (SDES) items are normally transported in RTP
control protocol (RTCP). In some cases it can be beneficial to speed control protocol (RTCP). In some cases it can be beneficial to speed
up the delivery of these items. Mainly when a new source (SSRC) up the delivery of these items. Mainly when a new source (SSRC)
joins an RTP session and the receivers needs this source's identity, joins an RTP session and the receivers needs this source's identity,
relation to other sources, or its synchronization context, all of relation to other sources, or its synchronization context, all of
which may be fully or partially identified using SDES items. To which may be fully or partially identified using SDES items. To
enable this optimization, this document specifies a new RTP header enable this optimization, this document specifies a new RTP header
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2016. This Internet-Draft will expire on October 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7 4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7
4.2.3. Transmission Considerations . . . . . . . . . . . . . 7 4.2.3. Transmission Considerations . . . . . . . . . . . . . 7
4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9 4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9
4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9 4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9
4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10 4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11 5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11
5.2. Creation of an SDES Sub-Registry . . . . . . . . . . . . 11 5.2. Creation of an SDES Sub-Registry . . . . . . . . . . . . 11
5.3. Registration of SDES Items . . . . . . . . . . . . . . . 12 5.3. Registration of SDES Items . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This specification defines an RTP header extension [RFC3550][RFC5285] This specification defines an RTP header extension [RFC3550][RFC5285]
that can carry RTCP source description (SDES) items. By including that can carry RTCP source description (SDES) items. Normally the
selected SDES items in a header extension the determination of SDES items are carried in their own RTCP packet type [RFC3550]. By
relationship and synchronization context for new RTP streams (SSRCs) including selected SDES items in a header extension the determination
in an RTP session can be optimized. Which relationship and what of relationship and synchronization context for new RTP streams
information depends on the SDES items carried. This becomes a (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. complement to using only RTCP for SDES Item delivery.
It is important to note that not all SDES items are appropriate to It is important to note that not all SDES items are appropriate to
transmit using RTP header extensions. Some SDES items performs transmit using RTP header extensions. Some SDES items performs
binding or identifies synchronization context with strict timeliness binding or identifies synchronization context with strict timeliness
requirements, while many other SDES items do not have such requirements, while many other SDES items do not have such
requirements. In addition, security and privacy concerns for the requirements. In addition, security and privacy concerns for the
SDES item information need to be considered. For example, the Name SDES item information need to be considered. For example, the Name
and Location SDES items are highly sensitive from a privacy and Location SDES items are highly sensitive from a privacy
perspective and should not be transported over the network without perspective and should not be transported over the network without
skipping to change at page 4, line 44 skipping to change at page 4, line 44
The Rapid Synchronization of RTP Flows specification does provide an The Rapid Synchronization of RTP Flows specification does provide an
analysis of the initial synchronization delay for different sessions analysis of the initial synchronization delay for different sessions
depending on number of receivers as well as on session bandwidth depending on number of receivers as well as on session bandwidth
(Section 2.1 of [RFC6051]). These results are applicable also for (Section 2.1 of [RFC6051]). These results are applicable also for
other SDES items that have a similar time dependency until the other SDES items that have a similar time dependency until the
information can be sent using RTCP. These figures can be used to information can be sent using RTCP. These figures can be used to
determine the benefit of reducing the initial delay before determine the benefit of reducing the initial delay before
information is available for some use cases. information is available for some use cases.
That document also discusses the case of late joiners, and defines an Rapid Synchronization of RTP Flows [RFC6051] also discusses the case
RTCP Feedback format to request synchronization information, which is of late joiners, and defines an RTCP Feedback format to request
another potential use case for SDES items in RTP header extension. synchronization information, which is another potential use case for
It would for example be natural to include CNAME SDES item with the SDES items in RTP header extension. It would for example be natural
header extension containing the NTP formatted reference clock to to include CNAME SDES item with the header extension containing the
ensure synchronization. NTP formatted reference clock to ensure synchronization.
There is an another SDES item that can benefit from timely delivery, There is an another SDES item that can benefit from timely delivery,
and an RTP header extension SDES item was therefore defined for it: and an RTP header extension SDES item was therefore defined for it:
MID: This is a media description identifier that matches the value MID: This is a media description identifier that matches the value
of the Session Description Protocol (SDP) [RFC4566] a=mid of the Session Description Protocol (SDP) [RFC4566] a=mid
attribute, to associate RTP streams multiplexed on the same attribute, to associate RTP streams multiplexed on the same
transport with their respective SDP media description as described transport with their respective SDP media description as described
in [I-D.ietf-mmusic-sdp-bundle-negotiation]. in [I-D.ietf-mmusic-sdp-bundle-negotiation].
skipping to change at page 7, line 5 skipping to change at page 7, line 5
[RFC7022], using short term persistent values, and if 96-bit random [RFC7022], using short term persistent values, and if 96-bit random
values prior to base64 encoding are sufficient, then they will fit values prior to base64 encoding are sufficient, then they will fit
into the one-byte header format. into the one-byte header format.
An RTP middlebox needs to take care choosing between one-byte headers An RTP middlebox needs to take care choosing between one-byte headers
and two-byte headers when creating the first packets for an outgoing and two-byte headers when creating the first packets for an outgoing
stream (SSRC) with header extensions. First of all it needs to stream (SSRC) with header extensions. First of all it needs to
consider all the header extensions that may potentially be used. consider all the header extensions that may potentially be used.
Secondly, it needs to know the size of the SDES items that are going Secondly, it needs to know the size of the SDES items that are going
to be included, and use two bytes headers if any are longer than 16 to be included, and use two bytes headers if any are longer than 16
bytes. An RTP middlebox that forwards a stream, i.e. not mixing it bytes. An RTP middlebox that forwards a stream, i.e., not mixing it
or combing it with other streams, may be able to base its choice on or combing it with other streams, may be able to base its choice on
the header size in incoming streams. This is assuming that the the header size in incoming streams. This is assuming that the
middlebox does not modify the stream or add additional header middlebox does not modify the stream or add additional header
extensions to the stream it sends, in which case it needs to make its extensions to the stream it sends, in which case it needs to make its
own decision. own decision.
4.2.2. MTU and Packet Expansion 4.2.2. MTU and Packet Expansion
The RTP packet size will clearly increase when a header extension is The RTP packet size will clearly increase when a header extension is
included. How much depends on the type of header extensions and included. How much depends on the type of header extensions and
their data content. The SDES items can vary in size. There are also their data content. The SDES items can vary in size. There are also
some use-cases that require transmitting multiple SDES items in the some use-cases that require transmitting multiple SDES items in the
same packet to ensure that all relevant data reaches the receiver. same packet to ensure that all relevant data reaches the receiver.
An example of that is when both CNAME, a MID, and the rapid time An example of that is when both CNAME, a MID, and the rapid time
synchronization extension from RFC 6051 are needed. Such a synchronization extension from RFC 6051 are needed. Such a
combination is quite likely to result in at least 16+3+8 bytes of 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 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 headers, plus two bytes of header padding to make the complete header
extension word aligned, thus in total 36 bytes. extension 32-bit word aligned, thus in total 36 bytes.
If the packet expansion cannot be taken into account when producing If the packet expansion cannot be taken into account when producing
the RTP payload, it can cause an issue. An RTP payload that is the RTP payload, it can cause an issue. An RTP payload that is
created to meet a particular IP level Maximum Transmission Unit created to meet a particular IP level Maximum Transmission Unit
(MTU), taking the addition of IP/UDP/RTP headers but not RTP header (MTU), taking the addition of IP/UDP/RTP headers but not RTP header
extensions into account, could exceed the MTU when the header extensions into account, could exceed the MTU when the header
extensions are present, thus resulting in IP fragmentation. IP extensions are present, thus resulting in IP fragmentation. IP
fragmentation is known to negatively impact the loss rate due to fragmentation is known to negatively impact the loss rate due to
middleboxes unwilling or not capable of dealing with IP fragments, as middleboxes unwilling or not capable of dealing with IP fragments, as
well as increasing the target surface for other types of packet well as increasing the target surface for other types of packet
skipping to change at page 9, line 42 skipping to change at page 9, line 42
SDES information needs to be updated, then the use of the RTP header SDES information needs to be updated, then the use of the RTP header
extension is superior to RTCP. Using the RTP header extension extension is superior to RTCP. Using the RTP header extension
ensures that the information is updated on reception of the related ensures that the information is updated on reception of the related
RTP media, ensuring synchronization between the two. Continued use RTP media, ensuring synchronization between the two. Continued use
of the old SDES information can lead to undesired effects in the of the old SDES information can lead to undesired effects in the
application. Thus, header extension transmission strategies with application. Thus, header extension transmission strategies with
high probability of delivery should be chosen. high probability of delivery should be chosen.
4.2.5. SDES Items in RTCP 4.2.5. SDES Items in RTCP
The RTP header extension information, i.e. SDES items, can and will The RTP header extension information, i.e., SDES items, can and will
be sent also in RTCP. Therefore, it is worth making some reflections be sent also in RTCP. Therefore, it is worth making some reflections
on this interaction. As an alternative to the header extension, it on this interaction. As an alternative to the header extension, it
is possible to schedule a non-regular RTCP packet transmission is possible to schedule a non-regular RTCP packet transmission
containing important SDES items, if one uses an RTP/AVPF-based RTP containing important SDES items, if one uses an RTP/AVPF-based RTP
profile. Depending on which mode one's RTCP feedback transmitter is profile. Depending on which mode one's RTCP feedback transmitter is
working on, extra RTCP packets may be sent as immediate or early working on, extra RTCP packets may be sent as immediate or early
packets, enabling more timely SDES information delivery. packets, enabling more timely SDES information delivery.
There are however two aspects that differ between using RTP header There are however two aspects that differ between using RTP header
extensions and any non-regular transmission of RTCP packets. First, extensions and any non-regular transmission of RTCP packets. First,
skipping to change at page 10, line 32 skipping to change at page 10, line 32
sender's SDES item parameter can take a different time to propagate sender's SDES item parameter can take a different time to propagate
to the receiver than the corresponding media data. For example, an to the receiver than the corresponding media data. For example, an
RTCP packet with the SDES item included that may have been generated 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 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 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 cause RTP packets to be sent including the header extension, prior to
the RTCP packet being sent. the RTCP packet being sent.
However, most of these issues can be avoided by the receiver However, most of these issues can be avoided by the receiver
performing some checks before updating the receiver's stored value. performing some checks before updating the receiver's stored value.
To handle flaps caused by reordering, only SDES items received in RTP To handle flaps caused by reordering, SDES items received in RTP
packets with a higher extended sequence number than the last change packets with the same or a lower extended sequence number than the
shall be applied, i.e. discard items that can be determined to be last change MUST NOT be applied, i.e., discard items that can be
older than the current one. For compound RTCP packets, which will determined to be older than the current one. For compound RTCP
contain an Sender Report (SR) packet (assuming an active RTP sender), packets, which will contain a Sender Report (SR) packet (assuming an
the receiver can use the RTCP SR Timestamp field to determine at what active RTP sender), the receiver can use the RTCP SR Timestamp field
approximate time it was transmitted. If the timestamp is earlier to determine at what approximate time it was transmitted. If the
than the last received RTP packet with a header extension carrying an timestamp is earlier than the last received RTP packet with a header
SDES item, and especially if carrying a previously used value, the extension carrying an SDES item, and especially if carrying a
SDES item in the RTCP SDES packet can be ignored. Note that media previously used value, the SDES item in the RTCP SDES packet can be
processing and transmission pacing can easily cause the RTP header ignored. Note that media processing and transmission pacing can
timestamp field as well as the RTCP SR timestamp field to not match easily cause the RTP header timestamp field as well as the RTCP SR
with the actual transmission time. timestamp field to not match with the actual transmission time.
5. IANA Considerations 5. IANA Considerations
This section makes the following requests to IANA: This section makes the following requests to IANA:
o Create a new sub-registry reserved for RTCP SDES items with the o Create a new sub-registry reserved for RTCP SDES items with the
URN sub-space "urn:ietf:params:rtp-hdrext:sdes:" in the RTP URN sub-space "urn:ietf:params:rtp-hdrext:sdes:" in the RTP
Compact Header Extensions registry. Compact Header Extensions registry.
o Register the SDES items appropriate for use with the RTP header o Register the SDES items appropriate for use with the RTP header
skipping to change at page 13, line 7 skipping to change at page 13, line 7
protected. This implies that to provide confidentiality, users of protected. This implies that to provide confidentiality, users of
SRTP need to implement and use encrypted header extensions per SRTP need to implement and use encrypted header extensions per
[RFC6904]. The security level that is applied to RTCP packets [RFC6904]. The security level that is applied to RTCP packets
carrying SDES items SHOULD also be applied to SDES items carried as carrying SDES items SHOULD also be applied to SDES items carried as
RTP header extensions. If the security level is chosen to be RTP header extensions. If the security level is chosen to be
different for an SDES item in RTCP and RTP header extension, it is different for an SDES item in RTCP and RTP header extension, it is
important to motivate the exception, and to consider the security important to motivate the exception, and to consider the security
properties as the worst in each aspect for the different properties as the worst in each aspect for the different
configurations. configurations.
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 storage requirements.
The extension for SDES items defined, 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.
As the SDES items are used by the RTP based application to establish As the SDES items are used by the RTP based application to establish
relationships between RTP streams or between an RTP stream and relationships between RTP streams or between an RTP stream and
information about the originating participant, there SHOULD be strong information about the originating participant, there SHOULD be strong
integrity protection and source authentication of the header integrity protection and source authentication of the header
extensions. If not, an attacker can modify the SDES item value to extensions. If not, an attacker can modify the SDES item value to
create erroneous relationship bindings in the receiving application. create erroneous relationship bindings in the receiving application.
For information regarding options for securing RTP, see [RFC7201].
7. Acknowledgements 7. Acknowledgments
The authors likes to thank the following individuals for feedback and The authors likes to thank the following individuals for feedback and
suggestions; Colin Perkins, Ben Campbell. suggestions: Colin Perkins, Ben Campbell, and Samuel Weiler.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 13, line 48 skipping to change at page 14, line 20
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013, DOI 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>. <http://www.rfc-editor.org/info/rfc6904>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-27 (work in progress), February 2016. negotiation-29 (work in progress), April 2016.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
skipping to change at page 14, line 43 skipping to change at page 15, line 14
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
<http://www.rfc-editor.org/info/rfc6051>. <http://www.rfc-editor.org/info/rfc6051>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>. September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[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 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>. <http://www.rfc-editor.org/info/rfc7656>.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
 End of changes. 18 change blocks. 
36 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/