Last Call Review of draft-ietf-6lo-privacy-considerations-04
review-ietf-6lo-privacy-considerations-04-secdir-lc-kaduk-2016-12-01-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.  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