Subject: [dispatch] draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 May 2011 12:10:39 -0600

I have said in the past, I have several concerns around the combined proposal in these two drafts. In this email, I've tried to focus on the high level problems and ignore small problems in the drafts that can be fixed by change a bit of text in the drat. 

The biggest issues is that this is going to reduce interoperability with systems that don't use this type of instance id yet this does not provide features that could not be done in away that did not reduce interoperability. To be concrete, let me offer an alternative solution that would be interoperable, would not have any IPR that I am aware of, and would provide the same functionality as the goals of these drafts - or at least the goals that have been stated at the IETF. 

To indicate the version of the software, I would suggest using the SIP User Agent header. If a more structured form is required to specifically line up with existing mobile systems, I would suggest defining an well structured format to use inside the User Agent header field. The advantage is that this is what most sip systems do today and many management systems already can look at this header and use it. A more structured form would be useful by systems outside the GSMA space and would also be backwards compatible with existing systems that treat it as an unstructured string. 

For the issue of identifying stolen handsets and correlating devices between SIP and non SIP calls, I would propose that you use a UUID as the URN but that the UUID be created using IMEI or a hash of the IMEI instead of the MAC. This would involve an extension to RFC 4122 but would result in a system that meets the needs. Even if a hash is used, the server side can do the same hash to match. 

If the WG is interest in such an idea, I am glad to write up an ID for each of these and submit it to the group so that it can be properly considered in contrast to draft-allen-dispatch-imei-urn-as-instanceid. 

As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I am not in favor of publishing it as is because  I believe it will result in interoperability failures with the many SIP devices that don't support it, and it has IPR that we can easily avoid and provide the same functionality. I also have issues with some of the technical details in it but theses could all be fairly easily resolved with a few back and forth of suggested text. RIM is offering awful licensing terms for something that I believe you would have to implement to be workable in the bulk mobile SIP deployments. Give this is easily avoidable, I think we should avoid it. It's not really a topic for this WG but if this draft proceeded, it was very late IPR disclosure. When it came to IETF LC, I would also want to point out that the only teeth IETF has to enforce very late IPR disclosures is to say no. I'm not particularly interested in talking about this here as I don't think it will help solve the problem but I have brought this up in the past in context of this draft and I don't want anyone to be surprised if I brought it up in an IETF LC. 

There are also significant privacy concerns around this proposal. A key design of GRUU is being able to meet people goals of privacy while not revealing private information. The IMEI is sometimes used as a security identifier between a user and SP as a shared secret. This proposal would break theses systems. The privacy and security aspects of this would need to be addressed. It's conceivable that in many cases IMEI is Personal Identifiable Information. The idea that every call would have to have PII information in it or my call would be blocked as coming form a stolen phone seems like a pretty serious flaw in this proposal. I'll note I brought up the privacy issues in 2007 and have yet to get a reply on it. 

On the topic of draft-montemurro-gsma-imei-urn, I of course think it is fine for the GSMA to be able to allocate a namespace where they need it. However, there are bunch of changes that would be needed to make this draft fit all the URN rules. They are all small actionable things like defining how comparison of things such as svn is defined and how allocation of new things works. As I have also brought up many times in the past, what the relationship between GSMA and 3GPP on this is very weird and I would want clarity on that before proceeding. In the time we have been discussing this draft, people constantly tell me that GSMA is the group that will handle the namespace allocation for the 3GPP deployments yet at the same time we have approved RFC 5279 which oddly looks like a better namespace for this than the GSMA one. I would want to have a clear understanding of how these different spaces interact. The more we splinter this namespace, the less interoperability we have. 

On the topic of including the software version as part of the device identifier, given the software is upgraded, I think this is a mistake and it is better to consider the software version as a separate thing from the unique device identifier. It does not seem consistent with the goals and requirements of a device id URN. 

I will also note that as far as process is concerned, I would prefer the problem, not the solution was brought to dispatch and we could figure out how to solve it. I do think the problem here is well worth solving, I just think there are solutions that will work better that this when considering the whole eco systems of SIP endpoints and not just the GSM ones. 

Cullen in my individual contributor role

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 19 May 2011 10:45:29 -0400

> From: Cullen Jennings [[email-masked]]
> 
> The biggest issues is that this is going to reduce interoperability
> with systems that don't use this type of instance id [...]

Could you explain this?  The system I'm familiar treats the
instance-id largely as an opaque string.  Certainly, any SIP system
must be prepared to see instance-id values from namespaces that it
does not understand.  How could a device using a new instance-id
namespace break any existing registrar, unless the registrar was only
able to deal with a limited set of namespaces?

> To indicate the version of the software, I would suggest using the SIP
> User Agent header.

That sounds like a good idea, unless the "Software Version" is not
just an attribute of the device but somehow a qualifier of the meaning
of the IMEI.

I'm more worried that the "Software Version" is a declaration of the
capabilities of the handset, in which case it should really be encoded
in the Supported header in some way.  Is there a list of specified
Software Versions?

> There are also significant privacy concerns around this proposal.

That's true, but it seems to me that that's the whole point of it --
to make the endpoint rigidly identifiable to the user and mobile
account.

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 May 2011 14:19:17 -0600

> to make the endpoint rigidly identifiable to the user and mobile

well making it identifiable to the home network or even the roaming network could make sense but this would be delivered to everyone you ever call. We been trying to move away from PII identifiers that are delivered to everyone you communicate with.

---

From: "Andrew Allen" <[email-masked]>
Date: Fri, 27 May 2011 22:07:05 -0500

Cullen

Responses to your technical points below:

regards
Andrew

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: Wednesday, May 18, 2011 1:11 PM
> To: DISPATCH list
> Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen-
> dispatch-imei-urn-as-instanceid
> 
> 
> I have said in the past, I have several concerns around the combined
> proposal in these two drafts. In this email, I've tried to focus on
the
> high level problems and ignore small problems in the drafts that can
be
> fixed by change a bit of text in the drat.
> 
with
> systems that don't use this type of instance id yet this does not
provide
> features that could not be done in away that did not reduce
> interoperability. 

Can you please elaborate on what your interoperability concerns are? I
don't see any issue with end to end interoperability since with public
GRUU the gr parameter is opaque. Devices that contain an IMEI are only
those devices specified by 3GPP. Only 3GPP mandates that the IMEI is
included in the instance ID, non 3GPP devices or devices not operating
in an IMS network do not need to use an IMEI (indeed a non 3PP device
would not even have an IMEI to use). RFC 5626 allows the possibility for
URNs other than UUID to be used as an instance ID and RFC 5627 does not
mandate an algorithm for the generation of GRUUs based on the instance
ID. If the 3GPP determines that its devices that already contain an IMEI
for their device ID need to use that as an Instance ID and defines a
GRUU generation algorithm that satisfies its requirements when receiving
an Instance ID that contains the IMEI URN then that seems fine to me. Is
your concern regarding a 3GPP IMS terminal registering in a non IMS
domain? I think that in reality a device acting as an IMS terminal
registering in a non IMS compliant network isn't a practical scenario.
There are so many 3GPP and IMS compliant things that would need to
happen in the network for the device (acting as an IMS terminal) to
register and obtain service that basically the network would need to be
an IMS compliant network. Of course there is nothing preventing a device
that is IMS capable being configured to either act as an IMS compliant
device or a basic SIP compliant device (quite a few devices have such
dual mode capabilities). The use of the IMEI as the instance ID should
not in itself prevent the successful registration of the device in a non
IMS network (since as Dale points out the registrar is likely to treat
the instance ID opaquely if it doesn't understand it).

>To be concrete, let me offer an alternative solution
> that would be interoperable, would not have any IPR that I am aware
of,
> and would provide the same functionality as the goals of these drafts
- or
> at least the goals that have been stated at the IETF.
> 
> User Agent header. If a more structured form is required to
specifically
> line up with existing mobile systems, I would suggest defining an well
> structured format to use inside the User Agent header field. The
advantage
> is that this is what most sip systems do today and many management
systems
> already can look at this header and use it. A more structured form
would
> be useful by systems outside the GSMA space and would also be
backwards
> compatible with existing systems that treat it as an unstructured
string.

I am not against the proposal of including the software version in the
User Agent header but don't see it as an alternative to the
representation of the IMEI-SV as part of the IMEI URN. One of the main
objectives of the use of the IMEI and IMEI-SV in SIP signaling is to
maintain compatibility with the IMEI and IMEI-SV use in Circuit Switched
signaling. In some case in circuit switched signaling the device will
return the IMEI and in other cases the device will return the IMEI-SV.
It needs to be possible that devices registered in circuit switched
domain and in the IMS domain can use whichever is returned IMEI or
IMEI-SV in the same identifier.
> 
> For the issue of identifying stolen handsets and correlating devices
> between SIP and non SIP calls, I would propose that you use a UUID as
the
> URN but that the UUID be created using IMEI or a hash of the IMEI
instead
> of the MAC. This would involve an extension to RFC 4122 but would
result
> in a system that meets the needs. Even if a hash is used, the server
side
> can do the same hash to match.

I don't fully understand the details of your proposal but a clear
requirement is that the IMEI in the instance ID be recoverable and
understandable by the registrar as the IMEI value of the terminal. Does
this proposal allow the IMEI value to be obtained and understood by the
registrar? 

If an extension to RFC 4122 is required isn't this more overhead and has
more impact than simply defining and using a URN that represents the
namespace that you wish to include? UUID itself is also heavier in
computational resources and less efficient in size than the IMEI URN.

> 
> If the WG is interest in such an idea, I am glad to write up an ID for
> each of these and submit it to the group so that it can be properly
> considered in contrast to draft-allen-dispatch-imei-urn-as-instanceid.
> 
> As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I am
not
> in favor of publishing it as is because  I believe it will result in
> interoperability failures with the many SIP devices that don't support
it,

This needs justification. 3GPP specifications also support handling
devices that use UUID and not IMEI as many IMS compatible devices do not
actually have an IMEI (only GSM mobile devices have an IMEI).

> and it has IPR that we can easily avoid and provide the same
> functionality. I also have issues with some of the technical details
in it
> but theses could all be fairly easily resolved with a few back and
forth
> of suggested text. RIM is offering awful licensing terms for something
> that I believe you would have to implement to be workable in the bulk
> mobile SIP deployments. Give this is easily avoidable, I think we
should
> avoid it. It's not really a topic for this WG but if this draft
proceeded,
> it was very late IPR disclosure. When it came to IETF LC, I would also
> want to point out that the only teeth IETF has to enforce very late
IPR
> disclosures is to say no. I'm not particularly interested in talking
about
> this here as I don't think it will help solve the proble
>  m but I have brought this up in the past in context of this draft and
I
> don't want anyone to be surprised if I brought it up in an IETF LC.
> 
> There are also significant privacy concerns around this proposal. A
key
> design of GRUU is being able to meet people goals of privacy while not
> revealing private information. 

Privacy in GRUU is achieved through temporary GRUUs. Properties of
temporary GRUUs are unaffected by using the IMEI as an instance ID.

>The IMEI is sometimes used as a security
> identifier between a user and SP as a shared secret. This proposal
would
> break theses systems. 

The IMEI is easily readable from the UI of mobile phones and is quite
often printed on the case under the battery. Mobile phone stores
sometimes keep lists (sometimes on paper) of IMEIs and the customers who
have been allocated them (warranty reasons etc). It is hardly a super
secret security identifier. I am not aware of the security usage you
describe and if it does exist it seems pretty flawed.

>The privacy and security aspects of this would need to be addressed. 

3GPP has addressed aspects of revealing the IMEI when generating GRUUs
in their specifications.

> It's conceivable that in many cases IMEI is Personal
> Identifiable Information. 

IMEI is not really anymore personal information than IP address which
IETF specifications reveal all the time. Furthermore it is not the
intention that the IMEI is exchanged end to end.

> The idea that every call would have to have PII
> information in it or my call would be blocked as coming form a stolen
> phone seems like a pretty serious flaw in this proposal. 

In general the IMEI is not placed in an IMS call. The blocking would be
achieved via the registration. Blocked mobiles simply would be unable to
register in IMS (which in IMS means they are unable to make calls). If
an IMEI check is needed during a call the mobile can be requested by the
network to re-register. The only use in 3GPP of the IMEI during an IMS
call is for emergency calls.

> I'll note I brought up the privacy issues in 2007 and have yet to get
a reply on it.

I don't recall your previous comment (but it was 4 years ago). If we
have failed to respond adequately to a previous comment then please
restate it if the above responses do not cover it.
> 
> On the topic of draft-montemurro-gsma-imei-urn, I of course think it
is
> fine for the GSMA to be able to allocate a namespace where they need
it.
> However, there are bunch of changes that would be needed to make this
> draft fit all the URN rules. They are all small actionable things like
> defining how comparison of things such as svn is defined and how
> allocation of new things works. 

Of course all technical issues and concerns can be fixed. Please supply
details on those so they can be addressed.

> As I have also brought up many times in
> the past, what the relationship between GSMA and 3GPP on this is very
> weird and I would want clarity on that before proceeding. In the time
we
> have been discussing this draft, people constantly tell me that GSMA
is
> the group that will handle the namespace allocation for the 3GPP
> deployments yet at the same time we have approved RFC 5279 which oddly
> looks like a better namespace for this than the GSMA one. I would want
to
> have a clear understanding of how these different spaces interact. The
> more we splinter this namespace, the less interoperability we have.

My understanding is that in order to be allocated a URN namespace the
registrant of the namespace has to guarantee uniqueness of the
namespace. GSMA provides for the allocation of IMEIs and ensures
adherence to the guidelines for IMEI allocation "GSMA Association, "IMEI
Allocation and Approval Guidelines", PRD DG.06". Thus for the IMEI the
GSMA is the appropriate registrant for that namespace. 3GPP has no
responsibility for allocation of IMEIs so should not be the responsible
registrant. 3GPP namespace would seem appropriate for items which are
completely specified (including all their values) in 3GPP
specifications. It should be noted that 3GPP is not a legal entity and
might not exist for the entire period of time that IMEIs are being
allocated and used.
> 
> On the topic of including the software version as part of the device
> identifier, given the software is upgraded, I think this is a mistake
and
> it is better to consider the software version as a separate thing from
the
> unique device identifier. It does not seem consistent with the goals
and
> requirements of a device id URN.

As stated above the software version is included for backward
compatibility with the IMEI-SV usage in circuit switched signaling. The
SVN is a parameter and so the original IMEI which does not change can be
easily obtained. Registrars and other devices that understand the IMEI
URN with the SVN parameter can ignore the parameter when generating
GRUUs for instance. If a book has a 2nd edition with different content
doesn't that warrant being assigned a new value within the ISBN URN
namespace? Similarly if the software is upgraded the nature and
capabilities of the device may change so doesn't this warrant a new
value? Note that RFC 5626 and RFC 5627 do not require that the instance
IDs or GRUUs be forever persistent (RFC 5626 only requires that it MUST
be persistent through a power cycle). I doubt very much that most
embedded SIP endpoints will after a complete software upgrade (such as
involving completely rewriting flash memory) still use the same UUID as
previously used either.
> 
> I will also note that as far as process is concerned, I would prefer
the
> problem, not the solution was brought to dispatch and we could figure
out
> how to solve it. I do think the problem here is well worth solving, I
just
> think there are solutions that will work better that this when
considering
> the whole eco systems of SIP endpoints and not just the GSM ones.

When this was first proposed in 2006 all that was being done was
registering a namespace. I don't think that 3GPP needs to bring
requirements to the dispatch WG, propose a charter etc for every problem
that can be solved by registering a namespace or a parameter. In fact
the SIP change process has moved away from that with only specification
required and expert review needed for defining "proprietary" SIP header
fields. As stated above the IMEI only applies to the GSM family of
technology mobiles not all SIP endpoints and I fail to see the impact of
the use of the IMEI URN by the GSM family of technology mobiles when
registering with IMS on any other SIP endpoints. This proposal does not
mandate the use of the IMEI URN as an Instance ID by non 3GPP terminals
and is not being proposed to become part of an IETF standard. This is
just trying to follow the process whereby external users of IETF
protocols register their identifiers with IANA and provide informational
documentation to the internet community about such usage. It seems to me
that some of the issues of principle being raised are those
considerations that more appropriately apply to standards track
submissions and not to these informational submissions. If the same
level of consideration and debate about different solutions takes place
for informational submissions as would take place for standards track
submissions then I fear this will become a big deterrent to outside
users of IETF protocol submitting their proprietary usages as
informational RFCs for the benefit of the internet community and in
ensuring that are no conflicts with the IANA registry.  
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
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.

---

From: "Andrew Allen" <[email-masked]>
Date: Fri, 27 May 2011 22:09:32 -0500

Dale

I have sent a separate response to Cullen"s email which I think addresses most of your points but I would like to address here one of the points you make.

>That sounds like a good idea, unless the "Software Version" is not
just an attribute of the device but >somehow a qualifier of the meaning
of the IMEI.

>in the Supported header in some way.  >Is there a list of specified
Software Versions?

The software version of the IMEI-SV basically indicates a revision of the base software of the device (pretty much the firmware version). It is unlikly to indicate different SIP capabilities. It is more likely to indicate whether certain bugs in earlier versions have been fixed (for example any security holes etc) and in most cases doesn't have any impact on SIP behaviour at all.

I certainly don't think this should go in the Supported header field.

Andrew

----- Original Message -----
From: Worley, Dale R (Dale) [mailto:[email-masked]]
Sent: Thursday, May 19, 2011 09:45 AM
To: Cullen Jennings <[email-masked]>; DISPATCH list <[email-masked]>
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urnand	draft-allen-dispatch-imei-urn-as-instanceid

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 May 2011 15:02:46 -0400

________________________________________
From: Andrew Allen [[email-masked]]

Hmmm...   It seems like the "software version" shouldn't be in the URN at all.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 May 2011 15:12:30 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Andrew Allen [[email-masked]]

Could you spell this out more?  From where I sit, there seems to be no reason for the SV
to appear in the URN (as it is not really part of the device identity, indeed, is expected
to change).  I don't grasp the data-flows for the actions you are describing above.

Dale