draft-ietf-avtcore-6222bis-04.txt   draft-ietf-avtcore-6222bis-05.txt 
Network Working Group A. Begen Network Working Group A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 6222 (if approved) C. Perkins Obsoletes: 6222 (if approved) C. Perkins
Intended status: Standards Track University of Glasgow Updates: 3550 (if approved) University of Glasgow
Expires: December 21, 2013 D. Wing Intended status: Standards Track D. Wing
Cisco Expires: January 09, 2014 Cisco
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
June 19, 2013 July 08, 2013
Guidelines for Choosing RTP Control Protocol (RTCP) Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs) Canonical Names (CNAMEs)
draft-ietf-avtcore-6222bis-04 draft-ietf-avtcore-6222bis-05
Abstract Abstract
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
persistent transport-level identifier for an RTP endpoint. While the persistent transport-level identifier for an RTP endpoint. While the
Synchronization Source (SSRC) identifier of an RTP endpoint may Synchronization Source (SSRC) identifier of an RTP endpoint may
change if a collision is detected or when the RTP application is change if a collision is detected or when the RTP application is
restarted, its RTCP CNAME is meant to stay unchanged, so that RTP restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
endpoints can be uniquely identified and associated with their RTP endpoints can be uniquely identified and associated with their RTP
media streams. media streams.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2013. This Internet-Draft will expire on January 09, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Deficiencies with Earlier Guidelines for Choosing an RTCP 3. Deficiencies with Earlier Guidelines for Choosing an RTCP
CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 CNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Choosing an RTCP CNAME . . . . . . . . . . . . . . . . . . . 4 4. Choosing an RTCP CNAME . . . . . . . . . . . . . . . . . . . 4
4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs . . 4 4.1. Persistent RTCP CNAMEs versus Per-Session RTCP CNAMEs . . 4
4.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
5. Procedure to Generate a Unique Identifier . . . . . . . . . . 6 5. Procedure to Generate a Unique Identifier . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6.1. Considerations on Uniqueness of RTCP CNAMEs . . . . . . . 7 6.1. Considerations on Uniqueness of RTCP CNAMEs . . . . . . . 7
6.2. Session Correlation Based on RTCP CNAMEs . . . . . . . . 7 6.2. Session Correlation Based on RTCP CNAMEs . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
In Section 6.5.1 of [RFC3550], there are a number of recommendations
In Section 6.5.1 of the RTP specification, [RFC3550], there are a for choosing a unique RTCP CNAME for an RTP endpoint. However, in
number of recommendations for choosing a unique RTCP CNAME for an RTP practice, some of these methods are not guaranteed to produce a
endpoint. However, in practice, some of these methods are not unique RTCP CNAME. [RFC6222] updated the guidelines for choosing
guaranteed to produce a unique RTCP CNAME. [RFC6222] updated the RTCP CNAMEs, superseding those presented in Section 6.5.1 of
guidelines for choosing RTCP CNAMEs, superseding those presented in [RFC3550]. Unfortunately, some parts of the new algorithms are
Section 6.5.1 of [RFC3550]. Unfortunately, some parts of the new rather complicated and also produce RTCP CNAMEs which in some cases
algorithms are rather complicated and also produce RTCP CNAMEs which are potentially linkable over multiple RTCP sessions even if a new
in some cases are potentially linkable over multiple RTCP sessions RTCP CNAME is generated for each session. This document specifies a
even if a new RTCP CNAME is generated for each session. This replacement for the algorithm in Section 5 of [RFC6222], which does
document specifies a replacement for the algorithm in Section 5 of not have this limitation and is also simpler to implement.
[RFC6222], which does not have this limitation and is also simpler to
implement.
For a discussion on the linkability of RTCP CNAMES produced by For a discussion on the linkability of RTCP CNAMES produced by
[RFC6222], refer to [I-D.rescorla-avtcore-random-cname]. [RFC6222], refer to [I-D.rescorla-avtcore-random-cname].
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
skipping to change at page 5, line 27 skipping to change at page 5, line 38
RTCP CNAME MUST use one of the following two methods: RTCP CNAME MUST use one of the following two methods:
o To produce a long-term persistent RTCP CNAME, an RTP endpoint MUST o To produce a long-term persistent RTCP CNAME, an RTP endpoint MUST
generate and store a Universally Unique IDentifier (UUID) generate and store a Universally Unique IDentifier (UUID)
[RFC4122] for use as the "host" part of its RTCP CNAME. The 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 MUST be version 1, 2, or 4, as described in [RFC4122], with the
"urn:uuid:" stripped, resulting in a 36-octet printable string "urn:uuid:" stripped, resulting in a 36-octet printable string
representation. representation.
o To produce a short-term persistent RTCP CNAME, an RTP endpoint o To produce a short-term persistent RTCP CNAME, an RTP endpoint
MUST either (a) use the numeric representation of the layer-2 MUST generate and use an identifier by following the procedure
(Media Access Control (MAC)) address of the interface that is used described in Section 5. That procedure is performed at least once
to initiate the initial set of RTP sessions as the "host" part of per initialization of the software. After obtaining an
its RTCP CNAME or (b) generate and use an identifier by following identifier, minimally the least significant 96 bits SHOULD be
the procedure described in Section 5. In either case, the converted to ASCII using Base64 encoding [RFC4648] (to compromise
procedure is performed once per initialization of the software. between packet size and uniqueness - refer to Section 6.1). If 96
After obtaining an identifier in case of (a), the 48 bits are bits are used, the resulting string will be 16 octets.
converted to the standard colon-separated hexadecimal format
[RFC5342], e.g., "00:23:32:af:9b:aa", resulting in a 17-octet
printable string representation. In case of (b), 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.
In some environments (for example, a virtualized operating
system), the MAC address may not be unique as expected. In these
cases, using option (b) above is RECOMMENDED.
In the two cases above, the "user@" part of the RTCP CNAME MAY be 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 omitted on single-user systems and MAY be replaced by an opaque token
on multi-user systems, to preserve privacy. on multi-user systems, to preserve privacy.
An RTP endpoint that wishes to generate a per-session RTCP CNAME MUST An RTP endpoint that wishes to generate a per-session RTCP CNAME MUST
use the following method: use the following method:
o For every new RTP session, a new CNAME is generated following the o For every new RTP session, a new RTCP CNAME is generated following
procedure described in Section 5. After performing that the procedure described in Section 5. After performing that
procedure, minimally the least significant 96 bits SHOULD be procedure, minimally the least significant 96 bits SHOULD be
converted to ASCII using Base64 encoding [RFC4648]. The RTCP converted to ASCII using Base64 encoding [RFC4648]. The RTCP
CNAME cannot change over the life of an RTP session [RFC3550]. CNAME cannot change over the life of an RTP session [RFC3550].
The "user@" part of the RTCP CNAME is omitted when generating The "user@" part of the RTCP CNAME is omitted when generating
per-session RTCP CNAMEs. per-session RTCP CNAMEs.
It is believed that obtaining uniqueness (with a high probability) is It is believed that obtaining uniqueness (with a high probability) is
an important property that requires careful evaluation of the method. an important property that requires careful evaluation of the method.
This document provides a number of methods, at least one of which This document provides a number of methods, at least one of which
would be suitable for all deployment scenarios. This document would be suitable for all deployment scenarios. This document
skipping to change at page 6, line 33 skipping to change at page 6, line 33
used for multiple RTP sessions that are to be correlated. However, used for multiple RTP sessions that are to be correlated. However,
such a specification needs to be reviewed and approved before such a specification needs to be reviewed and approved before
deployment. deployment.
The mechanisms described in this document are to be used to generate The mechanisms described in this document are to be used to generate
RTCP CNAMEs, and they are not to be used for generating general- RTCP CNAMEs, and they are not to be used for generating general-
purpose unique identifiers. purpose unique identifiers.
5. Procedure to Generate a Unique Identifier 5. Procedure to Generate a Unique Identifier
To locally produce a unique identifier, we simply generate a To locally produce a unique identifier, one simply generates a
cryptographically pseudorandom value as described in [RFC4086]. This cryptographically pseudorandom value as described in [RFC4086]. This
value MUST be at least 96 bits but MAY be longer. value MUST be at least 96 bits and MAY be up to 512 bits.
The biggest bottleneck to implementation of this algorithm is the The biggest bottleneck to implementation of this algorithm is the
availability of an appropriate cryptographically secure pseudorandom availability of an appropriate cryptographically secure pseudorandom
number generator (CSPRNG). In any setting which already has a secure number generator (CSPRNG). In any setting which already has a secure
PRNG, this algorithm described is far simpler than the algorithm PRNG, this algorithm described is far simpler than the algorithm
described in Section 5 of [RFC6222]. SIP stacks [RFC3261] are described in Section 5 of [RFC6222]. SIP stacks [RFC3261] are
required to use cryptographically random numbers to generate To and required to use cryptographically random numbers to generate To and
From tags (Section 19.3). RTCWEB implementations From tags (Section 19.3). RTCWEB implementations
[I-D.ietf-rtcweb-security-arch] will need to have secure PRNGs to [I-D.ietf-rtcweb-security-arch] will need to have secure PRNGs to
implement ICE [RFC5245] and DTLS-SRTP [RFC5764]. And, of course, implement ICE [RFC5245] and DTLS-SRTP [RFC5764]. And, of course,
skipping to change at page 7, line 14 skipping to change at page 7, line 14
6.1. Considerations on Uniqueness of RTCP CNAMEs 6.1. Considerations on Uniqueness of RTCP CNAMEs
The considerations in this section apply to random RTCP CNAMEs. The considerations in this section apply to random RTCP CNAMEs.
The recommendations given in this document for RTCP CNAME generation The recommendations given in this document for RTCP CNAME generation
ensure that a set of cooperating participants in an RTP session will, ensure that a set of cooperating participants in an RTP session will,
with very high probability, have unique RTCP CNAMEs. However, with very high probability, have unique RTCP CNAMEs. However,
neither [RFC3550] nor this document provides any way to ensure that neither [RFC3550] nor this document provides any way to ensure that
participants will choose RTCP CNAMEs appropriately, and thus participants will choose RTCP CNAMEs appropriately, and thus
implementations MUST NOT rely on the uniqueness of CNAMEs for any implementations MUST NOT rely on the uniqueness of RTCP CNAMEs for
essential security services. This is consistent with [RFC3550], any essential security services. This is consistent with [RFC3550],
which does not require that RTCP CNAMEs are unique within a session which does not require that RTCP CNAMEs are unique within a session
but instead says that condition SHOULD hold. As described in the but instead says that condition SHOULD hold. As described in the
Security Considerations section of [RFC3550], because each Security Considerations section of [RFC3550], because each
participant in a session is free to choose its own RTCP CNAME, they 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 can do so in such a way as to impersonate another participant. That
is, participants are trusted to not impersonate each other. No is, participants are trusted to not impersonate each other. No
recommendation for generating RTCP CNAMEs can prevent this recommendation for generating RTCP CNAMEs can prevent this
impersonation, because an attacker can neglect the stipulation. impersonation, because an attacker can neglect the stipulation.
Secure RTP (SRTP) [RFC3711] keeps unauthorized entities out of an RTP Secure RTP (SRTP) [RFC3711] keeps unauthorized entities out of an RTP
session, but it does not aim to prevent impersonation attacks from session, but it does not aim to prevent impersonation attacks from
skipping to change at page 7, line 38 skipping to change at page 7, line 38
Because of the properties of the PRNG, there is no significant Because of the properties of the PRNG, there is no significant
privacy/linkability difference between long and short RTCP CNAMEs. privacy/linkability difference between long and short RTCP CNAMEs.
However, the requirement to generate unique RTCP CNAMEs implies a However, the requirement to generate unique RTCP CNAMEs implies a
certain minimum length. A length of 96 bits allows on the order of 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 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} collision (there is about a 50% chance of one collision after 2^{48}
RTCP CNAMEs). RTCP CNAMEs).
6.2. Session Correlation Based on RTCP CNAMEs 6.2. Session Correlation Based on RTCP CNAMEs
In some environments, notably telephony, a fixed RTCP CNAME value Earlier recommendations for RTCP CNAME generation allowed a fixed
allows separate RTP sessions to be correlated and eliminates the RTCP CNAME value, which allows an attacker to easily link separate
obfuscation provided by IPv6 privacy addresses [RFC4941] or IPv4 RTP sessions, eliminating the obfuscation provided by IPv6 privacy
Network Address Port Translation (NAPT) [RFC3022]. SRTP [RFC3711] addresses [RFC4941] or IPv4 Network Address Port Translation (NAPT)
can help prevent such correlation by encrypting Secure RTCP (SRTCP), [RFC3022].
but it should be noted that SRTP only mandates SRTCP integrity
protection (not encryption). Thus, RTP applications used in such
environments should consider encrypting their SRTCP or generate a
per-session RTCP CNAME as discussed in Section 4.1.
7. IANA Considerations 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
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. IANA Considerations
No IANA actions are required. No IANA actions are required.
8. Acknowledgments 8. Acknowledgments
Thanks to Marc Petit-Huguenin, who suggested using UUIDs in Thanks to Marc Petit-Huguenin, who suggested using UUIDs in
generating RTCP CNAMEs. Also, thanks to David McGrew for providing generating RTCP CNAMEs. Also, thanks to David McGrew for providing
text for the Security Considerations section in RFC 6222. text for the Security Considerations section in RFC 6222.
9. References 9. References
 End of changes. 14 change blocks. 
54 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/