[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 10:42, Paul Jakma escribió:
On Sun, 2 Oct 2005, marcelo bagnulo braun wrote:
there is no public key in HBA... there is public key in CGA though
(and in hybrid CGA/HBA)
Hybrid being required to support renumbering events, right?
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.
However there is no security issues with CGA public key distribution
because the CGA is intrinsically bound to the public key, so it is
extrmely hard to find a different public key that is bound to a given
CGA
Sure.
the HBA addresses are intrinsically bound to the prefix set, so there
is no leap of faith involved in the usage of HBA (nor in CGA) as
opposed to opportunistic IPSec
HBA addresses are bound to a given prefix set i.e. the addresses of a
given HBA set are bound together and this cannot be easily forged. In
the same way, the CGA is bound to a public key and cannot be easily
forged.
Sure, so it proves the packet was constructed correctly, at least the
association of the outer locator prefix to the inner ULID. This
doesn't prove anything about who sent the packet though, does it?
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. 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
It seems vulnerable to injection attacks (unless you assume routing is
secured in some way, eg RPF everywhere, but that still leaves a an
attacker who is on-link or MITM able to inject packets. Further,
operational experience shows this to be a dangerous assumption to rely
on).
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
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?
Anyobe can send form any IP address as long as there are no ingress
filters, but if you want to receive packets to the calimed address, you
need to be at the correct topological location (i.e. be the owner of
the address) or be on the path.
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
As i mentioned above, there is no leap of faith in HBA/CGA security,
while it does exists in oportunistic IPSec. Actually, the nice thing
about CGA/HBA is that they do provide a quite continuos protection
and don't need to trust in the information exchanged during the
initial contact, preventing the so-called future or time shifted
attacks
I'm not quite sure that's true:
A-----B D ---E
| |
-----
|
C
For whatever operational reasons C is able to send packets with the
same source prefix as A, it /might/ also able to able to observe the
packets sent by E to A.
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
if the only security is HBA and the shim protocol is stateless
(without having to observe packets obviously). If the shim protocol is
not stateless, eg through use of some sequence number, then it can
(without observation) possibly deny A from speaking to E by setting up
shim6 negotiation in advance of A doing so (A's shim6 control packets
then might be rejected, due to wrong state) if E assumes that for a
given valid HBA future state will match. With observation, C can
likely play further havoc.
Attacks requiring no observation likely would work regardless where C
is located..
Obviously, we don't know yet what the shim6 protocol will be. But I
don't think it can assume very much about security just because HBA
checks out..
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.
The problem is not key exchange, is the binding between the
identifier and the key. for example you could use the key of the CGA
in IPSec, (actually, HIP is basically what it does) and we could use
AH and ESP formats here for securing the shim protocol, no problem
with that. The point is how do we make sure that the key used in
IPSec corresponds to the identifier we are using and not to an
attacker
I don't see what prevents an attacker constructing the same HBA.
it prevents that an attacker to freely associate any locator to any
identifer, as described in the threats draft
If you rely solely on HBA validation then Shim would be vulnerable to
injection attacks. If you add further state to the Shim protocol to
defeat blind injection attacks, then you'll be open to same anonymous
state DoSes as anonymous IPSec. (In which case you might as well have
used IPSec).
right, how do you bind the key used in IPSec with the ULP identifier
used in the shim?
Well, why is this required exactly?
because otherwise, anyone could claim that any identifier is located in
any locator, which is clearly worst than what we have today
I don't think it provides that much security (just a modicum of
anti-spoofing protection).
how to perform the binding between the ULP identifier and the key
used in IPSec
You don't have a secure binding though, unless you assume IPv6 routing
is to be completely secured before shim6 deployment and made immune to
injection (unlikely).
Well, actually, today, if you want that packets addressed to a given
address A are delivered to address X you need to tamper the routing
system. This may not be so difficult, but it is definitely not
available to any user.
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.
regards, marcelo
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
UFOs are for real: the Air Force doesn't exist.