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

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

 

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

The text in RFC3550, a full standard, says 'a host can use 
its FQDN'.  Your document (which I expect will only be a 
Proposed Standard) does not explicitly discourage using FQDN.

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

I don't know who has the red Ferrari in my neighborhood, but
I notice when he comes and goes.  And I notice when he has
a passenger.  

In telephony, if an endpoint is using UUID in its RTCP messages,
I can learn its UUID by just calling it and having someone 
answer.  Or waiting for it to call me (by phishing the human
with an email message, for example).  Now, if I manage to
trace any traffic (even if it is encrypted with SRTP) I can
determine who that person is calling (by doing a simlar attack
on the destination).  

It is valuable to know, for example, that the CEO and CFO of
Company "A" are talking a lot to the CEO and CFO of Company
"B".  Millions of dollars can be made (or lost).

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

That's what IPv6 Privacy Addresses (RFC4941) are intended to
thwart.  (We can get into a long discussion about their viability,
how difficult they are to trigger from an application, how 
application programmers who have never needed to consider 
such things don't know when/how/why to bother getting a new
IPv6 address.)

But the CNAMEs being encouraged in this draft do expose hosts
to expose host-specific identifiers that have not been encouraged
to be disclosed previously.  That's why it seems prudent to discuss
in the Security Considerations section.

Which brings up another minor thing:  the draft should mention 
that a host with any sort of IPv6 address can use that address as
its CNAME.  That is, the RTP session does not to be with an
IPv4 address on the host.

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

Yep.  Or "Choosing RTCP CNAME"

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

No problem with the 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.

Depends on the application, I suppose.  Telephony is different
from streaming IPTV of today's news.  But, I suppose there
are some interesting/controversial news programs.  I can throw
some text your way when you need it.

-d