Subject: [Sip] Question regarding instance ID in GRUU and outbound

From: Aki Niemi <[email-masked]>
Date: Tue, 08 Aug 2006 23:49:09 +0300

Howdy,

I read GRUU and outbound, and an old nagging concern of mine resurfaced:
what the heck do we need the instance ID for?

Seems outbound uses it to guarantee uniqueness of flows in a registrar,
but to me it sounds weird that the task of acquiring unique IDs within
the registrar's internal state is left to the UA -- after all, browsers
don't generally generate cookies themselves but store whatever the
website gives them.

To me, a much better approach would be to have the registrar generate
and allocate a unique ID (perhaps the 'opaque' used in GRUU?) for the
first REGISTER, and whenever a client registers with that ID again, it
is deemed the same UA. A REGISTER without an ID would be another UA
instance.

Even DHCP clients' leases seem to survive reboots without some weird URN
generation, so I don't think that it's unreasonable to require UAs to
store their outbound IDs either. I mean, they already have to store the
reg-id, no? (Not to mention web cookies...)

And worst case is you need to garbage-collect some stale flows, in case
a UA happens to forget its ID, but that you need to be doing in any
case.

We chose a similar approach over instance ID in PUBLISH, which uses
etags generated by the server to identify uniqueness of publisher
instances. With PUBLISH, UAs are also instructed to remember their
etags, even across reboots.

Cheers,
Aki

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 08 Aug 2006 18:29:00 -0500

> don't generally generate cookies themselves but store whatever the

Well, to answer your nagging or "persistent" question, I believe the 
instance ID is there to create persistence.

The idea (to which I'm not sure I subscribe) is that a GRUU is a very 
long-lived thing. For example, if client X registers with domain 
example.com in 2004, and then again in 2011, domain example.com should 
assign the exact same GRUU on both occasions.

The only way we could come up with to do this (that didn't require 
eternal state in the registrar) was to make the assigned GRUU dependent 
on a transformation of "something unique to the client".

> is deemed the same UA. A REGISTER without an ID would be another UA

I think that works, but it doesn't have this long-lived persistence 
property that some people find desirable.

So the argument, should we decide to revisit it, is "Do GRUUs need to be 
effectively immortal, or is okay if they're ephemeral?" So far, we seem 
to have a consensus (recorded many times in meetings and on the list) 
that we subscribe to the immortality model.

Unless somebody has some real motivation otherwise, I suggest it might 
be better not to open that particular can of fish bait.

--
Dean

---

From: [email-masked]
Date: Tue, 8 Aug 2006 23:38:28 -0400

From: Aki Niemi <[email-masked]>

I believe the presupposition is that the common case will be a
physical "SIP telephone".  It already must have a unique MAC address,
and there is a simple, defined way to turn that into a URN.  So it is
assumed to be simpler for the device to generate an ID for itself from
its MAC address than for it to get and remember the ID given to it by
a registrar.

Dale

---

From: Aki Niemi <[email-masked]>
Date: Wed, 09 Aug 2006 11:49:58 +0300

> on a transformation of "something unique to the client".

Actually, this is completely orthogonal to the issue of who generates
this "something". 

Similarly, I can make a website that never expires cookies. Persistence
there doesn't require browsers issuing any kind of unique IDs; browsers
simply need to store the cookies they receive and offer them to sites as
necessary.

> that we subscribe to the immortality model.

But sip-outbound doesn't even have this immortality model.

The pattern in SIP outbound is that of web cookies. I think it's not
good design to ignore that pattern and go with yet another approach that
kind of does the same and might work, too. 

I see at least three problems with sip-outbound's use of the UUID URN:

1) It's generally a bad idea (and a security risk) to rely on the UA
generating data to be used in registrar-internal state lookups. Even if
the UUID seems all dandy and easy to use in database lookups, I'd still
prefer to decide exactly with which data I populate my own database that
holds my own internal state. 

2) Generating a UUID is yet another obscure specification to read,
interpret correctly and implement. I fear implementations won't get this
right, and the registrar will simply have to make due with crappy
instance IDs UAs are giving it. It has no other choice, even when those
IDs are generated my malicious UAs that intentionally look for
collisions.

Cheers,
Aki

-- 
Aki Niemi
Nokia Research Center

---

From: Aki Niemi <[email-masked]>
Date: Wed, 09 Aug 2006 11:55:20 +0300

> its MAC address than for it to get and remember the ID given to it by

I don't agree with that assumption. I am willing to bet softphones
(ranging from Java apps in mobile phones to desktop softphones) probably
outnumber blackphones already now, and definitely in the future. It's a
mistake to optimize for a niche product, IMHO.

Cheers,
Aki

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 Aug 2006 09:35:59 -0500

> simply need to store the cookies they receive and offer them to  

Assume the browser loses the cookie and the server loses the  
authentication record.

How does the web site know to issue the exact same cookie the next  
time the browser connects?
> But sip-outbound doesn't even have this immortality model.

Ah, I thought we were talking GRUU.

> IDs are generated my malicious UAs that intentionally look for

But if we're already doing all this for GRUU, why not just use the  
same thing?

The "malicious UA" thing is interesting. It might apply to GRUU as  
well. I haven't thought about this.

Anybody out there think it though yet?

--
Dean

---

From: [email-masked]
Date: Wed, 9 Aug 2006 10:44:01 -0400

Perhaps so.  But in that case, a UA can generate a pseudo-random URN.
In either case, it's simpler for the UA to generate a URN for itself
than to execute protocol operations to obtain and save one.  And that
avoids adding Yet Another Feature to SIP.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Aug 2006 12:49:14 -0400

Historically, the instance id was first introduced for GRUU. Then it was 
adopted for use in outbound. Then the dependencies were inverted, with 
outbound providing the definition of instance id and gruu referencing it.

In theory they could use different techniques, though the value of that 
seems dubious to me. If they both use the same id, then it has to meet 
both of their needs. As things stand it does. If it were to be changed 
to a cookie supplied by the registrar, then its unclear if it could as 
well meet both sets of needs.

At the moment the predominant need is to *get done*. The existing 
approach has a huge advantage on that score.

	Paul

Dean Willis wrote:
> How does the web site know to issue the exact same cookie the next time 
> the browser connects?
>>
> But if we're already doing all this for GRUU, why not just use the same 
> thing?
> 
> The "malicious UA" thing is interesting. It might apply to GRUU as well. 
> I haven't thought about this.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Aug 2006 17:35:10 -0400

Aki,

Can you point to anything wrong with the current approach? The only 
evidence of a problem that I saw in this discussion was that it would be 
harder to implement UUID URN than a cookie mechanism. YMMV on that one.

Consequently, if it aint broke - don't fix it. I am loathe to reopen the 
whole gruu/outbound design technique without a concrete problem being 
identified.

I also think its easier for a server to remember an instance ID to GRUU 
binding for a long time, than it is for a client to remember its cookie 
for a long time AND for the server to remember the cookie to GRUU 
mapping for a long time. GRUU persistence would depend on a client 
remembering its cookie basically forever. GRUU currently doesn't require 
persistent storage of any soft state in the client.

-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: Cullen Jennings <[email-masked]>
Date: Wed, 9 Aug 2006 15:58:16 -0700

This email is sort of irrelevant but I'm sending it anyways :-)

A few year back, I wrote
http://www.softarmor.com/wgdb/docs/draft-jennings-sipping-instance- 
id-00.txt

and it had some use cases for why one might need a long term stable  
identifier for a device. I think theses still hold. We need something  
and it needs to survive reboots of a device. You are right it does  
not matter who generates the ID but the UA needs to store it. Cookies  
were discussed but rejected due to worries about if there was AT&T  
IPR on them.

I originally proposed something "simple" to generate - I'm a big fan  
of large random numbers. Others were less comfortable with large  
random numbers and wanted something algorithmically guaranteed to be  
unique by some sort of delegated assignment - like MAC or OIDs. Most  
devices had MAC addresses or an equivalent sort of identifier. I  
wrote something for MAC plus something for things without a MAC. It  
was looking less simple. There were problems with the multiple phones  
on one MAC that added more complexity. Pretty soon, I was reinventing  
UUID. UUID covered everything we needed and encompassed a huge set of  
existing arguments on the subject. If you remove any part of UUID,  
there is some use case that gets broken. It may be that the use case  
is bogus but none the less the argument goes on.

Anyways, I think we needs something and I can't imagine anything much  
simpler than what we have right now.

> reg-id, no? (Not to mention web cookies...)

Side issue but I think they would usually just hardcode in reg-id of  
1 for the first one, 2 for second and so on. Some devices store only  
their MAC and the configuration system uses that to know what data to  
hand down to them. I have seen some systems where the config handed  
to the phone is based only on the which ethernet port in the switch  
the device was connected to. Some residential ethernet to the home  
systems do this so that if my neighbor plugs in his phone at my  
house, it becomes my phone. In theory these systems would not need to  
really store anything.

> etags, even across reboots.

of course close to none of them do :-)

---

From: [email-masked]
Date: Wed, 9 Aug 2006 23:02:46 -0400

From: Cullen Jennings <[email-masked]>

Let me suggest that the current concept (a URN as an instance ID) is
(from the point of view of the protocol) as simple as UUIDs, but more
general, and covers cases that UUIDs cannot:

- If you have a MAC address, you can package that into a UUID, which
  can be made into a URN.

- If you choose a big random number, you can package that into a UUID,
  which can be made into a URN.

- If you want delegated assignment, you can assign an OID, which can
  be made into a URN.

While leaving the essentials of the mechanism (and its minimal
implementations) quite simple, it allows alternative methods that
cover every use case anyone has thought of.

There is a certain overhead for forcing the UA to choose/have a URN,
but IMHO it's less than the protocol complications of having a
registrar hand them out.  (Especially the failure cases.)

Dale

---

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Thu, 10 Aug 2006 08:22:29 +0200

Probably Dr. Rosenberg is the right person to answer this, but to my understanding the instance ID has two complementary usages:

1) allow the construction of GRUUs in a stateless manner in registrars; e.g. the registrar does not need to store the GRUUs it has allocated since it can generate them algorithmically from the AoR and the instance ID. This issue is of utterly importance for telecom-grade platforms where storage space is scarce; if an IMS registrar has to persistently and eternally store all the GRUUs it generates it would take several Gbs of expensive RAM memory to do it.

2) provide a simple way to statelessly guarantee uniqueness of GRUUs, e.g. when a multi-host registrar is in the game. Web servers guarantee uniqueness of cookies by using very long values as cookies. Exchanging those long values over limited bandwidth links like e.g. those of a UMTS radio access network decreases the net bandwidth available for media.

Obviously a malicious UA might attempt to tweak this mechanism for its own obscure purposes. However the chances that it suceeds are low; even though that UA tried to force collisions by using tweaked instance IDs, in the worst case the instance ID is only one part of the GRUU, the AoR being the other. Since the AoR is authenticated and cannot be tweaked, the GRUU will still be unique no matter what the client puts in the instance ID.

Re-using the instance ID mechanism in sip-outbound enables the usage of the same Contact values for both GRUU and outbound, which IMHO makes sense.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: miércoles, 09 de agosto de 2006 16:36
To: Aki Niemi
Cc: sip
Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound

On Aug 9, 2006, at 3:49 AM, Aki Niemi wrote:

>> eternal state in the registrar) was to make the assigned GRUU 
>> dependent on a transformation of "something unique to the client".
>
> there doesn't require browsers issuing any kind of unique IDs; 
> browsers simply need to store the cookies they receive and offer them 
> to sites as necessary.
>

Assume the browser loses the cookie and the server loses the authentication record.

How does the web site know to issue the exact same cookie the next time the browser connects?

> good design to ignore that pattern and go with yet another approach 
> that kind of does the same and might work, too.
>
> the UUID seems all dandy and easy to use in database lookups, I'd 
> still prefer to decide exactly with which data I populate my own 
> database that holds my own internal state.
>
> interpret correctly and implement. I fear implementations won't get 
> this right, and the registrar will simply have to make due with crappy 
> instance IDs UAs are giving it. It has no other choice, even when 
> those IDs are generated my malicious UAs that intentionally look for 
> collisions.

But if we're already doing all this for GRUU, why not just use the same thing?

The "malicious UA" thing is interesting. It might apply to GRUU as well. I haven't thought about this.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 08:58:21 -0400

> Obviously a malicious UA might attempt to tweak this mechanism for its own obscure purposes. However the chances that it suceeds are low; even though that UA tried to force collisions by using twea…

There is very little that a UA can do to pervert this mechanism for some 
value. By lying about the instance id, all it can do is:
- appear to be multiple instances, rather than a single one
- impersonate some other instance

appearing to be multiple instances may have value in some cases, and in 
any case it at most hurts the user of the device doing it. It simply 
provides a cheaper way of *actually* having multiple devices.

Because the instance id is combined with the AOR to make a gruu, 
impersonation of the instance id only conflicts with other devices 
registering to the same AOR. Generally those all represent the same 
"user", and so this is only hurting the user that owns the device. This 
is no worse that one of the user's devices malfunctioning in some other 
way. There may be cases when moving an instance id among devices is a 
useful thing to do. It only is a problem at all when the same instance 
id is simultaneously used in two devices. And that is likely pilot error 
on the part of the user.

I don't see a problem here.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Thu, 10 Aug 2006 16:12:34 +0300

> well meet both sets of needs.

Like I responded to Dean, the issue of who generates the unique
identifier is completely orthogonal to the issue of having to store it
"indefinitely".

You can just as easily lose track of client provided instance IDs at the
registrar as you do those you created yourself. But I feel a lot more
comfortable giving UAs handles from my own private pool.

As an aside, the immortal GRUU to me is simply an alias, and for those,
the other allocation scheme (namely the admin allocated) seems much more
feasible. That's also a common feature in proxies, I believe.

> approach has a huge advantage on that score.

This, I admit, is hard to counter with my argument, which basically is
"the current scheme is kind of ugly". :)

Cheers,
Aki 
-- 
Aki Niemi
Nokia Research Center

---

From: Aki Niemi <[email-masked]>
Date: Thu, 10 Aug 2006 16:26:38 +0300

> whole gruu/outbound design technique without a concrete problem being 

The problem I have is letting the UA create identifiers that the
registrar uses in its internal state lookup. Now there isn't anything
totally broken with this approach per se, but it just seems like a bad
idea.

So in that sense, I agree this may be "too little, too late".

> persistent storage of any soft state in the client.

Except it has to persistently store the instance-ID. When the UA moves
to another device, it supposedly needs to take the instance ID with it?

There's really no difference here to the (implicit) requirement on a UA
that the UA has to store the user credentials, per AOR, in persistent
storage, forever. 

Unless a blackphone intends to query a digest password upon every
registration after a reboot cycle? That probably wouldn't work,
especially with a numeric keypad and an alphanumeric password. Or at
least I would toss that phone out the window pretty quickly. ;)

Cheers,
Aki

-- 
Aki Niemi
Nokia Research Center

---

From: Aki Niemi <[email-masked]>
Date: Thu, 10 Aug 2006 16:33:54 +0300

> were discussed but rejected due to worries about if there was AT&T  

This is pretty interesting. Has anyone verified there is an actual
patent or patent application on the cookie approach?

> is bogus but none the less the argument goes on.

Let me be clear, I'm not against UUID as such. In fact that would be a
perfectly valid spec to follow when implementing the registrar's
cookie-generation algorithm.

> Some devices store only  

And that configuration handed down to them couldn't just include the
cookie?

> of course close to none of them do :-)

Touche! ;)

-- 
Aki Niemi
Nokia Research Center

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 09:37:56 -0400

> comfortable giving UAs handles from my own private pool.

There is a huge difference. The UA can remember is instance id or not as 
it sees fit. In that regard it controls its own destiny. If it forgets, 
then old gruus stop working. It can make its own decision if that is 
acceptable, bad, or intended.

With the current scheme, the registrar only needs to remember the 
instance ids while a registration is active. If it can't manage that, 
then it is incompetent to be a registrar. It doesn't have to remember 
them longer. That is a good thing, because it is not in a position to 
decide how long one should remain valid.

Maybe you would just prefer the current scheme, except that the 
registrar is the only source of instance ids. I can see no advantage in 
that over the current scheme. And I do see considerable disadvantage.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 10:18:37 -0400

> to another device, it supposedly needs to take the instance ID with it?

Well, that depends on whether you think it makes sense for a UA to move 
to another device, or whether you thing UAs on different devices are 
intrinsically different.

I don't think there is a single answer to that - it seems to be a 
religious issue. Some time ago I got into a debate about this with some 
IMS folk, regarding how this should work on cell phones.

I though the instance id ought to move around with the ISIM.

Some others had very strong opinions that the instance id should be tied 
to some id (I forget which one) that is tied to the body of the cell 
phone rather than the ISIM.

I gave up on that argument. It can be an individual choice by the maker 
of the device and the software that runs on it.

In any case, it should often be the case that the instance id can be 
derived from some piece of unchanging state that the UA has access to. 
In such cases there is no need for the UA to take extra actions to save it.

There are cases when this isn't the true. The most obvious one to me is 
when a soft phone is installed on a PC. There can be multiple softphones 
potentially running concurrently on the same PC, but operating and 
registering independently of one another. In such a case each one must 
come up with a unique instance id. It may even be the case that the same 
softphone installation can be used by different users on the PC, each 
with a unique identity. In these cases there may be a need to explicitly 
persist the instance id in a store that properly correlated with the 
particular notion of "instance" that makes sense under the circumstances.

> least I would toss that phone out the window pretty quickly. ;)

The black phone can simply derive the instance id from its serial number 
or some other convenient and unchanging piece of info.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Thu, 10 Aug 2006 18:29:11 +0300

> decide how long one should remain valid.

Hmm.. Then I must be reading the specs wrong. To my reading, the
registrar needs to store the instance ID and use it as a search key into
allowed GRUUs for the AOR.

If the registrar didn't need to remember the instance-id -> GRUU mapping
indefinitely to make the GRUU always be assigned to the same instance,
then I don't understand why the UA bothers offering its "+sip.instance"
to the registrar in the first place? In fact, isn't the GRUU effectively
the "cookie" here?

Or is the intention, in fact, that the UA knows nothing whatsoever of
its assigned GRUUs, but uses the instance-ID to fetch the GRUUs from the
registrar in the first REGISTER? Ugh.

What you say holds true for sip-outbound, though, which is partly the
problem I was having with instance-id. In outbound, it is really only a
*recommendation* that the instance-id survives a reboot; if it doesn't,
nothing breaks, and the old flow will simply be garbage-collected sooner
or later anyway by the registrar.

I think there is a disconnect here somewhere (maybe me), because to me,
by your description of the persistence of GRUU, the following things
need to happen:

- A UA generates a GRUU
- The UA remembers the GRUU as long as it seems fit
- The registrar remembers the GRUU indefinitely
- The registrar allows registrations from the same AOR to the GRUU

So effectively, the GRUU *is* the cookie here, and this really boils
down to whether the UA remembers its GRUUs, or just its instance-ID. I'd
argue it better remember its GRUUs. 

Otherwise this demented UA will be receiving lots of requests with no
idea why it's receiving them, and what these different grids are
supposed to do.

> that over the current scheme. And I do see considerable disadvantage.

I guess, but now I'm just confused. ;)

Cheers,
Aki
 
-- 
Aki Niemi
Nokia Research Center

---

From: Dean Willis <[email-masked]>
Date: Thu, 10 Aug 2006 11:55:00 -0500

> to another device, it supposedly needs to take the instance ID with  

As I understand it the new the other device is a different instance,  
so it's a new GRUU.

> that the UA has to store the user credentials, per AOR, in persistent

Yes, there is. The instance-ID can be determined algorithmically from  
things known to the device. The user credentials cannot.

Now, things do get a little fuzzy.

Let's take, for example, a multiple-user UA running on a general- 
purpose computer. It supports N different UA instances, so it devises  
N-different instance IDs.

A naive approach might  take the primary MAC address and concatenate  
1 for the first ID, 2, for the second ID, and so on. So far, so good.

Now, let's say that instance 1 goes to Alice, and Alice has made  
calls that would result in somebody using her GRUU.

The UA loses its hard drive and gets reinstalled. This time, instance  
1 is assigned to Bob.  Is the GRUU factory confused by this? No, as  
has been pointed out, because the GRUU is assembled from both the AOR  
and the instance ID, and we assuming Alice and Bob did not also  
exchange AORs.

Of course, if we REALLY wanted the instance ID to be locally unique,   
we could have synthesized it using a time-date stamp instead of  
starting with 1. Thus, following the reinstall, we get all new  
instance-IDs and all new GRUUs with no potential for overlap or  
confusion.

Of course, this makes the pre-installation GRUUs no longer valid, but  
they MIGHT not have been valid anyhow.

So which approach does the most damage to the immortality of a GRUU?  
I'd argue that they're equal -- GRUUs aren't really eternal, just  
relatively long-lived. The important thing is that when we cross a  
GRUU "generation boundary" is that the GRUU of the next generation  
are either exactly the same as their ancestors (in effect, continuing  
the same GRUU), or that they are completely distinct from their  
ancestors, such that each is unique.

Scenarios where post-reinstall, the GRUU for Alice's UA is the same  
as the GRUU for Bob's UA before reinstall would violate this  
principle, and must be prevented. Fortunately, we seem to have met  
this criteria with the current mechanism.

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 12:55:23 -0400

> allowed GRUUs for the AOR.

There is discretion on how the registrar implements GRUU. It *could* 
implement it in a way that requires storage. But it is also possible to 
implement in a way that does not.

The (actually *a*) way to do this without storage is by the registrar 
placing the instance id, or some invertable mapping of it, and the AOR, 
or some invertable mapping of it, into the gruu. The draft defines the 
"opaque" parameter for this purpose. As long as the instance id and AOR 
can be recovered from the gruu by the home proxy, and some UA is 
registered to the AOR with the instance id, requests addressed to the 
gruu can be routed.

> registrar in the first REGISTER? Ugh.

Yes, exactly. The UA is presumed to remember (or be able to reconstruct) 
its instance id, but not its GRUU.

Each time it registers afresh, it receives its gruu. If the registrar is 
compatible with prior ones for the same AOR, then the gruu returned will 
normally be the same as previously. (This is a matter of applying a 
constant function to the same parameters and so getting the same result.)

In that case, any gruus that happen to have been saved by others will 
work and reach the newly reregistered UA.

> by your description of the persistence of GRUU, the following things

The UA asks the registrar to assign it a gruu

> - The UA remembers the GRUU as long as it seems fit

The UA only has to remember it as long as it remains registered, so it 
can use it as the contact address of dialogs it is involved in.

> - The registrar remembers the GRUU indefinitely

The registrar only needs to remember how to reconstruct the AOR and the 
instance id from gruus it constructed in the past.

> - The registrar allows registrations from the same AOR to the GRUU

I don't understand the above.

> So effectively, the GRUU *is* the cookie here,

The gruu is more than a cookie. If the registrar follows the suggested 
implementation, then the "opaque" parameter is a cookie for the registrar.

> and this really boils

If the UA registers multiple AORs then it can have multiple gruus, but 
it need have only one instance id. And it can be derived from something 
that it already has permanently, rather than being saved. That seems way 
simpler to me.

> idea why it's receiving them, and what these different grids are

Huh? Say more.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 10 Aug 2006 13:06:54 -0500

> totally broken with this approach per se, but it just seems like a bad

Let's pursue this a bit.

Assume a hostile (or simply defective) UA that does something stupid  
like increment its instance-ID on each registration.

As I understand it, this would generate a new GRUU for each  
registration.

Does this consume additional resources on the registrar? Does the  
registrar have to keep a record of each GRUU forever in case some  
request comes in for that GRUU? Is there a recovery cycle for GRUUs,  
like garbage collection?

Or does this error simply result in any messages to the "old" GRUU  
being lost or misrouted, and thereby hurt nobody but the user of the  
misbehaving UA?

Are there things like buffer-overrun attacks that we might think about?

Could I construct a "very long instance-ID" such that some internal  
buffer in the registrar is overrun?

Certainly not without a programming error in the registrar, but such  
errors do happen. Is there any more probability of this happening in  
instance-ID as opposed to any other part of SIP?

Maybe there is. After all, the instance-ID feeds into the GRUU  
calculation, and the resulting GRUU gets written to some sort of  
database (which may be in-memory). Is this really a substantially  
greater risk than any other buffer-overrun attack?

What constitutes a too-long instance-ID and how do we reject it if we  
see one?

I will note here that people probe my web servers with long-URLs a  
couple of times a day, especially when they find a CGI script's entry  
point.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 14:51:36 -0400

Dean Willis wrote:
> As I understand it, this would generate a new GRUU for each registration.
> 
> Or does this error simply result in any messages to the "old" GRUU being 
> lost or misrouted, and thereby hurt nobody but the user of the 
> misbehaving UA?

It *can* be implemented so as to behave as you describe in the last 
paragraph above.

> instance-ID as opposed to any other part of SIP?

I don't think so.

> greater risk than any other buffer-overrun attack?

I think a reasonable implementation is likely not to store the gruu at 
all. It need not be stored to be able to resolve incoming requests 
addressed to it, and it can be computed on the fly in order to return in 
response to REGISTER requests.

> What constitutes a too-long instance-ID and how do we reject it if we 

Depending on who you want to blame, I think either a 400 or 500 response 
would be appropriate.

If we want to worry about this, then there are lots of other things to 
worry about: Branches, to/from tags, callids, (the list goes on and on).

	Paul

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 10 Aug 2006 14:05:59 -0700

Aki,

Taking some of Dean's questions and running with them, I think there
are three kinds of implementations with respect to setting the
instance-id:

1) malicious
2) stupid
3) correct

Examining the implications of the UA setting the instance-id in each
of these cases:

1) It makes no difference who generates the "cookie".  A malicious UA
will probe all the available nooks and crannies.
2) A stupid UA can either change its instance-id when it isn't
supposed to (in which case it is only hurting itself), or it and
another stupid UA can choose the same instance-id and AOR, in which
case only one of the two UAs will work at a time.  They will
effectively "duel".  I expect this would be pretty easy to detect from
the symptoms alone.  I consider this a very minor problem.
3) For correctly implemented UAs, each category of UA generates a UUID
once according to some relavent algorithm.  This UUID is the same for
each target server, for each AOR, etc..  It is easy to store and once
the programmer figures out which algorithm to use, easy to generate.

thanks,
-rohan

---

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Fri, 11 Aug 2006 08:15:00 +0200

See inline. Regards,
/Javier 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: jueves, 10 de agosto de 2006 16:19
To: Aki Niemi
Cc: sip
Subject: Re: [Sip] Question regarding instance ID in GRUU and outbound

Aki Niemi wrote:

>> I also think its easier for a server to remember an instance ID to 
>> GRUU binding for a long time, than it is for a client to remember its

>> cookie for a long time AND for the server to remember the cookie to 
>> GRUU mapping for a long time. GRUU persistence would depend on a 
>> client remembering its cookie basically forever. GRUU currently 
>> doesn't require persistent storage of any soft state in the client.
> 

[Javier] The "id" you refer to above is the IMEI, which is sort of a
"serial number" that is assigned to each cell phone sold around the
globe. Generating the instance ID of a cell phone from its IMEI value
makes a lot of sense. The ISIM holds user-related information only, thus
that information alone cannot be used to generate an instance ID that
refers to the device where the ISIM is running.
That is orthogonal to whether the instance ID must change when a user
moves his ISIM around. The whole point of GRUU is to be able to reach a
specific user at a specific device, in most cases because it is known
that user is answering on that device. Hence if the user moves around
his ISIM the instance ID must change and he will get a new GRUU from the
registrar.

In any case, it should often be the case that the instance id can be
derived from some piece of unchanging state that the UA has access to. 
In such cases there is no need for the UA to take extra actions to save
it.

particular notion of "instance" that makes sense under the
circumstances.

[Javier] IMHO the cases you mention are not a problem. In the first
case, since each softphone's UAS will be bound to its own TCP/UDP port
each softphone might receive different, unique GRUUs if the registrar
includes that port in the generated GRUU. In the second case, since each
user has his own AoR the GRUUs generated will be unique for each user if
the registrar includes the AoR in the GRUU.
A more complex situation arises when the same AoR is registered by
different users through the same shared softphone. In that case the
softphone must set the "grid" parameter to some value unique for each
user (it could be e.g. the user's login name or based on the user's
login password).

> There's really no difference here to the (implicit) requirement on a 
> UA that the UA has to store the user credentials, per AOR, in 
> persistent storage, forever.
> 

[Javier] The UA does not need to store any user-related information, nor
does it need to use different information per AoR. It only needs a bit
of information it knows is unique and unchanging for the device the UA
is running on. The uniqueness characteristic might seem controversial
(i.e. how can it be guaranteed that some device manufactured next year
is not going to produce instance Ids that collide with IMEI or MAC
address values?) but if the URN concept is used properly there should
not be any collision.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Aug 2006 08:30:38 -0400

> his ISIM the instance ID must change and he will get a new GRUU from the

I don't want to get deeply involved in a discussion of this because 
ultimately it is up to the implementor of the device to decide how it 
wants to do this.

IMO the ISIM is the essence of the device, with the rest simply being 
peripherals that it uses. If I drop and break my cell phone, and move 
the ISIM to another one, *I* think that it should be considered to be 
the "same" *instance* for purposes of GRUU, presence, etc.

But other reasonable people think otherwise. I'm satisfied to leave this 
to the discretion of the device implementor.

	Paul

---

From: Dale Worley <[email-masked]>
Date: Fri, 11 Aug 2006 10:43:29 -0400

From: Paul Kyzivat <[email-masked]>

Speaking as someone who as actually implemented GRUU support (in the
sipX open-source proxy, http://www.sipfoundry.org), it is all quite
easy in practice:

At registration time, the registrar hashes the AOR and instance ID
(with a key-string) to generate the GRUU.  This assures that an
AOR/instance pair always generates the same GRUU.

To provide reverse mapping from the GRUU to the contact, the GRUU is
stored in the database record that holds the registration.  This is a
bit more storage, but the registrar already contains a database table
of registrations, so it's not much programming work.

Of course, if a UA decides to use different instance IDs over time, it
gets different GRUUs, but that only interferes with its own operation.
The database records for the additional GRUUs are automatically
garbage collected when the registrations that created them time our or
are superseded.

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Aug 2006 21:56:54 -0700

> - If you want delegated assignment, you can assign an OID, which can

Yes, I agree - but do we have a use case where someone wants to use  
an OID?

---

From: [email-masked]
Date: Mon, 14 Aug 2006 18:01:10 -0400

I, personally, like OIDs (in the abstract, not for instance IDs), but
that's not important.

Every once in a while, someone mentions that it would be useful to
allow for delegated administrative assignment of instance IDs.  OIDs
are a natural solution to that problem.  I've not heard of anyone
saying that *they* want delegated administrative assignment of
instance IDs, but people mention it as a possibility.

But the bigger point is that there are types of URNs for creating
almost any sort of naming scheme, and by letting an instance ID be a
general URN, we inherit all of that work.

Dale