Re: [secdir] secdir review of draft-ietf-avt-rtp-cnames-02

["DRAGE, Keith (Keith)" <[e-mail]>]

Just coming back on the following:

> > 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".
> 
> We will delete the sentence that says:
> 
>   Other methods, beyond the	
>   three methods listed above, are not compliant with this 
> specification	
>   and SHOULD NOT be used.
> 
> because it is really saying "if you don't comply with this 
> document's requirements, you aren't in compliance with this 
> document" -- which is a silly thing to say.
> 

This sentence was added as a result of my comment in the document shepherd review as follows:

"1)	Section 3 contains the following statement:

   The recommendation in [RFC3550] is to generate an RTCP CNAME of the
   form "user@host" for multiuser systems, or "host" if the username is
   not available.  The "host" part is specified to be the fully
   qualified domain name (FQDN) of the host from which the real-time
   data originates.  While this guidance was appropriate at the time
   [RFC3550] was written, FQDNs are no longer necessarily unique, and
   can sometimes be common across several endpoints in large service
   provider networks.  Thus, the use of FQDN as the CNAME is strongly
   discouraged.

Given the statement above, can you point me at the SHOULD requirement that I would expect to see relating to this in section 4."

So if we no longer have that added text in section 4, then we need to go back and revisit section 3, and particularly the sentence: "Thus, the use of FQDN as the CNAME is strongly discouraged." because it no longer is discouraged by this document.

An alternative statement in section 3 would be: "This document replaces the use of FQDN as a CNAME by alternative mechanisms."

regards

Keith



 

> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]] 
> Sent: Tuesday, December 14, 2010 11:22 PM
> To: 'Tobias Gondrom'; [e-mail]; [e-mail]; 
> [e-mail]
> Cc: [e-mail]; [e-mail]; DRAGE, Keith 
> (Keith); [e-mail]; [e-mail]
> Subject: RE: secdir review of draft-ietf-avt-rtp-cnames-02
> 
>  -----Original Message-----
> > From: Tobias Gondrom [mailto:[e-mail]]
> > Sent: Monday, December 13, 2010 4:42 PM
> > To: [e-mail]; [e-mail]; draft-ietf-avt-rtp- 
> > [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]; 
> > [e-mail]; [e-mail]; 
> > [e-mail]
> > Subject: secdir review of draft-ietf-avt-rtp-cnames-02
> > 
> > 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.
> 
> Tobias, 
> 
> Thanks for your review.
> 
> > 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"
> 
> Will be fixed in -03, thanks.
> 
> > 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.
> 
> It is explained in Section 4.1's paragraph 2 and 3, which 
> essentially say that short-term is per each RTP session and 
> necessary for lipsync, while long-term is across several RTP 
> sessions and useful for third- party monitoring of RTP 
> performance.  Are those descriptions inadequate for 
> implementers to determine which they want?
> 
> > 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).
> 
> UUID is a persistent and permanent identifier, so can't be 
> used with d (per-session).  However, you have a good point 
> that it is equally useful for b (short-term IPv6) and c 
> (short-term IPv4).  See more on that below.
> 
> > 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".
> 
> We will delete the sentence that says:
> 
>   Other methods, beyond the	
>   three methods listed above, are not compliant with this 
> specification	
>   and SHOULD NOT be used.
> 
> because it is really saying "if you don't comply with this 
> document's requirements, you aren't in compliance with this 
> document" -- which is a silly thing to say.
> 
> 
> Based on other reviews, we also added the following new text 
> at the end of that section:
>  
>    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.
> 
> > 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?
> 
> CNAME values are opaque strings to remote peers, so there is 
> no upgrade problem.
> 
> > 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?
> 
> If we expect / fear IPv6 NAPT (IPv6 address sharing), I 
> concur that using an IPv6 address is not safely unique, and 
> we will eliminate the option where an IPv6 address is used as CNAME.
> 
> Your review highlighted another issue, which had escaped me 
> until now, with two IPv6-only networks using a NAT64 and the 
> well-known prefix 64:ff9b::/96 defined by RFC6052.  Those two 
> hosts can't communicate directly with each other over IPv6, 
> but they could communicate with each other using an 
> application-level proxy (Session Border Controller) or a 
> NAT64.  And in both cases they would have an RTCP CNAME 
> collision because their IPv6 addresses are not unique.
> 
> Because of these two problems, we need to remove the option 
> to use the IPv6 address in CNAME.
> 
> > 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.
> 
> Would adding the following highlighted text be sufficient to clarify:
> 
> NEW:
>    To generate a per-session RTCP CNAME, an endpoint MUST perform 
>    a Hash-based Message Authentication Code at least as 
> strong as 
> ...^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    SHA1-HMAC [RFC2104] on the concatenated values of the RTP 
> endpoint's
>    initial SSRC, 
> 
> > 3.2. Question: maybe obvious, but why do you need to truncate the 
> > output to 96bit?
> 
> would adding the following text be sufficient to clarify:
> 
>   The output of the hash function is truncated to 96 bits to
>   provides a reasonable compromise between security and packet
>   size.
> 
> > 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?
> 
> For the last sentence of Section 4.2, would adjusting this 
> text be sufficient to clarify:
> 
> OLD:
>   The "user@" part of the RTCP CNAME is omitted when generating
>   per-session RTCP CNAMEs.
> NEW:
>   In all cases of single- or multi-user systems, 
> ..^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   the "user@" part of the RTCP CNAME is omitted when generating
>   per-session RTCP CNAMEs.
> 
> -d
> 
> > Kind regards, Tobias
> > 
> > 
> > Tobias Gondrom
> > email: [e-mail]
> 
>