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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 5 May 2010 07:34:08 -0700

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.

-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 10:31 AM
To: Ali C. Begen (abegen)
Cc: [email-masked]
Subject: New Version Notification for draft-begen-avt-rtp-cnames-01 

A new version of I-D, draft-begen-avt-rtp-cnames-01.txt has been successfully submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-begen-avt-rtp-cnames
Revision:	 01
Title:		 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
Creation_date:	 2010-05-05
WG ID:		 Independent Submission
Number_of_pages: 6

Abstract:
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
persistent transport-level identifier for an RTP endpoint.  While the
Synchronization Source (SSRC) identifier of an RTP endpoint may
change if a collision is detected, or when the RTP application is
restarted, the CNAME is meant to stay unchanged, so that RTP
endpoints can be uniquely identified and associated with their RTP
media streams.  For proper functionality, CNAMEs should be unique
within the participants of an RTP session.  However, the
recommendations for choice of the RTCP CNAME provided in RFC 3550 are
insufficient to achieve this uniqueness.  This memo updates the
guidelines in RFC 3550 to allow endpoints to choose unique CNAMEs.

The IETF Secretariat.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 18 May 2010 17:08:19 -0700

> 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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 May 2010 20:39:23 -0700

Hi Dan,

Thanks for the detailed review.

> From: Dan Wing (dwing)
> Sent: Tuesday, May 18, 2010 8:08 PM
> To: Ali C. Begen (abegen); [email-masked]
> Cc: [email-masked]
> Subject: RE: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01
> 

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

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

>    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?
 
> reasons the RFC Editor will remove that prior to publication.

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

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

Good suggestion.
 
> thinking this was a problem solely with RFC1918 addresses.

Is "Choice of RTCP CNAME" good?
 
> and don't mention STUN at all.

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

Agreed.
  
> IPv6 privacy address [RFC4941], if present?

Sure, but is there a problem with others?
  
> and an implementation can choose which to use."

Sounds good to me.
 
> detail.  If you want to mention it, I suggest doing so in a separate paragraph

We thought of this and I don't think we need to mention this.
 
> the normal SRTP operation will continue to expose that same information.

Correct.
 
>   SRTCP payloads should be encrypted.

We should add this.
 
> every new RTP session?  This seems it could eliminate traffic analysis

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 18 May 2010 21:06:48 -0700

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Tuesday, May 18, 2010 8:39 PM
> To: Dan Wing (dwing); [email-masked]
> #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.

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

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

> Is "Choice of RTCP CNAME" good?

Yep.  Or "Choosing RTCP CNAME"

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

No problem with the others.

> > detail.  If you want to mention it, I suggest doing so in a 
> > separate paragraph and/or section.
> 
> 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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 May 2010 21:32:24 -0700

> Proposed Standard) does not explicitly discourage using FQDN.

OK, we will make it more explicit.
 
> "B".  Millions of dollars can be made (or lost).

:) we will be happy to add the text you suggest for this.
 
> in the Security Considerations section.

Fair enough.
 
> IPv4 address on the host.

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

---

From: Roni Even <[email-masked]>
Date: Thu, 20 May 2010 10:05:46 +0300

Hi,

> every new RTP session?  This seems it could eliminate traffic analysis

RFC 3550 says that one of the usage of RTCP is for monitoring and "To
facilitate third-party monitoring, the CNAME SHOULD be suitable for either a
program or a person to locate the source." 

Other comments

1. For the UUID I assume the proposal is to use the string representation of
the UUID maybe as a URN. 

2. As for the structure of CNAME, section 6.5.1 of RFC 3550 has the cname
composed of user and domain name. it also says that
"The user name SHOULD be in a form that a program such as "finger" or "talk"
could use, i.e., it typically is the login name rather than the personal
name.  The host name is not necessarily identical to the one in the
participant's electronic mail address. "
Maybe this document should recommend how to create a unique host part of the
CNAME and not the whole CNAME.

Regards
Roni Even

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 20 May 2010 06:03:03 -0700

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, May 20, 2010 3:06 AM
> To: Dan Wing (dwing); Ali C. Begen (abegen); [email-masked]
> Subject: RE: [AVT] FW: New Version Notification fordraft-begen-avt-rtp-cnames-01
> 
> Hi,
> 
> >

What does "locate the source" imply?

We also saw this text the other day and actually I wanna understand this a bit more. The concern Dan is raising is valid in my opinion. The current 3 methods we have in the draft are sticky. If one uses the same CNAME in totally irrelevant RTP sessions, a monitoring agent can still infer that those users are the same person. For several reasons, this is not a good thing. That's why I am inclined to include Dan's suggestion (e.g., hashing) as the 4th method for those who want to take that option. We will also mention this risk in the sec. section.
 
> 1. For the UUID I assume the proposal is to use the string representation of

This is the second issue and let's have WG's input on this. Do we need ascii CNAMEs or not? Does it everything need to be encoded in base64?
 
> CNAME and not the whole CNAME.

If the host part is unique, why would we still need user@host?
 
Thanks for bringing these up. Let's reach an agreement and we will submit a revision accordingly.

-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 May 2010 23:09:32 +0100

On 20 May 2010, at 14:03, Ali C. Begen (abegen) wrote:
>>> * 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.
>>
>> RFC 3550 says that one of the usage of RTCP is for monitoring and  
>> "To facilitate third-party monitoring, the CNAME SHOULD be suitable  
>> for either a program or a person to locate the source."
>
> We also saw this text the other day and actually I wanna understand  
> this a bit more. The concern Dan is raising is valid in my opinion.  
> The current 3 methods we have in the draft are sticky. If one uses  
> the same CNAME in totally irrelevant RTP sessions, a monitoring  
> agent can still infer that those users are the same person. For  
> several reasons, this is not a good thing. That's why I am inclined  
> to include Dan's suggestion (e.g., hashing) as the 4th method for  
> those who want to take that option. We will also mention this risk  
> in the sec. section.

Being able to infer that disparate RTP sessions involve the same end  
point can be useful for network management purposes. I understand the  
desire for opaque, per-session, unique identifiers as an option, but  
there are legitimate use-cases for persistent, identifiable, CNAMES.

>> Other comments
>>
>> 1. For the UUID I assume the proposal is to use the string  
>> representation of the UUID maybe as a URN.
>
> This is the second issue and let's have WG's input on this. Do we  
> need ascii CNAMEs or not? Does it everything need to be encoded in  
> base64?

It needs to be UTF-8 format text [RFC 3550, top of page 46].

>> 2. As for the structure of CNAME, section 6.5.1 of RFC 3550 has the  
>> cname composed of user and domain name. it also says that "The user  
>> name SHOULD be in a form that a program such as "finger" or "talk"  
>> could use, i.e., it typically is the login name rather than the  
>> personal name.  The host name is not necessarily identical to the  
>> one in the participant's electronic mail address. " Maybe this  
>> document should recommend how to create a unique host part of the  

Multi-user hosts still exist.

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 May 2010 16:03:04 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roni Even
> Sent: Thursday, May 20, 2010 12:06 AM
> To: 'Dan Wing'; 'Ali C. Begen (abegen)'; [email-masked]
> Subject: Re: [AVT] FW: New Version Notificationfor 
> draft-begen-avt-rtp-cnames-01
> 
> Hi,
> 
> > 
> > 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
> facilitate third-party monitoring, the CNAME SHOULD be 
> suitable for either a program or a person to locate the source." 

Two points about that:

  o  This requirement is at odds with the need, in some RTP
     applicatoins, to thwart traffic analysis.  
  o  I find it VERY confusing to need to read both RFC3550's
     section on CNAMEs and draft-begen-avt-rtp-cnames and reach 
     some create my own Vulcan mind meld.  This is unnecessarily
     confusing.  It would be far cleaner to have one canonical
     place to read about CNAMEs.  

     So, can we pull all of the requirements and justification
     text for those requirements into draft-begen-avt-rtp-cnames,
     and have that supercede RFC3550's suggestions and
     requirements about CNAMEs?

> representation of the UUID maybe as a URN. 

The CNAME doesn't need the 9 characters of "urn:uuid:", though.

> CNAME and not the whole CNAME.

I don't know how to do that, but maybe someone else does.

-d

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 20 May 2010 16:20:28 -0700

>      applicatoins, to thwart traffic analysis.

So, our suggestion is to have multiple methods to come up with a CNAME, and some of them will be sticky across sessions and will not be opaque whereas others won't be sticky but will be opaque. Application should be able to choose whatever satisfies their needs. Each will have a con vs pro.

>      requirements about CNAMEs?

I agree that this will be a clean solution. We can add text around this.

Correct.
 
> I don't know how to do that, but maybe someone else does.

So, the methods we will have will be used to create the "host" part of the CNAME, and when combined with the "user" part, things will work out fine.

-acbegen

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 24 May 2010 22:02:43 -0400

Hi Ali,

In the context of synchronizing multiple media flows (multiple audio
streams or audio+video) from a unique source - cnames can be useful to
determine which media streams are from a common node and need to be
aligned in time for playback. The use of a session specific cname
would break this usage (or we would require e.g the audio and video
subsystems to agree on a session specific cname - which is an
implementation constraint I would prefer to avoid).

Is it worth mentioning that session specific cnames are not suitable
in cases such as this?

Peter Musgrave

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 24 May 2010 19:09:19 -0700

Hi Peter,

Indeed. Could you have a look at today's revision? It discusses when per-session or persistent cnames should be used.

http://tools.ietf.org/html/draft-begen-avt-rtp-cnames-02

-acbegen

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Monday, May 24, 2010 10:03 PM
> Cc: [email-masked]
> Subject: Re: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-01
> 
> Hi Ali,
>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 25 May 2010 07:10:15 -0400

Hi Ali,

I suppose it is covered by the statement in 4.1
"To provide a binding across multiple media tools
   used by one participant in a set of related RTP sessions, the CNAME
   SHOULD be fixed for that participant. "

But I would also suggest that a bullet point in the guidelines might
help make this more explicit. Something like:
"An endpoint which is emitting multiple related streams which require
synchronization at the receiver SHOULD use a persistent CNAME . "

Peter Musgrave

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 25 May 2010 07:01:58 -0700

Sure. But, let's wait until WG approval and in the next revision, we can put that text in.

Thanks for the review.
-acbegen

> Sent: Tuesday, May 25, 2010 7:10 AM
> >> > A new version of I-D, draft-begen-avt-rtp-cnames-01.txt has been successfully submitted by Ali
> Begen
> >> and posted to the IETF repository.
> >> >