Re: Notes about identifier - locator separator

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Pekka;

> [During the last couple of days there have been quite a lot
>   of comments, by various people, on the ideas of separating
>   identifiers and locators (see the end of this message for
>   some quotations).  Based on our experience on Mobile IPv6,
>   the late Homeless Mobile IPv6 suggestion, and our current
>   work on Mobile IPv6 security and HIP, I'd like to present
>   a few observations.  Disclaimer:  I am far from being a
>   routing expert, so take your usual grain of salt.]

You are mostly correct.

However, you made mistakes on security, DNS and mobility.

>     From the privacy point of view, it would be a
>     definite plus if the actual, long lasting identifiers
>     would not be visible in packets.

Your privacy concern is caused by long lasting IDs by itself and
has nothing to do with visibility in packets. No one think it a
problem that their phone numbers are visible in SS7 packets.

Long lasting IDs weaken privacy because it is used as a key to
merge multiple databases.

>     There are
>     techniques how identifiers could be cryptographically
>     masked in a way that still allows middle boxes
>     (such as firewalls) and end-points to still recognize
>     valid identifiers but make it hard for outsiders
>     to track them.

As long as the end-points, which hold the databases, can
recognize the ID, the end-points can merge their databases.

You might think that, the concern can be avoided with short-lived
ID. However, long lasting database entries needs long lasting IDs.

The solution is to accept the reality.

Those who mind can change their IDs as frequently as they want
or can use multiple IDs at once.

> 3. Resolution
> 
>     Apparently there must also be some way of finding the
>     locators based on the identifier or a name.  Apparently
>     there is a huge number of possible solutions to this.
>     One of the most obvious ones is to store both identifiers
>     and locators into the DNS, and make the name resolution
>     library to fetch both.

You seems to be thinking of inverse query, leagacy feature found in
RFC103[45] replaced by in-addr.arpa. However, it does not work.

If you rely on DNS, you must make DNS work in multihomed environment.

In addition, you can't force DNS act quickly enough for mobility.

							Masataka Ohta