Subject: Re: NATs *ARE* evil!

From: [email-masked] (Sean Doran)
Date: Tue, 19 Dec 2000 15:46:49 +0100 (CET)

Steve Bellovin, on IPSEC, not-AH:

| [A] host's identity is represented by its certificate (I'm speaking a bit 
| loosely here); its IP address is merely the way that packets reach it.  

This is an example of two separate namespaces that allow one
to distinguish between "who" and "where".   That the network
layer can be rewritten to the point of total protocol substitution
without interfering with the identification of who sent it
is a feature, adding enormous flexibility into the development
of network features.

That IPSEC can preserve the end-to-end integrity of the the
application-to-application data even in a rabidly-rewriting
environment makes one wonder why people are so fanatical
about preventing that rewriting at all!

(The important thing is that one knows that "Steve's Machine"
sent a packet that happened to arrive with a particular source
address, which for a while can be used to send replies back to
"Steve's Machine").

The only tricky thing here is having a "who" <-> "where" translation
readily available to the host.

	Sean.

P.S.: Incidentally, I have no trouble whatsoever with the concept
      of a last-hop-router before a host that can distinguish "who" 
      "where" being presented with a permanent, deterministic association
      between the two.  I also have no problem with the last-hop-router
      moving "corewards" even several hops.  The thing I want to prevent
      is the requirement that ALL routers provide such a deterministic
      permanent mapping between the two, because ultimately that makes
      the Internet more expensive for everyone to use over time.  
      (It also makes a non-dual-stack transition to a new Internet protocol 
      much harder on the host side, and a non-ships-in-the-night deployment
      in routers nearly impossible).

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Dec 2000 14:14:43 -0500

> is a feature, adding enormous flexibility into the development

agreed, *provided* there is a fast and reliable service for mapping
between one kind of identity and another.  arguments of the form
"separate identities are better" tend to gloss over the difficulty
of providing an adequate mapping service.

(Hint: DNS is neither sufficiently fast nor sufficiently reliable)

the other problem with separating the layers is that the ability to
drill down through layers is essential for diagnostic purposes, 
for tracking down miscreants, and to allow prototyping new kinds 
of services that need to operate with knowledge of layer 3.  So 
we will always have a need for some kinds of "applications" to 
operate with knowledge of network addresses.   

Keith

---

From: [email-masked] (Kai Henningsen)
Date: 26 Dec 2000 17:32:00 +0200

> (Hint: DNS is neither sufficiently fast nor sufficiently reliable)

Hmm, can't resist putting on my brain-storming hat here ...

Let's see: assume we have a map from "who" (endpoint identifier) to  
"where" (topology descriptor).

There will probably be a seconf map mapping "where" to "how" (routing  
info); this second will certainly be locally different - essentially  
traditional routing.

Hmm. If this is to include multi-homing support, the who-where map needs  
to be 1:N.

There's a problem with secure updating. I can connect via several  
different ISPs, just like a multi-homed host, so preferrably my endpoint  
identifier would not "belong" to those ISPs but to me. But then I don't  
know the topology information for that map any better than "I just  
connected to ISP X". And if that ISP isn't known to all routers globally  
(and at least one of them certainly isn't, doesn't even have an AS), then  
that information is not sufficient.

So: I need to update the map to say "I just connected to system X", and  
there needs to be a secondary map (unless of course the first one can be  
reused) that says "system X is in turn connected to system Y, which is  
connected to globally known system Z". (Except all of those really are  
1:N, not 1:1.)

Now when I want to send a packet, I need to do the equivalent to ARP -  
query the map for topology information for the endpoint identifier of the  
other side, resolve the next hop via local routing information, and send  
it on it's way to the next hop.

And here it gets interesting again. ARP just sends out a broadcast packet.  
We certainly don't want anything like that on the global Internet. So the  
packet needs to go to a specific destination, and for that to not create a  
bootstrapping problem, we'd need to have well-known ways to reach a local  
proxy.

Proxy. Hmm. Caching would certainly be necessary. How long? Until someone  
on the route says "I can't deliver this"? What about routers in the  
middle, how do they find out?

Where does the map live? We'd need to distribute the storage according to  
end-point ranges, I think, which means we get endpoint registries. Which  
probably need to be globally known (i.e. use special routing table  
entries) at least for the highest level, assuming there are several  
levels. (Why am I thinking EUI-64?)

This looks possible, but I can see a great many new headaches in actually  
getting it operable.

> operate with knowledge of network addresses.

That seems entirely possible with something like the above.

MfG Kai