[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: addition of TLV to locator ID or locator ID set
El 03/10/2005, a las 14:10, Paul Jakma escribió:
On Mon, 3 Oct 2005, marcelo bagnulo braun wrote:
well, hybrid CGA/HBA is required if you want that an established
communications can use a new prefix introduced to the site due for
instance, to renumbering. I guess that the need for this is at least
debatable, since a renumbering event is expected to be not so
frequent compared to the expect lifetime of most established
communications. I guess that for most established communications, it
is good enough to keep on using the remaining prefixes available, and
then when a new communication is established to incorporate the new
prefix available after renumbering. So i would say that the public
key will be needed in rare cases where extremely long lived
communications are required.
Ok, sure. That could be an acceptable tradeoff. That's also the detail
I had been missing / not considered. That allowing the underlying
prefix set to change significantly would not be allowed.
Actually we can therefore end this discussion wrt
Shim6-by-site-intermediary, because there are no more
incompatibilities - simply be saying that the site-intermediary case
would have to use a globally assigned address prefix.
i am not sure what you mean here, nut just for stating things
precisely, HBA do have globally assigned prefixes
That is what I had in mind, so:
end-host shim6 -> uses a HBA for ULID.
site shim6 ->
hosts are assigned ULIDs from a stable, invariant address range.
hosts just use regular IPv6 stacks and regular ways to
assign themselves IPv6 addresses
These could be HBA as well, just that someone else should create the
HBA set for the host e.g. the dhcp server could generate the hba set
for the legacy hosts
intermediary does shim6, 1:1 mapping.
Both cases would use the shim6 mechanisms. The latter case would need
further thought regarding the ulid:locator(s) binding (providing proof
of its validity), which HBA would have provided (as per end-host).
(One possibility would be that such a globally-assigned but
non-globally routable prefix would also have a key set registered at
the point assignment, gets tricky - but the mechanism at could allow
for such. Probably difficult to solve without significant operational
considerations. :( )
I guess this depends about how do you define who... At this level,
who is the identifier and where is the locator, so the HBA/CGA
actually securely bind the who with the where This is exactly what
need to be protected, since the shim is separating the who form the
where.
Right.
I mean, currently, the relationship between the who and the where is
the identity, since both are the IP address of the node. With the
shim, the locator and the id are separated, so what is needed from a
security p.o.v. is to restore the security of that binding, which is
exactly what is achieved with the CGA/HBA
Well, that depends on 'security' really. But as your point below, I
guess it does at least make it the same as existing IP, yes.
Problem is, we intend to introduce something new, shim6 mechanisms. :)
HBA does solve a lot of the spoofing issues though, yes - i understand
that now - if renumbering is left out.
right but current (non shim) communications are vulnerable to on path
attackers, so this is no worst that today... the goal from a security
perspective is that shim communications are as secure as non shim
communications
Ok.
HBA seems a way to detect quite fraudulent packets (invalid
binding), it doesn't seem (to me) to be a way to assure a received
packet came from where the binding claims it did.
just as today, right?
Sure.
With HBA/CGA is the same, since in order to receive packets to the
claimed locator, you need to be the owner of the HBA set (i.e. being
able to receive packets at the HBA addresses) or be an on path
attacker
Right.
C can, at a minimum, play havoc with any shim mapping on E relevant
to A,
not sure what do you mean here... what kind of attack do you have in
mind?
I mean, shim communications protected by the CGA/HBA are susceptible
to on path attackers as any non-shim communications
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
(to support (partial-)?renumbering events). If that is not to be
allowed, then indeed the attacks are minimal.
I think that the key point here is to understand the threats
introduced by the shim. The goal in not to provide extra security,
but to make things not worse that what are today in non-shim
communications.
because otherwise, anyone could claim that any identifier is located
in any locator, which is clearly worst than what we have today
Right, and HBA prevents such claims. I had failed to understand that.
I had thought (from the example in the draft which referred to using a
public key) that there would be a way to allow such claims to be made
(or at least, for an existing HBA mapping to change its verifiable
mapping and claim a new mapping).
yes they are, see above.
However, you should note that the public key used is included in the
hash that results in the interface identifier of the addresses
If that is not to be allowed, then everything is much simpler. But at
a 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?
regards, marcelo