Re: [secdir] secdir review of draft-ietf-6man-why64-05

[Brian E Carpenter <[e-mail]>]

Thanks Melinda.

> 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).

It's hard to avoid a nit when citing drafts by Fred Templin, since he
updates them faster than the refresh cycle in Henrik's archive ;-).

The odell draft is actually missing from Henrik's archive, perhaps because
all his tools choke on the "+", but since it's a genuine singularity I just
hand-crafted the reference in the XML.

Regards
    Brian

On 29/09/2014 08:46, Melinda Shore wrote:
> 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
>