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

Fernando Gont <fgont@si6networks.com> Wed, 08 February 2012 14:24 UTC

Return-Path: <fgont@si6networks.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 A220121F85DD; Wed, 8 Feb 2012 06:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.374
X-Spam-Level:
X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX-EhpNqnj6j; Wed, 8 Feb 2012 06:24:37 -0800 (PST)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id D6AB721F85F7; Wed, 8 Feb 2012 06:24:36 -0800 (PST)
Received: from [190.48.215.115] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1Rv8Rk-0000d3-5X; Wed, 08 Feb 2012 15:24:32 +0100
Message-ID: <4F31EFFC.5020402@si6networks.com>
Date: Wed, 08 Feb 2012 00:46:04 -0300
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: ietf@ietf.org, igor@yahoo-inc.com, jjaeggli@zynga.com, Warren Kumari <warren@kumari.net>
References: <20120206150214.5445.40209.idtracker@ietfa.amsl.com>
In-Reply-To: <20120206150214.5445.40209.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6nd-problems-04.txt> (Operational Neighbor Discovery Problems) to Informational RFC
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: Wed, 08 Feb 2012 14:24:37 -0000

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: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492