Subject: [Sipping] Device Identity

From: "De Leo Walter" <[email-masked]>
Date: Wed, 15 Feb 2006 12:15:25 -0300

Hi.
Does anybody know if there is a "standarized" way (tag, header or
whatever) to convey an identity of the device from which a message is
being sent?  I refer to a hardware identity (ATA, IP-Phone, PC runing a
Softphone) something like, MAC, serial number, that uniquely identifies
a device.
 
Thank you and best regards.
Walter D. De Leo.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 15 Feb 2006 10:35:04 -0500

On Wed, 2006-02-15 at 12:15 -0300, De Leo Walter wrote:
> being sent?  I refer to a hardware identity (ATA, IP-Phone, PC runing
> a Softphone) something like, MAC, serial number, that uniquely
> identifies a device.

There is the "+sip.identity" parameter that a UA puts on its Contact
when registering so that the registrar will give it a GRUU.  That value
is expected to be globally unique.  And the GRUU is bound to the
identity, so if the Contact in a request is a GRUU (which, IIRC, you can
usually tell due to the presence of the "opaque" parameter), it would
function fairly well as a calling-UA-identity.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Feb 2006 11:23:06 -0500

Minor clarification; its the +sip.instance contact header field 
parameter, defined in 
http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-06.txt/

The draft talks about uniqueness requirements.

-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: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 15 Feb 2006 19:04:52 +0100

In addition, see 
http://www3.ietf.org/proceedings/05mar/IDs/draft-ietf-sipping-config-framework-06.txt
3.13.1  Device URIsfor the formatting of MAC addresses

Jeroen

PS Jonathan, perhaps the GRUU draft should reference this section for a 
suggested syntax of +sip.instance ?

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Dale R. Worley" <[email-masked]>
Cc: "Sipping" <[email-masked]>
Sent: Wednesday, February 15, 2006 5:23 PM
Subject: Re: [Sipping] Device Identity

> Minor clarification; its the +sip.instance contact header field parameter, 
> defined in http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-06.txt/
>

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 15 Feb 2006 13:17:05 -0500

> suggested syntax of +sip.instance ?

It seems like these "MAC:" pseudo-URIs should be registered as a proper
URI scheme.

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Feb 2006 17:57:42 -0600

> It seems like these "MAC:" pseudo-URIs should be registered as a  

I'm strongly inclined to agree.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Feb 2006 10:37:34 -0500

Me too. This has bugged me since it first started being used. I bitched 
at the time, but never followed up. :-(

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 16 Feb 2006 13:49:16 -0500

> >> It seems like these "MAC:" pseudo-URIs should be registered as a  proper

What if I write a section of the I-D that is a proper request to
register "MAC:" as a URI-scheme?  If it can stand alone as a
registration request, and also be a section of the I-D, I would think it
should be fairly easy to get it approved as a URI-scheme.

Dale

---

From: Josh Littlefield <[email-masked]>
Date: Thu, 16 Feb 2006 14:25:08 -0500

> should be fairly easy to get it approved as a URI-scheme.

If this discussion is around the MAC: pseudo-URI in the 
sipping-config-framework, I should point out that it does not use MAC: 
as a URI scheme.  MAC: is a username convention used in a normal SIP: URI.

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Feb 2006 13:37:54 -0600

> should be fairly easy to get it approved as a URI-scheme.

Don't we have different underlying registries for different sorts of  
MAC address: ethernet, token-ring, FDDI, etc.?

Also in the mobile world, we have ESN, IMEI, IMSI, and MEID registries.

I suspect we need a different URI scheme for each MAC address type.

I also have a vague memory of somebody else already working on this.

The guy to ask is Michael Mealling, [email-masked]. I'll  
ask him.

--
Dean

---

From: Josh Littlefield <[email-masked]>
Date: Thu, 16 Feb 2006 15:00:33 -0500

Dean Willis wrote:
> 
> On Feb 16, 2006, at 1:25 PM, Josh Littlefield wrote:
> 
>> Dale R. Worley wrote:
> It should also be pointed out that  RFC 4122 defines a process for 
> mapping things like MAC Addresses into UUID URNs. Not quite as tidy as 
> having a separate namespace for each address/name type, but perhaps good 
> enough.

Right, and sipping-config-framework allows exactly this form or UUID 
URI/URN as well.  The benefit of the purely MAC-based form specified there:

	sip:[email-masked]

is that it IS predictable for hard clients when only the MAC address is 
written on the box.  I'm also aware of a situation where certificate 
based authentication, using existing certificates that validate a MAC 
address, could leverage this nicely.  No way to apply those certificates 
to a UUID that factors in an unknown time value.

> 
> The algorithm as given in section 4.3 of 4122 follows:
> 
> 
> 4.3.  Algorithm for Creating a Name-Based UUID
> 
>    The version 3 or 5 UUID is meant for generating UUIDs from "names"
>    that are drawn from, and unique within, some "name space".  The
>    concept of name and name space should be broadly construed, and not
>    limited to textual names.  For example, some name spaces are the
>    domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished
>    Names (DNs), and reserved words in a programming language.  The
>    mechanisms or conventions used for allocating names and ensuring
>    their uniqueness within their name spaces are beyond the scope of
>    this specification.
> 
>    The requirements for these types of UUIDs are as follows:
> 
>    o  The UUIDs generated at different times from the same name in the
>       same namespace MUST be equal.
> 
>    o  The UUIDs generated from two different names in the same namespace
>       should be different (with very high probability).
> 
>    o  The UUIDs generated from the same name in two different namespaces
>       should be different with (very high probability).
> 
>    o  If two UUIDs that were generated from names are equal, then they
>       were generated from the same name in the same namespace (with very
>       high probability).
> 
>    The algorithm for generating a UUID from a name and a name space are
>    as follows:
> 
>    o  Allocate a UUID to use as a "name space ID" for all UUIDs
>       generated from names in that name space; see Appendix C for some
>       pre-defined values.
> 
>    o  Choose either MD5 [4] or SHA-1 [8] as the hash algorithm; If
>       backward compatibility is not an issue, SHA-1 is preferred.
> 
>    o  Convert the name to a canonical sequence of octets (as defined by
>       the standards or conventions of its name space); put the name
>       space ID in network byte order.
> 
>    o  Compute the hash of the name space ID concatenated with the name.
> 
>    o  Set octets zero through 3 of the time_low field to octets zero
>       through 3 of the hash.
> 
>    o  Set octets zero and one of the time_mid field to octets 4 and 5 of
>       the hash.
> 
>    o  Set octets zero and one of the time_hi_and_version field to octets
>       6 and 7 of the hash.
> 
>    o  Set the four most significant bits (bits 12 through 15) of the
>       time_hi_and_version field to the appropriate 4-bit version number
>       from Section 4.1.3.
> 
>    o  Set the clock_seq_hi_and_reserved field to octet 8 of the hash.
> 
>    o  Set the two most significant bits (bits 6 and 7) of the
>       clock_seq_hi_and_reserved to zero and one, respectively.
> 
>    o  Set the clock_seq_low field to octet 9 of the hash.
> 
>    o  Set octets zero through five of the node field to octets 10
>       through 15 of the hash.
> 
>    o  Convert the resulting UUID to local byte order.
> 
> 
> Now, the problem with this is that although it gives us a pretty unique 
> identifier, it's both hard to predict (as it includes time-based 
> information), and it doesn't let us make declarations about the source 
> of the name, like "I want this request to go to Dale's contacts that 
> have a device identifier in the MEID: namespace, but not to his contacts 
> that have a device identifier in the IMSI: namespace."
> 
> -- 
> Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Feb 2006 13:51:41 -0600

On Feb 16, 2006, at 1:25 PM, Josh Littlefield wrote:

> If this discussion is around the MAC: pseudo-URI in the sipping- 
> config-framework, I should point out that it does not use MAC: as a  
> URI scheme.  MAC: is a username convention used in a normal SIP: URI.

It should also be pointed out that  RFC 4122 defines a process for  
mapping things like MAC Addresses into UUID URNs. Not quite as tidy  
as having a separate namespace for each address/name type, but  
perhaps good enough.

    o  The UUIDs generated from two different names in the same  
namespace
       should be different (with very high probability).

    o  The UUIDs generated from the same name in two different  
namespaces
       should be different with (very high probability).

    o  If two UUIDs that were generated from names are equal, then they
       were generated from the same name in the same namespace (with  
very
       high probability).

    o  Set octets zero and one of the time_mid field to octets 4 and  
5 of
       the hash.

    o  Set octets zero and one of the time_hi_and_version field to  
octets
       6 and 7 of the hash.

Now, the problem with this is that although it gives us a pretty  
unique identifier, it's both hard to predict (as it includes time- 
based information), and it doesn't let us make declarations about the  
source of the name, like "I want this request to go to Dale's  
contacts that have a device identifier in the MEID: namespace, but  
not to his contacts that have a device identifier in the IMSI:  
namespace."

--
Dean

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 16 Feb 2006 14:49:00 -0500

> MAC address: ethernet, token-ring, FDDI, etc.?

My belief (which may be wrong) is that all MACs are drawn from the same
number space, which is managed and assigned by the IEEE.  If so, we
don't need to have separate schemes for different sorts of MACs.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 17 Feb 2006 08:29:58 +0100

[ .. snap ... ]
> identifier, it's both hard to predict (as it includes time- based 
> information), and it doesn't let us make declarations about the  source of 
> the name, like "I want this request to go to Dale's  contacts that have a 
> device identifier in the MEID: namespace, but  not to his contacts that 
> have a device identifier in the IMSI:  namespace."
>
> --
> Dean

Dean,

Wouldn't this particular scenario be better served using "Accept-Contact: 
*;mobility="mobile";methods="INVITE" (RFC3841 section 5.2)

To my knowledge callerprefs has no mechanism to express preferences on the 
namespace of the target's contact. I also doubt whether it would really be 
useful.

It seems we are mixing several issues in this thread:

1) official registration of device identifier namespaces (note that "MAC" 
IMO isn't the appropriate term)
2) use of unique, generated, predictable, fixed (non-random) identifiers as 
part of SIP URIs

(2) could make use of (1), but I'm not sure if the username part is the 
thing to (ab)use for this. It adds a kind of 'hidden' structure to it.

What about defining additional user-param tokens for this purpose? i.e.
sip:[email-masked];user=MAC
sip:[email-masked];user=IMSI

"user=phone" is already used to indicate that the username part should be 
interpreted as a phonenumber, and is included in URI comparison rules 
(unlike arbitrary parameters).

Regards,

Jeroen

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Feb 2006 18:39:26 -0800

Some early version of draft-jennings-sipping-instance-id define some of
this. However, people pointed out that UUID already was capable of doing
this, and even better UUID could work for softphone too. It seemed like UUID
was a super set of everything we need so I abandoned that draft.

It seems like a UUID in the +sip.instance meets the needs people have
identified.

Cullen