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

[Erik Nordmark <[e-mail]>]

Paul Jakma wrote:
> On Mon, 3 Oct 2005, Erik Nordmark wrote:
> 
>> 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.
> 
> 
> Surely we ought to distinguish CGA from HBA here? Only HBA provides a 
> unique mapping. CGA is just 'anonymous' public key crypto, as IPSec is. 
> IPSec at least does /allow/ for key exchange schemes other than 
> anonymous keys, like X.509 cert chains, GSS-API, etc.

No, CGA is qualitatively different to IPsec leap-of-faith as in HBA.
Thus for the perspective of understanding how IPsec leap-of-faith is 
different than what we have on the table with HBA/CGA, the CGA vs. HBA 
difference isn't critical.
(That doesn't mean that CGA and HBA are identical, but they are the same 
in that neither of them rely on leap-of-faith.)

>> 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.)
> 
> 
> Note that if Bob is not MITM, he can still get Alice's HBA, though it 
> requires Bob to first communicate with Alice. Eg with some innocent 
> unrelated pretence.

Yes.

>> 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.
> 
> 
> Yes, it's a very nice property of HBA, I must admit. Though, it does 
> completely rule out number portability, seemingly (in terms of ULIDs).

But the alternative is leap-of-faith, which, depending on the details, 
might allow my laptop to fool your laptop into it thinking my laptop is 
  www.google.com with very little effort.

I think being able to recover from a MiTM as soon as the MiTM moves off 
the path is an important property.

(FWIW some of this is discussed in 
draft-ietf-multi6-multihoming-threats-03.txt, which is in the RFC 
editors queue.)

   Erik