summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7022.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7022.txt')
-rw-r--r--doc/rfc/rfc7022.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc7022.txt b/doc/rfc/rfc7022.txt
new file mode 100644
index 0000000..cf76ead
--- /dev/null
+++ b/doc/rfc/rfc7022.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Begen
+Request for Comments: 7022 Cisco
+Obsoletes: 6222 C. Perkins
+Updates: 3550 University of Glasgow
+Category: Standards Track D. Wing
+ISSN: 2070-1721 Cisco
+ E. Rescorla
+ RTFM, Inc.
+ September 2013
+
+
+ Guidelines for Choosing RTP Control Protocol (RTCP)
+ Canonical Names (CNAMEs)
+
+Abstract
+
+ The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
+ persistent transport-level identifier for an RTP endpoint. While the
+ Synchronization Source (SSRC) identifier of an RTP endpoint may
+ change if a collision is detected or when the RTP application is
+ restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
+ endpoints can be uniquely identified and associated with their RTP
+ media streams.
+
+ For proper functionality, RTCP CNAMEs should be unique within the
+ participants of an RTP session. However, the existing guidelines for
+ choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are
+ insufficient to achieve this uniqueness. RFC 6222 was published to
+ update those guidelines to allow endpoints to choose unique RTCP
+ CNAMEs. Unfortunately, later investigations showed that some parts
+ of the new algorithms were unnecessarily complicated and/or
+ ineffective. This document addresses these concerns and replaces RFC
+ 6222.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7022.
+
+
+
+
+Begen, et al. Standards Track [Page 1]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Requirements Notation ...........................................3
+ 3. Deficiencies with Earlier Guidelines for Choosing an
+ RTCP CNAME ......................................................3
+ 4. Choosing an RTCP CNAME ..........................................4
+ 4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs ......4
+ 4.2. Requirements ...............................................5
+ 5. Procedure to Generate a Unique Identifier .......................6
+ 6. Security Considerations .........................................7
+ 6.1. Considerations on Uniqueness of RTCP CNAMEs ................7
+ 6.2. Session Correlation Based on RTCP CNAMEs ...................7
+ 7. Acknowledgments .................................................8
+ 8. References ......................................................8
+ 8.1. Normative References .......................................8
+ 8.2. Informative References .....................................8
+
+1. Introduction
+
+ In Section 6.5.1 of [RFC3550], there are a number of recommendations
+ for choosing a unique RTCP CNAME for an RTP endpoint. However, in
+ practice, some of these methods are not guaranteed to produce a
+ unique RTCP CNAME. [RFC6222] updated the guidelines for choosing
+ RTCP CNAMEs, superseding those presented in Section 6.5.1 of
+ [RFC3550]. Unfortunately, some parts of the new algorithms are
+ rather complicated and also produce RTCP CNAMEs that, in some cases,
+ are potentially linkable over multiple RTCP sessions even if a new
+ RTCP CNAME is generated for each session. This document specifies a
+ replacement for the algorithm in Section 5 of [RFC6222], which does
+ not have this limitation and is also simpler to implement.
+
+
+
+
+
+Begen, et al. Standards Track [Page 2]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+ For a discussion on the linkability of RTCP CNAMEs produced by
+ [RFC6222], refer to [RESCORLA].
+
+2. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME
+
+ The recommendation in [RFC3550] is to generate an RTCP 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. While this guidance was appropriate at the time
+ [RFC3550] was written, FQDNs are no longer necessarily unique and can
+ sometimes be common across several endpoints in large service
+ provider networks. This document replaces the use of the FQDN as an
+ RTCP CNAME by alternative mechanisms.
+
+ IPv4 addresses are also suggested for use in RTCP CNAMEs in
+ [RFC3550], where the "host" part of the RTCP CNAME is the numeric
+ representation of the IPv4 address of the interface from which the
+ RTP data originates. As noted in [RFC3550], the use of private
+ network address space [RFC1918] can result in hosts having network
+ addresses that are not globally unique. Additionally, this shared
+ use of the same IPv4 address can occur with public IPv4 addresses if
+ multiple hosts are assigned the same public IPv4 address and are
+ connected to a Network Address Translation (NAT) device [RFC3022].
+ When multiple hosts share the same IPv4 address, whether private or
+ public, using the IPv4 address as the RTCP CNAME leads to RTCP CNAMEs
+ that are not necessarily unique.
+
+ It is also noted in [RFC3550] that if hosts with private addresses
+ and no direct IP connectivity to the public Internet have their RTP
+ packets forwarded to the public Internet through an RTP-level
+ translator, they could end up having non-unique RTCP CNAMEs. The
+ suggestion in [RFC3550] is that such applications provide a
+ configuration option to allow the user to choose a unique RTCP CNAME;
+ this technique puts the burden on the translator to translate RTCP
+ CNAMEs from private addresses to public addresses if necessary to
+ keep private addresses from being exposed. Experience has shown that
+ this does not work well in practice.
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 3]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+4. Choosing an RTCP CNAME
+
+ 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. Using the numeric representation of
+ the IPv4 address as the "host" part of the RTCP CNAME is NOT
+ RECOMMENDED.
+
+4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs
+
+ The RTCP CNAME can be either persistent across different RTP sessions
+ for an RTP endpoint or unique per session, meaning that an RTP
+ endpoint chooses a different RTCP CNAME for each RTP session.
+
+ An RTP endpoint that is emitting multiple related RTP streams that
+ require synchronization at the other endpoint(s) MUST use the same
+ RTCP CNAME for all streams that are to be synchronized. This
+ requires a short-term, persistent RTCP CNAME that is common across
+ several RTP streams, and potentially across several related RTP
+ sessions. A common example of such use occurs when syncing audio and
+ video streams in a multimedia session, where a single participant has
+ to use the same RTCP CNAME for its audio RTP session and for its
+ video RTP session. Another example might be to synchronize the
+ layers of a layered audio codec, where the same RTCP CNAME has to be
+ used for each layer.
+
+ If the multiple RTP streams in an RTP session are not related, and
+ thus do not require synchronization, an RTP endpoint can use
+ different RTCP CNAMEs for these streams.
+
+ A longer-term persistent RTCP CNAME is sometimes useful to facilitate
+ third-party monitoring, consistent with [RFC3550]. One such use
+ might be to allow network management tools to correlate the ongoing
+ quality of service for a participant across multiple RTP sessions for
+ fault diagnosis and to understand long-term network performance
+ statistics. An application developer that wishes to discourage this
+ type of third-party monitoring can choose to generate a unique RTCP
+ CNAME for each RTP session, or group of related RTP sessions, that
+ the application will join. Such a per-session RTCP CNAME cannot be
+ used for traffic analysis, and so provides some limited form of
+ privacy. Note that there are non-RTP means that can be used by a
+ third party to correlate RTP sessions, so the use of per-session RTCP
+ CNAMEs will not prevent a determined traffic analyst from monitoring
+ such sessions.
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 4]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+ This memo defines several different ways by which an implementation
+ can choose an RTCP CNAME. It is possible, and legitimate, for
+ independent implementations to make different choices of RTCP CNAME
+ when running on the same host. This can hinder third-party
+ monitoring, unless some external means is provided to configure a
+ persistent choice of RTCP CNAME for those implementations.
+
+ Note that there is no backwards compatibility issue (with
+ implementations compatible with [RFC3550]) introduced in this memo,
+ since the RTCP CNAMEs are opaque strings to remote peers.
+
+4.2. Requirements
+
+ RTP endpoints will choose to generate RTCP CNAMEs that are persistent
+ or per-session. An RTP endpoint that wishes to generate a persistent
+ RTCP CNAME MUST use one of the following two methods:
+
+ o To produce a long-term persistent RTCP CNAME, an RTP endpoint MUST
+ generate and store a Universally Unique IDentifier (UUID)
+ [RFC4122] for use as the "host" part of its RTCP CNAME. The UUID
+ MUST be version 1, 2, or 4, as described in [RFC4122], with the
+ "urn:uuid:" stripped, resulting in a 36-octet printable string
+ representation.
+
+ o To produce a short-term persistent RTCP CNAME, an RTP endpoint
+ MUST generate and use an identifier by following the procedure
+ described in Section 5. That procedure is performed at least once
+ per initialization of the software. After obtaining an
+ identifier, minimally the least significant 96 bits SHOULD be
+ converted to ASCII using Base64 encoding [RFC4648] (to compromise
+ between packet size and uniqueness -- refer to Section 6.1). If
+ 96 bits are used, the resulting string will be 16 octets. Note
+ the Base64 encoded value cannot exceed the maximum RTCP CNAME
+ length of 255 octets [RFC3550].
+
+ In the two cases above, the "user@" part of the RTCP CNAME MAY be
+ omitted on single-user systems and MAY be replaced by an opaque token
+ on multiuser systems, to preserve privacy.
+
+ An RTP endpoint that wishes to generate a per-session RTCP CNAME MUST
+ use the following method:
+
+ o For every new RTP session, a new RTCP CNAME is generated following
+ the procedure described in Section 5. After performing that
+ procedure, minimally the least significant 96 bits SHOULD be
+ converted to ASCII using Base64 encoding [RFC4648]. The RTCP
+
+
+
+
+
+Begen, et al. Standards Track [Page 5]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+ CNAME cannot change over the life of an RTP session [RFC3550].
+ The "user@" part of the RTCP CNAME is omitted when generating
+ per-session RTCP CNAMEs.
+
+ It is believed that obtaining uniqueness (with a high probability) is
+ an important property that requires careful evaluation of the method.
+ This document provides a number of methods, at least one of which
+ would be suitable for any given deployment scenarios. This document
+ therefore does not provide for the implementor to define and select
+ an alternative method.
+
+ A future specification might define an alternative method for
+ generating RTCP CNAMEs, as long as the proposed method has
+ appropriate uniqueness and there is consistency between the methods
+ used for multiple RTP sessions that are to be correlated. However,
+ such a specification needs to be reviewed and approved before
+ deployment.
+
+ The mechanisms described in this document are to be used to generate
+ RTCP CNAMEs, and they are not to be used for generating general-
+ purpose unique identifiers.
+
+5. Procedure to Generate a Unique Identifier
+
+ To locally produce a unique identifier, one simply generates a
+ cryptographically pseudorandom value as described in [RFC4086]. This
+ value MUST be at least 96 bits.
+
+ The biggest bottleneck to implementation of this algorithm is the
+ availability of an appropriate cryptographically secure pseudorandom
+ number generator (CSPRNG). In any setting that already has a secure
+ PRNG, this algorithm described is far simpler than the algorithm
+ described in Section 5 of [RFC6222]. SIP stacks [RFC3261] are
+ required to use cryptographically random numbers to generate To and
+ From tags (Section 19.3). Real-Time Communications on the Web
+ (RTCWEB) implementations [ARCH] will need to have secure PRNGs to
+ implement ICE [RFC5245] and DTLS-SRTP [RFC5764]. And, of course,
+ essentially every Web browser already supports TLS, which requires a
+ secure PRNG.
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 6]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+6. Security Considerations
+
+ The security considerations of [RFC3550] apply to this memo.
+
+6.1. Considerations on Uniqueness of RTCP CNAMEs
+
+ The considerations in this section apply to random RTCP CNAMEs.
+
+ The recommendations given in this document for RTCP CNAME generation
+ ensure that a set of cooperating participants in an RTP session will,
+ with very high probability, have unique RTCP CNAMEs. However,
+ neither [RFC3550] nor this document provides any way to ensure that
+ participants will choose RTCP CNAMEs appropriately; thus,
+ implementations MUST NOT rely on the uniqueness of RTCP CNAMEs for
+ any essential security services. This is consistent with [RFC3550],
+ which does not require that RTCP CNAMEs are unique within a session
+ but instead says that condition SHOULD hold. As described in the
+ Security Considerations section of [RFC3550], because each
+ participant in a session is free to choose its own RTCP CNAME, they
+ can do so in such a way as to impersonate another participant. That
+ is, participants are trusted not to impersonate each other. No
+ recommendation for generating RTCP CNAMEs can prevent this
+ impersonation, because an attacker can neglect the stipulation.
+ Secure RTP (SRTP) [RFC3711] keeps unauthorized entities out of an RTP
+ session, but it does not aim to prevent impersonation attacks from
+ authorized entities.
+
+ Because of the properties of the PRNG, there is no significant
+ privacy/linkability difference between long and short RTCP CNAMEs.
+ However, the requirement to generate unique RTCP CNAMEs implies a
+ certain minimum length. A length of 96 bits allows on the order of
+ 2^{40} RTCP CNAMEs globally before there is a large chance of
+ collision (there is about a 50% chance of one collision after 2^{48}
+ RTCP CNAMEs).
+
+6.2. Session Correlation Based on RTCP CNAMEs
+
+ Earlier recommendations for RTCP CNAME generation allowed a fixed
+ RTCP CNAME value, which allows an attacker to easily link separate
+ RTP sessions, eliminating the obfuscation provided by IPv6 privacy
+ addresses [RFC4941] or IPv4 Network Address Port Translation (NAPT)
+ [RFC3022].
+
+ This specification no longer describes a procedure to generate fixed
+ RTCP CNAME values, so RTCP CNAME values no longer provide such
+ linkage between RTP sessions. This was necessary to eliminate such
+
+
+
+
+
+Begen, et al. Standards Track [Page 7]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+ linking by an attacker, but of course complicates linking by traffic
+ analysis devices (e.g., devices that are looking for dropped or
+ delayed packets).
+
+7. Acknowledgments
+
+ Thanks to Marc Petit-Huguenin, who suggested using UUIDs in
+ generating RTCP CNAMEs. Also, thanks to David McGrew for providing
+ text for the Security Considerations section in RFC 6222.
+
+8. References
+
+8.1. Normative References
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122, July
+ 2005.
+
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, October 2006.
+
+ [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+8.2. Informative References
+
+ [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
+ Choosing RTP Control Protocol (RTCP) Canonical Names
+ (CNAMEs)", RFC 6222, April 2011.
+
+ [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+ E. Lear, "Address Allocation for Private Internets", BCP
+ 5, RFC 1918, February 1996.
+
+ [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
+ Address Translator (Traditional NAT)", RFC 3022, January
+ 2001.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, March 2004.
+
+
+
+Begen, et al. Standards Track [Page 8]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+ [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
+ Extensions for Stateless Address Autoconfiguration in
+ IPv6", RFC 4941, September 2007.
+
+ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols", RFC 5245, April
+ 2010.
+
+ [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
+ Security (DTLS) Extension to Establish Keys for the Secure
+ Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [ARCH] Rescorla, E., "WebRTC Security Architecture", Work in
+ Progress, July 2013.
+
+ [RESCORLA] Rescorla, E., "Random algorithm for RTP CNAME generation",
+ Work in Progress, July 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 9]
+
+RFC 7022 Choosing an RTCP CNAME September 2013
+
+
+Authors' Addresses
+
+ Ali Begen
+ Cisco
+ 181 Bay Street
+ Toronto, ON M5J 2T3
+ CANADA
+
+ EMail: abegen@cisco.com
+
+
+ Colin Perkins
+ University of Glasgow
+ School of Computing Science
+ Glasgow G12 8QQ
+ UK
+
+ EMail: csp@csperkins.org
+
+
+ Dan Wing
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, California 95134
+ USA
+
+ EMail: dwing@cisco.com
+
+
+ Eric Rescorla
+ RTFM, Inc.
+ 2064 Edgewood Drive
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1 650 678 2350
+ EMail: ekr@rtfm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 10]
+