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(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf