Re: [CGA-EXT] Hashed DAD

[marcelo bagnulo braun <[e-mail]>]

Hi,

El 28/02/2008, a las 22:58, Suresh Krishnan escribió:

> 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.
>

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


> * 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
>
> Pars Mutaf wrote:
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cga-ext
>
> _______________________________________________
> CGA-EXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cga-ext

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