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

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Dan,

Thanks for the detailed review.

> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Tuesday, May 18, 2010 8:08 PM
> To: Ali C. Begen (abegen); [e-mail]
> Cc: [e-mail]
> Subject: RE: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01
> 
> > 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.

Thanks.
 
> 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 is not suggesting to use 'home.comcast.net', is it? It is suggesting to use the mac address for the host part.

> 2. The three current recommendations (IPv6 address, FQDN,
>    UUID) all expose information about the RTP host, which
>    provides additional information for traffic analysis.

These are unique identifiers, and they are supposed to be. But, how would you know who has a given specific UIUD for example?

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

Do you think this is a real concern? And even if yes, the IPv6 address of an endpoint can always be recorded next to the RTCP reports it sends (even if we use something else for the CNAME) so the risk is still there, no?
 
> 
> Detail:
> 
> 
> * Abstract should remove citations to RFC3550, because for style
> reasons the RFC Editor will remove that prior to publication.

We can deal with that at that time.
 
> 
> * Section 1,
> 
> Change reference from [I-D.miles-behave-l2nat] to RFC3022.

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

Good suggestion.
 
> 
> * 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.

Is "Choice of RTCP CNAME" good?
 
> 
> * 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.

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

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

Sure, but is there a problem with others?
  
> * 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."

Sounds good to me.
 
> 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.

We thought of this and I don't think we need to mention this.
 
> 
> * 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.

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

We should add this.
 
> 
> * 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.

Personally, I did not consider the need for this one but looks like you want to have this option. And I don't see why we should not have it.

-acbegen
 
> -d