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