Subject: [Geopriv] GRUU in HELD Identities

From: "Sherry, Robert" <[email-masked]>
Date: Mon, 19 Mar 2007 13:44:57 -0500

This is a recommendation to add GRUUs to the list of heldDevice
enumerations in
draft-winterbottom-geopriv-held-identity-extensions-01.txt.

The GRUUs define a specific instance of a UA and are described in
http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt

The schema might look as follows.

<xs:element name="gruu">

                        <xs:annotation>

                                    <xs:documentation>gruu based upon
draft-ietf-sip-gruu-12 </xs:documentation>

                        </xs:annotation>

                        <xs:complexType>

                                    <xs:sequence>

                                                <xs:element
name="pub_gruu" type="xs:anyURI" minOccurs="0"/>

                                                <xs:element
name="temp_gruu" type="xs:anyURI" minOccurs="0"/>

                                                <xs:element name="uuid"
type="xs:token" minOccurs="0"/>

                                    </xs:sequence>

                        </xs:complexType>

            </xs:element>

However, I would be satisfied it just uuid were included.

Bob Sherry, ENP 

Intrado Inc.

3030 Warrenville Rd, 4th Floor

Lisle, IL 60532

direct: 630-300-2838   mobile: 630-880-3704

fax: 720-494-6600  email: [email-masked]

Intrado

www.intrado.com 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 19 Mar 2007 17:26:14 -0400

I'm not sure how good of an idea this is

1.	You probably need some other identifier that lets the registrar
associate a location with the endpoint.  I'm not sure what that would be.
Normally, the registrar doesn't have that kind of information.  Any device
that has the user's credentials is normally indistinguishable from any other
device with those credentials.  The GRUU can keep the devices straight, so
that if there are more than one device which are simultaneously registered
with the same AoR, the GRUU will be unique for that device.  But it doesn't
usually know where the device is.  It doesn't usually have any other
information that a LIS could use to identify the device for location
purposes either.
2.	A GRUU is pretty ephemeral.  It's typically good as long as the user
maintains a registration at the SIP registrar.  That is pretty useful for
the emergency case, and probably most other uses of location, but it may not
be useful in some circumstances.  
3.	You need a correlation between the LIS and the registrar, so it
probably only works in a situation where the access network and the calling
network are operated by the same entity.  

Brian  

  _____  

From: Sherry, Robert [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 2:45 PM
To: [email-masked]
Subject: [Geopriv] GRUU in HELD Identities

This is a recommendation to add GRUUs to the list of heldDevice enumerations
in draft-winterbottom-geopriv-held-identity-extensions-01.txt.

<xs:element name="gruu">

                        <xs:annotation>

                        </xs:annotation>

                        <xs:complexType>

                                    <xs:sequence>

                                                <xs:element name="pub_gruu"
type="xs:anyURI" minOccurs="0"/>

                                                <xs:element name="temp_gruu"
type="xs:anyURI" minOccurs="0"/>

                                                <xs:element name="uuid"

                                    </xs:sequence>

                        </xs:complexType>

            </xs:element>

Bob Sherry, ENP 

Intrado Inc.

Lisle, IL 60532

Intrado

www.intrado.com

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 19 Mar 2007 16:32:52 -0500

Hi Bob,

A GRUU is just a SIP URI with special properties.  If this is a necessary identifier (emphasis on “if”, c.f. Brian’s reply) the <link> element can be used.  I don’t see any need to include additional parameters.

Cheers,

Martin

________________________________

From: Sherry, Robert [mailto:[email-masked]] 
Sent: Tuesday, 20 March 2007 5:45 AM
To: [email-masked]
Subject: [Geopriv] GRUU in HELD Identities

This is a recommendation to add GRUUs to the list of heldDevice enumerations in draft-winterbottom-geopriv-held-identity-extensions-01.txt.

The GRUUs define a specific instance of a UA and are described in http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-12.txt

<xs:element name="gruu">

                        <xs:annotation>

                                    <xs:documentation>gruu based upon draft-ietf-sip-gruu-12 </xs:documentation>

                        </xs:annotation>

                        <xs:complexType>

                                    <xs:sequence>

                                                <xs:element name="pub_gruu" type="xs:anyURI" minOccurs="0"/>

                                                <xs:element name="temp_gruu" type="xs:anyURI" minOccurs="0"/>

                                                <xs:element name="uuid" type="xs:token" minOccurs="0"/>

                                    </xs:sequence>

                        </xs:complexType>

            </xs:element>

Bob Sherry, ENP 

Intrado Inc.

Lisle, IL 60532

Intrado

www.intrado.com 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Mon, 19 Mar 2007 20:47:53 -0400

> information that a LIS could use to identify the device for location

I guess that depends on the level of sophistication of your  
registrar.  A good many registrars do create a binding between the  
endpoint, as much as it can be known through tricks like STUN, etc..,  
and AoR (and probably GRUU once it is more widely supported).

> network are operated by the same entity.

I think this is the better point, but I see no reason not to have  
this identity for those environments where it could be used.  We're  
not talking about disallowing other identifiers.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 19 Mar 2007 23:54:31 -0500

Okay I will add a GRUU type in the next release of this draft.

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Tuesday, 20 March 2007 11:48 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: [Geopriv] GRUU in HELD Identities
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 20 Mar 2007 04:18:18 -0400

I'm not following your thought in 1).  Suppose I have 3 endpoints that
register the same AoR.  They have the credentials to do that, and the
registrar permits that (say, it forks incoming calls to all of them).  Are
you aware of a registrar that could know which device was which?  Most
registrars I know that can handle more than one registration don't have any
mechanism that would know the difference between the snom phone in my house,
the cisco TA in my office and the Nokia handheld that walks around with me.
They all have my credentials.  They would each have a unique GRUU if they
were all registered with my AoR, but which one was which would not be known
to the registrar.  Presence could very well know the difference, but not the
registrar.

Does your mileage vary?

Brian

> Sent: Monday, March 19, 2007 8:48 PM
> To: Brian Rosen
> Cc: 'Sherry, Robert'; [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Tue, 20 Mar 2007 06:04:16 -0400

> to the registrar.  Presence could very well know the difference,  

I don't think it matters.  The client asks the registrar for its  
location using the GRUU.  The registrar looks at the GRUU-to-endpoint  
mapping that it has (which might be 10.0.0.5:48001), then consults  
its location table for the endpoint (most likely, a network map that  
says "network 10.0.0/24 is at 923 Main St., Topeka, KS").

Thinking about this entire space does make me ask one question: with  
the list of HELD identities topping 22 now, how is a client to know  
which identity to use?  Does it send everything it has in hopes that  
the LIS supports just one of them?  Certainly, every LIS will not  
support every type of identity.

-andy

---

From: "Sherry, Robert" <[email-masked]>
Date: Tue, 20 Mar 2007 10:45:01 -0500

So according to the gruu draft a gruu can have three attributes: the
Public gruu and Private gruu which are URIs and uuid

However, the uuid is a fixed format and is what the UA would register
with.

This allows different UAs with the same TN.

To Brian's point uuids are globally unique so can be used in which ever
network a UA can register.

Bob Sherry, ENP 

Intrado Inc.

Lisle, IL 60532

Intrado

www.intrado.com 

From: Thomson, Martin [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 4:33 PM
To: Sherry, Robert; [email-masked]
Subject: RE: [Geopriv] GRUU in HELD Identities

Hi Bob,

A GRUU is just a SIP URI with special properties.  If this is a
necessary identifier (emphasis on "if", c.f. Brian's reply) the <link>
element can be used.  I don't see any need to include additional
parameters.

Cheers,

Martin

<xs:element name="gruu">

                        <xs:annotation>

                        </xs:annotation>

                        <xs:complexType>

                                    <xs:sequence>

                                                <xs:element

                                                <xs:element

                                                <xs:element name="uuid"

                                    </xs:sequence>

                        </xs:complexType>

            </xs:element>

Bob Sherry, ENP 

Intrado Inc.

Lisle, IL 60532

Intrado

www.intrado.com 

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Sherry, Robert" <[email-masked]>
Date: Tue, 20 Mar 2007 10:50:22 -0500

I think there has to be a correlation between the identity that is
registered and the identity that the LIS knows.
I would expect a type of UA to use only one identity.
(Although I could see TN and MAC. With MAC being the unique identifier
and TN used for tracking or logging.)
The LIS would have to support many types of identities depending upon
what types of access networks it supports.

Bob Sherry, ENP 

Intrado Inc.

Lisle, IL 60532

Intrado

www.intrado.com 

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2007 5:04 AM
To: Brian Rosen
Cc: Sherry, Robert; [email-masked]
Subject: Re: [Geopriv] GRUU in HELD Identities

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 20 Mar 2007 13:02:47 -0400

> what types of access networks it supports.

Naturally, the LIS can only usefully support the identities relevant  
to the networks in which it is deployed.  However, a client can be  
deployed in many types of networks and can jump from one type to  
another.  How does it know which identity to send to the LIS?

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 20 Mar 2007 18:21:12 +0100

The end host sends all identities it has to the LIS --> great for privacy.

Ciao
Hannes

---

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Mar 2007 18:41:42 +0100

If we had some taxonomy (say, an IANA registry?) on classes of these 
identifiers, couldn't this be part of the LIS discovery?  Result of 
discovery is: "Here's the LIS to contact, and the identifiers to send."

--Richard

Andrew Newton wrote:
> Naturally, the LIS can only usefully support the identities relevant to 
> the networks in which it is deployed.  However, a client can be deployed 
> in many types of networks and can jump from one type to another.  How 
> does it know which identity to send to the LIS?
> 
> -andy
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 20 Mar 2007 13:58:40 -0400

On Mar 20, 2007, at 1:41 PM, Richard Barnes wrote:

> If we had some taxonomy (say, an IANA registry?) on classes of  
> these identifiers, couldn't this be part of the LIS discovery?   
> Result of discovery is: "Here's the LIS to contact, and the  
> identifiers to send."

As Hannes noted, we have fairly serious privacy and security issue  
here.  Even if you only send an identifier that is part of discovery,  
only identifiers truly associated with the network avoids problems.

Accidently attaching to a wireless network run by Evil, Inc. and  
automatically sending your telephone number or private GRUU is  
probably not a good idea.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 20 Mar 2007 14:31:39 -0400

For a consumer-grade end device that's not knowingly connecting to a
mobile network, it doesn't look too bad, to me. I see ipV4 and ipV6. And
a device should know whether the IP address that it wants to use is v4
or v6. mac and lldp look like they could be optionally used when a
location assertion is being done, but I wouldn't use them for a LIS
query (to acquire location). I'm not sure how useful ssid is, but I
can't think of a really good application for it. Especially not for
consumer devices.
 
For LIS-LIS, the querying LIS is going to have to know what identifiers
it needs to use for a particular access network LIS. That will be
programmatically defined in the querrying LIS, and shouldn't be
difficult. This includes atm, vlan, l2tp, nas-ip-address, and
nas-identifier. I'm not sure how dhcp or access-node-id would be used,
but they aren't things that would be known by an end device.
 
For mobile devices, I'm clueless as to what they would be doing. It
looks like it might depend on the type of network they're connecting to?
I think the following apply to mobile devices: msisdn, imsi,
directorynumber, imei, mdn, min.
 
extension looks like it would only work on devices intended to operate
in a PBX environment. If that's the case, I would expect it to be a
non-consumer, custom, closed environment.
 
Which leaves link and depend, where link is anything you want it to be
(and therefore only useful in custom, closed environments), and depend
is associated with the signatures that we haven't resolved.
 
So, I don't really see what the problem is with this long list. There's
flexibility for custom, closed environments, and for LIS-LIS, but
regular consumer devices aren't burdened with lots of IDs. Unless there
are too many mobile identifiers, since I don't know about those things. 
Barbara

From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2007 1:03 PM
To: Sherry, Robert
Cc: [email-masked]
Subject: Re: [Geopriv] GRUU in HELD Identities

	I think there has to be a correlation between the identity that
is

	(Although I could see TN and MAC. With MAC being the unique
identifier

	The LIS would have to support many types of identities depending
upon

-andy

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Andrew Newton <[email-masked]>
Date: Tue, 20 Mar 2007 15:11:05 -0400

Barbara,

Thanks for pointing out that some of the identifiers are not relevant  
to LCP and only relevant to LIS-to-LIS.

However,  msisdn, directoryNumber, mdn, and extension all seem to be  
phone numbers (or part of one) that can be used externally of the  
specific network and which can be tracked back to the user.  That's a  
privacy issue.

Additionally, imsi, imei, and min appear to be tied to specific  
devices, which can also be related back to a user.  Again, that's a  
privacy issue.

And while link sounds useful, if the client doesn't know when to send  
it, then it could also potentially leak user sensitive information.

Finally, GRUUs that contain an AoR might also leak user sensitive  
information.

-andy

On Mar 20, 2007, at 2:31 PM, Stark, Barbara wrote:

> For a consumer-grade end device that's not knowingly connecting to  
> a mobile network, it doesn't look too bad, to me. I see ipV4 and  
> ipV6. And a device should know whether the IP address that it wants  
> to use is v4 or v6. mac and lldp look like they could be optionally  
> used when a location assertion is being done, but I wouldn't use  
> them for a LIS query (to acquire location). I'm not sure how useful  
> ssid is, but I can't think of a really good application for it.  
> Especially not for consumer devices.
>
> For LIS-LIS, the querying LIS is going to have to know what  
> identifiers it needs to use for a particular access network LIS.  
> That will be programmatically defined in the querrying LIS, and  
> shouldn't be difficult. This includes atm, vlan, l2tp, nas-ip- 
> address, and nas-identifier. I'm not sure how dhcp or access-node- 
> id would be used, but they aren't things that would be known by an  
> end device.
>
> looks like it might depend on the type of network they're  
> connecting to? I think the following apply to mobile devices:  
> msisdn, imsi, directorynumber, imei, mdn, min.
>
> extension looks like it would only work on devices intended to  
> operate in a PBX environment. If that's the case, I would expect it  
> to be a non-consumer, custom, closed environment.
>
> Which leaves link and depend, where link is anything you want it to  
> be (and therefore only useful in custom, closed environments), and  
> depend is associated with the signatures that we haven't resolved.
>
> So, I don't really see what the problem is with this long list.  
> There's flexibility for custom, closed environments, and for LIS- 
> LIS, but regular consumer devices aren't burdened with lots of IDs.  
> Unless there are too many mobile identifiers, since I don't know  
> about those things.
> Barbara
> Naturally, the LIS can only usefully support the identities  
> relevant to the networks in which it is deployed.  However, a  
> client can be deployed in many types of networks and can jump from  
> one type to another.  How does it know which identity to send to  
> the LIS?
>
> -andy
> *****
>
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential,  
> proprietary, and/or privileged material. Any review,  
> retransmission, dissemination or other use of, or taking of any  
> action in reliance upon this information by persons or entities  
> other than the intended recipient is prohibited. If you received  
> this in error, please contact the sender and delete the material  
> from all computers. GA622

---

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Mar 2007 22:57:21 +0100

> Additionally, imsi, imei, and min appear to be tied to specific devices, 
> which can also be related back to a user.  Again, that's a privacy issue.

OK, I'm a confused here.  In order to locate something, you need to 
identify a unique physical thing to locate.  But you're saying that 
transmitting something that identifies a unique physical thing is a 
privacy violation?

I'm not an expert here, but aren't those identifiers transmitted to the 
access network anyway, as part of the attachment process?  (And 
analogously for other physical/MAC-layer identifiers in other 
scenarios.)  If that's the case, then how is using them to query a LIS 
controlled by the access network any more a privacy violation?

--RB

>> mobile network, it doesn't look too bad, to me. I see ipV4 and ipV6. 
>> And a device should know whether the IP address that it wants to use 
>> is v4 or v6. mac and lldp look like they could be optionally used when 
>> a location assertion is being done, but I wouldn't use them for a LIS 
>> identifiers it needs to use for a particular access network LIS. That 
>> will be programmatically defined in the querrying LIS, and shouldn't 
>> be difficult. This includes atm, vlan, l2tp, nas-ip-address, and 
>> looks like it might depend on the type of network they're connecting 
>> to? I think the following apply to mobile devices: msisdn, imsi, 
>> There's flexibility for custom, closed environments, and for LIS-LIS, 
>> but regular consumer devices aren't burdened with lots of IDs. Unless 
>> there are too many mobile identifiers, since I don't know about those 
>> things.
>> Barbara
>> The information transmitted is intended only for the person or entity 
>> to which it is addressed and may contain confidential, proprietary, 
>> and/or privileged material. Any review, retransmission, dissemination 
>> or other use of, or taking of any action in reliance upon this 
>> information by persons or entities other than the intended recipient 
>> is prohibited. If you received this in error, please contact the 
>> sender and delete the material from all computers. GA622
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 20 Mar 2007 18:48:44 -0400

On Mar 20, 2007, at 5:57 PM, Richard Barnes wrote:

> I'm not an expert here, but aren't those identifiers transmitted to  
> the access network anyway, as part of the attachment process?  (And  
> scenarios.)  If that's the case, then how is using them to query a  
> LIS controlled by the access network any more a privacy violation?

Admittedly, you have a point.

Though a MAC is only required to be unique on a network, and  
therefore could be changed by the user.  Still, I don't know many  
people who do that, or even know how.  I don't know how imsi, imei,  
and min are administered.

-andy

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 20 Mar 2007 18:00:59 -0500

IMSI is assigned to a mobile SIM.  IMEI is assigned to the actual hardware. MIN is likewise assigned to hardware (no UICC in IS-95/CDMA2000).  None of these can be changed, and are globally unique. 

MAC can be changed for some devices, but this is a recent development.  Someone at the office here bought a motherboard that has a BIOS setting for MAC address.  The default is 00:00:00:00:00:00.

M

From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, 21 March 2007 9:49 AM
To: Richard Barnes
Cc: [email-masked]; Stark, Barbara
Subject: Re: [Geopriv] GRUU in HELD Identities

I'm not an expert here, but aren't those identifiers transmitted to the access network anyway, as part of the attachment process?  (And analogously for other physical/MAC-layer identifiers in other scenarios.)  If that's the case, then how is using them to query a LIS controlled by the access network any more a privacy violation?

Though a MAC is only required to be unique on a network, and therefore could be changed by the user.  Still, I don't know many people who do that, or even know how.  I don't know how imsi, imei, and min are administered.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 20 Mar 2007 19:05:48 -0400

On Mar 20, 2007, at 7:00 PM, Thomson, Martin wrote:
> MAC can be changed for some devices, but this is a recent  
> development.  Someone at the office here bought a motherboard that  
> has a BIOS setting for MAC address.  The default is 00:00:00:00:00:00.

I'll give you the point, but the ability to change MAC addresses is  
nothing new.  Network admins use to do it on a regular basis,  
encoding office locations into the addresses.  That was considered  
state-of-the-art in network management back in 1990.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 20 Mar 2007 18:43:51 -0500

Hi everyone,

With this discussion, I think it has to be borne in mind what the
purpose of providing a device identity extension to a LIS is.

It is to provide the LIS with some additional identifier that can be
correlated with network measurements where the IP address is not known
or not sufficient. It needs to be some value that the LIS is already
aware of and is already capable of correlating with a location.

So, for example, in a DSL network the L2TP tunnel identifier may be
passed from an ISP LIS to an RBP LIS because the IP address doesn't mean
anything in the DSL infrastructure provider's domain.

Cellular is a bit of a special case - it already has a location
infrastructure that, at the gateway level, uses the MSISDN as the device
identifier. In this case a cellular device in a target-LIS query could
also pass its MSISDN when it's in a cellular network. It's obviously not
ideal for a device to have to know it's in the cellular-access network
scenario in order to add this extension - though it's possible for a
specific client implementation to do that. Actually, there are a number
of published methodologies that describe how the LIS can work out the
MSISDN from the IP address in a cellular access domain anyway - then use
the MSISDN to invoke the existing location infrastructure. So even this
scenario should not really be necessary.

Beyond that, it is going to be very specific implementation scenarios
where anything other than IP address is really needed. For example, a
specific enterprise implementation that uses LLDP to determine the
switch/port ID (rather than using DHCP relay or SNMP bridge MIB queries
for example) and passes that switch port value in the target-LIS
request. Or it may be where an application server is performing an OBO
to the LIS using the identifier it knows and which the LIS can still
actually use to correlate to location. And, as mentioned already,
specific network LIS-LIS scenarios may use these extensions. I tend to
think these kind of additional identity parameters will actually be
lower layer parameters rather than application layer identities because
they are most likely able to be associated with the physical
connectivity from which location is determined.

In no cases should an identity be passed to a LIS that isn't already
known by the LIS and which isn't useful to perform correlation with some
other network parameters which permit location to be determined.

I have my doubts that quite high level application identities (which I
get the sense that GRUU is - I don't pretend to have a clue in that
quarter) will actually provide any kind of meaningful correlator for a
LIS to determine location from. On the other hand, I certainly don't
claim to know if it couldn't be useful. At worst, it's presence in the
identity form list should be benign and at best it will be useful to
some domain specific LIS implementation. I don't think that the use of
these identity extensions should ever create a privacy issue.

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, 21 March 2007 8:57 AM
To: Andrew Newton
Cc: [email-masked]; Stark, Barbara
Subject: Re: [Geopriv] GRUU in HELD Identities

> Additionally, imsi, imei, and min appear to be tied to specific
devices, 

--RB

>> extension looks like it would only work on devices intended to
operate 
>> Which leaves link and depend, where link is anything you want it to
be 

identifier
upon