Re: [CGA-EXT] Hashed DAD

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 28 February 2008 22:12 UTC

Return-Path: <cga-ext-bounces@ietf.org>
X-Original-To: ietfarch-cga-ext-archive@core3.amsl.com
Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9153A6827; Thu, 28 Feb 2008 14:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.284
X-Spam-Level:
X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
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 LRXcpJk5a5Wv; Thu, 28 Feb 2008 14:12:14 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF073A68EE; Thu, 28 Feb 2008 14:12:14 -0800 (PST)
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 C14A63A6A51 for <cga-ext@core3.amsl.com>; Thu, 28 Feb 2008 14:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 8T6GA9uxGMGK for <cga-ext@core3.amsl.com>; Thu, 28 Feb 2008 14:12:08 -0800 (PST)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 3FAC83A6827 for <cga-ext@ietf.org>; Thu, 28 Feb 2008 14:12:08 -0800 (PST)
Received: from [192.168.0.195] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1SMBfUJ064199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2008 23:11:42 +0100 (CET) (envelope-from iljitsch@muada.com)
Message-Id: <68CBF5CB-56EE-40F4-AEA2-4A142767D7CA@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
In-Reply-To: <47C72E84.9010000@ericsson.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 28 Feb 2008 23:11:44 +0100
References: <18a603a60802281139x220a6227j24d9b0234c65b71b@mail.gmail.com> <47C72E84.9010000@ericsson.com>
X-Mailer: Apple Mail (2.919.2)
Cc: cga-ext@ietf.org
Subject: Re: [CGA-EXT] Hashed DAD
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: cga-ext-bounces@ietf.org
Errors-To: cga-ext-bounces@ietf.org

On 28 feb 2008, at 22:58, Suresh Krishnan wrote:

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

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?

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

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
CGA-EXT@ietf.org
https://www.ietf.org/mailman/listinfo/cga-ext