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

"Laganier, Julien" <julienl@qualcomm.com> Tue, 01 December 2009 00:20 UTC

Return-Path: <julienl@qualcomm.com>
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 A43A728C148 for <cga-ext@core3.amsl.com>; Mon, 30 Nov 2009 16:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.745
X-Spam-Level:
X-Spam-Status: No, score=-103.745 tagged_above=-999 required=5 tests=[AWL=-1.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Iev4EHNXELZZ for <cga-ext@core3.amsl.com>; Mon, 30 Nov 2009 16:20:34 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A494528C0CF for <cga-ext@ietf.org>; Mon, 30 Nov 2009 16:20:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259626827; x=1291162827; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Tony=20Cheneau=20<tony.cheneau@it-sudparis.eu>|CC: =20=3D?utf-8?B?QWxiZXJ0byBHYXJjw61h?=3D=20<alberto@it.uc3 m.es>,=0D=0A=20=20=20=20=20=20=20=20"cga-ext@ietf.org"=0D =0A=09<cga-ext@ietf.org>|Date:=20Mon,=2030=20Nov=202009 =2016:19:54=20-0800|Subject:=20RE:=20[CGA-EXT]=20Possible =20DoS=20attack=20to=20DAD=20in=20SEND=20?|Thread-Topic: =20[CGA-EXT]=20Possible=20DoS=20attack=20to=20DAD=20in=20 SEND=20?|Thread-Index:=20AcpyBtRDd9cieX7kS0aBHberRH6CtAAE zatg|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C65F B2B0F@NALASEXMB04.na.qualcomm.com>|References:=20<BA2095E 910AB454F9408A7EF7B249BD9@bombo>=0D=0A=20<alpine.LNX.2.00 .0911262254210.11124@localhost.localdomain>=0D=0A=20<BF34 5F63074F8040B58C00A186FCA57F1C65FB2ABA@NALASEXMB04.na.qua lcomm.com>=0D=0A=20<alpine.LNX.2.00.0911302220160.11124@l ocalhost.localdomain>|In-Reply-To:=20<alpine.LNX.2.00.091 1302220160.11124@localhost.localdomain>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5400,1158,5818"=3B=20 a=3D"28747822"; bh=0xRHXDPzfM3czGbhK6uyK9g9TW+7oeArZbb4ZbnMwp4=; b=c3d9Ywv/7aETUBdDml0RsRFPl3AK3xPGhSBU3MFJS4BcsDo8vh2EJSU3 o50r3PT4Y0Ef2qFgAp+0aGdGQVDBBLgpgisLNPz1EV4Nlgb/jy+EjnMkT Ea+c72pcMuHwYw3G4Aebm7C+/HXPdEtbLSebLlB/LP9klVnP3BSgw2slA E=;
X-IronPort-AV: E=McAfee;i="5400,1158,5818"; a="28747822"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 30 Nov 2009 16:20:12 -0800
Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB10KC2W001290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2009 16:20:12 -0800
Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB10JuWg010438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Nov 2009 16:20:11 -0800
Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Nov 2009 16:19:56 -0800
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Mon, 30 Nov 2009 16:19:55 -0800
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Tony Cheneau <tony.cheneau@it-sudparis.eu>
Date: Mon, 30 Nov 2009 16:19:54 -0800
Thread-Topic: [CGA-EXT] Possible DoS attack to DAD in SEND ?
Thread-Index: AcpyBtRDd9cieX7kS0aBHberRH6CtAAEzatg
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C65FB2B0F@NALASEXMB04.na.qualcomm.com>
References: <BA2095E910AB454F9408A7EF7B249BD9@bombo> <alpine.LNX.2.00.0911262254210.11124@localhost.localdomain> <BF345F63074F8040B58C00A186FCA57F1C65FB2ABA@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911302220160.11124@localhost.localdomain>
In-Reply-To: <alpine.LNX.2.00.0911302220160.11124@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Tue, 01 Dec 2009 00:20:35 -0000

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

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