Subject: RE: Notes about identifier - locator separator

From: "Christian Huitema" <[email-masked]>
Date: Fri, 8 Nov 2002 09:37:03 -0800

> If you separate locators completely from end-point identifiers,
> the logical conclusion is NOT to move the function to the
> transport layer but to split the IP layer into two halves:
> 
> -  A "lower" IP that routers packets much as today, and uses
>     IP addresses as locators.
> 
> -  An "upper" IP that provides end-point identifiers to the
>     transport protocols and eventually to the hosted applications,
>     and maps these identifiers to locators before passing them
>     to the "lower" IP.

There are a couple of issues with any proposal of that nature, and the
main one is privacy. Having a unique identifier exposed to the network
means that anybody on the path can track the presence and location of
users, with consequence ranging from annoying (e.g. variations of
telemarketing) to downright dramatic (e.g. missile auto-aining to a cell
phone). To meet the privacy requirement, you would want addresses (as
incorporated in the header) to disclose as little as possible about
their owner. In a mobility or multi-homing situation, you may well want
to hide from the network any correlation between addresses that happen
to be used by the same entity.

-- Christian Huitema

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 08 Nov 2002 19:57:08 +0200

> to be used by the same entity.

Indeed.  I've been engaged in a heated discussion about this
off-line for some time now.  Some people seem to be so worried
about terrorism that they don't acknowledge the privacy concerns,
and don't believe in the possibilities of cryptography at the
same time.

The current HIP design sends the identifiers in clear text
only in the first four packets (the HIP handshake).  It
also includes the possibility of using pseudonyms (i.e. multiple
identifiers).  Furthermore, we are considering schemes where
it would be possible to hide (cryptographically "blind") the
identifiers even in the first four packets iff the parties know
each other beforehand, i.e., have communicated before and have
the peer's ID stored.

What's the other issue(s) (the other half of the "couple of issues")?

--Pekka Nikander

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Nov 2002 16:23:16 -0500

On Friday, Nov 8, 2002, at 12:37 America/Montreal, Christian Huitema 
wrote:
> phone).

They can be tracked *anyway* using traffic analysis.  And the silly
Privacy stateless autoconfig thing currently specified does NOT
prevent user tracking either -- that spec does solve the marketing
problem about privacy, but only for people who don't understand how
real commercial user tracking happens at many web sites (particularly
sites that don't use cookies and rely on existing commercial traffic
analysis tools) today.

Ran

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Nov 2002 17:03:18 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Christian" == Christian Huitema <[email-masked]> writes:
    >> If you separate locators completely from end-point identifiers, the
    >> logical conclusion is NOT to move the function to the transport layer
    >> but to split the IP layer into two halves:
    >> 
    >> - A "lower" IP that routers packets much as today, and uses IP
    >> addresses as locators.
    >> 
    >> - An "upper" IP that provides end-point identifiers to the transport
    >> protocols and eventually to the hosted applications, and maps these
    >> identifiers to locators before passing them to the "lower" IP.

    Christian> There are a couple of issues with any proposal of that nature,
    Christian> and the main one is privacy. Having a unique identifier

  Sounds like an opportunity to me.
  Let's solve this problem by securing the internet.

  End-point identifiers with public keys in reverse DNS is very nice.
The argument against has been that the ISPs don't give end-users access
to the reverse DNS. 

  But, they'll just worry about reverse for locators, not for end-points.
We can do something sane about getting access to reverse for end-points.

    Christian> exposed to the network means that anybody on the path can
    Christian> track the presence and location of users, with consequence
    Christian> ranging from annoying (e.g. variations of telemarketing) to
    Christian> downright dramatic (e.g. missile auto-aining to a cell
    Christian> phone). To meet the privacy requirement, you would want
    Christian> addresses (as incorporated in the header) to disclose as
    Christian> little as possible about their owner. In a mobility or
    Christian> multi-homing situation, you may well want to hide from the
    Christian> network any correlation between addresses that happen to be
    Christian> used by the same entity.

    Christian> -- Christian Huitema

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 8 Nov 2002 20:38:11 -0500

On Friday, Nov 8, 2002, at 17:03 America/Montreal, Michael Richardson 
> The argument against has been that the ISPs don't give end-users access

ASIDE:
	One can emulate PTR by adding an IPv6 end-to-end option that gives
the recipient a hint about which forward lookup to try to 
authenticate.[1]

Ran

[1] Not originally my idea.  Pointed out to me by someone else during
a meeting at ICIR last year...

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Nov 2002 17:17:04 +0859 ()

Christian;

> users,

Note that you said "location". That is, it is an issue related to
semi-permanent locators.

It is fine.

The worst approach to the issue, on the other hand, is to hide
identity from general public but not from governments and ISPs.

Governments and ISPs watching packets can trace them to
their destinations.

Not giving ID->locator mapping is such an approach.

Privacy on ID is non-issue.

						Masataka Ohta