Subject: RE: [Sip] SIP instance identifiers

From: "Brian Stucker" <[email-masked]>
Date: Wed, 18 Feb 2004 01:26:52 -0600

Inline...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 10:32 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [Sip] SIP instance identifiers
> 
> 
> 
> 
> Paul Kyzivat wrote:
> 
> > Jonathan,
> > 
> > I like using a callee-cap feature tag in a registration. 
> OTOH, I can see 
> > validity in Brian's desire to have it in a header of its own, 
> > potentially in any message. I don't see those usages as conflicting.
> 
> No, but it represents additional work.

A very small amount of additional work, and I believe the majority of it
has already been handled in my draft (specifically defining the header). 
We've agreed that there's a need for a mechanism like this
for PUBLISH. There's an obvious hole in generating meaningful instance 
identifiers for PIDF documents and the such. Other state aggregation
mechanisms
in the future are easily envisionable that would need to know which unique 
client sent a request, where it would be useful to have that information
transported in a request in a handy mechanism.

Why not take care of both problems in one shot, define the (minimal)
interactions
and then follow things up in the various drafts like PUBLISH and any others
that
see a need for this where they define the appropriate policy for using the
instance identifier they've been given ala RFC-3265. Define the basic
mechanism
(in that case SUBSCRIBE/NOTIFY) and let others define the usages.

> 
> > 
> > The only potential conflict would be in REGISTER, but that 
> isn't a real 
> > conflict - a Guid header would describe the entity sending 
> the REGISTER 
> > message, while the +sip.instance tag on a contact would 
> describe the 
> > endpoint being registered. Often they would be the same, but not 
> > necessarily.
> 
> This makes sense.

Agreed. The two mechanisms can easily live together much like an 
expires header in the registration does along side one in the contact.

> 
> > 
> > Regarding the form of guids, I don't think any single 
> scheme works in 
> > all cases. My preference is to:
> > 
> > - represent the instance id as a URI
> > 
> > - make it the responsibility of the endpoint to select a URI
> >   that is unique
> > 
> > - Recommend that a URN be used.
> > 
> > - Define a couple of new URN namespaces that are especially
> >   suitable for this purpose. (I have in mind urn:mac:xxx for
> >   mac addresses, and possibly urn:random:xxx for random numbers
> >   in some large range.)
> 
> This is a well trod area, and I think it would behoove us to look at 
> work in other groups. Dean has mentioned HIP as one obvious 
> candidate; 
> generally speaking this exact issue - of endpoint identifiers 
> that work 
> better than IP address, is the subject of much other work at this 
> moment, including MAST. I'm not familiar enough with it to 
> know if its 
> relevant... its on my reading list for this ietf.
> 
> 

This represents additional work as well. =)

I think we're limiting ourselves to just MACs and random numbers. Having
looked around a bit, I've seen material (I want to say it's from WebDAV
but I could be remembering incorrectly) that the MAC address isn't always
a good thing to pass around because you can figure out that the UA is 
running on a particular piece of hardware without otherwise having access
to their MAC (because you're on the other side of the world many routers
away). That can be used to determine a method of attack because you can 
inferr what operating systems, etc might be running if you know what kind
of hardware that box is plugged into the network with.

That said, if you want to use a MAC, fine. Buyer beware. If you want to use
a random number, fine. If you want to use the GPS coordinates of the box to
some ridiculous level of precision (and that's good enough for your
application)
fine. 

I don't see why we necessarily need to put any restrictions on this
instance ID to make it a URN or anything else when it really need not be any
more complex than a VIA branch. I also don't see a reason why we should
expect
other nodes in the network to be able to use the instance identifier for
anything
other than a token (ie. if it's a mac address, and two UA instances do
something
because it's a MAC address, that's OK, but other's may not take that tact).
There's
no guarantee others are going to be able to take whatever action might be
denoted
by the contents of the instance identifier itself, so it becomes entirely 
proprietary at that point. 

> > 
> > A couple of other comments:
> > 
> > Section 7.1 says:
> > 
> >    The combination of a UA instance ID and an AOR is 
> referred to as an
> >    instance ID/AOR pair. There is a one-to-one mapping 
> between such a
> >    pair and a GRUU; ...
> > 
> > And figure 2 shows the corresponding 1:1 relationship. But it isn't 
> > necessarily 1:1. It should be 1:0..1 because it is possible 
> to have an 
> > instance ID/AOR Pair that doesn't have a GRUU. (Instance IDs are 
> > valuable in their own right.)
> 
> OK, I'll update the diagram.
> 
> > 
> > This 1:0..1 relationship imposes another error condition on 
> registrars. 
> > If an attempt is made to register a contact with an 
> instance id in use 
> > by some other contact of the same AOR, the registrar will 
> have to refuse 
> > it. 
> 
> Well, thats one option.

This is why I put some boundaries on the length of the GUID and some
basic guidelines, to make this very unlikely to occur for reasonably 
well behaved implementations.

> 
> This needs to be spelled out somewhere, and a suitable error
> > identified. (I don't know if any of the existing responses 
> works for 
> > this. At the least, a new Reason code is likely to be needed.)
> 
> Here is the use case for this. The use case is when a UA crashes, 
> recovers, obtains a new IP, and re-registers. In this case, several 
> things could possibly happen:
> 
> 1. The registrar accepts the second registration, as per normal 
> registration procedures. An INVITE to the gruu bound to that 
> id/aor pair 
> gets translated into BOTH contacts, causing the request to 
> fork. There 
> is never any response from the old IP. Within one refresh 
> interval, the 
> old contact is removed and all is well.
> 
> 2. The registrar accepts the second registration, and automatically 
> deletes the old one. I believe Brian proposed this behavior.
> 
> 3. The registrar returns an error. The client fetches the 
> current list 
> of contacts, finds the old one listed, and unregisters it.
> 
> 
> 
> Approach 1 is problematic, as it will introduce herfp; any 
> non-2xx from 
> the new contact will wait for the 2nd branch to timeout. Its 
> not clear 
> to me whether 2 or 3 is more right. It depends a lot on who owns the 
> policy for how to resolve the conflict - is it the server or 
> the client?

Agree on 1 being bad.

IMHO it's the server that owns the policy. If the client is too dumb to 
remember their previous contact address, then it's probably too stateless
to make policy decisions about which contact should be removed too
(otherwise
it would have simply deregistered that contact in the first place).

> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Feb 2004 10:11:27 -0500

Responding to both Jonathan and Brian inline...

	Paul

>  > From: Jonathan Rosenberg [mailto:[email-masked]]
...
>  > relevant... its on my reading list for this ietf.

I'm fine with reusing existing work. What is HIP?

My primary point is to give the endpoint flexibility in the form of 
identifier it uses by representing the identifier as a URI.

Beyond that, I wanted to ensure that we had a way to use a mac address 
as one of the options. I didn't find a way to do that in URI/URN form, 
which is why I suggest defining a new URN namespace for this. If there 
is some other standard that already achieves this, fine.

I'm not at all attached to any particular way of using random numbers. 
I'm happy with pretty much anything that permits an instance of a 
software endpoint on a multi-user/multi-application box to come up with 
a guid.

> I think we're limiting ourselves to just MACs and random numbers.

I'm not suggesting *limiting* to macs and random numbers. Just that tese 
be available options.

 > Having
> because it's a MAC address, that's OK, but other's may not take that 
> tact). There's
> no guarantee others are going to be able to take whatever action might 
> be denoted

The reason to use URIs/URNs is to manage the namespaces. Your MAC-based 
id may collide with my timestamp-based id if there isn't something to 
distinguish that they come from different namespaces. For that matter, 
your mac-based id may conflict with my mac-based id if we choose to 
format them differently.

By using URIs, there is always some specification that governs the 
format and defines uniqueness within that format, while the scheme name 
itself ensures uniqueness of ids generated based on different 
specifications.

>  > > by some other contact of the same AOR, the registrar will

You are right - there are other options.

> well behaved implementations.

That assumes it isn't done on purpose.

In any case, the whole concept of GRUUs is based on the uniqueness, so 
the registrar is bound to enforce this uniqueness, one way or another.

>  > the new contact will wait for the 2nd branch to timeout.

This is also problematic because it violates the invariant on which GURR 
is based - that it always represents a single endpoint.

>  >  Its not clear

I agree that the right choice here isn't immediately obvious. But having 
the registrar generate an error is a way to push the decision back on 
the endpoint. If it wants to prevail then it can send a new REGISTER 
that removes the old conflicting contact as well as adding its own new 
one. Or it can just give up.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2004 18:00:58 -0800

On 2/17/04 11:26 PM, "Brian Stucker" <[email-masked]> wrote:

> . I also don't see a reason why we should expect

I sort of agree and sort of don't. The only important thing about MAC is
that most phone vendors have it on the outside of the box and you can read
it with a barcode scanner. If a user goes to some configuration web page and
see that they have 2 devices registered, they have some hope of finding an
identifier on the back of the phone (the MAC) that they can match to one of
the two instances on the web page.