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 [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
