Subject: [CGA-EXT] Hashed DAD

From: "Pars Mutaf" <[email-masked]>
Date: Thu, 28 Feb 2008 20:39:50 +0100

Hello,

Below is a IMHO better protection against DAD DoS attack for
SEND.  It is very simple I won't bother you with a personal draft. :-)
I hope the solution is OK.

Regards,
pars

=========

                     Hashed duplicate address detection

Abstract

   This document proposes a cheap defense against the
   Duplicate Address Detection (DAD) denial-of-service attack in IPv6.

1. Introduction

   Duplicate Address Detection (DAD) in IPv6 is vulnerable to a well-known
   Denial-of-Service attack. Each time the victim performs DAD on a
   tentative address, the attacker returns a positive response indicating
   that the address is already in use. This attack prevents the victim
   from configuring an IPv6 address.

   "Secure Neighbor Discovery 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." [SEND]

   This solution leads to unnecessary energy consumption for
   signature/verification and generating larger packets including an RSA
   signature option. An attacker may be able to force a victim to
   continuously use this solution and consume more energy than it would
   using insecure DAD.

   This document proposes an alternative solution which is computationally
   cheap and does not require the modification of the neighbor
   advertisement packet.

2. Hashed duplicate address detection

   In the proposed solution, the node performing DAD on its tentative
   address, computes a cryptographic hash of that address, and performs DAD
   for the result.

   Each node in the subnet, using the same hash function, computes the hash
   of its address and compares it to the hash result received from the node
   that performs DAD. Upon match, the target node returns a neighbor
   advertisement that contains its address (i.e. not the hash result but its
   real address). This proves that the target node has really configured
   that address.

   An attacker cannot know in advance which address is being tested.
   Consequently, the DAD denial-of-service attack is defeated.

3. Conclusion

   This document proposed a computationally cheap defense to the Duplicate
   Address Detection (DAD) denial-of-service attack.
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 28 Feb 2008 16:58:28 -0500

Hi Pars,
   There are not much details to go on, but I can already see that there 
are a couple of issues with this approach.

* It works only if ALL NODES in the network support your upgraded 
specification, since if there is even one unupgraded node it will 
destroy your scheme. This makes this proposal a non-starter.

* Even on a theoretical note, it is pretty simple to defeat.
This is an example exchange. Let's say there are two nodes A (the nice 
node) and M(the malicious node). A owns the address X.

a) A sends a DAD NS for Hash(X)
b) M gets this message
c) M sends a DAD NS for Hash(X)
d) A responds to M with the original address X
e) M can now defend the address X since he knows it

Cheers
Suresh

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 28 Feb 2008 23:11:44 +0100

> destroy your scheme. This makes this proposal a non-starter.

Hm, eventually stuff gets upgraded. A more problematic issue would be  
that non-SEND hosts probably don't care to implement this so how would  
SEND and non-SEND hosts live together on a subnet?

> e) M can now defend the address X since he knows it

It's also probably possible to precompute all possible IIDs for a  
subnet.

A solution to both of these problems would be to have A include a  
nonce and M then, rather than send the address in clear text, sends  
hash(X+nonce).

However, wouldn't the attack only work if M gets to monitor all  
multicast traffic? If M is required to set up MLD state for the  
multicast group that the NS goes to then a layer 2 device could limit  
the number of multicast groups that M can subscribe to and existing  
DAD wouldn't be susceptible to this attack.
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 28 Feb 2008 17:14:28 -0500

Hi Iljitsch,

> SEND and non-SEND hosts live together on a subnet?

That was my point as well.

> It's also probably possible to precompute all possible IIDs for a subnet.
> 
> A solution to both of these problems would be to have A include a nonce 
> and M then, rather than send the address in clear text, sends 
> hash(X+nonce).
> 
> the number of multicast groups that M can subscribe to and existing DAD 
> wouldn't be susceptible to this attack.

Depends on the link type. On an ethernet link, it would be as easy as 
putting the interface in promiscuous mode.

Cheers
Suresh

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 28 Feb 2008 23:31:05 +0100

On 28 feb 2008, at 23:14, Suresh Krishnan wrote:

>> multicast group that the NS goes to then a layer 2 device could  
>> limit the number of multicast groups that M can subscribe to and  
>> existing DAD wouldn't be susceptible to this attack.

> Depends on the link type. On an ethernet link, it would be as easy  
> as putting the interface in promiscuous mode.

That won't help you if the ethernet switch doesn't forward the  
multicasts. Although the really cheap switches implement multicast  
simply by broadcasting them to all ports and the somewhat more  
expensive but still cheap switches don't support IGMP snooping (and we  
can reasonably assume that in the future, they won't support MLD  
snooping), in a managed environment having the switches do this is  
probably easier than a protocol-based solution.

However, on wireless links it's much harder to protect against  
stations simply receiving all multicasts.
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: "Pars Mutaf" <[email-masked]>
Date: Thu, 28 Feb 2008 23:59:53 +0100

Hello,

>  destroy your scheme. This makes this proposal a non-starter.

At first look, I would say if an unupgraded node configured
the address hash(X), it would defend the address hash(X).
The DADing node can discard it because it wants the address X  ?

Regards,
pars

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 28 Feb 2008 18:06:34 -0500

Hi Pars,

> The DADing node can discard it because it wants the address X  ?

   An unupgraded node wants to configure address X. An upgraded node 
(that has already configured X on one if its interfaces) receives this 
packet. It creates Hash(X) and compares it to the address sent by A 
(i.e. X) and does not find a match. Hence it does not defend its address.

Cheers
Suresh

---

From: "Pars Mutaf" <[email-masked]>
Date: Fri, 29 Feb 2008 00:29:22 +0100

Hello,

>  (i.e. X) and does not find a match. Hence it does not defend its address.

I assumed that an upgraded node would also know traditional DAD, so it
would defend X against the traditional node. This would be diffilcult
to achieve?

For example, in hashed DAD you can indicate in the packet that the target
address field carries the hash of the actual target address. Otherwise, this is
traditional DAD and we act accordingly.

Thanks,
pars

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 29 Feb 2008 07:06:46 +0100

Hi,

> destroy your scheme. This makes this proposal a non-starter.

right, your point is that if you simply substitute the address by a  
hash then you change the semantics of the address field in the NA so  
it would break the protocol

In order to solve this problem an approach similar to SeND is needed,  
i.e. to keep the original address and add some additional information  
that can be processed by upgraded nodes if they support the new  
security mechanism, right?

Actually, i think that there would be possible a simpler mechanism to  
achieve similar level of protection with a similar cost to the one  
that is being proposed by Pars, and it is basically veryfying that the  
address corresponds to the CGA PDS contained in the  CGA option  
defined by SeND.

I mean, by performing only this verification (and not the one of the  
signature) it would be impossible for a host to respond to the DAD for  
an address it does not know the CGA PDS. So essentially it would  
result in a similar protection to the one proposed by PArs, with the  
similar verification cost, i.e. performing a hash computation for the  
verification. Not only that, but is also would be more backward  
compatible, in the sense that a host that not supports send can just  
omit the CGA option processing

However, this still has the second problem identified by Suresh, that  
is that basically, if an attacker can learn the CGA PDS, it will be  
able to launch the DoS attack for that address. This basically means  
that the host can defend the address the first tim it has generated  
the address, but after that, if it want to reuse it, it will be  
vulnerable to the DOS attack, cause the potential attackers could have  
learnt the associated CGA PDS

So, i guess this could be cheaper, but also weaker. The only  
application of such approach that i can think that makes sense is for  
Privacy addresses, where you are likely to use the address a reduced  
amount of time, and you may want to use tdifferent addresses  
frequently, so, maybe it makes sense this tradeoff i.e. lower  
processing for the defense (since you will be doing this many times  
each time a new privacy address is generated) and you can only defend  
the address efectively the first time you use it (if this is a privacy  
address, you will probably use it only for a short while)

but, maybe it just too much of a corner case to be worth it

in any case, it is an interesting exercise

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 29 Feb 2008 10:59:52 +0100

> address corresponds to the CGA PDS contained in the  CGA option

[...]

Wouldn't this be vulnerable to bidding down attacks? The malicious  
host could just claim to not understand the new options.

Also, wouldn't a host that claims to have an address be right by  
definition? I.e., If I want to prevent you from using your new  
address, I can simply configure the same address and this will  
certainly confuse the link layer enough to make it very hard for you  
to use the address, even if SEND can help you "defend" it against  
network layer attacks.

Maybe a useful heuristic would be to trust the first 3 DAD failures  
with a node with a given link layer address and after that, simply  
ignore DAD failures with that link layer address. Either the node  
holding that link layer address is just targeting DAD and you'll be  
able to use the address, or they're really out to get you at layer 2  
and no amount of DAD is going to help.
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 29 Feb 2008 11:24:19 +0100

> host could just claim to not understand the new options.

but this is already the case in all the send protocol
i mean, in order to enable backward compatibility you need to deal  
with hosts that don't understand the protocol and then you may have  
bidding down attacks. The solution for this is that the host need to  
figure out what to do. Either it only believes send messages and is  
secure but may not be able to communicate with legacy nodes or it does  
trust non send messages and he may be vulnerable to bidding down  
attacks (At least that how i understand this, please correct me if i  
am wrong)

> to use the address, even if SEND can help you "defend" it against  

but in this case, the host can protect itself by only accepting send  
protected messages

> ignore DAD failures with that link layer address.

or only trust send protected messages

regards, marcelo

> Either the node holding that link layer address is just targeting  
> DAD and you'll be able to use the address, or they're really out to  
> get you at layer 2 and no amount of DAD is going to help.