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

On 20 May 2010, at 14:03, Ali C. Begen (abegen) wrote:
>> -----Original Message-----
>> From: Roni Even [mailto:Even.roni@huawei.com]
>> Sent: Thursday, May 20, 2010 3:06 AM
>> To: Dan Wing (dwing); Ali C. Begen (abegen); avt@ietf.org
>> Cc: draft-begen-avt-rtp-cnames@tools.ietf.org
>> Subject: RE: [AVT] FW: New Version Notification fordraft-begen-avt- 
>> rtp-cnames-01
>>
>> Hi,
>>
>>>
>>> * 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."
>
> 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.

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  
>> CNAME and not the whole CNAME.
>
> If the host part is unique, why would we still need user@host?

Multi-user hosts still exist.

> Thanks for bringing these up. Let's reach an agreement and we will  
> submit a revision accordingly.
>
> -acbegen
>
>> Regards
>> Roni Even
>>
>>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

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