[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    new draft: draft-gashinsky-v6nd-enhance-00
From:       Joel Jaeggli <joelja () bogus ! com>
Date:       2011-06-30 7:06:59
Message-ID: AB323C8D-BD03-4458-B541-5EE343D6AA31 () bogus ! com
[Download RAW message or body]

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 &quot;join&quot; 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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]