RE: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt

[Christian Huitema <[e-mail]>]

>> I agree the CGA information will match in the case mentioned, and thus it is
>> possible to make CGA verification succeed for two different hashes for two
>> different values of sec (one with lower sec value being easier to generate
>> than the other).
>> 
>> But didn't we know that already?
>
> NO, as far as I know, up to now everybody thought that it is not possible to attack CGA with lower sec value while CGA node uses 
> higher sec value. We knew that it is faster to break CGA sec value 0. 

The CGA mechanism protects an IPv6 address. All the identifier bits are part of the IPv6 address. If an attacker uses a different SEC value, it is not attacking the protected IPv6 address, but a different one. 

> We also thought that it would take 2^59 but this is not true too based on Birthday paradox attack. 

This is a serious misunderstanding of the birthday paradox. The paradox states that if a number can take N values, it takes about sqrt(N) random trials for having 50% chance to find the same number twice. But the number found is a random number.

The birthday paradox does not apply in the scenario where you try to find a specific value. If a number can take N values, it takes about N/2 trials before having 50% chance to find the target number. 

>> Since the 3 bits of the sec level are copied from the IID, won't any mismatch in
>> the sec value used to create the hash be picked up by a simple comparison of
>> the received IID with the machines local IID in the case of DAD?
> 
> The CGA node retrieve sec value from the source IP address of the attacker and not from his own packet and do not get it from his own.
> The following sentence is after step 4 that already the victim node retrieved the source IP address from the attacker's packet.

So what? The attacker ends up using an IPv6 address that has many bits in common as the target address, but it different. There is no masquerading. The attack that you are describing just does not work.


Hosnieh, your draft also mentions a duplicate address attack. That attack is already described in RFC 3971 (SEND), with a proposed mitigation:

   9.2.3.  Duplicate Address Detection DoS Attack

   This attack is described in Section 4.1.3 of [22].  SEND counters
   this attack by requiring that the Neighbor Advertisements sent as
   responses to DAD include an RSA Signature option and proof of
   authorization to use the interface identifier in the address being
   tested.  If these prerequisites are not met, the node performing DAD
   discards the responses.

Do you have a novel way to break these mitigations?

-- Christian Huitema