I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG. These comments were written primarily for the benefit of the  
security area directors. Document editors and WG chairs should treat  
these comments just like any other last call comments.


The Security Considerations section is ok and the draft does not add
further security aspects beyond it.
However there are a number of issues with the draft, including use of
rfc2119 language and hash agility:

1. section 4.2 first bullet point:
spelling:
s/"and endpoint MUST generate and store a Universally"/"an endpoint MUST
generate and store a Universally"

2. COMMENTS/DISCUSS:
section 4.2: the draft makes the distinction between 4 cases:
a) long-term persistent
b) short-term persistent with IPv6
c) short-term persistent with IPv4
d) per-session RTCP CNAME
all use MUST to specify the generated CNAME with _different_ methods. 

This raises a number of potential issues:
2.1. The boundary between the definition of long-term and short-term
with persistence across several related RTP sessions (see 4.1) is not
well defined, thus different MUST clauses for how to treat these two
cases seem problematic. As it can be hard for an application to
determine the difference between across several sessions and long-term.
2.2. Though I understand why a system may not want to use UUID in all
four cases, it is unclear to me why it should be forbidden to use UUID
for scenarios b, c and d. (which is implied by using "MUST" with the
defined method).
2.3. in section 4.2. next to last paragraph it states: (other methods)
"beyond the three methods listed above, are not compliant with this
specification and SHOULD NOT be used."
If the document is std track and updates 3550 and uses "MUST" for the
methods it would be inconsistent to frame it here as "SHOULD NOT".
2.4. Question: which leads to another question: are there upgrade issues
with 3550-applications with this update or is there an upgrade path for
RTP from 3550 to draft-ietf-avt-rtp-cnames?
2.5. case b (IPv6): I understand that one reason for different handling
of IPv4 is NAT and private address spaces. And although NAT with IPv6
should not make sense, in theory this could still happen, so I am not
sure whether these two cases (b and c) can be and need to be handled
differently.

Overall: a solution could be that UUID be allowed for all methods (e.g.
frame it as "MUST use one of the here described methods") and maybe the
unification of case b (short-term IPv6) and c (short-term IPv4) - either
allowing both methods for both and indicating preferred approaches with
"SHOULD" for each of them (e.g. SHOULD use MAC for scenarios of possible
NAT) -  unless the authors can explain why we really need to mandate
these two different scenarios and why IPv6 has not at least in theory
NAT issues?

3. hash agility: in section 4.2 last paragraph the draft mandates for
case d (per-session RTCP CNAMEs ) to use SHA1-HMAC and truncate the
value to 96bit
3.1. DISCUSS: The drafts should not be tied to SHA1 and actually allow
use of other algorithms (e.g. SHA2/SHA-256/-512) as well.

3.2. Question: maybe obvious, but why do you need to truncate the output
to 96bit?

3.3. Clarification: it also states at the end of this paragraph that the
"user@" part of the CNAME "is omitted". Does this mean "MAY be omitted
on single-user systems, and MAY be replaced by an opaque token on
multiuser systems" like for cases a-c or is this intentionally different
and mandatory in d?

Kind regards, Tobias


Tobias Gondrom
email: tobias.gondrom at gondrom.org