idnits 2.17.1 draft-ietf-avt-rtp-cnames-02.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 (November 10, 2010) is 4909 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: May 14, 2011 D. Wing 7 Cisco 8 November 10, 2010 10 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names 11 (CNAMEs) 12 draft-ietf-avt-rtp-cnames-02 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 May 14, 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. Using the numeric representation of 135 the IPv4 address as the "host" part of the RTCP CNAME is NOT 136 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 has to 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 has to 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 can 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 can 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 [RFC5952], resulting in a 196 printable string representation as short as 3 octets and as long 197 as 24 octets. Note: using IPv6 addresses as the "host" part of a 198 CNAME was originally suggested in [RFC3550]. 200 o To produce a short-term persistent RTCP CNAME, an endpoint that 201 has only IPv4 addresses MUST use the numeric representation of the 202 layer-2 (MAC) address of the interface that is used to initiate 203 the RTP session as the "host" part of its RTCP CNAME. For IEEE 204 802 MAC addresses, such as Ethernet, the standard colon-separated 205 hexadecimal format is to be used, e.g., "00:23:32:af:9b:aa" 206 resulting in a 17 octet printable string representation. 208 In all three cases, the "user@" part of the RTCP CNAME MAY be omitted 209 on single-user systems, and MAY be replaced by an opaque token on 210 multiuser systems, to preserve privacy. Other methods, beyond the 211 three methods listed above, are not compliant with this specification 212 and SHOULD NOT be used. 214 To generate a per-session RTCP CNAME, an endpoint MUST perform SHA1- 215 HMAC [RFC2104] on the concatenated values of the RTP endpoint's 216 initial SSRC, the source and destination IP addresses and ports, and 217 a randomly-generated value [RFC4086], and then truncate the 160-bit 218 output to 96 bits and finally convert the 96 bits to ASCII using 219 Base64 encoding [RFC4648]. This results in a 16 octet printable 220 string representation. The RTCP CNAME MUST NOT change if an SSRC 221 collision occurs, hence only the initial SSRC value chosen by the 222 endpoint is used. The "user@" part of the RTCP CNAME is omitted when 223 generating per-session RTCP CNAMEs. 225 5. Security Considerations 227 The security considerations of [RFC3550] apply to this memo. 229 In some environments, notably telephony, a fixed RTCP CNAME value 230 allows separate RTP sessions to be correlated and eliminates the 231 obfuscation provided by IPv6 privacy addresses [RFC4941] or IPv4 NAPT 232 [RFC3022]. Secure RTP (SRTP) [RFC3711] can help prevent such 233 correlation by encrypting Secure RTCP (SRTCP) but it should be noted 234 that SRTP only mandates SRTCP integrity protection (not encryption). 235 Thus, RTP applications used in such environments should consider 236 encrypting their SRTCP or generate a per-session RTCP CNAME as 237 discussed in Section 4.1. 239 6. IANA Considerations 241 No IANA actions are required. 243 7. Acknowledgments 245 Thanks to Marc Petit-Huguenin who suggested to use UUIDs in 246 generating RTCP CNAMEs. 248 8. References 250 8.1. Normative References 252 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 253 Jacobson, "RTP: A Transport Protocol for Real-Time 254 Applications", STD 64, RFC 3550, July 2003. 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 260 Addresses", RFC 4193, October 2005. 262 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 263 Extensions for Stateless Address Autoconfiguration in 264 IPv6", RFC 4941, September 2007. 266 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 267 Unique IDentifier (UUID) URN Namespace", RFC 4122, 268 July 2005. 270 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 271 Hashing for Message Authentication", RFC 2104, 272 February 1997. 274 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 275 Requirements for Security", BCP 106, RFC 4086, June 2005. 277 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 278 Encodings", RFC 4648, October 2006. 280 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 281 Address Text Representation", RFC 5952, August 2010. 283 8.2. Informative References 285 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 286 E. Lear, "Address Allocation for Private Internets", 287 BCP 5, RFC 1918, February 1996. 289 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 290 Address Translator (Traditional NAT)", RFC 3022, 291 January 2001. 293 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 294 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 295 RFC 3711, March 2004. 297 Authors' Addresses 299 Ali Begen 300 Cisco 301 181 Bay Street 302 Toronto, ON M5J 2T3 303 CANADA 305 Email: abegen@cisco.com 306 Colin Perkins 307 University of Glasgow 308 Department of Computing Science 309 Glasgow, G12 8QQ 310 UK 312 Email: csp@csperkins.org 314 Dan Wing 315 Cisco Systems, Inc. 316 170 West Tasman Dr. 317 San Jose, CA 95134 318 USA 320 Email: dwing@cisco.com