Re: Notes about identifier - locator separator

[Pekka Nikander <Pekka.Nikander@nomadiclab.com>]

Ohta-san,

Masataka Ohta wrote:
> However, you made mistakes on security, DNS and mobility.
I am always eager to learn more.  Thank you for providing
this opportunity.

I wrote:
> >    From the privacy point of view, it would be a
> >    definite plus if the actual, long lasting identifiers
> >    would not be visible in packets.
To which you replied:
> 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.
Well, let me both agree and disagree with you.  From my point
of view, the situation is not as simple as you seem to say.
But maybe we are just talking about the same thing with
different words.

Firstly, if we want to build long lasting relationships, we
need long lasting identifiers.  There we seem to agree.

However, the long lasting identifiers are no business to
those outside of that relationship.   The relationship may
be binary, in which case the IDs are relevant only to the
two communicating parties.  Or it may have higher arity,
in which case there are also other parties that have
legitimite access to the identifiers.

Secondly, given a single packet travelling in the network,
the long lasting IDs may be presented in clear text, or
alternatively they may be either implied or encrypted.
If they are not present in clear text, most parties
that see the packet have no access to the IDs.  On the other
hand, the receiver of the packet, and perhaps also some
middle boxes (such as a corporate firewall) do need to have
access to the IDs.

The key here is state.  If the middle box or the receiver
has state (e.g. a cryptographic key or a communication context),
it can check that the arriving packet indeed contains or
implies a known long lasting identifier, and act accordingly.
However, parties that do not have that state cannot find
out the long lasting identifiers.

If we want to go to the heavy transactions track, Marianne
Winslett in one hand and the KeyNote guys (Bellovin, Blaze,
Feigenbaum, Keromytis, JI, and more recently also others)
have done quite a lot of work.  However, if we want to hide
the long lasting IDs but not pay the cost of PK crypto, there
seems to be fewer published works.

> 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 issue with database merging is completely different.
That can be resolved by having multiple pseudonyms that
cannot be easily linked.  However, each of the pseudonyms
can be long lasting by itself.

> The solution is to accept the reality.
Of course.  I couldn't agree more.  And IMHO, the reality
also includes parties that attempt to perform traffic
analysis on the packets flowing in the wire instead of
trying to penetrate to the end-points.  Echelon comes
to my mind...

-----

> > 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.
Would you please point me to text that explains why the
reverse DNS database does not work, and in which way?

OTOH, I was mostly thinking about a very simple forward
resolution:

  a.domain.name -> (identifier, locator, locator)

For example,

  a.domain.name.   IN   AAAA  locator1
                   IN   AAAA  locator2
                   IN   XXX   identifier

where XXX would be either a new RR type or, e.g., KEY RR,
if public keys were used as identifiers.

What comes to identifier -> locator resolution, I don't
think there is anything ready.  Distributed Hash Tables
seem like one possible future technology, but it has
a long way to go before it can become a part of the
established infrastructure, if ever.

Or alternatively the identifiers could be hierarchically
assigned.

> If you rely on DNS, you must make DNS work in multihomed environment.
I agree, and I'd like to learn better the issues around this.

> In addition, you can't force DNS act quickly enough for mobility.
Yes, I know.  For mobility something like Home Agents or LIN6
identifiers are needed.  In the HIP architecture, this is
called randezvous service.

--Pekka Nikander