Subject: RE: [Sip] GRUU and Anonymity

From: "Andrew Allen" <[email-masked]>
Date: Tue, 12 Sep 2006 13:14:41 -0400

Is it any worse than the situation today where the contact address is an
IP Address where the netid part reveals the domain the user is in and if
there is any knowledge of that network topology and the subnet ids even
potentially the geographic location of the caller?

Certainly IP addresses can be correlated to not only reveal the identity
of the user but also potentially something about their location.

The question as I see it for the progress of GRUU is does GRUU have
bigger annonymity concerns than RFC 3261? I think solving all the
potential anonymity issues with SIP and IP is well beyond the scope of
the GRUU work.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Tuesday, September 12, 2006 12:42 PM
To: Jonathan Rosenberg; IETF SIP List
Subject: RE: [Sip] GRUU and Anonymity

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, September 11, 2006 2:18 PM
> To: IETF SIP List
> Subject: [Sip] GRUU and Anonymity
> Pseudonymity
> ------------
> 
> One feature that can be provided is pseudonymity. The idea is 
> that the registrar, when it first creates a GRUU for an 
> AOR/insteance-ID pair, actually would create two. One is the 
> 'normal' one (generally constructed by adding an opaque 
> parameter to the AOR), and another is a pseudonym for the GRUU:
> 
> sip:[email-masked];gruu;opaque=9asd8bvghasd8
> sip:[email-masked];gruu

I'm not sure that an annonymity feature that obfuscate the user name but
not
the domain name is good enough.

It may be good enough when the provider is Big Ma Bell, but not
otherwise.

If the people that are susceptible to call me in a specific domain is
small
enough, I could probably guess who the annonymous entity is.

It reminds me of a "confidential feedback" I submitted for my boss's
performance. 
I discovered later that my feedback (submitted to my boss) didn't have
my name, 
but it had my location (I was the only employee working for him located
the Bay 
Area).

In other words, I don't think pseudonymity is good enough.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Sep 2006 12:38:08 -0500

> Is it any worse than the situation today where the contact 
> address is an IP Address where the netid part reveals the 
> domain the user is in and if there is any knowledge of that 
> network topology and the subnet ids even potentially the 
> geographic location of the caller?
>
> Certainly IP addresses can be correlated to not only reveal 
> the identity of the user but also potentially something about 
> their location.
> 
> The question as I see it for the progress of GRUU is does 
> GRUU have bigger annonymity concerns than RFC 3261? I think 
> solving all the potential anonymity issues with SIP and IP is 
> well beyond the scope of the GRUU work.

I guess what I'm trying to say is that if we need annonymity,
it needs to be full annonymity. I don't see a value in "pseudonymity".

So, I agree with you. When we DO solve annonymity, it needs to
work with GRUU and everthing else. In the meanwhile, I don't think GRUU 
is special and requires immediately a solution to annonymity.

---

From: Dean Willis <[email-masked]>
Date: Tue, 12 Sep 2006 14:01:48 -0500

I'll try and summarize. Please correct me if I'm wrong:

1) GRUU is required for successful call transfer whenever a target is  
behind a NAT relative to either the transferor or transferee or both.

2) Call transfer functions are a requirement for the operational  
environment. Therefore, all calls originating from a NATed node must  
be made using a GRUU.

3) Call transfers made using GRUU as it is currently specified cannot  
be made legally on a service operated in a Euro-style privacy regime  
when the identity of the transferee and target must be protected.  
Note that signaling of the privacy requirements of a transfer target  
is, AFAIK, out of the scope of anything we've done so far.

4) To expand on #3, call transfers using GRUU as currently specified  
can never be made without revealing the identity of the transferee to  
the target

5) Further, unless an aliasing mechanism outside the scope of GRUU is  
available, the AOR of the transfer target is always revealed to the  
transferee, so this subaspect may not be a GRUU problem. Perhaps we  
should concentrate on accidental revelation of the transferee to the  
target?

Question: Does this conundrum mean we should not advance GRUU until  
we figure out something that might work?

Possible Solution: Find a way for the transferor to construct a  
"GRUU" (or at least a suitable alias)  for each of the transferee and  
the target to use for the duration of the transfer dialog.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Sep 2006 15:06:06 -0400

inline.

> it needs to be full annonymity. I don't see a value in "pseudonymity".

Why? Certainly there are privacy applications (such as calling the 
police to anonymously report an incident) where pseudonymity is probably 
sufficient.

> is special and requires immediately a solution to annonymity.

You may have to wait a while. A LONG while.

In:
http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-privacy-00.txt

I took a stab at some thoughts on true anonymity. Its nearly impossible 
to do. Even anonymizers aren't sufficient. It is possible that the only 
solutions require crazy BGP hacks like I describe else a global, massive 
p2p mesh.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Sep 2006 17:14:35 -0500

> > I guess what I'm trying to say is that if we need 
> annonymity, it needs 
> > to be full annonymity. I don't see a value in "pseudonymity".
> 
> Why? Certainly there are privacy applications (such as 
> calling the police to anonymously report an incident) where 
> pseudonymity is probably sufficient.

I don't believe that a system that "works sometimes" is useful.

To take the "police" example, if my domain is enough for the police
to track me down (or to a subset small enought that I'm not annonymous),
then, well, it's not annonymous anymore. Maybe I have my own 
domain, or you can track that there was only one user with that
particular
domain who might have made that call. Maybe I'm reporting something to 
police, and it shows my employer's domain. Suddently, my employer is
embroiled.

The end-user will not have confidence that's it's really annonymous
because
it's not always annonymous.

Maybe I'm missing something that is special to GRUU. I'm reading Dean's
summary,
but I'm not terribly convinced that the claims are true.

I'm highly sceptical that somehow that we (IETF) need to provide a
solution to
the GRUU anonimity problem.

But I could be missising something.

> > 
> > So, I agree with you. When we DO solve annonymity, it needs to work 
> > with GRUU and everthing else. In the meanwhile, I don't 
> think GRUU is 
> > special and requires immediately a solution to annonymity.
> > 
> 
> I took a stab at some thoughts on true anonymity. Its nearly 
> impossible to do. Even anonymizers aren't sufficient. It is 
> possible that the only solutions require crazy BGP hacks like 
> I describe else a global, massive p2p mesh.

Yeah, I have read this, and I do agree that it's MUCH bigger than just
GRUU.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Sep 2006 17:14:35 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Sep 2006 11:01:23 -0400

Francois,

You are stating a need for a level of anonymity that Jonathan says is 
almost impossible to achieve. Something has to give here.

I think the world already deals with differing levels of anonymity. 
Callerid blocking in the pstn only blocks your identity from the 
receiving party, while the whole intervening network has access to your 
identity. And its often negated when making emergency calls. So if I 
have a *serious* need to remain anonymous, invoking callerid blocking 
already isn't enough. Instead I am forced to seek out an anonymous phone 
from which to originate the call, or use some very complex mechanisms 
that are not widely available. And when seeking out an anonymous phone 
from which to make my call, I will again typically be limited in the 
scope of anonymity. For instance if I cannot travel to an arbitrary 
location to make my call then the location I make the call from can be 
used to guess where I am.

One part of jonathan's old proposal escapes me: why is it important to 
support sip identity when making an anonymous call? Does it really 
matter to the recipient that the caller is really the particular 
anonymous caller it claims to be rather than some other unknown caller?

I am inclined to think that an independent anonymizer service (b2bua 
based) running in its own domain, would be sufficient for all *my* worst 
case anonymity needs, and that anonymity within the domain of my own 
provider would be sufficient for those cases when I just want to "block 
callerid". YMMV.

It is clear that the more complete forms of anonymity are relatively 
expensive to provide, to the point that it probably wouldn't be good to 
make that the default. If it became an extra cost service then it would 
be self funding. Then people will settle for less when the need doesn't 
justify the cost.

	Paul

---

From: [email-masked]
Date: Thu, 14 Sep 2006 23:04:37 -0400

From: Dean Willis <[email-masked]>

I believe strongly that the answer is "No", that we can and should
advance the GRUU I-D now, as doing so will be valuable immediately,
and no one has even claimed that doing so will interfere with a
suitably prvacy-enhanced contact URI in the future.

In regard to my proposed scheme for generating TRUUs, I'm not
surprised that it has weaknesses.  The point is that if I can solve a
significant fraction of the TRUU problem with literally a few minutes'
thought, it should be possible for someone versed in crypto
engineering to devise a real solution which we can advance as a
successor/extension of the GRUU I-D.

"This is not the problem we're solving today..."

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2006 11:05:52 -0400

Back to the original question, I feel strongly that it is not in the 
scope of gruu to solve THIS level of anonymity. I agree its worth doing 
but not in the gruu spec.

I think its fair to ask whether or not the gruu spec should be specified 
in a way that it provides privacy services that are no worse than what 
what is defined in RFC 3261. And more specifically, if a user does not 
explicitly invoke a privacy service (through the privacy header or other 
mechanisms), does GRUU make things worse, and can we specify it in a way 
that doesnt make it worse?

Clearly one could use gruu as defined today, and if you wanted header 
anonymity, you can use the 'header' privacy service and that would work 
and provide you a level of anonymity on par with today without gruu.

It is certainly the case that, in RFC 3261, the SIP invite, without 
treatment by some external b2bua service, will reveal the domain of the 
originator, through the IP addresses in the SDP alone. Even with 
treatment by ANY of the privacy services provided in RFC3323, the domain 
of the originator is revealed. Consequently I don't think we need to 
hold up gruu on this feature.

With RFC 3261 today, if the user didn't use an anonymization service, 
they could include a From header field of [email-masked]. 
They could rotate the value of 'username' from call to call, though the 
IP addresses in various places would probably correlate across calls, 
since most users have fairly static IPs.

Thus, I would asser that SIP today, without usage of an anonymity 
service, provides nothing more than pseudonymity (with the IP address as 
your pseudonym). This would tell me that it would be acceptable to 
produce a gruu spec which provides nothing more than pseudonymity. Since 
IP addresses can change over longer periods of time (reboot cycles), I'd 
also propose that gruu support slowly changing pseudonyms - namely, 
different on each registration. This is fairly easy to add to gruu.

With this proposal, I would assert that GRUU provides privacy services 
equivalent to the level of anonymity afforded by RFC 3261, and that 
better anonymity can be provided by the mechanisms in rfc3323, which get 
no better or worse with the addition of gruu. I think this is the metric 
we need to meet, and NO BETTER.

Does this get us out of this conundrum?

-Jonathan R.

Paul Kyzivat wrote:

>>> police to anonymously report an incident) where pseudonymity is 
>>> probably sufficient.
>>
>>
>> then, well, it's not annonymous anymore. Maybe I have my own domain, 
>> or you can track that there was only one user with that
>> particular
>>> http://www.jdrosen.net/papers/draft-rosenberg-sip-identity-pri
>>
>> vacy-00.txt
>>
>>> impossible to do. Even anonymizers aren't sufficient. It is possible 
>>> that the only solutions require crazy BGP hacks like I describe else 
>>> a global, massive p2p mesh.
>>
>>

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 15 Sep 2006 19:21:54 +0300

Jonathan Rosenberg writes:

 > originator, through the IP addresses in the SDP alone. 

many ISPs (and also cellular operators officing GPRS/EDGE/UMTS services)
provide a dynamic IP address that changes for each connection to
the internet, for example, this was the last one that i got:

eukaryote41.gprs.dnafinland.fi

in those cases, SDP does not reveal my domain, only the ISP that i was
connected to the network.  it cannot be worse that that when my SIP UA
uses "pseudonymity" gruu , i.e., it must not reveal my real domain
tutpro.com.

-- juha

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 17 Sep 2006 22:28:15 -0700

That sounds like a good way out of the conundrum. I think that if we  
make try to find a solution that is plausible to implement and deploy  
and is no worse that what we currently have deployed, then that is  
the minimal level to meet at this point.

I think it is worth nothing that anonymous actions of any kind are  
only as good as the pool they can hide in - if know my IP phone is on  
a network with only one other phone, well nothing helps. The problem  
we are trying to solve here is one that allows this to be useful for  
a large number of deployments and uses cases but clearly it won't  
work for everything.  For a large domain, this will offer reasonable  
security in many of the use cases - in other cases such as you only  
know one person in Finland and the IP address for the RTP is in  
Finland, well it won't help much.  In cases of small domains, I'm  
sure that a larger domain could offer a virtual forward to a GRUU  
that provided something much stronger. However, even with all these  
limitations, this level of anonymization would allow many  
communication providers to meet the needs of their users.

On Sep 15, 2006, at 8:05 AM, Jonathan Rosenberg wrote:

> Back to the original question, I feel strongly that it is not in  
> the scope of gruu to solve THIS level of anonymity. I agree its  
> worth doing but not in the gruu spec.
>
> I think its fair to ask whether or not the gruu spec should be  
> specified in a way that it provides privacy services that are no  
> worse than what what is defined in RFC 3261. And more specifically,  
> if a user does not explicitly invoke a privacy service (through the  
> privacy header or other mechanisms), does GRUU make things worse,  
> and can we specify it in a way that doesnt make it worse?
>
> Clearly one could use gruu as defined today, and if you wanted  
> header anonymity, you can use the 'header' privacy service and that  
> would work and provide you a level of anonymity on par with today  
> without gruu.
>
> treatment by some external b2bua service, will reveal the domain of  
> the originator, through the IP addresses in the SDP alone. Even  
> with treatment by ANY of the privacy services provided in RFC3323,  
> the domain of the originator is revealed. Consequently I don't  
> think we need to hold up gruu on this feature.
>
> With RFC 3261 today, if the user didn't use an anonymization  
> service, they could include a From header field of  
> [email-masked]. They could rotate the value of  
> 'username' from call to call, though the IP addresses in various  
> places would probably correlate across calls, since most users have  
> fairly static IPs.
>
> service, provides nothing more than pseudonymity (with the IP  
> address as your pseudonym). This would tell me that it would be  
> acceptable to produce a gruu spec which provides nothing more than  
> pseudonymity. Since IP addresses can change over longer periods of  
> time (reboot cycles), I'd also propose that gruu support slowly  
> changing pseudonyms - namely, different on each registration. This  
> is fairly easy to add to gruu.
>
> With this proposal, I would assert that GRUU provides privacy  
> services equivalent to the level of anonymity afforded by RFC 3261,  
> and that better anonymity can be provided by the mechanisms in  
> rfc3323, which get no better or worse with the addition of gruu. I  
> think this is the metric we need to meet, and NO BETTER.
>
>> You are stating a need for a level of anonymity that Jonathan says  
>> is almost impossible to achieve. Something has to give here.
>> I think the world already deals with differing levels of  
>> anonymity. Callerid blocking in the pstn only blocks your identity  
>> from the receiving party, while the whole intervening network has  
>> access to your identity. And its often negated when making  
>> emergency calls. So if I have a *serious* need to remain  
>> anonymous, invoking callerid blocking already isn't enough.  
>> Instead I am forced to seek out an anonymous phone from which to  
>> originate the call, or use some very complex mechanisms that are  
>> not widely available. And when seeking out an anonymous phone from  
>> which to make my call, I will again typically be limited in the  
>> scope of anonymity. For instance if I cannot travel to an  
>> arbitrary location to make my call then the location I make the  
>> call from can be used to guess where I am.
>> One part of jonathan's old proposal escapes me: why is it  
>> important to support sip identity when making an anonymous call?  
>> Does it really matter to the recipient that the caller is really  
>> the particular anonymous caller it claims to be rather than some  
>> other unknown caller?
>> I am inclined to think that an independent anonymizer service  
>> (b2bua based) running in its own domain, would be sufficient for  
>> all *my* worst case anonymity needs, and that anonymity within the  
>> domain of my own provider would be sufficient for those cases when  
>> I just want to "block callerid". YMMV.
>> It is clear that the more complete forms of anonymity are  
>> relatively expensive to provide, to the point that it probably  
>> wouldn't be good to make that the default. If it became an extra  
>> cost service then it would be self funding. Then people will  
>> settle for less when the need doesn't justify the cost.
>>     Paul
>> Francois Audet wrote:
>>>
>>>> Why? Certainly there are privacy applications (such as calling  
>>>> the police to anonymously report an incident) where pseudonymity  
>>>> is probably sufficient.
>>>
>>>
>>> domain who might have made that call. Maybe I'm reporting  
>>> something to police, and it shows my employer's domain.  
>>> Suddently, my employer is
>>> embroiled.
>>>
>>>>> work with GRUU and everthing else. In the meanwhile, I don't
>>>>
>>>> think GRUU is
>>>>
>>>> possible that the only solutions require crazy BGP hacks like I  
>>>> describe else a global, massive p2p mesh.
>>>
>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2006 09:48:04 -0400

So what is your view on the specific mechanism I was proposing to meet 
this objective? Namely, that the registrar would provide you with a 
'regular' gruu and a pseudononymous one, and the latter changes every 
time you create a new registration (not refresh, a new one entirely).

-Jonathan R.

Cullen Jennings wrote:

> and is no worse that what we currently have deployed, then that is  the 
> minimal level to meet at this point.
> 
> I think it is worth nothing that anonymous actions of any kind are  only 
> as good as the pool they can hide in - if know my IP phone is on  a 
> network with only one other phone, well nothing helps. The problem  we 
> are trying to solve here is one that allows this to be useful for  a 
> large number of deployments and uses cases but clearly it won't  work 
> for everything.  For a large domain, this will offer reasonable  
> Finland, well it won't help much.  In cases of small domains, I'm  sure 
> that a larger domain could offer a virtual forward to a GRUU  that 
> provided something much stronger. However, even with all these  
> limitations, this level of anonymization would allow many  communication 
> providers to meet the needs of their users.
> 
> 
>> scope of gruu to solve THIS level of anonymity. I agree its  worth 
>> doing but not in the gruu spec.
>>
>> privacy header or other mechanisms), does GRUU make things worse,  and 
>> can we specify it in a way that doesnt make it worse?
>>
>> anonymity, you can use the 'header' privacy service and that  would 
>> work and provide you a level of anonymity on par with today  without 
>> gruu.
>>
>> the originator, through the IP addresses in the SDP alone. Even  with 
>> treatment by ANY of the privacy services provided in RFC3323,  the 
>> domain of the originator is revealed. Consequently I don't  think we 
>> need to hold up gruu on this feature.
>>
>> They could rotate the value of  'username' from call to call, though 
>> the IP addresses in various  places would probably correlate across 
>> calls, since most users have  fairly static IPs.
>>
>> service, provides nothing more than pseudonymity (with the IP  address 
>> as your pseudonym). This would tell me that it would be  acceptable to 
>> produce a gruu spec which provides nothing more than  pseudonymity. 
>> Since IP addresses can change over longer periods of  time (reboot 
>> cycles), I'd also propose that gruu support slowly  changing 
>> pseudonyms - namely, different on each registration. This  is fairly 
>> easy to add to gruu.
>>
>>> receiving party, while the whole intervening network has  access to 
>>> your identity. And its often negated when making  emergency calls. So 
>>> if I have a *serious* need to remain  anonymous, invoking callerid 
>>> blocking already isn't enough.  Instead I am forced to seek out an 
>>> anonymous phone from which to  originate the call, or use some very 
>>> complex mechanisms that are  not widely available. And when seeking 
>>> out an anonymous phone from  which to make my call, I will again 
>>> typically be limited in the  scope of anonymity. For instance if I 
>>> cannot travel to an  arbitrary location to make my call then the 
>>> location I make the  call from can be used to guess where I am.
>>> One part of jonathan's old proposal escapes me: why is it  important 
>>> to support sip identity when making an anonymous call?  Does it 
>>> really matter to the recipient that the caller is really  the 
>>> particular anonymous caller it claims to be rather than some  other 
>>> unknown caller?
>>> based) running in its own domain, would be sufficient for  all *my* 
>>> worst case anonymity needs, and that anonymity within the  domain of 
>>> my own provider would be sufficient for those cases when  I just want 
>>> to "block callerid". YMMV.
>>> expensive to provide, to the point that it probably  wouldn't be good 
>>> to make that the default. If it became an extra  cost service then it 
>>> would be self funding. Then people will  settle for less when the 
>>> need doesn't justify the cost.
>>>     Paul
>>> Francois Audet wrote:
>>>
>>>>
>>>> domain who might have made that call. Maybe I'm reporting  something 
>>>> to police, and it shows my employer's domain.  Suddently, my 
>>>> employer is
>>>> embroiled.
>>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2006 09:50:44 -0400

The SDP doesn't reveal your domain, but the topmost via certainly will. 
If you combine that with the fact that your own IP is static during your 
connection to the Internet, you end up with a level of anonymity that is 
functionally equal to what I'm proposing.

I'm not saying that we don't need anonymity where you can't even 
determine the domain of the originator; I'm merely saying that SIP 
itself doesn't provide this (and indeed neither does rfc3323 really), so 
we do not need to strive to meet this goal for gruu to progress.

Thanks,
Jonathan R.

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 18 Sep 2006 19:22:21 +0300

> The SDP doesn't reveal your domain, but the topmost via certainly

i don't get it.  i just made a call from my laptop that gets dynamic
address from my isp.  here is how topmost via and ip part of sdp look
like:

Via: SIP/2.0/UDP 62.78.104.204:6060;rport;branch=z9hG4bKfusbdfzf
...
c=IN IP4 62.78.104.204

based on that information, you cannot tell from which domain my call
came from.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 18 Sep 2006 12:25:55 -0500

> based on that information, you cannot tell from which domain my call

Accorfing to traceroute, it came from:

allozyme204.gprs.dnafinland.fi

Just guessing, I'd say you were in Finland or using a Finnish VPN  
when making the call . . . Further, I'd guess you were connected over  
a mobile phone (GPRS) network.  Hmm, "dnafinland.fi" has a web page.  
They look like a mobile services vendor. I bet that if I weren't  
illiterate I could get more useful info from the web page, and maybe  
even launch a pretexting attack and get some billing records.

Does me knowing this violate your privacy? Maybe not, but other  
people wig-out over less.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2006 13:58:05 -0400

Sorry for not being clear. I meant, the Via header as it leaves the 
proxy for your SIP provider. That will point to the proxy itself and 
thus identify the SIP provider.

In other words, when the call reaches the terminating party, the via 
stack plus your SDP IP address will tell them what SIP provider the call 
  is coming from, and that this is the same person that called me an 
hour ago.

-Jonathan R.

---

From: [email-masked]
Date: Tue, 19 Sep 2006 10:42:22 -0400

From: Jonathan Rosenberg <[email-masked]>

I agree that you've shown the necessity of modifying GRUU to support
this level of anonymity.  But one clarification -- is the
"pseudononymous GRUU" expected to have a longer lifetime than the
registration, or do you envision it having the same lifetime?

If the latter, it seems that implementing "pseudononymous GRUUs" is
simple, and not much of a burden on Registrars, since they can be
created by any method and stored in the record of the registration.
If the former, then we need to consider how a family of pseudononymous
GRUUs for each UA can be managed.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Sep 2006 11:36:01 -0400

The proposal was that it would have the lifetime of the registration. It 
would remain fixed during refreshes, but if your registration lapses and 
expires, or is ended with Expires:0, when you log back on with a new 
registration you'd get a new pseudononymnous gruu.

-Jonathan R.

---

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Wed, 20 Sep 2006 09:35:33 +0200

That approach has the drawback that if I as an end user want to start
consecutive calls that cannot be correlated I need to unregister and
register again. Setting aside the burden of doing that through the
terminal, while I unregister and register again I might miss some
incoming calls.

Wouldn't it be better to allow the UA to request a new pseudonym in a
registration refreshment?

/Javier

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: martes, 19 de septiembre de 2006 17:36
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] GRUU and Anonymity

-Jonathan R.

> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 20 Sep 2006 10:58:57 +0200

Javier,

I suspect the reason for excluding refreshes, is that the UAC has no control 
over when they happen (ie at one point it has a choice: refresh or be 
unregistered). If the lifetime of "the" pseudonymous GRUU were implicitly 
ended upon refresh (ie because a new one is issued), any ongoing dialogs 
using that GRUU would break.

But before we discuss the mechanisms: I believe it is a requirement to have 
not only one but N pseudonymous GRUUs in parallel, all with independent 
lifetimes (possibly bound by the lifetime of the registration). 
Implementations may limit N to a "reasonable" amount, but consider that a UA 
may have several long-running event subscriptions. A watcher should have a 
means to prevent correlation of independent subscriptions.

With N parallel pseudonyms, we will need an explicit invalidation mechanism.

The TRUU draft was written under these assumptions: 
http://tools.ietf.org/wg/sip/draft-jbemmel-sip-truu-02.txt
Section 7.1.1 proposes a 'truu-count' parameter to request N TRUUs for a 
contact (default:1, recommended <=10)
Section 7.1.3 discusses explicit TRUU invalidation, which may or may not be 
piggybacked on a registration refresh

Regards,

Jeroen

----- Original Message ----- 
From: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 20, 2006 9:35 AM
Subject: RE: [Sip] GRUU and Anonymity

/Javier

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: martes, 19 de septiembre de 2006 17:36
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] GRUU and Anonymity

-Jonathan R.

---

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Wed, 20 Sep 2006 12:05:34 +0200

See inline. Regards,
/Javier 

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: miércoles, 20 de septiembre de 2006 10:59
To: Jesus Javier Arauz (MI/EEM); Jonathan Rosenberg; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] GRUU and Anonymity

Javier,

I suspect the reason for excluding refreshes, is that the UAC has no control over when they happen (ie at one point it has a choice: refresh or be unregistered). If the lifetime of "the" pseudonymous GRUU were implicitly ended upon refresh (ie because a new one is issued), any ongoing dialogs using that GRUU would break.

[JJAR] AFAIK the UA may re-register at any time before the registration expires, so actually it has control over when it wants to get a new pseudonym. To get a new pseudonym does not necessarily imply that older pseudonyms are not valid anymore, that's also controlled by the UA by means of re-registrations. May be you've changed that in the latest TRUU draft but that's the way I remember TRUU works...

But before we discuss the mechanisms: I believe it is a requirement to have not only one but N pseudonymous GRUUs in parallel, all with independent lifetimes (possibly bound by the lifetime of the registration). 
Implementations may limit N to a "reasonable" amount, but consider that a UA may have several long-running event subscriptions. A watcher should have a means to prevent correlation of independent subscriptions.

[JJAR] I fully agree, but don't get your point with subscriptions. As long as subscriptions are to servers in the network privacy is not an issue and GRUU can be used. For e2e subscriptions the UA must either keep the pseudonym alive as long as the subscription lasts, or cancel the subscription and re-subscribe with the new pseudonym. What have I missed here?

The TRUU draft was written under these assumptions: 
http://tools.ietf.org/wg/sip/draft-jbemmel-sip-truu-02.txt
Section 7.1.1 proposes a 'truu-count' parameter to request N TRUUs for a contact (default:1, recommended <=10) Section 7.1.3 discusses explicit TRUU invalidation, which may or may not be piggybacked on a registration refresh

Regards,

Jeroen

----- Original Message -----
From: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 20, 2006 9:35 AM
Subject: RE: [Sip] GRUU and Anonymity

/Javier

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: martes, 19 de septiembre de 2006 17:36
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] GRUU and Anonymity

-Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 20 Sep 2006 12:27:20 +0200

inline...[JvB]

----- Original Message ----- 
From: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>; "Jonathan Rosenberg" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 20, 2006 12:05 PM
Subject: RE: [Sip] GRUU and Anonymity

See inline. Regards,
/Javier

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]]
Sent: miércoles, 20 de septiembre de 2006 10:59
To: Jesus Javier Arauz (MI/EEM); Jonathan Rosenberg; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] GRUU and Anonymity

Javier,

[JJAR] AFAIK the UA may re-register at any time before the registration 
expires, so actually it has control over when it wants to get a new 
pseudonym. To get a new pseudonym does not necessarily imply that older 
pseudonyms are not valid anymore, that's also controlled by the UA by means 
of re-registrations. May be you've changed that in the latest TRUU draft but 
that's the way I remember TRUU works...

[JvB] My interpretation of Jonathan's proposal was that upon a new 
registration a single new pseudononymous gruu is issued (per Contact 
perhaps), and the previous one implicitly becomes invalid. Indeed, the TRUU 
draft proposes a slightly different approach, ie without implicit 
invalidation. My interpretation might be wrong of course

[JJAR] I fully agree, but don't get your point with subscriptions. As long 
as subscriptions are to servers in the network privacy is not an issue and 
GRUU can be used. For e2e subscriptions the UA must either keep the 
pseudonym alive as long as the subscription lasts, or cancel the 
subscription and re-subscribe with the new pseudonym. What have I missed 
here?

[JvB] I was only trying to illustrate a case where a UA could have multiple 
ongoing dialogs, to support the argument for N pseudonyms. With regard to 
subscriptions being to servers in the network, and privacy not being needed 
in that case - (1) The UAC cannot know where the SUBSCRIBE will end up, and 
(2) in case the network in which the servers reside is different from the 
home network, a UA might still want privacy protection. Note that the TRUU 
draft currently does not provide a "keep alive" feature for TRUUs (though it 
could of course); currently, what an UA should do for subscriptions that 
outlive a TRUU being used as remote contact, is to request a new TRUU, and 
then refresh the subscription.

The TRUU draft was written under these assumptions:
http://tools.ietf.org/wg/sip/draft-jbemmel-sip-truu-02.txt
Section 7.1.1 proposes a 'truu-count' parameter to request N TRUUs for a 
contact (default:1, recommended <=10) Section 7.1.3 discusses explicit TRUU 
invalidation, which may or may not be piggybacked on a registration refresh

Regards,

Jeroen

----- Original Message -----
From: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 20, 2006 9:35 AM
Subject: RE: [Sip] GRUU and Anonymity

/Javier

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: martes, 19 de septiembre de 2006 17:36
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] GRUU and Anonymity

-Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 20 Sep 2006 15:19:12 +0200

(slightly off topic)

All,

I received a complaint regarding missing quotation (">") in some of my 
replies to this list. I do have quotation enabled, but it appears that my 
e-mail client (Outlook Express 6) does not use it when the e-mail being 
replied to contains a header 'Content-Transfer-Encoding: quoted-printable'

For example, Javier's previous e-mail to the list has this, while my reply 
to that has not.

This may be a quirk in my client. Still, I would like to ask you to not 
write e-mails using "quoted-printable" encoding if possible (probably a 
setting in your configuration)

Regards,

Jeroen

---

From: "kasturi Narayanan" <[email-masked]>
Date: Wed, 20 Sep 2006 08:57:01 -0500

Jonathan,
I have a question regarding the requirement for Record Routing by both the
home proxies of the Initiating Domain and Receiving Domain in Section 8.2.2
for dialog initiating Requests with GRUU contact.

Why is this requirement? Why can't it be treated as if a UA has inserted a
Domain name in the Contact and just route it to after resolving the Domain
name (which will happen to be the proxy responsible for that Domain). 
This way the requirement that all subsequent requests have to traverse the
same set of 2 proxies will not be needed, it will be just one proxy
corresponding to the Domain which is responsible for routing based on GRUU.

May be I am missing something.

Kasturi

---

From: [email-masked]
Date: Wed, 20 Sep 2006 12:53:33 -0400

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>

There is some context that you haven't seen -- Rosenberg's proposal is
to provide only a limited amount of anonymity (which is why it's
called pseudonymous), which is the amount that one already obtains
when one does not use GRUU.  Since the current Contact and Via values
reveal the caller's IP address, the pseudonymous GRUUs are only
required to change when the UA registers from a different IP address,
which is provided by the requirement that they change with each new
registration.

On the other hand, since there is only one pseudonymous GRUU per
registration and it lasts only as long as the registration, it
requires a fixed overhead per-registration and no state that lasts
longer than a registration, and hence is not a burden on registrars
with limited resources or no long-term state memory.

The feeling among the people reviewing the GRUU I-D is that it needs
to provide a mechanism that is "at least as anonymous as current
practice" before it can progress to being an RFC, but that providing
"quality anonymity" should be left to another I-D.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Sep 2006 01:56:23 -0400

This requirement is there to eliminate spirals that would otherwise 
occur if there is a separate edge and home proxy. That problem existed 
in many previous versions of the draft with a very ugly hack on 
record-route removal to fix.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Sep 2006 01:58:31 -0400

One other point on this - if you want to have consecutive calls that 
cannot be correlated, then another solution is to include Privacy: 
header,id into the request. A network anonymization service as already 
defined in RFC 3323 will provide this level of anonymity.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Sep 2006 23:00:27 -0400

inline.

Jeroen van Bemmel wrote:

> But before we discuss the mechanisms: I believe it is a requirement to 
> have not only one but N pseudonymous GRUUs in parallel, all with 
> independent lifetimes (possibly bound by the lifetime of the registration).
> Implementations may limit N to a "reasonable" amount, but consider that 
> a UA may have several long-running event subscriptions. A watcher should 
> have a means to prevent correlation of independent subscriptions.

This is a fine thing to want, and its not unreasonable for a draft like 
truu to propose it.

However, the MAIN point I am trying to make in gruu is that I believe we 
do not need to provide anonymity that is any better than RFC 3261. RFC 
3261 does NOT provide (without a privacy service) correlation of 
independent subscriptions. The Contact header IP address will provide 
such a correlator. Consequently, I do not think we need to do better in 
GRUU.

With RFC 3261, if you want to have uncorrelatable dialogs of any sort, 
you need to use an anonymizer service. With my proposal, when using 
GRUU, you would still need to use such an anonymizer service and it 
would be as effective (or ineffective) prior to GRUU.

I am not trying to solve the whole of anonymity here. I am trying to 
propose a minimal set of functions that is sufficient for gruu to pass. 
We should continue to pursue privacy mechanisms independently of gruu 
that do better than gruu/rfc3261 alone.

Thanks,
Jonathan R.

---

From: [email-masked]
Date: Thu, 28 Sep 2006 06:38:49 +0200

Jonathan,

In that case, I personally would prefer to do it properly in a separate 
draft, and for GRUU say something like: "GRUU provides the equivalent 
of a fixed public IP address. All privacy issues associated with the 
use of such an address also apply to GRUUs. If additional privacy 
protection is required, it is recommended to use a privacy service 
[ref]"

I don't see much added value in providing something that addresses the 
issues "kind of half". By adding a relatively simple feature now, we 
would create complexity in terms of the number of available 
options/alternatives later.

Regards,

Jeroen

> inline.
>
> Jeroen van Bemmel wrote:
>
>
>> But before we discuss the mechanisms: I believe it is a requirement 
>> to have not only one but N pseudonymous GRUUs in parallel, all with 
>> Implementations may limit N to a "reasonable" amount, but consider 
>> that a UA may have several long-running event subscriptions. A 
>> watcher should have a means to prevent correlation of independent 
>> subscriptions.
>
> This is a fine thing to want, and its not unreasonable for a draft 
> like truu to propose it.
>
> However, the MAIN point I am trying to make in gruu is that I believe 
> we do not need to provide anonymity that is any better than RFC 3261. 
> RFC 3261 does NOT provide (without a privacy service) correlation of 
> such a correlator. Consequently, I do not think we need to do better 
> in GRUU.
>
> With RFC 3261, if you want to have uncorrelatable dialogs of any 
> sort, you need to use an anonymizer service. With my proposal, when 
> using GRUU, you would still need to use such an anonymizer service 
> and it would be as effective (or ineffective) prior to GRUU.
>
> propose a minimal set of functions that is sufficient for gruu to 
> pass. We should continue to pursue privacy mechanisms independently 
> of gruu that do better than gruu/rfc3261 alone.
>
> Thanks,
> Jonathan R.
>
>
>
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Sep 2006 17:44:26 -0400

[email-masked] wrote:

> draft, and for GRUU say something like: "GRUU provides the equivalent of 
> a fixed public IP address.

But its worse than that. Today, it will give you a GRUU which is 
personally identifying you. An IP address is more of a pseudonym and is 
useful primary as a correlator. Thats the issue; GRUU makes things WORSE 
than rfc3261.

> All privacy issues associated with the use of 
> such an address also apply to GRUUs. If additional privacy protection is 
> required, it is recommended to use a privacy service [ref]"

While we could merely suggest usage of a privacy service, it would imply 
that a b2bua function is required for any kind of anonymity services 
with gruu enabled. That is a tough pill to swallow.

> options/alternatives later.

Its not 'kind of half' - its addressing them exactly like RFC 3261 does.

-Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 29 Sep 2006 14:32:23 +0200

Jonathan,

see inline

Regards,

jeroen

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: <[email-masked]>
Cc: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Thursday, September 28, 2006 11:44 PM
Subject: Re: [Sip] GRUU and Anonymity

> useful primary as a correlator. Thats the issue; GRUU makes things WORSE 

I assume you're refering to the case where the GRUU would contain the AoR 
verbatim? That would be an implementation choice (and as I'm sure you are 
aware, appendix A.2 provides a more privacy-preserving example for GRUU 
construction). So the draft already provides options to implement something 
more or less equivalent to RFC3261 (unless you had some other aspect in mind 
which makes it worse?).

>> All privacy issues associated with the use of such an address also apply 
>> to GRUUs. If additional privacy protection is required, it is recommended 
>> to use a privacy service [ref]"
>
> that a b2bua function is required for any kind of anonymity services with 
> gruu enabled. That is a tough pill to swallow.
>

IMHO it is better to have {GRUU draft as-is + RFC3323 privacy} while we are 
working on additional anonimity features and the underlying requirements, as 
opposed to {GRUU draft ammended with 1 temporary anonymous GRUU per Contact 
which changes for each registration}

> Its not 'kind of half' - its addressing them exactly like RFC 3261 does.

For the GRUU draft I agree on this scope. With 'the issues' above I was 
refering to the more general case of providing privacy/anonymity, for that I 
think we need more work and consensus on the requirements first