On Mon, 18 Dec 2000, Theodore Y. Ts'o wrote:
> My concern is that it may turn out that some transport/routing people
> may conclude that we may also need to do NAT to solve the routing
> problem.  In which case, we're back to where we started.
> 
> I'd feel a lot better if we could get key routing/transport people to
> sign some contract in blood stating that the IPV6 address is guaranteed
> to be invariant, and that any attempt to design boxes which muck with
> the IPV6 address in transit is architecturally out of bounds.  That may
> seem to you to be obviously true, but I 10 years ago we assumed the same
> would be true for IPV4 addresses.

Gateways that surreptitiously modify packets can break ANY end-to-end
protocol no matter what layer it's at.  Assume that we sacrifice IP
addresses as not necessarily end-to-end.  Fine, there are gateways that
need to modify your TCP ports too.  Okay, sacrifice make it so ports
aren't covered by e2e assumptions like IPsec.  Fine, there are gateways
that do ACK spoofing.  Okay, sacrifice all header data and assume that
only payload is e2e.  Whoops, even the payload has to be modified by some
gateways.  The hypothesis that you can have these gateways and have
any part of the packet be guaranteed to be e2e is false.

But I don't think these gateways are evil and should (or could) be
forbidden.  My hypothesis is that end applications have to know that these
gateways exist.  They shouldn't be surreptitiously transparent; they
should be discoverable and applications should be aware of how high   
in the protocol stack that gateway reaches.

Take the hardest problem, a gateway that reaches all the way up to the
application layer to do content inspection.  The application has to make a
trust decision about whether or not it is willing to negotiate a key with
that gateway that will let it decrypt the data.  Otherwise, the gateway
may refuse to pass the traffic.  So the application consents, a protocol
library provides the gateway with a decryption key, and the application
annotates the little padlock in the corner of the user's screen
appropriately.  If so desired, the application can implement a policy that
the decrypted form of the user's credit card number won't be provided to
any proxy or endpoint that doesn't have a certificate signed by Visa's
credit card practices review authority.
  
Take an intermediate problem.  Assume that only address and port
translation are required by the gateway.  The application can therefore
assume e2e payload authenticity and privacy, but cannot assume e2e privacy
of its ports.

So that means that the coverage and keying of IPsec and TLS needs to be
negotiable based on the policies of intervening gateways (middleboxes).  
And that, of course, if predicated on the ability to locate middleboxes.

Given our inability to rule out the need for gateways that change IP
addresses (or other routing headers), this leads to the conclusion that
applications shouldn't use any header field (IP address, port, etc.) for
authentication.

> If it turns out that we need some kind of routing identifier in the IPV6
> address, whether it's the dreaded 8+8 scheme, or adding another 16 byte
> value in the header which router are free to muck with to our heart's
> content, at some level, whatever, I don't care.  I'm security guy, not a
> routing guy, so I don't know what will work the best, and at some level,
> I don't care --- just so long as it works, and that we have something
> which *everyone* agrees will be an invariant end-point identifier, now
> and forever, world without end, Amen.
> 
> Otherwise, 5-7 years from now, we'll be using IPV6, and there will be a
> need for some kind of routiing-gw/NAT boxes, and people will *still* be
> complaning that it's all IPSEC's fault that IPSEC doesn't work through
> NAT boxes, and the anti-NAT people will be complaining that the NAT
> folks have changed the rules again.  And all that work which the IPV6
> rollout folks have put into that project will in the end be for naught.

As far as naming (who) versus routing (where) is concerned, endpoint
naming seems as problematic as user naming is for X.509, etc.  Why not
apply the theory that a participant can be uniquely identified (but not
necessarily located) by its key(s) and that no fixed mapping to or from a
globally unique name (IP address) is necessary?

Let's say a user sees a billboard and wants to communicate with what the
billboard calls "www.cheapwidgets.com".  Given a uniformly accepted DNS
root or .com TLD, I would argue that DNSSEC can provide the verifiable
chain to the key known as (.com's cheapwidgets's www).  It will also
provide a mapping to the current routing address (which could be a point
of aggregation that knows a better local address).

More sophisticated directory services (or SIP servers) can provide the
same secure mapping to a key and/or DNS name.

-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information