Re: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01

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

> Here is the new version of the CNAME draft.
> 
> http://www.ietf.org/id/draft-begen-avt-rtp-cnames-01.txt
> 
> We took the comments into consideration. Hopefully, the text 
> is almost complete now. Feedback is welcome.

I support this becoming an AVT WG document.  This resolves some
long-standing concerns I have had with RFC3550's suggestions
around CNAMEs.



My two large-ish issues with the draft:

1. FQDNs are not necessarily unique, but the draft assumes
   they are.  For example, 'home.comcast.net' is probably 
   a very common FQDN for Comcast customers.
2. The three current recommendations (IPv6 address, FQDN,
   UUID) all expose information about the RTP host, which
   provides additional information for traffic analysis.
   We might consider suggesting something more robust against
   traffic analysis, which changes for every RTP session, and
   which does not use an identifier (e.g., IPv6 address) that 
   can be correlated with the endpoint.


Detail:


* Abstract should remove citations to RFC3550, because for style
reasons the RFC Editor will remove that prior to publication.


* Section 1, 

Change reference from [I-D.miles-behave-l2nat] to RFC3022.


* Section 1 reads:

   [RFC3550] suggests that
   such applications provide a configuration option to allow the user to
   choose a unique CNAME, and puts the burden on the translator to
   translate CNAMEs from private addresses to public addresses if
   necessary to keep private addresses from being exposed.  Experience
   has shown that this does not work well in practice.

it is true that RFC3550 mentions CNAME "addresses" should 
be "translated".  But CNAMEs might, or might not, contain an
address.  If RFC3550 had recommended any sort of CNAME translation,
it should not have used the word 'address'; rather, it should have
just said 'translate'.  

As an example, and something else that should also be discussed
in the Introduction, is that hosts are often given simple names
("host" or "home" or "home-pc") and can use the default domain
name assigned by their ISP (a real example is comcast.net; an
example for the I-D would of course be example.net).  Thus, 
ignoring NAT and RFC1918 addresses and everything for just a 
moment, and thinking about some IPv6 nirvana, a RTP endpoint
that uses a FQDN such as "home-pc.comcast.net" is *also* 
not going to have a unique CNAME.

So, please add FQDN collisions as another example in the 
Introduction.


* Section 3, "Choice of RTCP CNAME in Private Networks"

I don't like the title.  The introduction already dissuaded readers from
thinking this was a problem solely with RFC1918 addresses.


* Section 3,

   It is a difficult task for a host to determine whether it resides
   behind a NAT without the help of an external mechanism such as STUN
   [RFC5389].  

Actually, it can be impossible, because "I am behind a NAT" is not
a binary answer.  Rather, it depends on the path to the RTP peer
if I am "behind a NAT".  For example, when communicating between
two hosts in my house.

I would rather that sentence above be rewritten to say:

  It is difficult, and in some cases impossible, for a host to
  determine if there is a NAT between itself and its RTP peer.

and don't mention STUN at all.  



* Section 3 recommends against IP address.  It should say "IPv4" (rather than
"IP").


* Section 3, which IPv6 address should be used?  Maybe recommend using the
IPv6 privacy address [RFC4941], if present?


* Section 3, I found the word "order" in the following paragraph confusing:

   This memo does not mandate a specific order in which these methods
   should be practiced.  A specific order would be only needed if an RTP
   endpoint was expected to be comprised of multiple programs that
   independently needed to choose the same CNAME.  Since this is not a
   common implementation technique, a specific order is not needed.

How about saying, instead, "Each of the techniques is equally effective, 
and an implementation can choose which to use."

As for the need to pick a single CNAME if there are disconnected bits and
pieces of RTP; do we need to mention that?  Seems like an implementation
detail.  If you want to mention it, I suggest doing so in a separate paragraph
and/or section.


* Section 4, Security Considerations:

   The security considerations of [RFC3550] apply to this document as
   well.

and RFC3550's Security Considerations says only this about CNAMEs:

   Within RTCP, the
   CNAME and NAME information may be used to impersonate another
   participant.  

The recommendations in draft-begen-avt-rtp-cnames create some additional
security exposure, specifically the ability for an on-path sniffer to examine
RTCP messages and get the unique identifier of the RTP endpoint (IPv6 address,
MAC address, or UUID) and correlate RTP traffic to/from different endpoints.
As SRTP (RFC3711) recommends that SRTCP be only authenticated (not encrypted),
the normal SRTP operation will continue to expose that same information. 

Here is a suggestion to get that started:

  Following the recommendations of this memo provides 
  additional information in RTCP which is useful for 
  traffic analysis.  The recommended default encryption
  mode for SRTCP [RFC3711] uses authentication (without
  encryption), so if traffic analysis is a concern the
  SRTCP payloads should be encrypted.


* Question: Are there any ideas on the table for generating a unique
identifier that wouldn't be useful for traffic analysis?  That is, a unique
identifier that is generated on each call?  For example, a BASE64-encoded
SHA1-HMAC of one of the three pieces of information currently suggested in the
memo (IPv6 address, unique FQDN, UUID), where the 'secret' is changed for
every new RTP session?  This seems it could eliminate traffic analysis
concerns.

-d