[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: addition of TLV to locator ID or locator ID set
On Sun, 2 Oct 2005, marcelo bagnulo braun wrote:
IMHO, what would be not so hard to support would be that source
address prefixes get rewritten by the exit routers as long as the
the security stuff remains end to end i.e. the hosts are the ones
that define the HBA/CGA sets and perform the security validation.
That is basically offloading the source address selection to the
router, but the remining parts of the shim are still in the hosts.
That depends I guess on whether the HBA stuff tries to use more than
the 64bits of lower-order address space reserved for the host. If it
confined itself to that, it could work. If HBA wants to affect the
higher order 64 bits, that would have implications for how to assign
such addresses.
The HBA draft seems to suggest it confines itself to the 'interface
identifier' though. (In which case, you just need a way to make the
available-prefixes known to the hosts, to allow them to construct the
HBA identifier).
The problem here is how do you bind the key that is used in IPSec with the
identifier used.
If you don't provide a security binding, then an atacker can provide its own
key and bind it to the victim's identifier, so no good.
The options to provide a secure binding are:
- a third trusted party i.e. PKI
- create the identifer so that it intrinsically contains key information i.e.
CGA/HBA
because of the deployment issues, the second option seems more attractive
But you still have the issue of distributing the HBA public key, no?
Otherwise the only thing HBA can prove is that the /first/ host which
communicated with you using some HBA address does not have its
addresses subverted, right? Further, you will have to put a limit on
how long a host remembers state (or, on the number of remote HBA
hosts it may keep state for). Once that state goes, so the window
opens up for the HBA concerned to be redirected, surely?
There's no difference between that and anonymous IPSec, is there?
IPSec however was designed to be able to be extensible and cope with
lots of different algorithms and key exchange schemas. You'd have to
reinvent all that to make HBA cope, plus you're limited to 128 bits
of information, if you want to use only the IPv6 address as the
identifier. (what about replay attacks? :) ).
Way I see it, as long as Shim state changes can not be effected with
ordinary shimmed packets, as long as state changes (eg,
addition/removal of locators) can only be signaled via some side-band
Shim protocol[1] then you only need to secure that side-band. IPSec
(the standardised, deployed and agreed on IETF security protocol for
IP..) will do fine for that and provide security ranging from
anonymous to more trustworthy schemes.
Mind you, I still don't really fully grok HBA - what critical detail
am i missing?
regards, marcelo
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Goda's Truism:
By the time you get to the point where you can make ends meet,
somebody moves the ends.