Re: [CGA-EXT] Hashed DAD

Iljitsch van Beijnum <iljitsch@muada.com> Fri, 29 February 2008 10:00 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 B68703A68F9; Fri, 29 Feb 2008 02:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.592
X-Spam-Level:
X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 nKowYfohpAM2; Fri, 29 Feb 2008 02:00:31 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F8E28C1F4; Fri, 29 Feb 2008 02:00:31 -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 E2A993A6EF5 for <cga-ext@core3.amsl.com>; Fri, 29 Feb 2008 02:00:29 -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 xwy-NqM4qagu for <cga-ext@core3.amsl.com>; Fri, 29 Feb 2008 02:00:24 -0800 (PST)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 5A3113A6A84 for <cga-ext@ietf.org>; Fri, 29 Feb 2008 02:00:24 -0800 (PST)
Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m1T9xi2f074223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Feb 2008 10:59:45 +0100 (CET) (envelope-from iljitsch@muada.com)
Message-Id: <E896F618-BCD9-4E32-8A74-C2168055DFEB@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
In-Reply-To: <21624D6A-0093-4E5C-96ED-BDF5C33164F9@it.uc3m.es>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Fri, 29 Feb 2008 10:59:52 +0100
References: <18a603a60802281139x220a6227j24d9b0234c65b71b@mail.gmail.com> <47C72E84.9010000@ericsson.com> <21624D6A-0093-4E5C-96ED-BDF5C33164F9@it.uc3m.es>
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 29 feb 2008, at 7:06, marcelo bagnulo braun wrote:

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

[...]

Wouldn't this be vulnerable to bidding down attacks? The malicious  
host could just claim to not understand the new options.

Also, wouldn't a host that claims to have an address be right by  
definition? I.e., If I want to prevent you from using your new  
address, I can simply configure the same address and this will  
certainly confuse the link layer enough to make it very hard for you  
to use the address, even if SEND can help you "defend" it against  
network layer attacks.

Maybe a useful heuristic would be to trust the first 3 DAD failures  
with a node with a given link layer address and after that, simply  
ignore DAD failures with that link layer address. Either the node  
holding that link layer address is just targeting DAD and you'll be  
able to use the address, or they're really out to get you at layer 2  
and no amount of DAD is going to help.
_______________________________________________
CGA-EXT mailing list
CGA-EXT@ietf.org
https://www.ietf.org/mailman/listinfo/cga-ext