[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: addition of TLV to locator ID or locator ID set
On Mon, 3 Oct 2005, marcelo bagnulo braun wrote:
i am not sure what you mean here, nut just for stating things
precisely, HBA do have globally assigned prefixes
Uh, ah. I didn't realise that. Who assigns them? And surely the point
of HBA is that they can be locally assigned? (Or do you mean HBA's
stand a very good chance of being globally /unique/?).
I had, in my mind, been considering that there would be a mechanism to
allow the prefix set -> ULID mapping to change
there is, the CGA part of the HBA/CGA hybrid addresses.
That is why there are three flavors of addresses:
- HBA that support a static set of addresses that cannot be changed during
the lifetime of an established communication (with the cost of a hash per
address)
- CGA/HBA that support a stable prefix set and additional addresses that can
be added during the lifetime of the communications (the cost of the stable
addresses is a hash operation while the cost of a new address (out of the
initial set) is a public key operation)
- CGA addresses, any addresses can be used with the cost of a public key
operation
I'd have to ask: Why use CGA?
AFAICT, CGA was created specifically because relying on IPSec for
address assignment has bootstrap issues. Hence CGA and SeND.
For modes relying on anonymously introduced public-key cryptography,
we won't have bootstrap issues here, so why not use standard IPSec?
Is it just to avoid the size of an AH header on each packet?
How will you communicate the CGA parameters? Is shim to reinvent
portions of IKE in order to communicate public keys? Why not just use
IKE? IPSec is well-understood, widely implemented and deployed. Why
give ourselves the task of reinventing aspects of it?
I can see some of the attractions of HBA, but using CGA beyond the
local-link is stretching it..
(That's not to say a host that was configured with a key for CGA
couldn't use the same public key for IPSec..)
However, you should note that the public key used is included in
the hash that results in the interface identifier of the addresses
Ok.
fairly big cost in functionality. (Eg, what exactly would shim6
using invariant HBAs offer over application layer remapping
support?
i am not sure i understand what you mean here... could you expand?
For me, the prime benefit of multihoming is not so much having
multiple links but having number portability and the ability to
easily transfer between providers[1]. Eg, shim'ing but having only
one provider would be something I'd be interested in if it gave me
portability. It's been a big reason for multihoming for two
organisations I've worked with.
Without portability, you're left only with solving failure events
amongst multihomed links. And I don't think you need a shim layer for
this, personally.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
travel, n.:
Something that makes you feel like you're getting somewhere.