Last Call Review of draft-ietf-6man-why64-05
review-ietf-6man-why64-05-secdir-lc-shore-2014-10-02-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.

Summary: This document is clearly written, appears to be
comprehensive with respect to the problem being considered, and
is ready for publication.

This draft is intended for publication as an informational document
describing the possible implications of allowing a variable-length
interface ID in IPv6 addresses.  Basically, it is addressing and
dismantling arguments against a fixed-length 64-bit IID, and
describing the introduction of new failure modes should the IID
length be allowed to vary.

There are also results from various popular operating systems
from processing neighbor discovery options when the prefixes are
shorter than /64 and longer than /64, as well as a discussion of
potential impacts on other published IETF specifications should
the IID length be allowed to vary or be changed.

The draft includes a privacy issues subsection: Big ups for that.

Specific security concerns: there may be situations in which the
IID is intended to be hard to guess, and a 64-bit length increases
the cost of finding the identifier:

   It is hard to
   state in general how many bits are enough to protect privacy, since
   this depends on the resources available to the attacker, but it seems
   clear that a privacy solution needs to resist an attack requiring
   billions rather than millions of guesses.  Trillions would be better,
   suggesting that at least 40 bits should be available.  Thus we can
   argue that subnet prefixes longer than say /80 might raise privacy
   concerns by making the IID guessable.

Security considerations are largely operational, with very clear
discussion of implications of address formats for resistance to
scanning attacks and DOS attacks, acknowledging that there may be
other resource exhaustion attacks available that could possibly
be exacerbated by sparsely populated subnets.

A nits check picked up an outdated reference (draft-templin-aerolink
is now at version -40), and choked on the '+' in "draft-odell-8+8.00"
(bug in the nits checker draft name parser).

Melinda