draft-ietf-avt-rtp-cnames-00.txt   draft-ietf-avt-rtp-cnames-01.txt 
AVT A. Begen AVT A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Updates: 3550 (if approved) C. Perkins Updates: 3550 (if approved) C. Perkins
Intended status: Standards Track University of Glasgow Intended status: Standards Track University of Glasgow
Expires: December 19, 2010 D. Wing Expires: February 27, 2011 D. Wing
Cisco Cisco
June 17, 2010 August 26, 2010
Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs) (CNAMEs)
draft-ietf-avt-rtp-cnames-00 draft-ietf-avt-rtp-cnames-01
Abstract Abstract
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
persistent transport-level identifier for an RTP endpoint. While the persistent transport-level identifier for an RTP endpoint. While the
Synchronization Source (SSRC) identifier of an RTP endpoint may Synchronization Source (SSRC) identifier of an RTP endpoint may
change if a collision is detected, or when the RTP application is change if a collision is detected, or when the RTP application is
restarted, the CNAME is meant to stay unchanged, so that RTP restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
endpoints can be uniquely identified and associated with their RTP endpoints can be uniquely identified and associated with their RTP
media streams. For proper functionality, CNAMEs should be unique media streams. For proper functionality, RTCP CNAMEs should be
within the participants of an RTP session. However, the existing unique within the participants of an RTP session. However, the
guidelines for choosing the RTCP CNAME provided in the RTP standard existing guidelines for choosing the RTCP CNAME provided in the RTP
are insufficient to achieve this uniqueness. This memo updates these standard are insufficient to achieve this uniqueness. This memo
guidelines to allow endpoints to choose unique CNAMEs. updates these guidelines to allow endpoints to choose unique RTCP
CNAMEs.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 19, 2010. This Internet-Draft will expire on February 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3
3. Deficiencies with Earlier RTCP CNAME Guidelines . . . . . . . . 3 3. Deficiencies with Earlier Guidelines for Choosing an RTCP
CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Choosing an RTCP CNAME . . . . . . . . . . . . . . . . . . . . 4 4. Choosing an RTCP CNAME . . . . . . . . . . . . . . . . . . . . 4
4.1. Persistent vs. Per-Session CNAMEs . . . . . . . . . . . . . 4 4.1. Persistent RTCP CNAMEs vs. Per-Session RTCP CNAMEs . . . . 4
4.2. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
In Section 6.5.1 of [RFC3550], there are a number of recommendations In Section 6.5.1 of the RTP specification, [RFC3550], there are a
for choosing a unique RTCP CNAME for an RTP endpoint. However, in number of recommendations for choosing a unique RTCP CNAME for an RTP
practice, some of these methods are not guaranteed to produce a endpoint. However, in practice, some of these methods are not
unique CNAME. This memo updates guidelines for choosing CNAMEs, guaranteed to produce a unique RTCP CNAME. This memo updates
superceding those presented in Section 6.5.1 of [RFC3550]. guidelines for choosing RTCP CNAMEs, superceding those presented in
Section 6.5.1 of [RFC3550].
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Deficiencies with Earlier RTCP CNAME Guidelines 3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME
The recommendation in [RFC3550] is to generate the CNAME of the form The recommendation in [RFC3550] is to generate an RTCP CNAME of the
"user@host" for multiuser systems, or "host" if the username is not form "user@host" for multiuser systems, or "host" if the username is
available. The "host" part is specified to be the fully qualified not available. The "host" part is specified to be the fully
domain name (FQDN) of the host from which the real-time data qualified domain name (FQDN) of the host from which the real-time
originates. However, FQDNs are not necessarily unique, and can data originates. While this guidance was appropriate at the time
sometimes be common across several endpoints in large service [RFC3550] was written, FQDNs are no longer necessarily unique, and
can sometimes be common across several endpoints in large service
provider networks. Thus, the use of FQDN as the CNAME is strongly provider networks. Thus, the use of FQDN as the CNAME is strongly
discouraged. discouraged.
IPv4 addresses are also suggested for use in CNAMEs in [RFC3550], IPv4 addresses are also suggested for use in RTCP CNAMEs in
where the "host" part of the RTCP CNAME is the numeric representation [RFC3550], where the "host" part of the RTCP CNAME is the numeric
of the IP address of the interface from which the RTP data representation of the IPv4 address of the interface from which the
originates. As noted in [RFC3550], the use of private network RTP data originates. As noted in [RFC3550], the use of private
address space [RFC1918] can result in hosts having network addresses network address space [RFC1918] can result in hosts having network
that are not globally unique. However, this shared use of the same addresses that are not globally unique. Additionally, this shared
IP address can also occur with public IP addresses if multiple hosts use of the same IPv4 address can also occur with public IPv4
are assigned the same public IP address and connected to a Network addresses if multiple hosts are assigned the same public IPv4 address
Address Translation (NAT) device [RFC3022]. When multiple hosts and connected to a Network Address Translation (NAT) device
share the same IP address, whether private or public, using the IP [RFC3022]. When multiple hosts share the same IPv4 address, whether
address as the CNAME leads to CNAMEs that are not necessarily unique. private or public, using the IPv4 address as the RTCP CNAME leads to
RTCP CNAMEs that are not necessarily unique.
[RFC3550] also notes that if hosts with private addresses and no It is also noted in [RFC3550] that if hosts with private addresses
direct IP connectivity to the public Internet have their RTP packets and no direct IP connectivity to the public Internet have their RTP
forwarded to the public Internet through an RTP-level translator, packets forwarded to the public Internet through an RTP-level
they may end up having non-unique CNAMEs. [RFC3550] suggests that translator, they may end up having non-unique RTCP CNAMEs. The
such applications provide a configuration option to allow the user to suggestion in [RFC3550] is that such applications provide a
choose a unique CNAME, and puts the burden on the translator to configuration option to allow the user to choose a unique RTCP CNAME,
translate CNAMEs from private addresses to public addresses if and puts the burden on the translator to translate RTCP CNAMEs from
necessary to keep private addresses from being exposed. Experience private addresses to public addresses if necessary to keep private
has shown that this does not work well in practice. addresses from being exposed. Experience has shown that this does
not work well in practice.
4. Choosing an RTCP CNAME 4. Choosing an RTCP CNAME
It is difficult, and in some cases impossible, for a host to It is difficult, and in some cases impossible, for a host to
determine if there is a NAT between itself and its RTP peer. determine if there is a NAT between itself and its RTP peer.
Furthermore, even some public IPv4 addresses can be shared by Furthermore, even some public IPv4 addresses can be shared by
multiple hosts in the Internet. Thus, using the numeric multiple hosts in the Internet. Thus, using the numeric
representation of the IPv4 address as the "host" part of the RTCP representation of the IPv4 address as the "host" part of the RTCP
CNAME is NOT RECOMMENDED. CNAME is NOT RECOMMENDED.
4.1. Persistent vs. Per-Session CNAMEs 4.1. Persistent RTCP CNAMEs vs. Per-Session RTCP CNAMEs
The RTCP CNAME can either be persistent across different RTP sessions The RTCP CNAME can either be persistent across different RTP sessions
for an RTP endpoint, or it can be unique per session, meaning that an for an RTP endpoint, or it can be unique per session, meaning that an
RTP endpoint chooses a different CNAME for each RTP session. RTP endpoint chooses a different RTCP CNAME for each RTP session.
Persistent CNAMEs: To provide a binding across multiple media tools An RTP endpoint that is emitting multiple related RTP streams that
used by one participant in a set of related RTP sessions, the CNAME require synchronization at the other endpoint(s) MUST use the same
SHOULD be fixed for that participant. An RTP endpoint that is RTCP CNAME for all streams that are to be synchronized. This
emitting multiple related streams that require synchronization at the requires a short-term persistent RTCP CNAME that is common across
other endpoint(s) SHOULD use a persistent CNAME. A persistent CNAME several RTP flows, and potentially across several related RTP
is also useful to facilitate third-party monitoring, allowing network sessions. A common example of such use occurs when lip-syncing audio
management tools to correlate the ongoing quality of service across and video streams in a multimedia session, where a single participant
multiple RTP sessions for fault diagnosis and to understand long-term MUST use the same RTCP CNAME for its audio RTP session and for its
network performance statistics. video RTP session. Another example might be to synchronize the
layers of a layered audio codec, where the same RTCP CNAME MUST be
used for each layer.
Note: A persistent CNAME will not provide a unique identifier for A longer-term persistent RTCP CNAME is sometimes useful to facilitate
each source if an application permits a user to generate multiple third-party monitoring. One such use might be to allow network
sources from one host. Such an application would have to rely on management tools to correlate the ongoing quality of service for a
the SSRC to further identify the source, or the profile for that participant across multiple RTP sessions for fault diagnosis, and to
application would have to specify additional syntax for the CNAME understand long-term network performance statistics. Other, less
identifier. benign, uses may also be envisaged. An implementation that wishes to
discourage this type of third-party monitoring can generate a unique
RTCP CNAME for each RTP session, or group of related RTP sessions,
that it joins. Such a per-session RTCP CNAME cannot be used for
traffic analysis, and so provides some limited form of privacy (note
that there are non-RTP means that can be used by a third-party to
correlate RTP sessions, so the use of per-session RTCP CNAMEs will
not prevent a determined traffic analyst).
Note: If each RTP application creates its CNAME independently, This memo defines several different ways by which an implementation
the resulting CNAMEs may not be identical as would be required to can choose an RTCP CNAME. It is possible, and legitimate, for
provide a binding across multiple media tools belonging to one independent implementations to make different choices of RTCP CNAME
participant in a set of related RTP sessions. If cross-media when running on the same host. This may hinder third-party
binding is required, it may be necessary for the CNAME of each monitoring, unless some external means is provided to configure a
tool to be externally configured with the same value by a persistent choice of RTCP CNAME for those implementations.
coordination tool.
Per-Session CNAMEs: The advantage of this approach is that the CNAME 4.2. Requirements
is unique for each RTP session. This prevents the CNAME from being
used for traffic analysis. In other words, the RTP endpoints cannot
be identified based on their CNAMEs. This provides privacy, but
inhibits the use of RTCP as a tool for long-term network management
and monitoring.
4.2. Guidelines An RTP endpoint that wishes to generate a persistent RTCP CNAME MUST
use one of the following three methods:
RTP endpoints SHOULD practice one of the following guidelines in o To produce a long-term persistent RTCP CNAME, and endpoint MUST
choosing RTCP CNAME: generate and store a Universally Unique IDentifier (UUID)
[RFC4122] for use as the "host" part of its RTCP CNAME. The
string representation described in Section 3 of [RFC4122] MUST be
used without "urn:uuid:", resulting in a 36 octet printable string
representation.
o Given that IPv6 addresses are naturally unique, an endpoint MAY o To produce a short-term persistent RTCP CNAME, an endpoint that
use one of its IPv6 address(es) as the "host" part of its CNAME has one or more IPv6 addresses MUST use one of those IPv6
regardless of whether that IPv6 interface is being used for RTP address(es) as the "host" part of its RTCP CNAME, regardless of
communication or not. If the RTP endpoint is associated with an whether that IPv6 interface is being used for RTP communication or
IPv6 privacy address [RFC4941] or a unique local IPv6 unicast not. That address can be an IPv6 privacy address [RFC4941] or a
address [RFC4193], that address MAY be used as well. The IPv6 unique local IPv6 unicast address [RFC4193]. The IPv6 address is
address is converted to its textual representation converted to its textual representation
[I-D.ietf-6man-text-addr-representation], resulting in a printable [I-D.ietf-6man-text-addr-representation], resulting in a printable
string representation as short as 24 bits and as long as 304 bits. string representation as short as 3 octets and as long as 24
Using IPv6 addresses as the "host" part of a CNAME was originally octets. Note: using IPv6 addresses as the "host" part of a CNAME
suggested in [RFC3550]. was originally suggested in [RFC3550].
o An endpoint that does not know its fully qualified domain name, o To produce a short-term persistent RTCP CNAME, an endpoint that
and is configured with a private IP address on the interface it is has only IPv4 addresses MUST use the numeric representation of the
using for RTP communication, MAY use the numeric representation of layer-2 (MAC) address of the interface that is used to initiate
the layer-2 (MAC) address of that interface as the "host" part of the RTP session as the "host" part of its RTCP CNAME. For IEEE
its CNAME. For IEEE 802 MAC addresses, such as Ethernet, the 802 MAC addresses, such as Ethernet, the standard colon-separated
standard colon-separated hexadecimal format is to be used, e.g., hexadecimal format is to be used, e.g., "00:23:32:af:9b:aa"
"00:23:32:af:9b:aa" resulting in a 136-bit printable string resulting in a 17 octet printable string representation. IPv4
representation. addresses, whether public or private, SHOULD NOT be used as the
RTCP CNAME host part, since they are not guaranteed to be unique.
o An endpoint MAY use its Universally Unique IDentifier (UUID) In all three cases, the "user@" part of the RTCP CNAME MAY be omitted
[RFC4122] to generate the "host" part of its CNAME. The string on single-user systems, and MAY be replaced by an opaque token on
representation described in Section 3 of [RFC4122] SHOULD be used multiuser systems, to preserve privacy.
without "urn:uuid:", which results in a 288-bit printable string
representation.
o To generate a per-session CNAME, an endpoint MAY perform SHA1-HMAC To generate a per-session RTCP CNAME, an endpoint MUST perform SHA1-
[RFC2104] on the concatenated values of the RTP endpoint's initial HMAC [RFC2104] on the concatenated values of the RTP endpoint's
SSRC, the source and destination IP addresses and ports, and a initial SSRC, the source and destination IP addresses and ports, and
randomly-generated value [RFC4086], and then truncate the 160-bit a randomly-generated value [RFC4086], and then truncate the 160-bit
output to 96 bits and finally convert the 96 bits to ASCII using output to 96 bits and finally convert the 96 bits to ASCII using
Base64 encoding [RFC4648]. This results in a 128-bit printable Base64 encoding [RFC4648]. This results in a 16 octet printable
string representation. Note that the CNAME MUST NOT change if an string representation. Note that the RTCP CNAME MUST NOT change if
SSRC collision occurs, hence only the initial SSRC value chosen by an SSRC collision occurs, hence only the initial SSRC value chosen by
the endpoint is used. the endpoint is used. The "user@" part of the RTCP CNAME is omitted
when generating per-session RTCP CNAMEs.
Each of the techniques is equally effective in generating unique
CNAMEs, and an RTP application MAY choose any of these techniques to
use.
5. Security Considerations 5. Security Considerations
The security considerations of [RFC3550] apply to this document as The security considerations of [RFC3550] apply to this memo.
well.
In some environments, notably telephony, a fixed CNAME value allows In some environments, notably telephony, a fixed RTCP CNAME value
separate RTP sessions to be correlated and eliminates the obfuscation allows separate RTP sessions to be correlated and eliminates the
provided by IPv6 privacy addresses [RFC4941] or IPv4 NAPT [RFC3022]. obfuscation provided by IPv6 privacy addresses [RFC4941] or IPv4 NAPT
Secure RTP (SRTP) [RFC3711] can help prevent such correlation by [RFC3022]. Secure RTP (SRTP) [RFC3711] can help prevent such
encrypting Secure RTCP (SRTCP) but it should be noted that SRTP only correlation by encrypting Secure RTCP (SRTCP) but it should be noted
mandates SRTCP integrity protection (not encryption). Thus, RTP that SRTP only mandates SRTCP integrity protection (not encryption).
applications used in such environments should consider encrypting Thus, RTP applications used in such environments should consider
their SRTCP or generate a per-session CNAME as discussed in encrypting their SRTCP or generate a per-session RTCP CNAME as
Section 4.1. discussed in Section 4.1.
6. IANA Considerations 6. IANA Considerations
There are no IANA considerations in this document. No IANA actions are required.
7. Acknowledgments 7. Acknowledgments
Thanks to Marc Petit-Huguenin who suggested to use UUIDs in Thanks to Marc Petit-Huguenin who suggested to use UUIDs in
generating CNAMEs. generating RTCP CNAMEs.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 31 change blocks. 
126 lines changed or deleted 135 lines changed or added

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