idnits 2.17.1 draft-ietf-avt-rtp-cnames-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 26, 2010) is 4993 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft Cisco 4 Updates: 3550 (if approved) C. Perkins 5 Intended status: Standards Track University of Glasgow 6 Expires: February 27, 2011 D. Wing 7 Cisco 8 August 26, 2010 10 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names 11 (CNAMEs) 12 draft-ietf-avt-rtp-cnames-01 14 Abstract 16 The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a 17 persistent transport-level identifier for an RTP endpoint. While the 18 Synchronization Source (SSRC) identifier of an RTP endpoint may 19 change if a collision is detected, or when the RTP application is 20 restarted, its RTCP CNAME is meant to stay unchanged, so that RTP 21 endpoints can be uniquely identified and associated with their RTP 22 media streams. For proper functionality, RTCP CNAMEs should be 23 unique within the participants of an RTP session. However, the 24 existing guidelines for choosing the RTCP CNAME provided in the RTP 25 standard are insufficient to achieve this uniqueness. This memo 26 updates these guidelines to allow endpoints to choose unique RTCP 27 CNAMEs. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 27, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 65 3. Deficiencies with Earlier Guidelines for Choosing an RTCP 66 CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Choosing an RTCP CNAME . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Persistent RTCP CNAMEs vs. Per-Session RTCP CNAMEs . . . . 4 69 4.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 In Section 6.5.1 of the RTP specification, [RFC3550], there are a 81 number of recommendations for choosing a unique RTCP CNAME for an RTP 82 endpoint. However, in practice, some of these methods are not 83 guaranteed to produce a unique RTCP CNAME. This memo updates 84 guidelines for choosing RTCP CNAMEs, superceding those presented in 85 Section 6.5.1 of [RFC3550]. 87 2. Requirements Notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME 95 The recommendation in [RFC3550] is to generate an RTCP CNAME of the 96 form "user@host" for multiuser systems, or "host" if the username is 97 not available. The "host" part is specified to be the fully 98 qualified domain name (FQDN) of the host from which the real-time 99 data originates. While this guidance was appropriate at the time 100 [RFC3550] was written, FQDNs are no longer necessarily unique, and 101 can sometimes be common across several endpoints in large service 102 provider networks. Thus, the use of FQDN as the CNAME is strongly 103 discouraged. 105 IPv4 addresses are also suggested for use in RTCP CNAMEs in 106 [RFC3550], where the "host" part of the RTCP CNAME is the numeric 107 representation of the IPv4 address of the interface from which the 108 RTP data originates. As noted in [RFC3550], the use of private 109 network address space [RFC1918] can result in hosts having network 110 addresses that are not globally unique. Additionally, this shared 111 use of the same IPv4 address can also occur with public IPv4 112 addresses if multiple hosts are assigned the same public IPv4 address 113 and connected to a Network Address Translation (NAT) device 114 [RFC3022]. When multiple hosts share the same IPv4 address, whether 115 private or public, using the IPv4 address as the RTCP CNAME leads to 116 RTCP CNAMEs that are not necessarily unique. 118 It is also noted in [RFC3550] that if hosts with private addresses 119 and no direct IP connectivity to the public Internet have their RTP 120 packets forwarded to the public Internet through an RTP-level 121 translator, they may end up having non-unique RTCP CNAMEs. The 122 suggestion in [RFC3550] is that such applications provide a 123 configuration option to allow the user to choose a unique RTCP CNAME, 124 and puts the burden on the translator to translate RTCP CNAMEs from 125 private addresses to public addresses if necessary to keep private 126 addresses from being exposed. Experience has shown that this does 127 not work well in practice. 129 4. Choosing an RTCP CNAME 131 It is difficult, and in some cases impossible, for a host to 132 determine if there is a NAT between itself and its RTP peer. 133 Furthermore, even some public IPv4 addresses can be shared by 134 multiple hosts in the Internet. Thus, using the numeric 135 representation of the IPv4 address as the "host" part of the RTCP 136 CNAME is NOT RECOMMENDED. 138 4.1. Persistent RTCP CNAMEs vs. Per-Session RTCP CNAMEs 140 The RTCP CNAME can either be persistent across different RTP sessions 141 for an RTP endpoint, or it can be unique per session, meaning that an 142 RTP endpoint chooses a different RTCP CNAME for each RTP session. 144 An RTP endpoint that is emitting multiple related RTP streams that 145 require synchronization at the other endpoint(s) MUST use the same 146 RTCP CNAME for all streams that are to be synchronized. This 147 requires a short-term persistent RTCP CNAME that is common across 148 several RTP flows, and potentially across several related RTP 149 sessions. A common example of such use occurs when lip-syncing audio 150 and video streams in a multimedia session, where a single participant 151 MUST use the same RTCP CNAME for its audio RTP session and for its 152 video RTP session. Another example might be to synchronize the 153 layers of a layered audio codec, where the same RTCP CNAME MUST be 154 used for each layer. 156 A longer-term persistent RTCP CNAME is sometimes useful to facilitate 157 third-party monitoring. One such use might be to allow network 158 management tools to correlate the ongoing quality of service for a 159 participant across multiple RTP sessions for fault diagnosis, and to 160 understand long-term network performance statistics. Other, less 161 benign, uses may also be envisaged. An implementation that wishes to 162 discourage this type of third-party monitoring can generate a unique 163 RTCP CNAME for each RTP session, or group of related RTP sessions, 164 that it joins. Such a per-session RTCP CNAME cannot be used for 165 traffic analysis, and so provides some limited form of privacy (note 166 that there are non-RTP means that can be used by a third-party to 167 correlate RTP sessions, so the use of per-session RTCP CNAMEs will 168 not prevent a determined traffic analyst). 170 This memo defines several different ways by which an implementation 171 can choose an RTCP CNAME. It is possible, and legitimate, for 172 independent implementations to make different choices of RTCP CNAME 173 when running on the same host. This may hinder third-party 174 monitoring, unless some external means is provided to configure a 175 persistent choice of RTCP CNAME for those implementations. 177 4.2. Requirements 179 An RTP endpoint that wishes to generate a persistent RTCP CNAME MUST 180 use one of the following three methods: 182 o To produce a long-term persistent RTCP CNAME, and endpoint MUST 183 generate and store a Universally Unique IDentifier (UUID) 184 [RFC4122] for use as the "host" part of its RTCP CNAME. The 185 string representation described in Section 3 of [RFC4122] MUST be 186 used without "urn:uuid:", resulting in a 36 octet printable string 187 representation. 189 o To produce a short-term persistent RTCP CNAME, an endpoint that 190 has one or more IPv6 addresses MUST use one of those IPv6 191 address(es) as the "host" part of its RTCP CNAME, regardless of 192 whether that IPv6 interface is being used for RTP communication or 193 not. That address can be an IPv6 privacy address [RFC4941] or a 194 unique local IPv6 unicast address [RFC4193]. The IPv6 address is 195 converted to its textual representation 196 [I-D.ietf-6man-text-addr-representation], resulting in a printable 197 string representation as short as 3 octets and as long as 24 198 octets. Note: using IPv6 addresses as the "host" part of a CNAME 199 was originally suggested in [RFC3550]. 201 o To produce a short-term persistent RTCP CNAME, an endpoint that 202 has only IPv4 addresses MUST use the numeric representation of the 203 layer-2 (MAC) address of the interface that is used to initiate 204 the RTP session as the "host" part of its RTCP CNAME. For IEEE 205 802 MAC addresses, such as Ethernet, the standard colon-separated 206 hexadecimal format is to be used, e.g., "00:23:32:af:9b:aa" 207 resulting in a 17 octet printable string representation. IPv4 208 addresses, whether public or private, SHOULD NOT be used as the 209 RTCP CNAME host part, since they are not guaranteed to be unique. 211 In all three cases, the "user@" part of the RTCP CNAME MAY be omitted 212 on single-user systems, and MAY be replaced by an opaque token on 213 multiuser systems, to preserve privacy. 215 To generate a per-session RTCP CNAME, an endpoint MUST perform SHA1- 216 HMAC [RFC2104] on the concatenated values of the RTP endpoint's 217 initial SSRC, the source and destination IP addresses and ports, and 218 a randomly-generated value [RFC4086], and then truncate the 160-bit 219 output to 96 bits and finally convert the 96 bits to ASCII using 220 Base64 encoding [RFC4648]. This results in a 16 octet printable 221 string representation. Note that the RTCP CNAME MUST NOT change if 222 an SSRC collision occurs, hence only the initial SSRC value chosen by 223 the endpoint is used. The "user@" part of the RTCP CNAME is omitted 224 when generating per-session RTCP CNAMEs. 226 5. Security Considerations 228 The security considerations of [RFC3550] apply to this memo. 230 In some environments, notably telephony, a fixed RTCP CNAME value 231 allows separate RTP sessions to be correlated and eliminates the 232 obfuscation provided by IPv6 privacy addresses [RFC4941] or IPv4 NAPT 233 [RFC3022]. Secure RTP (SRTP) [RFC3711] can help prevent such 234 correlation by encrypting Secure RTCP (SRTCP) but it should be noted 235 that SRTP only mandates SRTCP integrity protection (not encryption). 236 Thus, RTP applications used in such environments should consider 237 encrypting their SRTCP or generate a per-session RTCP CNAME as 238 discussed in Section 4.1. 240 6. IANA Considerations 242 No IANA actions are required. 244 7. Acknowledgments 246 Thanks to Marc Petit-Huguenin who suggested to use UUIDs in 247 generating RTCP CNAMEs. 249 8. References 251 8.1. Normative References 253 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 254 Jacobson, "RTP: A Transport Protocol for Real-Time 255 Applications", STD 64, RFC 3550, July 2003. 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 261 Addresses", RFC 4193, October 2005. 263 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 264 Extensions for Stateless Address Autoconfiguration in 265 IPv6", RFC 4941, September 2007. 267 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 268 Unique IDentifier (UUID) URN Namespace", RFC 4122, 269 July 2005. 271 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 272 Hashing for Message Authentication", RFC 2104, 273 February 1997. 275 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 276 Requirements for Security", BCP 106, RFC 4086, June 2005. 278 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 279 Encodings", RFC 4648, October 2006. 281 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 282 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 283 RFC 3711, March 2004. 285 [I-D.ietf-6man-text-addr-representation] 286 Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 287 Address Text Representation", 288 draft-ietf-6man-text-addr-representation-07 (work in 289 progress), February 2010. 291 8.2. Informative References 293 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 294 E. Lear, "Address Allocation for Private Internets", 295 BCP 5, RFC 1918, February 1996. 297 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 298 Address Translator (Traditional NAT)", RFC 3022, 299 January 2001. 301 Authors' Addresses 303 Ali Begen 304 Cisco 305 181 Bay Street 306 Toronto, ON M5J 2T3 307 CANADA 309 Email: abegen@cisco.com 311 Colin Perkins 312 University of Glasgow 313 Department of Computing Science 314 Glasgow, G12 8QQ 315 UK 317 Email: csp@csperkins.org 319 Dan Wing 320 Cisco Systems, Inc. 321 170 West Tasman Dr. 322 San Jose, CA 95134 323 USA 325 Email: dwing@cisco.com