Re: draft-jiang-v6ops-nc-protection-01.txt
Ole Troan <ot@cisco.com> Fri, 09 April 2010 06:39 UTC
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35423A6829 for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 8 Apr 2010 23:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.495
X-Spam-Level:
X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 ueMzowhOtn6M for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 8 Apr 2010 23:39:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 791FF3A67EA for <v6ops-archive@lists.ietf.org>; Thu, 8 Apr 2010 23:39:42 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1O07ql-00081V-8C for v6ops-data0@psg.com; Fri, 09 Apr 2010 06:37:55 +0000
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <ot@cisco.com>) id 1O07qi-00081A-E1 for v6ops@ops.ietf.org; Fri, 09 Apr 2010 06:37:52 +0000
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.52,176,1270425600"; d="scan'208";a="59175576"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2010 06:37:50 +0000
Received: from ams-otroan-8712.cisco.com (ams-otroan-8712.cisco.com [10.55.160.147]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o396boqb018328; Fri, 9 Apr 2010 06:37:50 GMT
Subject: Re: draft-jiang-v6ops-nc-protection-01.txt
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <ot@cisco.com>
In-Reply-To: <00eb01cad7ad$041b6a20$730c6f0a@china.huawei.com>
Date: Fri, 09 Apr 2010 08:37:49 +0200
Cc: 'Mark Smith' <ipng@69706e6720323030352d30312d31340a.nosense.org>, "'Hemant Singh (shemant)'" <shemant@cisco.com>, 'IPv6 Operations' <v6ops@ops.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9465019D-3119-4288-BCCC-FD72A610A915@cisco.com>
References: <00eb01cad7ad$041b6a20$730c6f0a@china.huawei.com>
To: Sheng Jiang <shengjiang@huawei.com>
X-Mailer: Apple Mail (2.1078)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
>> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mark Smith >> Sent: Thursday, April 08, 2010 5:45 AM >> To: Hemant Singh (shemant) >> Cc: IPv6 Operations >> Subject: Re: draft-jiang-v6ops-nc-protection-01.txt >> >> On Fri, 26 Mar 2010 12:24:38 -0500 >> "Hemant Singh (shemant)" <shemant@cisco.com> wrote: >> >>> The problem this document is trying to solve and any other >> ND related >>> security problem can be solved by use of SEND. >> >> It seems to me that SEND is protecting against illegitimate >> ND traffic. >> The specific problem as I see it is that SEND won't protect >> against illegitimate _non-ND_ traffic i.e. offlink traffic to >> non-existent onlink destinations (i.e. enters router on >> interface A (Internet), exits on interface B (LAN /64), >> triggers ND on subnet attached to interface B), that then >> triggers legitimate ND traffic. So SEND will ensure the >> router's NS is a legitimate one, but SEND doesn't verify that >> the destination address in the NS exists, without creating >> state in the router to allow the SEND ND transaction to >> complete. The attack is about remotely being able to utilise >> outstanding NS state in the router to trigger the DoS. >> >>> If SEND is not used, as >>> I said on the mike, read section 5.3 of the RFC 4861 which >> will purge >>> bogus entries due to NUD timeout. This document is of no >> use at all. >>> >> >> I've had a look at that section of 4861, and I don't think what is >> stated there will prevent this issue. >> >> Firstly it says that there is no need for active garbage collection >> under normal circumstances, as NUD will purge entries that become >> stale. However, the specific issue occurs before NUD kicks in - NUD >> fundamentally detects a neighbor disappearing, after it has existed. >> >> This attack is taking advantage of a neighbor never existing in the >> first place. The vulnerability is in the state that is kept while the >> initial ND NS is outstanding, for an address that doesn't exist. >> >> Secondly, it says that if there is a need to limit the size of the >> Neighbor Cache, then a least recently used policy should be used to >> purge entries, with a period of use up to 10 minutes. >> >> So it seems to me that there are potentially three types of entries in >> the Neighbor Cache: >> >> (1) Valid entries i.e. NS/NA has completed, and NUD will detect if >> and when the neighbor disappears. >> >> (2) Incomplete entries for valid addresses. NS has been issued, >> waiting for a corresponding NA to arrive. >> >> (3) Incomplete entries for non-existent addresses. NS has been issued, >> waiting for an NA that will never arrive. This is the attacker's >> traffic, generated by incrementing through the /64 (LAN or P2P link) >> >> >> If the attacker fills up the neighbor cache with (3) entries, then >> presumably the LRU garbage collection routine will kick in straight >> away. If it's as simple as that described in RFC4861, then I >> think it's >> probable that it'll start purging (1) and (2) entries, because the >> attacker is both creating and therefore keeping the (3) entries most >> recently used. By removing (1) and (2) entries, it creates a DoS for >> existing nodes for which the router has already completed the NS/NA >> transaction, and for existing nodes for with the router has an >> outstanding NS. The neighbor cache can end up with no completed >> entries, only (2)s and (3)s, resulting in a complete DoS for >> legitimate >> offlink sources trying to access the link. >> >> If the garbage routine is more selective that what is specified in >> RFC4861, and restricts it's LRU purging to Incomplete NS/NA >> transactions, then it still causes a DoS for existing nodes that >> haven't completed their NS/NA transaction. This is certainly >> significantly better than the simple garbage collection routine, >> however it still facilitates a remotely triggered DoS for nodes that >> may have recently become available. >> >> If the draft you are commenting on provides a mechanism that closes >> this vulnerability, or there are other effective methods that prevent >> remote attackers being able to create traffic triggered state in >> routers, I think they're well worth pursing. > > That's exactly what we are aiming to. We admit that our mechanism may not be > able to solve this vulnerability totally. But it reduces the rish very > largely. Quantitatively, it reduces the attack frequency to a level less > that 1% before. but only for on-link attacks? it does nothing for off-link attacks, correct? /ot
- draft-jiang-v6ops-nc-protection-01.txt Hemant Singh (shemant)
- Re: draft-jiang-v6ops-nc-protection-01.txt Mark Smith
- RE: draft-jiang-v6ops-nc-protection-01.txt Sheng Jiang
- Re: draft-jiang-v6ops-nc-protection-01.txt Ole Troan