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