Last Call Review of draft-ietf-6lowpan-nd-
review-ietf-6lowpan-nd-secdir-lc-eastlake-2012-01-05-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just
like any other last call comments.

This draft describes optimizations to IPv6 neighbor discovery (ND) for
low-power lossy networks, such a IEEE 802.15.4, that limit or do not
support multicast and may have other network differences. It makes 8
extensions to IPv6 Neighbor Discovery.

SECURITY CONSIDERATIONS:

Although this is a fairly extensive and complex specification, the
Security Considerations appear to be adequate.

The Security Considerations depend heavily on the assumption of lower
level security of the link layer that prevents tampering with or
replaying the messages involved. Versions are created of some ND
address messages which are no longer restricted to one hop by a
hop-count test but these versions are not permitted except where
explicitly configured and are not allowed to change Neighbor Address
Caches. These assumptions and mechanisms appear to be sufficient.

Finally, the Security Considerations section suggest future
investigation of the use of Secure Neighbor Discover (SEND).

POSSIBLE Security Considerations:

Section 4.3: There seems to be no discussion of how rapidly the
Version Number could change and whether there is any risk of it
incrementing >8K while some cached value was not updated resulting in
sequence number arithmetic confusion.

Section 7.2 on Context Configuration and Management does not indicate
what the consequences of improper management might be.

MINOR:

I found the first sentence of Section 1.5 to be hard to understand and
of slightly questionable grammar.

In Section 3.3, should "A host retransmits the Address
   Registration option until it is acknowledged by the receipt of a
   Address Registration option."
be augmented by adding "with zero Statius" at the end.

In Section 4.1, page 17: "... amount of time in a unit of 60 seconds
that ..." is peculiar wording. Does it mean "... amount of time in
units of 60 seconds that ..." (which might better be "... amount of
time in units of a minute that ...")? Or does it mean "... amount of
time as a fraction of the unit of 60 seconds, with the decimal point
just before the first bit of the field, that ..."?
   - ditto Section 4.2, page 18.
   - ditto Section 4.4, page 21.
  == OK, now that I've read the rest of the document, I guess these
16-bit fields are supposed to max out at ~18 hours. That seems to
imply that it is really "... amount of time in units of 1 second that
...", something I would never have guessed from the original wording.

In Section 4.3, for "... sequence number arithmetic ..." suggest
adding a reference to [RFC1982] which is already including in the
normative references.

In Section 4.4, for first occurrence of "ip-over-foo", suggest adding
an Informative reference to [RFC3092].

TYPO:

Replace "an Neighbor" with "a Neighbor" globally.

Section 10.3.2: "the its" -> "its"

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com