Last Call Review of draft-ietf-6lo-privacy-considerations-04
review-ietf-6lo-privacy-considerations-04-secdir-lc-kaduk-2016-12-01-00

Request Review of draft-ietf-6lo-privacy-considerations
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-11-29
Requested 2016-11-17
Authors Dave Thaler
Draft last updated 2016-12-01
Completed reviews Genart Telechat review of -04 by Paul Kyzivat
Secdir Last Call review of -04 by Benjamin Kaduk
Intdir Early review of -03 by Tatuya Jinmei (diff)
Intdir Early review of -03 by Jouni Korhonen (diff)
Opsdir Last Call review of -04 by Ron Bonica
Assignment Reviewer Benjamin Kaduk
State Completed
Review review-ietf-6lo-privacy-considerations-04-secdir-lc-kaduk-2016-12-01
Reviewed rev. 04
Review result Has Nits
Review completed: 2016-12-01

Review
review-ietf-6lo-privacy-considerations-04-secdir-lc-kaduk-2016-12-01

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

This document is ready with nits.

This document is something of a meta-document, accumulating pointers to other documents that cover privacy considerations regarding IPv6 addresses, and using them to give guidance for future documents that specify how to run IPv6 over [insert protocol here].  It's worth having that advice consolidated in one place with math giving guidance on actual amounts of entropy to have in addresses; thank you!

The security considerations section (correctly) notes that the whole document is about security/privacy.

I just had a few questions after reading the document:

In section 1, second paragraph, the claim is made that "when interface identifiers are generated without sufficient entropy compared to the link lifetime, devices and users can become vulnerable to various threats".  Is it always the *link* lifetime that is most relevant in this context, or are there other lifetimes that can come into play as well?  It seems that there are other lifetimes, at least for certain IID-generation schemes, which is covered later in the document, but may give cause for reconsidering word choice here.

In section 2 (bottom of page 3), the claim is made that ICMP unreachable errors are typically rate limited to 2/second.  Is there hardware that has no limit, or a much higher limit?  (That is, what is the shape of the distribution?)  If there is a risk of a device being on a network where the rate limit is much higher, that device may need to adjust its scheme for generating addresses.

Similarly, near the end of section 2, there is discussion of  46-bit threshold and cases where it may not apply; it's not clear to me when spoofing is possible (or if a device might in general even know whether spoofing is possible), so perhaps the 46-bit claim should be de-emphasized.  Unfortunately, the last paragraph of the section just says "more bits of entropy would be needed" for the case when 46 bits are not enough, which is not exactly clear guidance.  (I have no better alternative suggestion, though.)

In section 4, there is a claim that when a short address is "allocated by the network (rather than being constant in the node)", a short address is (unequivocally?) safe.  Is this supposed to be because a new address is generated each time a device connects to the network, so it is supposed to not be linkable?  (I am not sure I believe the claim from just the given discussion in the document.)

Editorial quibbles:

Top of page 4, is "actual" really needed in "actual math"?

End of section 2, maybe "more entropy would be needed" rather than "more bits of entropy would be needed"?

Thanks,

Ben