Re: addition of TLV to locator ID or locator ID set

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

[Seems like the topic hasn't anything to do with the subject line any 
more ;-) ]

Paul Jakma wrote:

> That's the same thing you could achieve with anonymous IPSec. (Though, 
> IPSec associates state with a 'security association' rather than 
> address, which could be more fine-grained than CGA). It's an anonymous 
> key either way, unless there is some other way to verify the 
> authenticity of a key and what it may be used for / who it is issued for 
> (who in terms of IP addresses).

There is a qualitative difference between the various leap-of-faith 
security schemes (ssh being one example, I think BTNS is talking of 
adding the same thing to IPsec), and HBA/CGA as it comes to securing the 
locator changes in shim6.

Let me take an example:
We have Alice and Bob on the IETF wireless network, and Cesar being some 
remote site (e.g., www.google.com).

If Bob can predict that Alice will communicate with Cesar, the if a 
leap-of-faith approach is used, Bob can contact Cesar and pretend to be 
Alice, and create state on Cesar (ssh key fingerprints, IPsec/IKE SAs).
This is trivial when Alice and Bob are on the same IP link. This state 
will be associated with Alice's IP address.

The effect of this is that Alice will fail to communicate with Cesar, 
since the created state is in the way; Cesar will conclude that Alice is
an impostor who is trying to be Bob and does not have the correct key.

Thus in effect, the leap-of-faith provides a first-come-first-serve 
approach to anybody wanting to claim an IP address as theirs.

And the attack can also be done in the reverse direction; Bob contacting 
Alice pretending to Cesar and creating state on Alice that will prevent 
Alice from talking to the real Cesar.

Note that these attacks assume that Bob can be a MiTM for a at least 
short time so that it can create the state.
But the effect of a short presence can be long lived; it depends on how 
quickly (if ever) the particular security mechanism on Cesar will 
discard the state for Alice. Typical IKE/IPsec timeouts might be 
measured in hours.

Compare this with using HBA.
With HBA Alice and Cesar will create the IPv6 address(es) as a hash of 
some things.

Thus the only want Bob can pretend to be Alice (and have the same IP 
address) is to use the identical HBA parameter data structure. (This 
isn't hard, since the parameters are sent in the clear.)

When it does this and communicates with Cesar, there will be shim6 state 
setup on Cesar for Alice's IP address and its HBA parameter structure. 
As part of this there will be some cookie (shim6 context tag) exchanged 
between Bob (pretending to be Alice) and Cesar, but there are no session 
keys or other long-lived material setup as part of the context, except 
from Alice's HBA parameter data structure.

What happens when Alice tries to setup a shim6 context with Cesar?
Well, the details have to be specified, but I suspect it's just a matter 
of Cesar verifying that the locator for Alice is the same as before, but 
that Alice doesn't have the context tag, and which point Cesar can tell 
Alice what context tag to use.

Unlike leap-of-faith schemes, which as part of their nature end up 
assuming that the first host to connect is who they claim to be, the 
intrinsic result of having a hash of something in the interface-id in 
the address, is that we don't need to make any such leap of faith.
Which means that we can have a lot more flexibility when it comes to 
handling attackers like Bob above who is on the path for some amount of 
the time, but perhaps isn't permanently on the path.

   Erik