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@xxxxxxxx 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. 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 Version 4. 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: www.ietf.org/proceedings/08nov/slides/saag-0.pdf With best regards to all, Allison mankin@xxxxxxx / allison.mankin@xxxxxxxxx / allison.mankin@xxxxxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf