[CGA-EXT] Subject: A new old attack on the NDP/SEND

[Tony Cheneau <[e-mail]>]

Hello,

I'm currently writing an article about an attack on the Duplicate
Address Detection (DAD) mechanism that works even with a SEND enabled
architecture.

Any comments are welcome.

The attack occurs when a node joins a network. An attacker can prevent
a node from joining a link by replaying the Neighbor Solicitation
packet (even if the packet contains the SEND protections). This is a
remake of the Section 4.1.3 in the RFC 3756: the "Duplicate Address
Detection DoS Attack".

As of Section 9.2.3 of RFC 3971 this old attack isn't supposed to work
anymore since the NA are "verified" with a RSA signature. Here, we
replay a NS message during the attack, so we will have a valid RSA
signature and this security mechanisms will be void.

According to Section 8 of RFC 3971 a DAD process is considered as
unsuccessful after 3 failures. Here again, an attacker can replay the
packets 3 times simulating unavailable addresses.

The success of the validity check on the packet is based on these
points:
- The CGA is fully valid as the packets are being replayed.
- The RSA signatures are still valid (the packet wasn't altered).
- Though RFC 3971 suggests using the "nonce" option to match requests
with responses, there's no specific usage defined for it. There isn't
any recommendation of how to use this option in SEND.
- Concerning the Timestamp protection: according to Section 5.3.3, the
  victim node will set the Timestamp field to his current time when it
  sends his packet. So the attacker will have the same value in the
  (replayed) Timestamp field. The replayed packet will be considered as
  a new by the victim. This implies that the victim should verify the
  packet with the following equation (according to Section 5.3.4.2):
  		- Delta < RDnew - TSnew < + Delta
  RDnew is time of receiving of the message and TSnew is the Timestamp
  of this new message. From the attacker perspective, RDnew is the time
  when he received the packet plus the time to effectively replay it.
  Since TSnew is supposed to be the current time of the victim when he
  sent the packet, RDnew should be close to that value. (as a side note,
  on the OpenSource NTT DoCoMo SEND's implementation, this Delta value
  is set by default to 300 seconds)

We may think that the node won't listen to the packet since it's a copy
of its own packet. Section 5.4.3 of RFC 4862 says it depends on the
loopback semantic (which means here that in any cases, a replayed
packet won't be considered as duplicated).

The requirement for the attacker is to have access on the link
resources. The attacker must be able to listen to multicast packets
emitted by the victim (to be able to listen to the packets sent to
victim's "solicited node" multicast group).

The packet must be replayed during the time window of
DupAddrDetectTransmists
*  RetransTimer (which with the default value is 1 second).

There is some ways to mitigate or to cancel the effects of this attacks.
One way is to give a semantic to the Nonce option in this particular
case and say that if there is a Neighbor Solicitation received during
the DAD process indicating a collision containing the same Nonce
option, the first time, it will trigger the computing of a new address
and the second time it will keep the address and ignore the message.

I was only able to test it on the NTT DoCoMo SEND's implementation and
it didn't work due to the non-full implementation of the DAD support
part. I have a PoC written with the Scapy framework, I can send it to
anyone wishing it.

Thanks in advance for all your feedbacks.

Best regards,
	Tony Cheneau

_______________________________________________
CGA-EXT mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cga-ext