[v6ops] new draft: draft-gashinsky-v6nd-enhance-00
Joel Jaeggli <joelja@bogus.com> Thu, 30 June 2011 07:07 UTC
Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FA011E813E; Thu, 30 Jun 2011 00:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.949
X-Spam-Level:
X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ZFEXz6sil7fd; Thu, 30 Jun 2011 00:07:03 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 08EFF11E8074; Thu, 30 Jun 2011 00:07:02 -0700 (PDT)
Received: from zorch.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5U76xw0047171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jun 2011 07:07:00 GMT (envelope-from joelja@bogus.com)
From: Joel Jaeggli <joelja@bogus.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 Jun 2011 00:06:59 -0700
Message-Id: <AB323C8D-BD03-4458-B541-5EE343D6AA31@bogus.com>
To: ipv6@ietf.org, "v6ops@ietf.org WG" <v6ops@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 30 Jun 2011 07:07:00 +0000 (UTC)
Subject: [v6ops] new draft: draft-gashinsky-v6nd-enhance-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2011 07:07:03 -0000
I would direct the two working groups' attention if I may to a recently posted draft: http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 the potential DOS exposure that ipv6 neighbor discovery poses to routers is generally understood at this point, the document covers usable work arounds, and includes some rough proposals for addressing what the authors views as shortcomings in the neighbor disocvery process. some inspiration was drawn from: http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00 thanks joel A new version of I-D, draft-gashinsky-v6nd-enhance-00.txt has been successfully submitted by joel jaeggli and posted to the IETF repository. Filename: draft-gashinsky-v6nd-enhance Revision: 00 Title: Operational Neighbor Discovery Problems and Enhancements. Creation date: 2011-06-29 WG ID: Individual Submission Number of pages: 15 Abstract: In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to denial of service attacks whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools that scan networks for inventory and other purposes. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing ipv6 transported flows may be interrupted. This document describes the problem in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases to protect against such attacks. It also discusses possible modifications to the traditional [RFC4861] neighbor discovery protocol itself. The IETF Secretariat
- [v6ops] new draft: draft-gashinsky-v6nd-enhance-00 Joel Jaeggli
- Re: [v6ops] new draft: draft-gashinsky-v6nd-enhan… Joel Jaeggli
- Re: [v6ops] new draft: draft-gashinsky-v6nd-enhan… Ray Hunter