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

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

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

OK, we will make it more explicit.
 
> > > 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 will be happy to add the text you suggest for this.
 
> > >    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.

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

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

Yes, we should get this into the next revision, which we should do in the next few days.

Thanks, acbegen.
 
> -d