idnits 2.17.1 draft-ietf-avtcore-6222bis-06.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 (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 (July 14, 2013) is 3936 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) == Unused Reference: 'RFC5342' is defined on line 354, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) -- Obsolete informational reference (is this intentional?): RFC 6222 (Obsoleted by RFC 7022) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Begen 3 Internet-Draft Cisco 4 Obsoletes: 6222 (if approved) C. Perkins 5 Updates: 3550 (if approved) University of Glasgow 6 Intended status: Standards Track D. Wing 7 Expires: January 15, 2014 Cisco 8 E. Rescorla 9 RTFM, Inc. 10 July 14, 2013 12 Guidelines for Choosing RTP Control Protocol (RTCP) 13 Canonical Names (CNAMEs) 14 draft-ietf-avtcore-6222bis-06 16 Abstract 18 The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a 19 persistent transport-level identifier for an RTP endpoint. While the 20 Synchronization Source (SSRC) identifier of an RTP endpoint may 21 change if a collision is detected or when the RTP application is 22 restarted, its RTCP CNAME is meant to stay unchanged, so that RTP 23 endpoints can be uniquely identified and associated with their RTP 24 media streams. 26 For proper functionality, RTCP CNAMEs should be unique within the 27 participants of an RTP session. However, the existing guidelines for 28 choosing the RTCP CNAME provided in the RTP standard are insufficient 29 to achieve this uniqueness. RFC 6222 was published to update those 30 guidelines to allow endpoints to choose unique RTCP CNAMEs. 31 Unfortunately, later investigations showed that some parts of the new 32 algorithms were unnecessarily complicated and/or ineffective. This 33 document addresses these concerns and replaces RFC 6222. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 15, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 70 3. Deficiencies with Earlier Guidelines for Choosing an RTCP 71 CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 4. Choosing an RTCP CNAME . . . . . . . . . . . . . . . . . . . 4 73 4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs . . 4 74 4.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 75 5. Procedure to Generate a Unique Identifier . . . . . . . . . . 6 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 6.1. Considerations on Uniqueness of RTCP CNAMEs . . . . . . . 7 78 6.2. Session Correlation Based on RTCP CNAMEs . . . . . . . . 7 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 83 9.2. Informative References . . . . . . . . . . . . . . . . . 8 85 1. Introduction 86 In Section 6.5.1 of [RFC3550], there are a number of recommendations 87 for choosing a unique RTCP CNAME for an RTP endpoint. However, in 88 practice, some of these methods are not guaranteed to produce a 89 unique RTCP CNAME. [RFC6222] updated the guidelines for choosing 90 RTCP CNAMEs, superseding those presented in Section 6.5.1 of 91 [RFC3550]. Unfortunately, some parts of the new algorithms are 92 rather complicated and also produce RTCP CNAMEs which in some cases 93 are potentially linkable over multiple RTCP sessions even if a new 94 RTCP CNAME is generated for each session. This document specifies a 95 replacement for the algorithm in Section 5 of [RFC6222], which does 96 not have this limitation and is also simpler to implement. 98 For a discussion on the linkability of RTCP CNAMES produced by 99 [RFC6222], refer to [I-D.rescorla-avtcore-random-cname]. 101 2. Requirements Notation 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119]. 108 3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME 110 The recommendation in [RFC3550] is to generate an RTCP CNAME of the 111 form "user@host" for multiuser systems, or "host" if the username is 112 not available. The "host" part is specified to be the fully 113 qualified domain name (FQDN) of the host from which the real-time 114 data originates. While this guidance was appropriate at the time 115 [RFC3550] was written, FQDNs are no longer necessarily unique and can 116 sometimes be common across several endpoints in large service 117 provider networks. This document replaces the use of FQDN as an RTCP 118 CNAME by alternative mechanisms. 120 IPv4 addresses are also suggested for use in RTCP CNAMEs in 121 [RFC3550], where the "host" part of the RTCP CNAME is the numeric 122 representation of the IPv4 address of the interface from which the 123 RTP data originates. As noted in [RFC3550], the use of private 124 network address space [RFC1918] can result in hosts having network 125 addresses that are not globally unique. Additionally, this shared 126 use of the same IPv4 address can also occur with public IPv4 127 addresses if multiple hosts are assigned the same public IPv4 address 128 and connected to a Network Address Translation (NAT) device 129 [RFC3022]. When multiple hosts share the same IPv4 address, whether 130 private or public, using the IPv4 address as the RTCP CNAME leads to 131 RTCP CNAMEs that are not necessarily unique. 133 It is also noted in [RFC3550] that if hosts with private addresses 134 and no direct IP connectivity to the public Internet have their RTP 135 packets forwarded to the public Internet through an RTP-level 136 translator, they could end up having non-unique RTCP CNAMEs. The 137 suggestion in [RFC3550] is that such applications provide a 138 configuration option to allow the user to choose a unique RTCP CNAME; 139 this technique puts the burden on the translator to translate RTCP 140 CNAMEs from private addresses to public addresses if necessary to 141 keep private addresses from being exposed. Experience has shown that 142 this does not work well in practice. 144 4. Choosing an RTCP CNAME 146 It is difficult, and in some cases impossible, for a host to 147 determine if there is a NAT between itself and its RTP peer. 148 Furthermore, even some public IPv4 addresses can be shared by 149 multiple hosts in the Internet. Using the numeric representation of 150 the IPv4 address as the "host" part of the RTCP CNAME is NOT 151 RECOMMENDED. 153 4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs 155 The RTCP CNAME can be either persistent across different RTP sessions 156 for an RTP endpoint or unique per session, meaning that an RTP 157 endpoint chooses a different RTCP CNAME for each RTP session. 159 An RTP endpoint that is emitting multiple related RTP streams that 160 require synchronization at the other endpoint(s) MUST use the same 161 RTCP CNAME for all streams that are to be synchronized. This 162 requires a short-term persistent RTCP CNAME that is common across 163 several RTP streams, and potentially across several related RTP 164 sessions. A common example of such use occurs when lip-syncing audio 165 and video streams in a multimedia session, where a single participant 166 has to use the same RTCP CNAME for its audio RTP session and for its 167 video RTP session. Another example might be to synchronize the 168 layers of a layered audio codec, where the same RTCP CNAME has to be 169 used for each layer. 171 If the multiple RTP streams in an RTP session are not related, thus 172 do not require synchronization, an RTP endpoint can use different 173 RTCP CNAMEs for these streams. 175 A longer-term persistent RTCP CNAME is sometimes useful to facilitate 176 third-party monitoring, consistent with [RFC3550]. One such use 177 might be to allow network management tools to correlate the ongoing 178 quality of service for a participant across multiple RTP sessions for 179 fault diagnosis, and to understand long-term network performance 180 statistics. An application developer that wishes to discourage this 181 type of third-party monitoring can choose to generate a unique RTCP 182 CNAME for each RTP session, or group of related RTP sessions, that 183 the application will join. Such a per-session RTCP CNAME cannot be 184 used for traffic analysis, and so provides some limited form of 185 privacy. Note that there are non-RTP means that can be used by a 186 third party to correlate RTP sessions, so the use of per-session RTCP 187 CNAMEs will not prevent a determined traffic analyst from monitoring 188 such sessions. 190 This memo defines several different ways by which an implementation 191 can choose an RTCP CNAME. It is possible, and legitimate, for 192 independent implementations to make different choices of RTCP CNAME 193 when running on the same host. This can hinder third-party 194 monitoring, unless some external means is provided to configure a 195 persistent choice of RTCP CNAME for those implementations. 197 Note that there is no backwards compatibility issue (with 198 [RFC3550]-compatible implementations) introduced in this memo, since 199 the RTCP CNAMEs are opaque strings to remote peers. 201 4.2. Requirements 203 RTP endpoints will choose to generate RTCP CNAMEs that are persistent 204 or per-session. An RTP endpoint that wishes to generate a persistent 205 RTCP CNAME MUST use one of the following two methods: 207 o To produce a long-term persistent RTCP CNAME, an RTP endpoint MUST 208 generate and store a Universally Unique IDentifier (UUID) 209 [RFC4122] for use as the "host" part of its RTCP CNAME. The UUID 210 MUST be version 1, 2, or 4, as described in [RFC4122], with the 211 "urn:uuid:" stripped, resulting in a 36-octet printable string 212 representation. 214 o To produce a short-term persistent RTCP CNAME, an RTP endpoint 215 MUST generate and use an identifier by following the procedure 216 described in Section 5. That procedure is performed at least once 217 per initialization of the software. After obtaining an 218 identifier, minimally the least significant 96 bits SHOULD be 219 converted to ASCII using Base64 encoding [RFC4648] (to compromise 220 between packet size and uniqueness - refer to Section 6.1). If 96 221 bits are used, the resulting string will be 16 octets. Note the 222 Base64 encoded value cannot exceed the maximum RTCP CNAME length 223 of 255 octets [RFC3550]. 225 In the two cases above, the "user@" part of the RTCP CNAME MAY be 226 omitted on single-user systems and MAY be replaced by an opaque token 227 on multi-user systems, to preserve privacy. 229 An RTP endpoint that wishes to generate a per-session RTCP CNAME MUST 230 use the following method: 232 o For every new RTP session, a new RTCP CNAME is generated following 233 the procedure described in Section 5. After performing that 234 procedure, minimally the least significant 96 bits SHOULD be 235 converted to ASCII using Base64 encoding [RFC4648]. The RTCP 236 CNAME cannot change over the life of an RTP session [RFC3550]. 237 The "user@" part of the RTCP CNAME is omitted when generating 238 per-session RTCP CNAMEs. 240 It is believed that obtaining uniqueness (with a high probability) is 241 an important property that requires careful evaluation of the method. 242 This document provides a number of methods, at least one of which 243 would be suitable for all deployment scenarios. This document 244 therefore does not provide for the implementor to define and select 245 an alternative method. 247 A future specification might define an alternative method for 248 generating RTCP CNAMEs, as long as the proposed method has 249 appropriate uniqueness and there is consistency between the methods 250 used for multiple RTP sessions that are to be correlated. However, 251 such a specification needs to be reviewed and approved before 252 deployment. 254 The mechanisms described in this document are to be used to generate 255 RTCP CNAMEs, and they are not to be used for generating general- 256 purpose unique identifiers. 258 5. Procedure to Generate a Unique Identifier 260 To locally produce a unique identifier, one simply generates a 261 cryptographically pseudorandom value as described in [RFC4086]. This 262 value MUST be at least 96 bits. 264 The biggest bottleneck to implementation of this algorithm is the 265 availability of an appropriate cryptographically secure pseudorandom 266 number generator (CSPRNG). In any setting which already has a secure 267 PRNG, this algorithm described is far simpler than the algorithm 268 described in Section 5 of [RFC6222]. SIP stacks [RFC3261] are 269 required to use cryptographically random numbers to generate To and 270 From tags (Section 19.3). RTCWEB implementations 271 [I-D.ietf-rtcweb-security-arch] will need to have secure PRNGs to 272 implement ICE [RFC5245] and DTLS-SRTP [RFC5764]. And, of course, 273 essentially every Web browser already supports TLS, which requires a 274 secure PRNG. 276 6. Security Considerations 278 The security considerations of [RFC3550] apply to this memo. 280 6.1. Considerations on Uniqueness of RTCP CNAMEs 282 The considerations in this section apply to random RTCP CNAMEs. 284 The recommendations given in this document for RTCP CNAME generation 285 ensure that a set of cooperating participants in an RTP session will, 286 with very high probability, have unique RTCP CNAMEs. However, 287 neither [RFC3550] nor this document provides any way to ensure that 288 participants will choose RTCP CNAMEs appropriately, and thus 289 implementations MUST NOT rely on the uniqueness of RTCP CNAMEs for 290 any essential security services. This is consistent with [RFC3550], 291 which does not require that RTCP CNAMEs are unique within a session 292 but instead says that condition SHOULD hold. As described in the 293 Security Considerations section of [RFC3550], because each 294 participant in a session is free to choose its own RTCP CNAME, they 295 can do so in such a way as to impersonate another participant. That 296 is, participants are trusted to not impersonate each other. No 297 recommendation for generating RTCP CNAMEs can prevent this 298 impersonation, because an attacker can neglect the stipulation. 299 Secure RTP (SRTP) [RFC3711] keeps unauthorized entities out of an RTP 300 session, but it does not aim to prevent impersonation attacks from 301 authorized entities. 303 Because of the properties of the PRNG, there is no significant 304 privacy/linkability difference between long and short RTCP CNAMEs. 305 However, the requirement to generate unique RTCP CNAMEs implies a 306 certain minimum length. A length of 96 bits allows on the order of 307 2^{40} RTCP CNAMEs globally before there is a large chance of 308 collision (there is about a 50% chance of one collision after 2^{48} 309 RTCP CNAMEs). 311 6.2. Session Correlation Based on RTCP CNAMEs 313 Earlier recommendations for RTCP CNAME generation allowed a fixed 314 RTCP CNAME value, which allows an attacker to easily link separate 315 RTP sessions, eliminating the obfuscation provided by IPv6 privacy 316 addresses [RFC4941] or IPv4 Network Address Port Translation (NAPT) 317 [RFC3022]. 319 This specification no longer describes a procedure to generate fixed 320 RTCP CNAME values, so RTCP CNAME values no longer provide such 321 linkage between RTP sessions. This was necessary to eliminate such 322 linking by an attacker, but of course complicates linking by traffic 323 analysis devices (e.g., devices that are looking for dropped or 324 delayed packets). 326 7. IANA Considerations 328 No IANA actions are required. 330 8. Acknowledgments 332 Thanks to Marc Petit-Huguenin, who suggested using UUIDs in 333 generating RTCP CNAMEs. Also, thanks to David McGrew for providing 334 text for the Security Considerations section in RFC 6222. 336 9. References 338 9.1. Normative References 340 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 341 Jacobson, "RTP: A Transport Protocol for Real-Time 342 Applications", STD 64, RFC 3550, July 2003. 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 348 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 349 2005. 351 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 352 Encodings", RFC 4648, October 2006. 354 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 355 for IEEE 802 Parameters", BCP 141, RFC 5342, September 356 2008. 358 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 359 Requirements for Security", BCP 106, RFC 4086, June 2005. 361 9.2. Informative References 363 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 364 Choosing RTP Control Protocol (RTCP) Canonical Names 365 (CNAMEs)", RFC 6222, April 2011. 367 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 368 E. Lear, "Address Allocation for Private Internets", BCP 369 5, RFC 1918, February 1996. 371 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 372 Address Translator (Traditional NAT)", RFC 3022, January 373 2001. 375 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 376 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 377 RFC 3711, March 2004. 379 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 380 Extensions for Stateless Address Autoconfiguration in 381 IPv6", RFC 4941, September 2007. 383 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 384 (ICE): A Protocol for Network Address Translator (NAT) 385 Traversal for Offer/Answer Protocols", RFC 5245, April 386 2010. 388 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 389 Security (DTLS) Extension to Establish Keys for the Secure 390 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 392 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 393 A., Peterson, J., Sparks, R., Handley, M., and E. 394 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 395 June 2002. 397 [I-D.ietf-rtcweb-security-arch] 398 Rescorla, E., "RTCWEB Security Architecture", draft-ietf- 399 rtcweb-security-arch-06 (work in progress), January 2013. 401 [I-D.rescorla-avtcore-random-cname] 402 Rescorla, E., "Random algorithm for RTP CNAME generation", 403 draft-rescorla-avtcore-random-cname-00 (work in progress), 404 July 2012. 406 Authors' Addresses 408 Ali Begen 409 Cisco 410 181 Bay Street 411 Toronto, ON M5J 2T3 412 CANADA 414 EMail: abegen@cisco.com 415 Colin Perkins 416 University of Glasgow 417 School of Computing Science 418 Glasgow G12 8QQ 419 UK 421 EMail: csp@csperkins.org 423 Dan Wing 424 Cisco Systems, Inc. 425 170 West Tasman Drive 426 San Jose, California 95134 427 USA 429 EMail: dwing@cisco.com 431 Eric Rescorla 432 RTFM, Inc. 433 2064 Edgewood Drive 434 Palo Alto, CA 94303 435 USA 437 Phone: +1 650 678 2350 438 EMail: ekr@rtfm.com