[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:
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. 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
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 (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).
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?
(another thread perhaps?)).
I mean, if the shim allows to freely bind any id to any locator,
then any communication could be redirected to any locator that any
attacker wants, which is way more vulnerable than current attacks
to the routing system.
Indeed.
Thanks for perserving in explaining the intended use of HBA to me.
Though, it does for me open some further questions.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
When you dig another out of trouble, you've got a place to bury your own.