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

Tony Cheneau <tony.cheneau@it-sudparis.eu> Mon, 30 November 2009 21:48 UTC

Return-Path: <tony.cheneau@it-sudparis.eu>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F883A6924 for <cga-ext@core3.amsl.com>; Mon, 30 Nov 2009 13:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level:
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBAZ1pu0KgMR for <cga-ext@core3.amsl.com>; Mon, 30 Nov 2009 13:48:22 -0800 (PST)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 547EC3A689A for <cga-ext@ietf.org>; Mon, 30 Nov 2009 13:48:22 -0800 (PST)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 6432DFE1AA6; Mon, 30 Nov 2009 22:48:14 +0100 (CET)
Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id 8B699405031; Mon, 30 Nov 2009 22:48:10 +0100 (CET)
Received: from alf94-6-82-226-232-167.fbx.proxad.net (alf94-6-82-226-232-167.fbx.proxad.net [82.226.232.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 31136900AE; Mon, 30 Nov 2009 22:48:10 +0100 (CET)
Date: Mon, 30 Nov 2009 22:48:01 +0100
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@localhost.localdomain
To: "Laganier, Julien" <julienl@qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C65FB2ABA@NALASEXMB04.na.qualcomm.com>
Message-ID: <alpine.LNX.2.00.0911302220160.11124@localhost.localdomain>
References: <BA2095E910AB454F9408A7EF7B249BD9@bombo> <alpine.LNX.2.00.0911262254210.11124@localhost.localdomain> <BF345F63074F8040B58C00A186FCA57F1C65FB2ABA@NALASEXMB04.na.qualcomm.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1543825537-1259617695=:11124"
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: 8B699405031.ACB05
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0.805, requis 6.01, BAYES_00 -2.60, FH_HELO_EQ_D_D_D_D 0.00, HELO_DYNAMIC_IPADDR 2.43, RCVD_IN_SORBS_DUL 0.88, RDNS_DYNAMIC 0.10)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Cc: "cga-ext@ietf.org" <cga-ext@ietf.org>
Subject: Re: [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: Mon, 30 Nov 2009 21:48:23 -0000

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