[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: addition of TLV to locator ID or locator ID set

In addition to what Marcelo posted...

On 3-okt-2005, at 10:42, Paul Jakma wrote:
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?
Right. With HBA, the ONLY thing that's protected is the set of prefixes that host using the HBA address is connected to. (Obviously a host can also add prefixes to the HBA that it's not connected to, but the point is that third parties can't.)
Along with a verification procedure, this makes it possible to authenticate the locator set / identifier relationship.
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).
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.
It's still entirely possible to inject all kinds of falsified packets. HBA and CGA aren't general purpose security mechanisms: if this is what you need, use IPsec.
However, without HBA or CGA it would be possible to redirect packets (assuming the shim is used) even in the presence of IPsec.
CGA simply ties a public key / certificate to an address. This key or certificate can then be used to authenticate further exchanges so an attacker can't successfully inject shim signalling.
With HBA, the shim signalling itself isn't protected: an attacker can execute any valid signalling exchange. However, the HBA limits the set of valid exchanges to the ones related to a prefix where that prefix is one of the set for which there is a valid hash in the interface identifier.
Now if the attacker has control over all these prefixes, the communication is at the mercy of the attacker. Even if the attacker can only observe packets flowing to/from the initial address and inject spoofed packets of his own, that's probably enough to make successful HBA-based shim signalling impossible. But the attacker can't do anything that he wouldn't be able to do if the shim wasn't there.
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,
Yes, it can inject falsified shim signalling packets that make the real shim signalling derail.
if the only security is HBA and the shim protocol is stateless (without having to observe packets obviously).
Obviously all signalling will use cookies so blind injection attacks shouldn't be an issue.
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.
So C would assume A's address and start communicating with E. C would then have to block traffic from E to A, or A would send RSTs or similar. So C would have to be a man in the middle.
Suppose C now initates a rehoming. C would also have to be present at the new address A' in order for E to accept the change. And A' must be an address that belongs to A because otherwise A wouldn't have included the prefix in question in its HBA.
I suppose this attack might be useful for C if C can only be a man in the middle between A and E for a short time, but be a man in the middle between A' and E for a longer period. As long as C keeps the A' - E association alive, A is going to have a hard time connecting to E using A - E. 


I don't see what prevents an attacker constructing the same HBA.
But ONLY the same HBA or an unrelated one: NOT one that has the same interface identifier with a different underlying prefix set (not without 2^50 or so tries). It's like being able to create a copy of a passport without being able to change the photo. Since in our case the "photo" doesn't allow for ambiguity this makes the "passport" useless for anyone but the real holder.