TSV-DIR Last Call review of "Guidelines for Chosing RTP Control Protocol
(RTCP) Canonical Names (CNAMEs)
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors for their information and to allow them to address any issues
raised. The authors should consider this review together with any other
last-call comments they receive. Please always cc tsv-dir(_at_)ietf(_dot_)org
reply to or forward this review.
Summary: This draft is on the right track, but has open issues described in
The review below gives my basis for three recommendations:
1. For long-term persistent CNAMEs, differentiate among the UUID "Versions"
in RFC 4122
2. For short-term persistent CNAMEs, allow IPv4-only endpoints to generate a
pseudo-random alternative to their MAC, if desired
3. For per-session CNAMEs, provide some guidance for the random value and
the key, which are currently left underspecified.
Section 3 sets up the major requirement to be met, which is better
uniqueness properties than those of the CNAME generation in RFC 3550.
There's a hint in the last sentence of the section about an additional
requirement to afford privacy support. This sentence only mentions avoiding
exposure of private addresses. Avoidance of linkage among RTP streams due
to the use of fixed CNAMEs comes up later.
Section 4 sets up the CNAME types, persistent versus per-session, and within
persistent types, short-term IPv4-only, short-term IPv6-capable, and
long-term. The methods of generating these CNAMEs are distinct and I
understand from the WG mailing list discussion of their AD review that they
are to be specified as mandatory. On December 2, Ali wrote to AVT that the
next revision will change language in Section 4 from the existing:
Other methods, beyond the three methods listed above, are not
compliant with this specification and SHOULD NOT be used.
To the following:
It is believed that obtaining uniqueness is an important property that
requires careful evaluation of the method. This document provides a
number of methods, for which it is believed that at least one of them
would meet all deployment scenarios. This document therefore does not
provide for the implementor to define and select an alternative
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 second sentence of the first paragraph could be written better:
This document provides a number of methods, at least one of which
should be suitable for all deployment scenarios.
My remaining discussion is about making this statement more true.
First, all the methods should afford some access to privacy support, but as
written, there is little or none for the long-term persistent and the
IPv4-only short-term persistent CNAMEs.
An implementation that wishes to
discourage this type of third-party monitoring can generate a unique
RTCP CNAME for each RTP session, or group of related RTP sessions,
that it joins. Such a per-session RTCP CNAME cannot be used for
traffic analysis, and so provides some limited form of privacy
The above statement implies that a long-term persistent CNAME inherently
cannot have privacy support. It's not necessarily so: if the CNAME doesn't
embed identifying information, observers get connections among multiple
streams but they only don't have a fixed host identity, only a pseudonym.
Specific issues per CNAME method:
1) Long-term persistent CNAMEs are required to be generated by an adaptation
of RFC 4122 UUIDs (the adaptation is to leave off the string "urn:uuid:").
The draft references Section 3 of RFC 4122. It should reference Section 4
instead because Section 3 does not detail the UUID components. Moreover, it
would be good for the draft to advise on usage among the four different
versions of UUID that RFC 4122 covers:
+ Version 1: generated from clock + MAC, or + MAC-format random number
+ Version 3: generated from namespace:name
+ Version 4: generated from "truly random or pseudo-random number"
+ Version 5: generated from hash of namespace:name
There needs to be some guidance because the use of the UUID Versions 3/5,
derived from namespace:name, has the same problem with non-uniqueness of
FQDNs as the RFC 3550 FQDN-based CNAMEs. Perhaps this document should
advise against using 3/5. In addition, right now the draft is silent on
mitigating identity exposure, but it could offer some guidance towards using
the variant of Version 1 that does not expose the MAC or towards using
2) Short-term persistent CNAMEs are allowed to use a pseudo-randomly
generated RFC 4941 IPv6 privacy address if the device is IPv6-capable, but
are required to exposetheir MACs if the device is IPv4-only. Why not allow
IPv4-only endpoints to to generate pseudo-random MACs using the
specification of doing so provided for the Version 1 variant in RFC 4122?
3) Per-session CNAMEs are generated using SHA1-HMAC over the concatenation
of the initially-used SSRC, the source and destination addresses and ports,
and "a randomly generated value". RFC 4086 is given as a reference for the
randomly generated value. I think an implementer would like to know how
many bytes of randomly generated value should be used; this doesn't come out
clearly from reading RFC 4086. Further, what are the requirements for the
key for HMAC here? In reading RFC 2104, the reference for HMAC, I end up
with some ideas about the key length, but not about how long/where I can use
the same key or whether there are problematic keys - to mention two
questions that come to mind. Keying would not normally be easy to
under-specify this way because a security application would call for some
keying details, but in this application there is no security use for the
keys. Either it would be good to add some guidance or perhaps SHA1-HMAC
could be replaced with an "insecure hash." Thoughts about this have arisen
from re-reading EKR's SAAG talk from IETF 73:
With best regards to all,
mankin(_at_)psg(_dot_)com / allison(_dot_)mankin(_at_)gmail(_dot_)com /
Ietf mailing list