Subject: Unique identifiers and privacy

From: "Christian Huitema" <[email-masked]>
Date: Fri, 9 Jul 2004 11:31:58 -0700

I am concerned with the general statement that we should merely "do no
worse than the current state of the art". I am specifically concerned
with the use of long lived unique identifiers. We have already got
significant feedback on such identifiers in a number of products, e.g.
identifiers of CPU chips, identifiers of users of audio-video players,
host identifiers in IPv6, use of social security numbers in data bases,
and the list goes on. Any unique identifier is a privacy time bomb.

Obviously, there are places where unique identifiers are unavoidable.
For example, one cannot receive mail without publishing a mail address
of some kind. But there are many places where identifiers are in fact
not needed. For example, a vast majority of Internet connections involve
resolving the name of a server, obtaining the server address or
"locator", and exchanging a few packets between a single pair of
locators. A cautious design would not mandate use of any identifier in
such circumstances.

If we do use identifiers, we should obviously allow systems to create
short-lived identifiers, and to use different identifiers for different
activities. However, we should be very concerned with the default
behavior. In practice, many application developers don't bother with
advanced API and just use whatever is the default behavior of the stack.
A cautious design would be to err on the side of privacy, and to make
sure that by default, an application's traffic will use an identifier
that is both short-lived and specific to that application. The use of
long lived global identifiers should be reserved to those applications
that specifically request them.

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 11 Jul 2004 16:01:55 +0200

Hi Christian,

El 09/07/2004, a las 20:31, Christian Huitema escribió:

> worse than the current state of the art".

I think that we already have considered the multihoming solution to be 
a possibility to improve other parts of the architecture, namely, we 
have considered improving the security, the mobility, the renumbering 
and now the privacy of the Internet.
I am attracted to all this approaches, since i can see that all these 
approaches could provide some great benefits.
However, the multihoming problem presents a great difficulty on its 
own, so i feel that we should focus on choosing the solutions that best 
solves the multihoming problem without breaking any other part of the 
Internet. In other words, providing multihoming support without doing 
worst on the other aspects concerned.
For sure, if the best solution for the multihoming problem also 
provides more security or privacy or mobility or renumbering support, 
then great. But for now, imho these are nice-to-have features.
Just my 2 cents on this.

>  I am specifically concerned

Okey, i see your concern but i think that this is not the case here.
I guess that your point is about unique identifiers in the sense that 
they cannot be changed over time, like a hardware serial number or a 
MAC address. In this case, the hardware number is fixed and it is a 
clear privacy time bomb as you mention.

However, using identifiers, like crypto identifiers that can be changed 
periodically, does not pose the same level of privacy issues.

I mean, the problem with fixed identifiers is that they can be traced 
during long periods of time.

Periodically generated identifiers can have the same behaviour than 
RFC3041 addresses, so they can be changed pretty frequently, so i 
really don't feel that they pose the same privacy threats that you are 
mentioning.

regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 26 Jul 2004 12:24:22 +0300

[Catching up e-mail]

On Jul 9, 2004, at 21:31, Christian Huitema wrote:
> with the use of long lived unique identifiers. ...
>
> behavior. ....

For the record, I strongly agree with Christian.  This is an
important issue.

In my opinion, it is also important to make it sufficiently hard
to link the network layer identifiers of a mobile user.  That is,
if a host changes its point of attachment, the default should
be that it can use a new network layer identifier / identifiers at
the new location, and linking the old identifier(s) with the new
identifier(s) should be hard for the average non-participating
attacker / eavesdropper.  (What is hard enough is debatable, of
course.)

RFC3014 succeeds in fulfilling this goal for certain types
of traffic with suitable implementations (e.g. HTTP where the
underlying IP address is changed) but not for others.  Mobile IPv6
fails miserably, unfortunately.  MULTI6 should not make the situation
any worse,  and preferably should make it better.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 Jul 2004 13:15:20 +0200

On 26-jul-04, at 11:24, Pekka Nikander wrote:

> to link the network layer identifiers of a mobile user.

[...]

> Mobile IPv6

I disagree that this is something that's relevant to multi6, as with 
site multihoming the relation between the different addresses is more 
or less permanent and therefore trying to hide it makes little sense.

As for mobility: is the header that contains the "real" address (I 
forget the lingo, sorry) encrypted by IPsec? I see no reason it 
wouldn't be. And if it is, this is a solved problem and people should 
just use IPsec.

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 27 Jul 2004 14:24:12 +0300

> wouldn't be. And if it is, this is a solved problem and people should 

For route optimisation, it is not encrypted, as IPsec is typically
not used in the RO case.  If IPsec is used with RO, I don't remember
what the specs say, but that doesn't currently matter much since
IPsec cannot really be used with RO until MOBIKE WG produces its
results.

--Pekka

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 Jul 2004 14:36:24 +0200

> IPsec cannot really be used with RO until MOBIKE WG produces its

I don't see why not. The only question is whether IPsec sits on top of 
mobility, or mobility sits on top of IPsec. In the latter case you can 
negotiate SAs between all pertinent address pairs and observers will be 
none the wiser.

But I have always been sceptic about the usefulness of mobility in the 
first place. So mobility for people who are paranoid about exposing 
their home address isn't something I really believe in.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 27 Jul 2004 17:41:39 -0700

I am not sure if this is the right mailing list for this discussion,
but I thought I should respond to Pekka's mail.

Pekka Nikander wrote:

> not used in the RO case.  

you can use it if you want to.

IPv6 hdr (MN_CoA, dst=CN)
ESP hdr
IPv6 hdr (MN_HoA, dst=CN)
Payload

you just need sufficient trust to run IPsec with the CN.

> If IPsec is used with RO, I don't remember

why? MIP signaling can be used to update the tunnel end points.

Vijay

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 28 Jul 2004 08:02:48 +0300

> why? MIP signaling can be used to update the tunnel end points.

I realised I was wrong some time after I sent my second message.
Sorry for the confusion.  Anyway, this discussion does not belong
to this list as it has nothing to do with multi6.

--Pekka