[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: addition of TLV to locator ID or locator ID set
El 30/09/2005, a las 22:16, Paul Jakma escribió:
On Thu, 29 Sep 2005, Erik Nordmark wrote:
How does the host get an IPv6 address assigned that has the right
low-order bits so that the HBA stuff on the remote shim/proxy can
prove (using HBA) to the peer that it owns the IPv6 address hence is
allowed to redirect it?
I don't know. I'm not terribly familiar with HBA. Marcelo seems to
think it's possible.
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.
doing proxy shim for legacy hosts is much more complex, i.e. letting a
proxy box to provide shim capabilities to a legacy host
BTW, one question, is HBA a requirement for shim6?
as is see it, HBA are not a requirement but so far they seem to provide
the security protection required
CGAs can also provide the security required, supporting additional
features with a higher computation cost.
As HBAs are defined as an extension to CGAs, then supporting both of
them would not be complex
Other possibilities include simply securing the side-band shim6
protocol (using, eg, anonymous IPSec) and disallowing any
locator<->ULID (do i have the jargon correct?) state changes to occur
other than through the secured side-band.
Then you wouldn't need to try stuff security state into an address.
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
destination locators to be changed). Thus if the shim proxy wants to
handle this, it needs to first do a 1:1 IPv6 NAT where the proxy has
created the HBA/CGA addresses for the host.
It'd have to be a 1:1 NAT yes.
One could envision having DHCPv6 be shim aware so that when the hosts
asks DHCP for an address, the DHCP server would interact with the
shim proxy so that the addresses are from a HBA or CGA set. In that
case one wouldn't need the 1:1 IPv6 NAT in the shim proxy.
Hmm, possible I guess.
Paul Jakma email@example.com firstname.lastname@example.org Key ID: 64A2FF6A
A lawyer with a roving commission.
-- Ambrose Bierce, "The Devil's Dictionary"