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

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Jul 2011 18:22:51 -0400

On May 27, 2011, at 23:07 , Andrew Allen wrote:

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

What happens in 3GPP tends to leak out into other standard and into other systems. 

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

I understand both are used in circuit switched but I don't see that that would require a design like this. 

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

The requirement was that they be matchable not recoverable which this meets

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

This extension to 4122 is pretty easy and has no IPR I am aware of. 

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

I think I have provided this on more than one occasion.

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

agree with what you are saying but you do agree it is used as a secret often used to show proof of possession of the phone?

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

right, send them on over 

> 
>> It's conceivable that in many cases IMEI is Personal
>> Identifiable Information.
> 
> IMEI is not really anymore personal information than IP address 

<..snip..>

I'll note I think you are just wrong on this. First of all, IMEI are more revealing than IP because they tend to be tighter bound to a single suer instead of multiple and exist over longer time and second of all many people, myself included, consider IP as PII in many cases.  

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

again, I think there are much better designs for this without IPR issues 

> 
>> 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 doubt that is true. Please look at the drafts from 2006. I have never objected to the idea that some other SDO might want a URN namespace. If that was all that was requested, this would have been done long ago and the current draft would not be requesting anything more than that. 

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

You are asking for something that can not be approved as an information draft by the ISE because it impacts interoperability of SIP devices. The bar here is somewhat higher than some information drafts. If what you needed to be approved could be done by the ISE, I would suggest you take it there but it can't. 

>> 
>> Cullen in my individual contributor role
>> 
>> 
>> _______________________________________________
>> 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.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html