Subject: [CGA-EXT] Possible DoS attack to DAD in SEND ?

From: Alberto García <[email-masked]>
Date: Thu, 26 Nov 2009 17:40:01 +0100

Hi,

I was wondering if the following is really an issue for SEND hosts doing
DAD, and if it is worth to be protected (this arose when defining SAVI
operation for SEND):

While address configuration in SEND hosts is reasonably protected against
other hosts responding with DAD NADV and claiming to be the owners of an
address, I don't see how the address configuration process is protected
against hosts just replying a secured DAD NSOL. 

Just consider a SEND host ("the victim") that wants to configure a CGA. It
generates a DAD NSOL (with a nonce and a timestamp), and sends it to the
corresponding Solicited Node address. Consider an attacker host that
receives this packet (IGMP snooping is not implemented in the switches, or a
broadcast medium). If the attacker wants to DoS the victim, it just replies
immediately the same DAD NSOL received. 

The victim then receives this message, and tries to validate it according to
SEND. It is valid, because the signatures are ok and it has been replied
fast enough to fit in the timestamp window (around 2 * TIMESTAMP_FUZZ , 2
seconds of margin more or less, time enough). RFC4862 says that when a node
is doing DAD NSOL, if it receives another DAD NSOL it must discard the
address. 

The victim increases its collision counter, and tries another address, but
the attacker replies again. 

When 3 collisions are detected, the victim stops and report the error
(RFC3972). 

1 attacker can prevent address configuration for all the hosts attaching to
the network.

I don't see in RFC 3971 any countermeasure to this. Am I right? 

Do you think this is a problem? If so, do you think it needs to be fixed?

A simple solution would be for the possible victim to discard received DAD
NSOLs for the same address that it has in tentative state that have equal
<public key, nonce, timestamp> than the DAD NSOL that it had sent before.
(The probability of a legitimate collision in which another host that
generates a DAD NSOL with the same public address, nonce and timestamp
should be really low).

For ND (unsecured), this case is also a problem, but for ND you can't decide
by looking to a received DAD NSOL when it is an attack or just a real
collision (and this could be also an incentive to use SEND, of course).

Regards,

Alberto

---

From: Tony Cheneau <[email-masked]>
Date: Thu, 26 Nov 2009 23:46:01 +0100 (CET)

Hello Alberto,

> DAD, and if it is worth to be protected (this arose when defining SAVI

This is the attack I described to the list in this mail:
http://www.ietf.org/mail-archive/web/cga-ext/current/msg00057.html
And then a thread (providing some other solutions):
http://www.ietf.org/mail-archive/web/cga-ext/current/msg00075.html

> I don't see in RFC 3971 any countermeasure to this. Am I right?
The spec does not say how to counter this. However, in a current
implementations, adding a fix seems pretty straightforward.

> Do you think this is a problem? If so, do you think it needs to be fixed?

IMHO, RFC 3971-bis should explicitly provide a solution to counter this 
attack.

> generates a DAD NSOL with the same public address, nonce and timestamp
Just comparing the nonce value should suffice.

> collision (and this could be also an incentive to use SEND, of course).
Plain ND is not secure anyway.
Some scenario are using a network setup where each nodes are on a
different port of a switch. If the switch was to support Multicast
Listener Discovery, the attacker will never get to receive the DAD NS
message to begin with. As stated in:
http://www.ietf.org/mail-archive/web/cga-ext/current/msg00077.html
Hence, it will preclude the attack. Am I wrong ?

Regards,
 	Tony

---

From: Alberto García <[email-masked]>
Date: Fri, 27 Nov 2009 11:36:10 +0100

Thanks, Tony

|  -----Mensaje original-----
|  De: Tony Cheneau [mailto:[email-masked]]
|  Enviado el: jueves, 26 de noviembre de 2009 23:46
|  Para: Alberto García
|  CC: [email-masked]
|  Asunto: Re: [CGA-EXT] Possible DoS attack to DAD in SEND ?
|  
|  Hello Alberto,
|  
|  > I was wondering if the following is really an issue for SEND hosts
doing
|  > DAD, and if it is worth to be protected (this arose when defining SAVI
|  > operation for SEND):
|  
|  This is the attack I described to the list in this mail:
|  http://www.ietf.org/mail-archive/web/cga-ext/current/msg00057.html
|  And then a thread (providing some other solutions):
|  http://www.ietf.org/mail-archive/web/cga-ext/current/msg00075.html
|  
|  > I don't see in RFC 3971 any countermeasure to this. Am I right?
|  The spec does not say how to counter this. However, in a current
|  implementations, adding a fix seems pretty straightforward.
|  
|  >
|  > Do you think this is a problem? If so, do you think it needs to be
fixed?
|  
|  IMHO, RFC 3971-bis should explicitly provide a solution to counter this
|  attack.
|  

Right 

|  
|  
|  > A simple solution would be for the possible victim to discard received
DAD
|  > NSOLs for the same address that it has in tentative state that have
equal
|  > <public key, nonce, timestamp> than the DAD NSOL that it had sent
before.
|  > (The probability of a legitimate collision in which another host that
|  > generates a DAD NSOL with the same public address, nonce and timestamp
|  > should be really low).
|  Just comparing the nonce value should suffice.
|  
|  
|  > For ND (unsecured), this case is also a problem, but for ND you can't
decide
|  > by looking to a received DAD NSOL when it is an attack or just a real
|  > collision (and this could be also an incentive to use SEND, of course).
|  Plain ND is not secure anyway.
|  Some scenario are using a network setup where each nodes are on a
|  different port of a switch. If the switch was to support Multicast
|  Listener Discovery, the attacker will never get to receive the DAD NS
|  message to begin with. As stated in:
|  http://www.ietf.org/mail-archive/web/cga-ext/current/msg00077.html
|  Hence, it will preclude the attack. Am I wrong ?

I agree with you that MLD-snooping does protect from this problem, but I
don't think it is realistic to assume that this feature is available in all
switches. In addition, there are some broadcast scenarios in which a bad guy
could circumvent this assumption.
I think a solution in the SEND domain (not depending on other deployment
issues) would still be nice.

Regards,
Alberto
|  
|  Regards,
|   	Tony

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 30 Nov 2009 11:33:47 -0800

Tony Cheneau wrote:
> [...] 
> > A simple solution would be for the possible victim to discard
> > received DAD NSOLs for the same address that it has in tentative
> > state that have equal <public key, nonce, timestamp> than the DAD
> > NSOL that it had sent before.

So I understand a node receiving a DAD NS after having sent out a DAD NS happens when two nodes are performing DAD simultaneously as per RFC 4862.

If so, are you Tony suggesting that incoming DAD NS's with nonce similar to a nonce included in an outgoing DAD NS be discarded?

The probability that two nodes ends up generating the same public-private key should be zero unless the public key scheme is broken, so I think when a node receives a SEND protected message where the public key is the same as its own, the node MUST assumes the message was sent by himself and MUST discard the message.
 
--julien

---

From: Tony Cheneau <[email-masked]>
Date: Mon, 30 Nov 2009 22:48:01 +0100 (CET)

Hi Julien,

> So I understand a node receiving a DAD NS after having sent out a DAD NS happens when two nodes are performing DAD simultaneously as per RFC 4862.
Yes, exactly. The attacker is replaying a protected NS, faking the case 
where two nodes want the same address.

> If so, are you Tony suggesting that incoming DAD NS's with nonce similar to a nonce included in an outgoing DAD NS be discarded?
Two nodes having the same Public Key could be a misconfiguration issue, 
while two nodes having the same Public Key and the same nonce clearly 
indicates an attacker.

> The probability that two nodes ends up generating the same public-private key should be zero unless the public key scheme is broken, so I think when a node receives a SEND protected message where t…
That's an other possibility. However, we should be careful that other
public key scheme are not used. Such as the ring signature algorithm
proposed in [1] (it's mainly a research paper), but all the node will
share the same Public Key (hence address), and this is an expected 
behavior. One could argue this was useful to solve the ND proxy case
(which is now solved differently), but I think it might also be a
solution to anycast related issue SEND.
To sum up, I'm OK to check for identical Public Keys, but I would rather
see a comparison on more data (Public Key + Nonce + Timestamp). 
Does that seem reasonable ?

Regards,
 	Tony

[1] J. Kempf, J. Wood, Z. Ramzan, and C. Gentry, “IP Address
Authorization for Secure Address Proxying Using Multi-key CGAs and Ring
Signatures,” Advances in Information and Computer Security, 2006, pp.
196-211.

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 30 Nov 2009 16:19:54 -0800

Hi Tony,

Tony Cheneau wrote:
> 
> [...]
> 
> > The probability that two nodes ends up generating the same public-
> > private key should be zero unless the public key scheme is broken, so I
> > think when a node receives a SEND protected message where the public
> > key is the same as its own, the node MUST assumes the message was sent
> > by himself and MUST discard the message.
>
> That's another possibility. However, we should be careful that other
> To sum up, I'm OK to check for identical Public Keys, but I would
> rather see a comparison on more data (Public Key + Nonce + Timestamp).

Hmm, for anycast there shouldn't be any DAD involved since an inherent characteristics of an anycast address is that it is shared and therefore duplicated. 

So maybe we can specify that a node receiving a DAD NS where the public key is the same as its own MUST assumes the message was sent by himself and MUST be ignored for the purpose of DAD?

--julien