Last Call Review of draft-ietf-avt-rtp-cnames-
review-ietf-avt-rtp-cnames-secdir-lc-gondrom-2010-12-16-00
Request | Review of | draft-ietf-avt-rtp-cnames |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2010-12-17 | |
Requested | 2010-11-30 | |
Authors | Colin Perkins , Ali C. Begen , Dan Wing | |
I-D last updated | 2010-12-16 | |
Completed reviews |
Secdir Last Call review of -??
by Tobias Gondrom
Tsvdir Early review of -?? by Allison Mankin |
|
Assignment | Reviewer | Tobias Gondrom |
State | Completed | |
Request | Last Call review on draft-ietf-avt-rtp-cnames by Security Area Directorate Assigned | |
Completed | 2010-12-16 |
review-ietf-avt-rtp-cnames-secdir-lc-gondrom-2010-12-16-00
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