Re: Shim6 proxies

[Erik Nordmark <erik.nordmark@sun.com>]

Iljitsch van Beijnum wrote:

> Unless I'm mistaken, if you go to an HTTPS website, what happens is that 
> your browser gets a certificate from the server that proves that the 
> holder of the certificate has a certain identity, such as 
> www.example.com. The browser checks whether the server has the private 
> key for the certificate by sending it a challenge and checks if the 
> identity in question matches the URL, which, I imagine, requires some 
> DNS lookups.
> shim6 security could work much the same way by tying a certificate to a 
> ULID, either with or without the intermediate step of an FQDN. Such a 
> certificate allows a host to prove that it holds a certain identity, 
> irrespective of the address it's actually using. Once you know who 
> you're talking with you can mostly believe them when they say what their 
> locators are, you just need to send a packet to those locators to make 
> sure the same host is present there to avoid the possibility of someone 
> dumping shim6 traffic on an unrelated third party.
> As for the PKI, yes, you need some kind of infrastructure, but it's 
> already there so I don't see the problem, especially for enterprises and 
> content hosters. Most home users don't have a certificate, but they can 
> still use HBA. (Note that in the above scenario only one side (usually 
> the server) needs a certificate.)
I can see this working, but it can't securely recover a context after a 
failure failure! This is because there is no trusted relationship 
between the certificate for the server and the alternate locators of the 
server. (And I have only thought about end-to-end use of this - not 
proxy use - so I don't know if that would add some further complications.)
The host (which doesn't have a cert) uses HBA. Looks up www.example.com 
and gets some IP addresses. The shim6 layer on the host is told the FQDN 
for the peer.
During the shim6 context establishment TLS is used, which verifies the 
server's cert. If the server needs to use a different locator it can use 
TLS to tell the client the new locator; the shim6 layer needs to verify 
that the same cert is used for the locator update as was used for the 
context establishment.
But that happens if the client looses the context and the server needs 
to send it some data? One would have to fall back on essentially return 
routability, since the client's shim doesn't remember the FQDN of the 
server any more (perhaps the application remembers the FQDN but that 
doesn't help unless we redo all the socket APIs from scratch).
The worst case is when the client has lost the context and the server 
needs to contact the client but using a locator that is different than 
its ULID; in this case even return routability can't be used.
Thus it would allow the server to say "my FQDN is www.foo.com and this 
is my cert, and even though I'm using locator X, I also have ULID=Y - 
trust me".
You could argue that the bulk of these problems occur when the "server" 
needs to contact the "client" and that this case isn't important. But if 
we'd want to add this, I think "server" is really "host that has a cert" 
thus we'd want this security scheme to work independently of the 
application layer roles (server vs. client) of the host that has the 
certificate.
So I don't see how the certificate helps, unless there is a global PKI 
which can assertively state the IP addresses of the holder of the 
certificate (and have this somehow be updated when the site/host 
renumbers). Without this, all we seem to get is something analogous to 
anonymous diffie-hellman, and that doesn't help prevent time-shifted 
redirection attacks.
I think one can try to do things using DNS forward+reverse lookups for 
verification of relationships between ULIDs and locators. The old NOID 
draft explored this space. But my personal conclusion was that such an 
approach would be expensive, since to be reasonably secure, the hosts 
would have to do forward+reverse lookup (or reverse+forward) even before 
establishing the shim context. There was also the issue that NOID 
assumed that all communicating parties had correct forward+reverse DNS 
entries.
But it might make sense to look at the possibility of using DNS 
verification for one end and HBA for the other.
   Erik