RE: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ?

"Frank Bulk" <frnkblk@iname.com> Fri, 29 July 2011 01:19 UTC

Return-Path: <frnkblk@iname.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8903021F8B31; Thu, 28 Jul 2011 18:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YuWKuITqeEo; Thu, 28 Jul 2011 18:19:40 -0700 (PDT)
Received: from premieronline.net (smtp2-5.premieronline.net [96.31.0.30]) by ietfa.amsl.com (Postfix) with ESMTP id A234F21F8B30; Thu, 28 Jul 2011 18:19:39 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26;
Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 2205779-1729245 for multiple; Thu, 28 Jul 2011 20:19:38 -0500
From: Frank Bulk <frnkblk@iname.com>
To: 'Christian Huitema' <huitema@microsoft.com>, Philip Homburg <pch-6man@u-1.phicoh.com>, Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
References: <D4F95C5E-20A3-4B1E-8211-07B7831F3E89@gmail.com> <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <E3161138-0CAA-44E8-A329-E71408D0AE61@gmail.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <m1QiN79-0001jMC@stereo.hq.phicoh.net> <A1924BC2-B42D-4A06-8122-ABFF325E1CF4@steffann.nl> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <m1QiRWn-0001i7C@stereo.hq.phicoh.net> <20110717234105.04069322@opy.nosense.org> <m1QiSmU-0001iBC@stereo.hq.phicoh.net> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Subject: RE: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ?
Date: Thu, 28 Jul 2011 20:19:36 -0500
Message-ID: <000701cc4d8d$94d0c860$be725920$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHMRJHLOaNFypP8jkSb4kdkNNCU2pTwpJNwgBHsZZA=
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net
X-SpamDetect: : 0.000000
X-Info: aspam skipped due to (useraccess)
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=12 Friend=777 Surbl=0 Catch=0 r=0 ip=199.120.69.26
X-IP-stats: Incoming Outgoing Last 0, First 870, in=13506195, out=50842, spam=0 Known=true ip=199.120.69.26
X-Mailman-Approved-At: Thu, 28 Jul 2011 18:22:45 -0700
Cc: IPv6 Operations <v6ops@ietf.org>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: frnkblk@iname.com
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2011 01:19:40 -0000

Just like some routers allow one to partition the RIB between v4 and v6
address space, the ND cache could be customizably split between good and
"bad" cache (i.e. 80-20), with the bad operating on a FIFO basis with some
kind of customizable COPS-style rate-limiter attached to that "bad" cache.
This would give the network guy the necessary knobs to manage ND DoS.

Frank

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Christian Huitema
Sent: Sunday, July 17, 2011 11:09 AM
To: Philip Homburg; Mark Smith
Cc: IPv6 Operations; ipv6@ietf.org
Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS"
concerns ?

>So perhaps the changes required would be mostly limited to -
>
>- DADs to all-nodes rather than solicited node addresses
>- nodes receiving the DAD use that to create a neighbor cache entry
>- NUD takes care of maintaining the validity of those entries
>- ND NS to all nodes with an unspecified target address solicits NAs
>  from all nodes to cover the router (or any device) reboot situation

I am not sure this addresses the problem too well. The DOS issue manifests
itself at the gateway, and the main issue is the remote DOS: attacker sends
packets to a very large number of putative IPv6 addresses in the subnet
managed by the local gateway, causing the size of the neighbor cache to
explode. If we want to protect the cache in the gateway, let's do that. The
solution has to be a tweak in the implementation of ND in the gateway, along
the lines of:

- Upon arrival of a packet from the local network:
- If the source address is already in ND cache, keep it there
- if the source address is not already in the ND cache:
	Perform some quota check on the source MAC address,
	If the quota is exceeded, drop the packet to protect against local
DOS
	If the quota is not exceeded, perform ND for the source address

- Upon arrival of a packet bound to the local subnet
- If the destination address is already in ND cache, route the packet;
- If the destination address is not in ND cache:
	If the table is "too full," drop the packet
	Else, perform ND

The basic idea is that remote parties should only be sending to addresses
that have already been discovered in the local subnet. This is, in a way, a
weak form of stateful filtering. It needs to be implemented softly, because
routers/gateways sometime lose their memory, so we want to allow for some
dynamic learning if the tables are not already populated.

The proposed tweaks amount to making ND learn faster. They are fine in
general, but they have the side effect of making local DOS easier. A local
attacker could generate a large number of addresses, etc.

-- Christian Huitema



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops