Subject: [v6ops] Last Call: <draft-ietf-v6ops-v6nd-problems-04.txt> (Operational Neighbor Discovery Problems) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 06 Feb 2012 07:02:14 -0800

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Operational Neighbor Discovery Problems'
  <draft-ietf-v6ops-v6nd-problems-04.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-02-20. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 (ND) can be vulnerable to deliberate or accidental denial
   of service, 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 or accident conditions.  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 potential for DOS in detail and suggests
   possible implementation improvements as well as operational
   mitigation techniques that can in some cases be used to protect
   against or at least alleviate the impact of such attacks.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/

No IPR declarations have been submitted directly on this I-D.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Feb 2012 00:46:04 -0300

Folks,

I've reviewed the aforementioned document.

These are my comments:

** Technical: **

* Section 6.1:

It should be noted that the proposed mitigations makes address scans easier.

Also, the text currently says "and may not interact well with networks
using [RFC4862]". -- I'd argue that "it does not work with networks
using [RFC4862]".

* Section 7:

I believe that probably the most important implementation advice with
respect to the issue being discussed is missing (at least explicitly).
It could be stated as follows:

"NDP implementations should limit the number of Neighbor Cache entries
that are in the INCOMPLETE state. The aforementioned limit should be
much lower than the global limit on the total number of Neighbor Cache
entries. Since the attack discussed in this document is based on
triggering address resolution for non-existing nodes, limiting the
number of entries in the Neighbor Cache that are in the INCOMPLETE state
will mitigate the aforementioned attack, while still allowing ongoing
communications with "known" nodes to continue unnafected".

(feel free to use the text verbatim or modify as necessary)

* Section 7.1, bullet "4":

This paragraph is at least a bit vague. I'm not sure if you're referring
to something similar to what I've mentioned above -- but it doesn't read
like that.

You may want to replace this paragraph with the one I provided above, or
at least clarify it.

* Section 7.2:
   On implementations in which requests to NDP are submitted via a
   single queue, router vendors SHOULD provide operators with means to
   control both the rate of link-layer address resolution requests
   placed into the queue and the size of the queue.

My understanding is that being an "Informational" document, you should
s/SHOULD/should/ -- i.e., remove the RFC2119 language in the recommendation.

** Editorial: **

* Section 3:
      packets.  In higher-end routers, the forwarding plane is typically
      implemented in specialized hardware optimized for performance.
      Steps in the forwarding process include determining the correct
      outgoing interface for a packet, decrementing its Time To Live
      (TTL), verifying and updating the checksum, placing the correct
      link-layer header on the packet, and forwarding it.

Maybe this text should reflect IPv6, rather than IPv4 (i..e, s/TTL/Hop
Limit/, and remove the checksum bit)

** Nits: **

* Abstract:

s/DOS/DoS/, (there are a few instances of this elsewhere) and expand the
acronym the first time you use it.

* Section 1.1:

s/IPV6/IPv6/

* Section 2:

Missing space in "memoryand replaces existing "

* Section 4:

   addresses (and in many cases becomes unable to perform maintenance of
   existing entries in the neighbor cache, and unable to answer Neighbor
   Solicitation).

s/Solicitation/Solicitations/

* Section 7.2:

s/Neighbour/Neighbor/

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492