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

Alberto García <alberto@it.uc3m.es> Thu, 26 November 2009 16:40 UTC

Return-Path: <alberto@it.uc3m.es>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 342763A6861 for <cga-ext@core3.amsl.com>; Thu, 26 Nov 2009 08:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.884
X-Spam-Status: No, score=-3.884 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Azw8z+5YwkQi for <cga-ext@core3.amsl.com>; Thu, 26 Nov 2009 08:40:10 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es []) by core3.amsl.com (Postfix) with ESMTP id 776F43A6851 for <cga-ext@ietf.org>; Thu, 26 Nov 2009 08:40:09 -0800 (PST)
X-uc3m-safe: yes
Received: from bombo (bombo.it.uc3m.es []) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 9B152BA7F16 for <cga-ext@ietf.org>; Thu, 26 Nov 2009 17:40:02 +0100 (CET)
From: =?iso-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
To: <cga-ext@ietf.org>
Date: Thu, 26 Nov 2009 17:40:01 +0100
Message-ID: <BA2095E910AB454F9408A7EF7B249BD9@bombo>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_016F_01CA6EBF.7ADDDE10"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acputq8P7sKncp1STkGasPJ3QGqmLQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-TM-AS-Product-Ver: IMSS-
Subject: [CGA-EXT] Possible DoS attack to DAD in SEND ?
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2009 16:40:15 -0000



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

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

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