Subject: Re: [dispatch] Revised draft draft-allen-dispatch-imei-urn-as-instanceid

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 1 Nov 2010 17:33:42 -0400

The draft looks good to me, and it seems quite useful.  I've got a few nits:

This draft probably needs to depend on draft-montemurro-gsma-imei-urn
as an RFC.  That allows giving a proper reference from this draft to
montemurro-gsma-imei-urn.  (I think this is already intended, but it
will require some tweaks to how the references are done.)

Section 3 includes:

   GSM and UMTS mobile devices each have a unique IMEI allocated which
   uniquely identifies the mobile device from all other GSM/UMTS
   mobile devices deployed.

This sentence contains both "unique" and "uniquely"; one of them
should be removed.

   ... a MSC (Mobile switching Center) server ...

"switching" should be capitalized.

Section 4 includes:

   If the UAC includes the "vers" and/or the "svn" parameters of this
   URN in the "sip.instance" media feature tag then the UAC MUST
   always include these parameters in the "sip.instance" media feature
   tag in the same sequence order as in the first usage in order to
   provide lexically equivalent URNs in each registration.

I think this should be written in a more universal way that covers any
future extensions of the URN syntax:

   The UAC must provide lexically equivalent URNs in each
   registration.[1]  Hence, any optional or variable components of the
   URN (e.g., the "vers" and "svn" parameters) must be presented with
   the same values and in the same order in every registration as in
   the first registration.

Section 5:

"In order to protect from tampering the register requests
containing..." would read better as "In order to protect from
tampering, the REGISTER requests containing...".

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Nov 2010 09:26:50 -0700

With my WG hat chair on ... This draft has IPR declared on it which makes me need to ask the questions of what is this draft does that we could not do some different way. So what is this draft provides that GRUU does not?

On Oct 29, 2010, at 11:00 AM, Andrew Allen wrote:

> A revised version of draft-allen-dispatch-imei-urn-as-instanceid was uploaded earlier this week and can be found at
>  
> http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01.txt
>  
> Please provide any feedback.
>  
> Thanks
> Andrew Allen
> --------------------------------------------------------------------- 
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 19 Nov 2010 16:59:46 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]

With my WG hat chair on ... This draft has IPR declared on it which makes me need to ask the questions of what is this draft does that we could not do some different way. So what is this draft provides that GRUU does not?
_______________________________________________

As far as I can see, all it does is allow a phone to use its IMEI as its instance-id.  In turn, that allows the phone to have a GRUU that is directly paired with its IMEI.  Alternatively, a phone could be assigned a MAC address, which can be used to generate a UUID which can be used as an instance-id (there are enough MAC addresses for all the phones).  But draft-allen-dispatch-imei-urn-as-instanceid-01 states "Additionally in order to meet the regulatory requirements to use the IMEI to identify [that] a stolen mobile is being used and help to identify the subscription that is using it and to prevent its use[,]  the same IMEI that is obtained from the circuit switched signaling needs to be obtainable from SIP signaling."  A natural way for a phone to report its IMEI is to use it as its instance id.

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 Nov 2010 10:07:58 -0700

On Nov 19, 2010, at 2:59 PM, Worley, Dale R (Dale) wrote:

>  But draft-allen-dispatch-imei-urn-as-instanceid-01 states "Additionally in order to meet the regulatory requirements to use the IMEI to identify [that] a stolen mobile is being used and help to identify the subscription that is using it and to prevent its use[,]  the same IMEI that is obtained from the circuit switched signaling needs to be obtainable from SIP signaling."  

Could someone provide a pointer to these regulator requirements so we can get everyone on the same page?  I would also like to see the discussion around how this is secured to meet the above requirements.

---

From: "Andrew Allen" <[email-masked]>
Date: Tue, 30 Nov 2010 12:14:40 -0600

Cullen

Sorry for the delay in responding due to Thanksgiving holiday last week.

Currently 3GPP mobile devices all use the IMEI as their unique device
identifier. The IMEI is the only device identifier that can be
transported in 3GPP circuit switched signaling without further
enhancement of the circuit switched signaling protocol. 3GPP has
specified handover of calls between direct access via IMS and indirect
access via the Circuit switched domain while providing all services via
servers hosted in the IMS. To do this a mobile switching center server
(MSC server) enhanced for ICS (IMS centralized services) SIP registers
on behalf of the IMS terminal when that terminal is attached via the
circuit switched domain. In order that the IMS terminal be reachable
using the same GRUU regardless of whether it is connected directly via
IMS or indirectly via the MSC server enhanced for ICS, the MSC server
enhanced for ICS needs to use the same Instance ID when it registers
with the IMS as the IMS terminal does when it registers directly with
IMS. Since the only device identifier that is transportable via the CS
domain signaling to the MSC server enhanced for ICS is the IMEI the
Instance ID needs to contain the IMEI of the terminal when the terminal
registers directly with IMS or when the MSC server enhanced for ICS
registers on the terminal's behalf.

Additionally provision is made in 3GPP systems for checking of the IMEI
(on black lists or white lists) in order that mobiles which have for
example been reported as stolen can be blocked from access to the
systems (in some countries such as Belgium (I understand) this is a
regulatory requirement and in some other countries such as the UK mobile
operators have voluntary provided this capability to address this
societal concern). 3GPP TS 22.016 states:

"It shall be possible to perform the IMEI check at any access attempt,
except IMSI detach, and during an established call at any time when a
dedicated radio resource is available, in accordance with the security
policy of the PLMN operator. It shall also be possible to perform the
IMEI check when a UE is IMS registered."

Thus it needs to be possible to perform the IMEI check during the
IMS/SIP registration of the terminal. Note that IMS procedures using
reg-events can also force an IMS terminal to re-register during a call
thus allowing the IMEI check to also be performed during an IMS call
(using the same registration procedure check).

I hope this explains the underlying reasons why 3GPP has chosen to use
IMEI for the Instance ID for IMS terminals.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cullen Jennings
Sent: Friday, November 19, 2010 10:27 AM
To: DISPATCH list
Subject: Re: [dispatch] Revised
draftdraft-allen-dispatch-imei-urn-as-instanceid

With my WG hat chair on ... This draft has IPR declared on it which
makes me need to ask the questions of what is this draft does that we
could not do some different way. So what is this draft provides that
GRUU does not?

On Oct 29, 2010, at 11:00 AM, Andrew Allen wrote:

> A revised version of draft-allen-dispatch-imei-urn-as-instanceid was
uploaded earlier this week and can be found at
http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01.tx
t
> This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
_______________________________________________

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.