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

From: Tobias Gondrom <[email-masked]>
Date: Tue, 14 Dec 2010 00:42:07 +0000

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: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Dec 2010 15:21:59 -0800

-----Original Message-----
> From: Tobias Gondrom [mailto:[email-masked]]
> Sent: Monday, December 13, 2010 4:42 PM
> To: [email-masked]; [email-masked]; draft-ietf-avt-rtp-
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: secdir review of draft-ietf-avt-rtp-cnames-02
> 

Tobias, 

Thanks for your review.

> generate and store a Universally"

Will be fixed in -03, thanks.

> 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?

> for scenarios b, c and d. (which is implied by using "MUST" with the

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.

> 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.

> RTP from 3550 to draft-ietf-avt-rtp-cnames?

CNAME values are opaque strings to remote peers, so there is no 
upgrade problem.

> these two different scenarios and why IPv6 has not at least in theory

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.

> 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.

> multiuser systems" like for cases a-c or is this intentionally

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Dec 2010 17:02:19 +0100

Just coming back on the following:

> 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

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Tuesday, December 14, 2010 11:22 PM
> To: 'Tobias Gondrom'; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; DRAGE, Keith 
> (Keith); [email-masked]; [email-masked]
> Subject: RE: secdir review of draft-ietf-avt-rtp-cnames-02
> 
> > s/"and endpoint MUST generate and store a Universally"/"an endpoint 
> > MUST generate and store a Universally"
> 
> 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?
> 
> 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.
> 
> 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:
>  
> > 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.
> > 
> > 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
> 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.
> 
> > 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.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:

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 22 Dec 2010 08:09:21 -0800

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, December 22, 2010 11:02 AM
> To: Dan Wing (dwing); 'Tobias Gondrom'; [email-masked]; [email-masked]; [email-masked]
> Cc: Ali C. Begen (abegen); [email-masked]; [email-masked]; [email-masked]
> 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.
> 

This replacement works.

Thanks, acbegen.