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

["Dan Wing" <[e-mail]>]

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