ietf
[Top] [All Lists]

Re: TSV-Dir Last Call review of draft-ietf-avt-rtp-cnames-02

2010-12-17 12:00:40
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

<Prev in Thread] Current Thread [Next in Thread>