[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notes about identifier - locator separator



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