Re: Notes about identifier - locator separator

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

Pekka;

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

Unfortunately, no.

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

It has nothing to do with whether the ID is long lasting or not.

Note also that locaters often act as long lasting 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.

For a receiver to retrieve an appropriate cryptographic key or
a communication context for a packet, a long lasting ID in clear
text, as an index to the long lasting database of key or context,
must be carried by the packet.

Once such key or context is retrieved, the following packets of a
connection can use locators as a short lasting IDs. But, it does not
mean that a long lasting ID is not initially necessary.

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

PK is useless.

Crypto works only if you tell your ID, that is, some index information
to retrive a cryptographic key or a communication context, in clear
text, to the other end.

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

Proxies are a way aginst Echelon.

However, more important aspect of the reality is that if identity
of someone is hidden, the network is valunerable to SPAM and other
forms of DOS.

In your case, as locators act as a long lasting ID, Echelon works
fine and SPAMMers can be traced.

Cyber terrorists can still use chains of a lot of proxies to make
the trace more difficult and the Internet less secure.

But that is unavoidable reality.

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

I said "inverse query". See the RFCs.

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

There are complex issues. The first step of learning is to read basic
RFCs.

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

I feel some difficulty that you call such approach "Homeless".

							Masataka Ohta