Re: [martini] GIN and anonymous GRUUS

[Paul Kyzivat <[e-mail]>]

Adam Roach wrote:
> So, I had a pretty long conversation with Cullen, and it turns out that 
> the issue (and I think he's convinced me that it's a real issue) is that 
> the "gr" portion of the anonymous public GRUUs is invariant across 
> multiple temp-gruus.
> 
> So, using the "women's shelter" example, the issue is that someone 
> receiving a call from a shelter could capture the inbound contact (a 
> temp gruu), and then attempt to contact all the shelters in the area 
> (not a difficult feat). Once he got a contact back with a matching "gr" 
> parameter, he knows precisely which shelter the call originated from.
> 
> Assuming we need to address this situation, there are really only two 
> watertight solutions that I can think of.
> 
> To Paul's point (below), I think it's critical that this solution works 
> with phones in the same way that GRUUs do in general. In other words, 
> the b2bua approach in which the phone is telling the PBX that it wants 
> privacy, and the PBX is invoking GRUU procedures is pretty much a 
> non-starter. It's not enabling GRUU procedures; it's enabling some 
> hybrid approach that I don't think gets us to where we want to be.

AFAIK we have no documented approach to anonymity using gruus with 
b2buas, or even with using gruus at all with b2buas. Typically the b2bua 
is going to replace the contact address supplied by the phone with an 
address that terminates on the B2BUA. If that contact is a gruu, and the 
b2bua is the issuer of that gruu, then with luck it will recognize it. 
If its really clever, it will then decide that it doesn't need to 
replace it, because it already terminates on the b2bua.

If the b2bua is upstream of the proxy/registrar that assigned the gruu 
the phone is using, then the b2bua will probably not recognize it, and 
so will replace it with something of its own. When incoming requests 
reach that address, it will replace with the original (phone-gruu) and 
forward on. That will work. But it might lose anonymity if it was a temp 
gruu.

If the contact is a gruu assigned by the SSP which is downstream from 
the b2bua then things get messy. The b2bua may not recognize this, and 
so replace it. That will then result in a spiral through the SSP. If the 
b2bua recognizes this (it was an SSP assigned gruu with additions by the 
pbx to generate a gruu for the phone, then it could leave it alone and 
things will probably work ok.

So it probably can be made to work, but it will take some care, and the 
precise things that must be done may vary by topology. This needs 
further investigation.

> So, the first kind of solution involves the SSP somehow minting a new 
> temp GRUU for each extension, and communicating all the temp GRUUs to 
> the PBX (in a confidential manner, of course). This approach also 
> requires the ability for the PBX to request a new temp GRUU whenever a 
> terminal registers (since a new registration causes creation of a new 
> temp GRUU).

When temp gruus were introduced, there was consideration of ways to 
request new ones. That was discarded since it didn't fit in well with 
the registration approach to gruu assignment. Instead, the decision was 
to assign a new temp gruu at every registration, including refreshes. 
Hence a UA that wants a new temp gruu can get it by re-registering. The 
cost of this is assigning new temp gruus each registration even if the 
register was not for that purpose. (Might have been a mistake, but it is 
what it is.)

When I started looking into the gruu reg event extension, and the 
implications of implicit registrations, it turned out that we had to 
depend on the reg event package to get temp gruus for implicitly 
registered AORs. And it implied that every registration refresh had to 
generate a new temp gruu for every implicitly registered AOR. That 
wasn't so bad when there might be 1 or 2 implicit registrations per 
explicit registration. Its not nearly as acceptable when there might be 
100-200+ of them.

Also, every time this happens, you need to generate a NOTIFY containing 
all that stuff to any subscriber to any of the implicitly registered 
AORs. (At least thats how I think it works for IMS.)

> I don't think that's tenable, since you basically end up having to send 
> a lot of per-extension state back and forth between the PBX and the SSP. 

Yup, that's the bottom line.

> It pretty much negates any benefit of using GIN. In other words, for all 
> the traffic and complication, you'd probably be better off registering 
> each extension individually instead.
> 
> So I'm not interested in pursuing that one.
> 
> The second approach involves a kind of distributed cookie factory. I 
> know this sounds complicated at first blush, but I think it's actually 
> pretty easy to do correctly, especially if we leverage the procedure in 
> appendix A.2 of RFC 5627.  Go read that appendix now, since it's pretty 
> important to understand what I'm talking about.
> 
> Effectively, what we would do is pass along some information from the 
> SSP to the PBX that the PBX uses to mix into the temp-gruu when it 
> generates it. This information could be sent in the REGISTER response. 
> At that point, the PBX could generate temp-gruus that the SSP could 
> correlate to the proper PBX; that the PBX could correlate to the proper 
> terminal; and that outside parties would be unable to correlate to any 
> other temp-gruus.

Note that if you can do this once, you can probably do it twice, so that 
the phone can generate *its* own gruus using a seed passed to it. Then 
you wouldn't need all the repetitive gruu generation on every register. 
But of course it would not be backward compatible.

> I'm about halfway done with the description of how this would be done, 
> and will post a proposal to the MARTINI list when I think I have 
> something that works.

What I learned in several years of working, off and on, on gruu is that 
side effects keep popping up all over the place. For instance, does this 
require another extension to the reg event package? Or will it even be 
possible to discover gruus that way?

I don't consider this to be a small undertaking. If we are to do it, I 
think we should consider if it should apply more broadly than to 
martini. I'd prefer if we could see fit to postpone this part to a 
follow on effort. Until then, maybe those outfits that can't live with 
their pbx being identifiable might have to do something else.

	Thanks,
	Paul

> /a
> 
> On 5/20/10 12:37 PM, Adam Roach wrote:
>> Okay, wait. Before we go trundling down the "let's re-engineer this" 
>> hole, I'd like someone to concisely state what's wrong with the 
>> currently proposed mechanism. There's a lot of 
>> back-to-the-drawing-board proposals implied by the last few messages, 
>> without any clear indication why. The one use "issue," raised by 
>> Cullen, appears to be based on a misunderstanding. Everything else 
>> looks like an "ooh, shiny!" race off to see if we can design something 
>> else just for the fun of it.
>>
>> /a
>>
>> On 5/20/10 9:21 AM, Paul Kyzivat wrote:
>>> Cullen,
>>>
>>> Focusing on the B2BUA PBX case, the contact address that the outside 
>>> world sees will be one inserted by the pbx b2bua, not the one 
>>> inserted by the phone. In that case, there are two issues:
>>> - how does the phone indicate it wants to make an anonymous call?
>>>   (Privacy header?)
>>> - how does the pbx get a supply of anonymous gruus?
>>> There is in that case no need to convey anonymous gruus to the phones.
>>>
>>> (The above assumes privacy only for calls to the outside world. 
>>> Privacy on calls between phones connected to the same pbx is a 
>>> *little* different. If there is still a b2bua in the path, its more 
>>> or less the same, except that contact used probably won't be a gruu 
>>> at all, just something cooked up by the b2bua for local use.)
>>>
>>> So, in this case the hard part is to get a temp gruu for the pbx to 
>>> use. Assuming the ssp registrar supports temp gruus, this is doable, 
>>> but there are potential efficiency issues. I'm now wondering if those 
>>> need to be investigated, or if they can be left as implementation 
>>> issues.
>>>
>>> We haven't spoken much about the pbx-as-proxy case. That is a bit 
>>> more difficult, because it becomes necessary to convey temp gruus to 
>>> the phones.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> Cullen Jennings wrote:
>>>> So I think this conversation is going a good way to find a solution 
>>>> to this. For a second, lets just consider the B2BUA style PBX.
>>>> Lets say that the PBX has 10 phones that register with the PBX and 
>>>> the PBX does one registration with the SSP that uses GIN with GRUU. 
>>>> The phones may not even support GRUU and their registration have 
>>>> very little to do with the registration to the SSP. I realize that 
>>>> to get a temp GRUU to each of the phones, we would either need a way 
>>>> for the PBX to generate multiple temp GRUU based on some template it 
>>>> got from the SSP or the PBX would need to get multiple temp GRUU 
>>>> from the SSP. We should look at if there is a reasonable design to 
>>>> achieve either of those that does not require changes to GRUU. I 
>>>> suspect their might be. But even if there is not, I think there is a 
>>>> simple solution to this.
>>>>
>>>> Keep in mind my issue is not the phones all all temp gruu, my issues 
>>>> is that anonymous calls need to not reveal which PBX it is. So one 
>>>> solution would be to have the PBX get a single temp GRUU and when 
>>>> the PBX makes an anonymous call  to the SSP use the temp gruu then 
>>>> get some more temp gruu for future use. This would probably work 
>>>> better if it had a small pool of available temp gruu for use when a 
>>>> temp gruu is need but you get the idea.
>>>> Another option would be just to have the GIN draft request the 
>>>> number of temp GRUU that the PBX wants the SSP to return.
>>>> There's a ton of way to skin this cat but I am strongly against 
>>>> depreciating anonymous call support of 3261 when using the GIN draft 
>>>> - I view that as GIN breaking SIP. It's a critical feature when 
>>>> using SIP for PSTN replacement and I believe it has very important 
>>>> value many types of SIP communication.
>>>>
>>>>
>>>> On May 19, 2010, at 11:11 AM, Paul Kyzivat wrote:
>>>>
>>>>>
>>>>> Adam Roach wrote:
>>>>>> Actually, you're right. I just re-read the "anonymous public GRUU" 
>>>>>> section again, and it doesn't reveal the information that we're 
>>>>>> fretting about. (I also found a minor error in some of the 
>>>>>> examples, but I'm fixing that in -03).
>>>>>> The example that the document gives for one of these GRUUs looks 
>>>>>> like this:
>>>>>> sip:ssp.example.com;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=0UYYRV046P 
>>>>>
>>>>>
>>>>>
>>>>> The above doesn't sound right. A public gruu for the pbx ought to 
>>>>> look like:
>>>>>
>>>>> sip:[e-mail];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 
>>>>>
>>>>>
>>>>> So anything derived off of it, for use as temp gruus, would also 
>>>>> contain the identification of the pbx.
>>>>>
>>>>> If the pbx also got a temp-gruu assigned by the ssp, then it could 
>>>>> derive its own temp gruus off of that. But assigning temp gruus for 
>>>>> a pbx registration is going to be problematic:
>>>>>
>>>>> *Every* time a REGISTER (or re-REGISTER) request is processed, if 
>>>>> the registrar supports temp-gruus and the registering UA supports 
>>>>> gruu, then a new temp-gruu is assigned and returned. In principle 
>>>>> that applies to implicitly registered AORs as well. There will be a 
>>>>> new temp-gruu for *each* implicitly registered AOR. Those aren't 
>>>>> returned, but if there is a subscription to the reg event package 
>>>>> convering those AORs, then it will need to generate a notification 
>>>>> containing all those temp-gruus. (See RFC 5628.) There is no good 
>>>>> way to know if those are desired, so they are to be generated 
>>>>> regardless. This works for the small numbers of implicit AORs used 
>>>>> in IMS (ignoring the pbx stuff). But it could be a lot of work to 
>>>>> generate, and a big notification to deliver all those temp gruus. 
>>>>> And it will happen again every time the registration is refreshed.
>>>>>
>>>>> So, till now we GIN says not to generate temp gruus.
>>>>>
>>>>> If we need the SSP to generate a temp gruu for the pbx to use in 
>>>>> generating its own temp gruus, but we don't want the ssp to 
>>>>> generate temp gruus for all the implicitly registered AORs, then 
>>>>> some added specification is required.
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>>> Going to Cullen's concern: if I got one of these URIs, it's not 
>>>>>> clear what part of that I could mine to find out whether it was a 
>>>>>> Women's Shelter (unless example.com has precisely one customer, in 
>>>>>> which case I don't think there's anything we can do anyway).
>>>>>> Cullen: can you elaborate on your use case, providing specific 
>>>>>> examples of the URIs that you think leak information?
>>>>>> /a
>>>>>> On 5/19/10 9:32 AM, Elwell, John wrote:
>>>>>>> Adam,
>>>>>>>
>>>>>>> Although I was generalising the use case that Cullen put forward, 
>>>>>>> doesn't the existing approach 2 satisfy this anyway?
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Adam Roach [mailto:[e-mail]]
>>>>>>>> Sent: 19 May 2010 15:18
>>>>>>>> To: Elwell, John
>>>>>>>> Cc: Cullen Jennings; [e-mail]
>>>>>>>> Subject: Re: [martini] GIN and anonymous GRUUS
>>>>>>>>
>>>>>>>> I'm sympathetic to the point, but don't think it's something that
>>>>>>>> MARTINI can appropriately solve. What's critical here is to
>>>>>>>> realize that
>>>>>>>> GIN does not make this problem any better or worse than the base 
>>>>>>>> GRUU
>>>>>>>> mechanism.
>>>>>>>>
>>>>>>>> For example, in a "normal" (i.e., 3263-routed, GIN-free) 
>>>>>>>> environment,
>>>>>>>> imagine you came into possession of a temp GRUU
>>>>>>>> "sip:596acff0-6350-11df-a08a-0800200c9a66@two-guys-and-a-goat.
>>>>>>>> com". And,
>>>>>>>> after a little research, you determine that the company does,
>>>>>>>> in fact,
>>>>>>>> consist of exactly two guys and their goat. You can be pretty 
>>>>>>>> certain
>>>>>>>> that the call came from one of the two guys who comprise the 
>>>>>>>> company
>>>>>>>> (unless the goat is really quite talented).
>>>>>>>>
>>>>>>>> So, yeah, it's a shortcoming of GRUUs in general. If you want
>>>>>>>> to solve
>>>>>>>> this problem, what is really needed is for you to take an
>>>>>>>> rfc5627bis to
>>>>>>>> DISPATCH.
>>>>>>>>
>>>>>>>> But I think it's a bit of a stretch to say "GRUUs as
>>>>>>>> currently defined
>>>>>>>> have this shortcoming. You mentioned GRUUs, and in doing so,
>>>>>>>> inherited
>>>>>>>> the shortcoming. Now fix it!"
>>>>>>>>
>>>>>>>> /a
>>>>>>>>
>>>>>>>> On 5/19/10 3:29 AM, Elwell, John wrote:
>>>>>>>>> Cullen makes a good point. In general, MARTINI is targeted
>>>>>>>> at small PBXs, so often an "anonymous" GRUU that still
>>>>>>>> reveals the name of the business will not be sufficient,
>>>>>>>> since the number of users might be very small, they all might
>>>>>>>> be located in the same office, and so on.
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [e-mail]
>>>>>>>>>> [mailto:[e-mail]] On Behalf Of Cullen Jennings
>>>>>>>>>> Sent: 19 May 2010 02:19
>>>>>>>>>> To: [e-mail]
>>>>>>>>>> Subject: [martini] GIN and anonymous GRUUS
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think the anonymous public GRUUs need some work. Imagine
>>>>>>>>>> that I have a small PBX at a women's shelter. Say they are 5
>>>>>>>>>> to 10 phones or so and this PBX connects to an SSP. I think
>>>>>>>>>> this is one of the use cases we need anonymous calls to work
>>>>>>>>>> for and when someone makes a call from one of these phones,
>>>>>>>>>> it can not reveal they are at the women's shelter.
>>>>>>>>>> Anonymizing which room they are in at the women's shelter is
>>>>>>>>>> not enough. I'll ignore the self make GRUU section because if
>>>>>>>>>> you could to that, well you would not need GIN in the first 
>>>>>>>>>> place.
>>>>>>>>>>
>>>>>>>>>> Moving on to the Approach 2 - it seem that the PBX needs to
>>>>>>>>>> get an anonymous GRUU from the SSP then use that to fabricate
>>>>>>>>>> it's anonymous GRUU. I think that if you modified what you
>>>>>>>>>> have in the draft now to use anonymous GRUUs from the SSP,
>>>>>>>>>> you could get this to work.
>>>>>>>>>>
>>>>>>>>>> I think it would be worth adding an example showing an
>>>>>>>>>> anonymous call. I know lots of people goes "who cares, that's
>>>>>>>>>> a corner case" but many of the environments where we want to
>>>>>>>>>> deploy GIN, it will be a requirement to support anonymous
>>>>>>>>>> call - not many people need them but governments are pretty
>>>>>>>>>> adamant about making sure the people who do need them can
>>>>>>>> have them.
>>>>>>>>>> Could you put a Note telling the RFC Ed to remove section 9.
>>>>>>>>>> If anyone ever needs to read that they can find the draft.
>>>>>>>>>>
>>>>>>>>>> Nice draft - can't say I like it but I can live with it and I
>>>>>>>>>> suspect most people will come to the same conclusion after
>>>>>>>>>> thinking about it for awhile. Something most people can live
>>>>>>>>>> with I view as huge success for this topic. It will be
>>>>>>>>>> infinitely better than the current situation of many things
>>>>>>>>>> that sounds close but when you look at them in detail don't
>>>>>>>>>> interoperate.
>>>>>>>>>>
>>>>>>>>>> Thanks, Cullen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cullen Jennings
>>>>>>>>>> For corporate legal information go to:
>>>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> martini mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/martini
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> martini mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/martini
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> martini mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/martini
>>>>> _______________________________________________
>>>>> martini mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/martini
>>>>
>>>>
>>>> Cullen Jennings
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>
>>>>
>>>>
>>>>
>>
>> _______________________________________________
>> martini mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/martini
> 
>