Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs?

From: [email-masked]
Date: Thu, 14 Mar 2002 17:53:14 -0800

Hi Alexandru,

I would be a bit careful to use IMEI as Interface Identifier. I am not really sure if this is something you want to tell the whole world. (I know that Francis has a draft out on this topic, and no I have not read it, yet.) 
For instance, when the 3GPP mechanism of address allocation was designed in 3GPP, one of the criteria was not to show the IMEI. This is kind of confidential information from the end user point of view. In addition, it might not always be unique... 

Cheers,

Jonne.

> -----Original Message-----
> From: ext Alexandru Petrescu [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2002 12:02 PM
> To: Steve Deering
> Cc: Alberto Escudero-Pascual; Erik Nordmark; [email-masked]
> Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs?
> 
> 
> Steve Deering <[email-masked]> writes:
> > The u bit in the current IID definition indicates whether or not the
> > IID can be considered globally unique.
> 
> I'm trying to fit the IMEI into one of:
> 
>       Links or Nodes with IEEE EUI-64 Identifiers
>       Links or Nodes with IEEE 802 48 bit MAC's
>       Links with Non-Global Identifiers
>       Links without Identifiers
> 
> and I can not fit into any, since it looks than an IMEI is global but
> is neither an EUI-64 identifier, nor an IEEE 802 48 MAC address.
> However, the link can not be considered as a link without
> identifiers[*].
> 
> IMEI being global I'm tempted to touch the u bit (universal/local).
> 
> IMEI has nothing in it that could influence the g bit
> (individual/group), but further investigation is necessary probably.
> 
> Alex
> 
> [*] or can it?  I guess that phones have IMEI's but their peers at the
>     other end of the link (GSNS/SGNS) don't.
> 
> 
> 
>   When trying to
> code other identifiers into Modified EUI-64, I wonder whether the
> individial/group bit should also be set/reset, in addition to the
> universal/local bit.
> 
> Also, why EUI-64 was adopted as basis and not any other?  I understand
> that this easily covers 802 LAN's, but why not something more agnostic
> like 
> 
> If it was chosen
> as the preferred coding for Interface ID's for global unicast
> addresses, and as such as an umbrella for other identifiers, was
> 
> I understand that
> Modified EUI-64 is to be used with all global unicast addresses 
> 
>   The zero value (implying *not*
> > globally unique) is used not only for randomly-generated ("privacy")
> > IIDs but also for manually-assigned IIDs, and IIDs assigned via DHCP
> > that are not derived from the node's IEEE-802 or EUI-64 address.  In
> > other words, u=0 does *not* mean randomly generated; it means not-
> > globally-unique.
> > 
> > Steve
> > 
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page:                      http://playground.sun.com/ipng
> > FTP archive:                      ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to [email-masked]
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alexandru Petrescu<[email-masked]>
Date: 15 Mar 2002 14:42:00 +0100

[email-masked] writes:
> I would be a bit careful to use IMEI as Interface Identifier.

Hi Jonne, please let me assure you that I'm trying to be very careful
in all this.  If I speak out so frequently is just because I need to
better understand how IPv6 and 3GPP/UMTS can be made to work together.
If I'm diverging too much from the list's topic, please stop me.

> I am not really sure if this is something you want to tell the whole
> world.

Ok, privacy, yes.  Alberto mentioned that not necessarily the IMEI
should be coded but a hash of it, periodically updated starting from a
nonce.

> This is kind of confidential information from the end user point of
> view.

Aha, confidential, then it's not to be put in IPv6 addresses that are
not confidential.

> In addition, it might not always be unique...

IMEI not being unique?  That's bad, again.  Then it's probably true
that some id's are more unique than other id's.

So I try something else than IMEI: IMSI.  As IMEI is for phones, IMSI
is in the SIM cards.  Is the IMSI private?  Is it unique?

What are the other identifiers in the GSM/3GPP/UMTS?  Phone number?

Would an IMT2000 identifier be better adapted, since it has a wider
reach, more neutral.

Thanks for any info, I need to cover them all, the id's :-)

Alex

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2002 20:38:23 +0100

In your previous mail you wrote:

   I would be a bit careful to use IMEI as Interface Identifier. I am
  not really sure if this is something you want to tell the whole world.

=> there is such a concern for ESD (CDMA 32 bit hardware ID) but
nothing about IMEI. In fact IMEI is sent in clear by the GSM protocol
(as shown by our capture/decoding tool).

  (I know that Francis has a draft out on this topic, and no I have
  not read it, yet.)

=> no comment (:-).

   For instance, when the 3GPP mechanism of address allocation was
  designed in 3GPP, one of the criteria was not to show the IMEI. This
  is kind of confidential information from the end user point of
  view. In addition, it might not always be unique...
   
=> or you confuse IMEI and IMSI or you have access to 3GPP documents
there are not on the 3GPP or ETSI sites. Can you give a pointer?

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2002 20:58:09 +0100

=> the IMEI idea is terribly simple: GSM/UMTS terminals usually have
no IEEE interface but have a globally unique ID, so use it exactly as
we use IEEE IDs/MAC addresses.

   > I am not really sure if this is something you want to tell the whole
   
   Ok, privacy, yes.

=> please read the last update of RFC 3041 before to get things from
3041 which are not in it...

   Alberto mentioned that not necessarily the IMEI
   should be coded but a hash of it, periodically updated starting from a
   nonce.
   
=> I can't see a reason to do that when RFC 3041 is supported.
Or do you mean we can replace the MAC address by the IMEI for the seed?

   
=> IMEI is unique according to 3GPP/ETSI standards.
In the true world I am afraid it is not far more unique than
MAC addresses...

=> IMSI is *private* and unique.

=> none, the hardware ID is the IMEI. Others (IMSI/phone number) are
private...

=> it seems the IMT2000 identifier would be the IMEI.

Regards

---

From: Alexandru Petrescu<[email-masked]>
Date: 19 Mar 2002 15:56:54 +0100

Francis Dupont <[email-masked]> writes:
> [email-masked]:

So I suppose there's draft, a pointer would help.  Far from me any
intention that you imply, sorry.

>    Alberto mentioned that not necessarily the IMEI should be coded
>    but a hash of it, periodically updated starting from a nonce.
>    

No-no.

> => IMEI is unique according to 3GPP/ETSI standards.

Ok, fact is that those future wireless phones things have not yet
agreed among themselves who uses what as unique ID.  This narrows the
option of coding IMEIs into addresses to in fact coding IMEIs for 3GPP
of ETSI into addresses.

> => none, the hardware ID is the IMEI. Others (IMSI/phone number) are

Ok, how about TMSI dynamically assigned by a VLR.  Like an RCoA in an
HMIPv6 domain.  I guess it would not fit because it changes when
moving into another geographical region.

Then how about MSISDN, whose correspondence with the IMSI is kept by
the HLR.  HLR is a sort of super-VLR, only one of them per operator
(there are several VLRs per operator).  MSISDN is not so private as
IMSI, only HLR knows the correspondence.  So one can consider it
overcomes IMSI's limitations.

I think there's also MSRN but know nothing about it more than it's
used for MSC-MSC communication.  And I don't know what MSC means.

> => it seems the IMT2000 identifier would be the IMEI.

Ah, some agreement, finally.

Note though another difference between 802 id's and all those
discussed above: the above identifiers identify the terminal itself,
but not the other end of the communication at L2.  I mean a base
station has neither IMEI/IMSI/etc, and if it's identified by something
it's certainly not the same kind of id as the one for the phone.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Tue, 19 Mar 2002 17:41:25 +0100

=> draft-ietf-ipngwg-temp-addresses-v2-00.txt

   
=> I am not the ITU so I can't solve the issues between the 3GPP and
the 3GPP2. Do you propose to wait they have merged (:-)?
For me, the 3GPP/ETSI base is already enough.

=> exactly.

=> MSISDN is too large and is not an hardware ID.

=> be serious, please! (BTW MSC=Mobile Switching Center)

   
=> as I've said I am not the ITU (:-).

=> a base station is not a Mobile Equipment, does this matter?

Regards

---

From: Alexandru Petrescu<[email-masked]>
Date: 19 Mar 2002 17:58:01 +0100

> => draft-ietf-ipngwg-temp-addresses-v2-00.txt

Thanks!

> => be serious, please! (BTW MSC=Mobile Switching Center)

That might have looked funny but I really didn't know what MSC meant.
Now I know.  And it removes it from the list of my tries of id's to be
coded into Interface ID's.  As I said, I was trying to cover them all.

> => a base station is not a Mobile Equipment, does this matter?

Ok, I think I agree with you.  I might have a different view of how
those id's are used, I mean different than yours; but exactly as you,
I was motivated to find how a sort of unique ID that can be fit into
an Interface ID.

Alex