[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.