draft-begen-avt-rtp-cnames-01.txt | draft-begen-avt-rtp-cnames-02.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: November 6, 2010 May 5, 2010 | Expires: November 25, 2010 D. Wing | |||
Cisco | ||||
May 24, 2010 | ||||
Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names | |||
(CNAMEs) | (CNAMEs) | |||
draft-begen-avt-rtp-cnames-01 | draft-begen-avt-rtp-cnames-02 | |||
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, the 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, CNAMEs should be unique | |||
within the participants of an RTP session. However, the | within the participants of an RTP session. However, the existing | |||
recommendations for choice of the RTCP CNAME provided in RFC 3550 are | guidelines for choosing the RTCP CNAME provided in the RTP standard | |||
insufficient to achieve this uniqueness. This memo updates the | are insufficient to achieve this uniqueness. This memo updates these | |||
guidelines in RFC 3550 to allow endpoints to choose unique CNAMEs. | guidelines to allow endpoints to choose unique 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 November 6, 2010. | This Internet-Draft will expire on November 25, 2010. | |||
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. Choice of RTCP CNAME in Private Networks . . . . . . . . . . . 3 | 3. Deficiencies with Earlier RTCP CNAME Guidelines . . . . . . . . 3 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 | 4. Choosing an RTCP CNAME . . . . . . . . . . . . . . . . . . . . 4 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 | 4.1. Persistent vs. Per-Session CNAMEs . . . . . . . . . . . . . 4 | |||
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4.2. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 5 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | ||||
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 | ||||
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 [RFC3550], there are a number of recommendations | |||
for choosing the RTCP CNAME for an RTP endpoint. These recommend | for choosing a unique RTCP CNAME for an RTP endpoint. However, in | |||
that the CNAME is of the form "user@host" for multiuser systems, or | practice, some of these methods are not guaranteed to produce a | |||
"host" if the username is not available. The "host" part is | unique CNAME. This memo proposes updated guidelines for choosing | |||
specified to be the fully qualified domain name of the host from | CNAMEs, superceding those presented in Section 6.5.1 of [RFC3550]. | |||
which the real-time data originates, or the numeric representation of | ||||
the IP address of the interface from which the RTP data originates | ||||
for hosts that do not have a domain name. | ||||
As noted in [RFC3550], the use of private network address space | 2. Requirements Notation | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in [RFC2119]. | ||||
3. Deficiencies with Earlier RTCP CNAME Guidelines | ||||
The recommendation in [RFC3550] is to generate the CNAME of the form | ||||
"user@host" for multiuser systems, or "host" if the username is not | ||||
available. The "host" part is specified to be the fully qualified | ||||
domain name (FQDN) of the host from which the real-time data | ||||
originates. However, FQDNs are not 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 | ||||
discouraged. | ||||
For hosts that do not have a unique domain name, the "host" part of | ||||
the RTCP CNAME could be the numeric representation of the IP address | ||||
of the interface from which the RTP data originates. However, as | ||||
noted in [RFC3550], the use of private network address space | ||||
[RFC1918] can result in hosts having network addresses that are not | [RFC1918] can result in hosts having network addresses that are not | |||
globally unique. However, this problem is not solely with private | globally unique. This can also occur with public IP addresses, if | |||
network addresses, but may also occur with public IP addresses, where | ||||
multiple hosts are assigned the same public IP address and connected | multiple hosts are assigned the same public IP address and connected | |||
to a Network Address Translation (NAT) device | to a Network Address Translation (NAT) device [RFC3022]. When | |||
[I-D.miles-behave-l2nat]. When multiple hosts share the same IP | multiple hosts share the same IP address, whether private or public, | |||
address, using the IP address as the CNAME can lead to non-unique | using the IP address as the CNAME leads to CNAMEs that are not | |||
CNAMEs. | necessarily unique. | |||
[RFC3550] also notes that if hosts with private addresses and no | [RFC3550] also notes that if hosts with private addresses and no | |||
direct IP connectivity to the public Internet have their RTP packets | direct IP connectivity to the public Internet have their RTP packets | |||
forwarded to the public Internet through an RTP-level translator, | forwarded to the public Internet through an RTP-level translator, | |||
they may end up having non-unique CNAMEs. [RFC3550] suggests that | they may end up having non-unique CNAMEs. [RFC3550] suggests that | |||
such applications provide a configuration option to allow the user to | such applications provide a configuration option to allow the user to | |||
choose a unique CNAME, and puts the burden on the translator to | choose a unique CNAME, and puts the burden on the translator to | |||
translate CNAMEs from private addresses to public addresses if | translate CNAMEs from private addresses to public addresses if | |||
necessary to keep private addresses from being exposed. Experience | necessary to keep private addresses from being exposed. Experience | |||
has shown that this does not work well in practice. | has shown that this does not work well in practice. | |||
For all these reasons, this memo proposes alternative algorithms for | 4. Choosing an RTCP CNAME | |||
choosing CNAMEs. | ||||
2. Requirements Notation | It is difficult, and in some cases impossible, for a host to | |||
determine if there is a NAT between itself and its RTP peer. | ||||
Furthermore, even some public IPv4 addresses can be shared by | ||||
multiple hosts in the Internet. Thus, using the numeric | ||||
representation of the IPv4 address as the "host" part of the RTCP | ||||
CNAME is NOT RECOMMENDED. | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | 4.1. Persistent vs. Per-Session CNAMEs | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in [RFC2119]. | ||||
3. Choice of RTCP CNAME in Private Networks | 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 | ||||
RTP endpoint chooses a different CNAME for each RTP session. | ||||
It is a difficult task for a host to determine whether it resides | Persistent CNAMEs: To provide a binding across multiple media tools | |||
behind a NAT without the help of an external mechanism such as STUN | used by one participant in a set of related RTP sessions, the CNAME | |||
[RFC5389]. Furthermore, even some public IP addresses can be shared | SHOULD be fixed for that participant. A persistent CNAME is also | |||
by multiple hosts in the Internet. Thus, using the numeric | useful to facilitate third-party monitoring, allowing network | |||
representation of the IP address as the RTCP CNAME is NOT | management tools to correlate the ongoing quality of service across | |||
RECOMMENDED. | multiple RTP sessions for fault diagnosis and to understand long-term | |||
network performance statistics. | ||||
In order to meet the SHOULD requirement of Section 6.5.1 of | Per-Session CNAMEs: The advantage of this approach is that the CNAME | |||
[RFC3550], RTP endpoints SHOULD practice one of the following | is unique for each RTP session. This prevents the CNAME from being | |||
guidelines: | 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. | ||||
o Given that IPv6 addresses are naturally unique, a host MAY use its | 4.2. Guidelines | |||
IPv6 address as the CNAME when using an IPv6 interface for RTP | ||||
communication. If the RTP endpoint is associated with a unique | ||||
local IPv6 unicast address [RFC4193], that address MAY be used as | ||||
the CNAME as well. Using IPv6 addresses as CNAMEs was originally | ||||
suggested in [RFC3550]. | ||||
o A host that does not know its fully qualified domain name, and is | RTP endpoints SHOULD practice one of the following guidelines in | |||
configured with a private IP address on the interface it is using | choosing RTCP CNAME: | |||
for RTP communication, MAY use the numeric representation of the | ||||
layer-2 (MAC) address of the interface it is using for RTP | ||||
communication as the "host" part of its CNAME. For IEEE 802 MAC | ||||
addresses, such as Ethernet, the standard colon-separated | ||||
hexadecimal format is to be used, e.g., "00:23:32:af:9b:aa". | ||||
o A host MAY use its Universally Unique IDentifier (UUID) [RFC4122] | o Given that IPv6 addresses are naturally unique, an endpoint MAY | |||
as the CNAME. | use its IPv6 address as the "host" part of its CNAME regardless of | |||
whether that IPv6 interface is being used for RTP communication or | ||||
not. If the RTP endpoint is associated with an IPv6 privacy | ||||
address [RFC4941] or a unique local IPv6 unicast address | ||||
[RFC4193], that address MAY be used as well. Using IPv6 addresses | ||||
as the "host" part of a CNAME was originally suggested in | ||||
[RFC3550]. | ||||
This memo does not mandate a specific order in which these methods | o An endpoint that does not know its fully qualified domain name, | |||
should be practiced. A specific order would be only needed if an RTP | and is configured with a private IP address on the interface it is | |||
endpoint was expected to be comprised of multiple programs that | using for RTP communication, MAY use the numeric representation of | |||
independently needed to choose the same CNAME. Since this is not a | the layer-2 (MAC) address of that interface as the "host" part of | |||
common implementation technique, a specific order is not needed. | its CNAME. For IEEE 802 MAC addresses, such as Ethernet, the | |||
standard colon-separated hexadecimal format is to be used, e.g., | ||||
"00:23:32:af:9b:aa". | ||||
4. Security Considerations | o An endpoint MAY use its Universally Unique IDentifier (UUID) | |||
[RFC4122] to generate the "host" part of its CNAME. The string | ||||
representation described in Section 3 of [RFC4122] should be used, | ||||
which results in a 288-bit string representation. | ||||
o To generate a unique CNAME for each RTP session, an endpoint MAY | ||||
perform SHA1-HMAC [RFC2104] on the concatenated values of the RTP | ||||
endpoint's initial SSRC, the source and destination IP addresses | ||||
and ports, and a randomly-generated value [RFC4086], and then | ||||
truncate the 160-bit output to 96 bits and finally convert the 96 | ||||
bits to ASCII using Base64 encoding [RFC4648]. This results in a | ||||
128-bit printable CNAME. Note that the CNAME MUST NOT change if | ||||
an SSRC collision occurs, hence only the initial SSRC value chosen | ||||
by the endpoint is used. | ||||
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 | ||||
The security considerations of [RFC3550] apply to this document as | The security considerations of [RFC3550] apply to this document as | |||
well. | well. | |||
5. IANA Considerations | In some environments, notably telephony, a fixed CNAME value allows | |||
separate RTP sessions to be correlated and eliminates the obfuscation | ||||
provided by IPv6 privacy addresses [RFC4941] or IPv4 NAPT [RFC3022]. | ||||
Secure RTP (SRTP) [RFC3711] can help prevent such correlation by | ||||
encrypting Secure RTCP (SRTCP) but it should be noted that SRTP only | ||||
mandates SRTCP integrity protection (not encryption). Thus, RTP | ||||
applications used in such environments should consider encrypting | ||||
their SRTCP or generate a new CNAME value for each RTP session as | ||||
described in Section 4. | ||||
6. IANA Considerations | ||||
There are no IANA considerations in this document. | There are no IANA considerations in this document. | |||
6. Acknowledgments | 7. Acknowledgments | |||
Thanks to Dan Wing who pointed out the concerns about cases where two | Thanks to Marc Petit-Huguenin who suggested to use UUIDs in | |||
hosts could share the same public IP address. Also, thanks to Marc | generating CNAMEs. | |||
Petit-Huguenin who suggested to use UUIDs as CNAMEs. | ||||
7. References | 8. References | |||
7.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 | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast | [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast | |||
Addresses", RFC 4193, October 2005. | Addresses", RFC 4193, October 2005. | |||
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy | ||||
Extensions for Stateless Address Autoconfiguration in | ||||
IPv6", RFC 4941, September 2007. | ||||
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | |||
Unique IDentifier (UUID) URN Namespace", RFC 4122, | Unique IDentifier (UUID) URN Namespace", RFC 4122, | |||
July 2005. | July 2005. | |||
7.2. Informative References | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
Hashing for Message Authentication", RFC 2104, | ||||
February 1997. | ||||
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness | ||||
Requirements for Security", BCP 106, RFC 4086, June 2005. | ||||
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | ||||
Encodings", RFC 4648, October 2006. | ||||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | ||||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | ||||
RFC 3711, March 2004. | ||||
8.2. Informative References | ||||
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and | [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and | |||
E. Lear, "Address Allocation for Private Internets", | E. Lear, "Address Allocation for Private Internets", | |||
BCP 5, RFC 1918, February 1996. | BCP 5, RFC 1918, February 1996. | |||
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, | [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network | |||
"Session Traversal Utilities for NAT (STUN)", RFC 5389, | Address Translator (Traditional NAT)", RFC 3022, | |||
October 2008. | January 2001. | |||
[I-D.miles-behave-l2nat] | ||||
Miles, D. and M. Townsley, "Layer2-Aware NAT", | ||||
draft-miles-behave-l2nat-00 (work in progress), | ||||
March 2009. | ||||
Authors' Addresses | Authors' Addresses | |||
Ali Begen | Ali Begen | |||
Cisco | Cisco | |||
181 Bay Street | 181 Bay Street | |||
Toronto, ON M5J 2T3 | Toronto, ON M5J 2T3 | |||
CANADA | CANADA | |||
Email: abegen@cisco.com | Email: abegen@cisco.com | |||
skipping to change at page 6, line 4 ¶ | skipping to change at page 7, line 14 ¶ | |||
Authors' Addresses | Authors' Addresses | |||
Ali Begen | Ali Begen | |||
Cisco | Cisco | |||
181 Bay Street | 181 Bay Street | |||
Toronto, ON M5J 2T3 | Toronto, ON M5J 2T3 | |||
CANADA | CANADA | |||
Email: abegen@cisco.com | Email: abegen@cisco.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
Department of Computing Science | Department of Computing Science | |||
Glasgow, G12 8QQ | Glasgow, G12 8QQ | |||
UK | UK | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
Dan Wing | ||||
Cisco | ||||
170 West Tasman Dr. | ||||
San Jose, CA 95134 | ||||
USA | ||||
Email: dwing@cisco.com | ||||
End of changes. 30 change blocks. | ||||
82 lines changed or deleted | 151 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |