Allison,
Thanks for the review. These all seem like reasonable suggestions, which we
should incorporate.
Colin
On 14 Dec 2010, at 02:56, Allison Mankin wrote:
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 if you
reply to or forward this review.
Summary: This draft is on the right track, but has open issues described in
the review.
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
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 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.
Agreed.
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.
Agreed. This looks like a typo that should be fixed.
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 Version 4.
This guidance seems appropriate, thanks.
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?
That seems like a reasonable addition.
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 "inse
cure hash."
We'll add some guidance in -03.
Thanks,
Colin
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf