Last Call Review of draft-ietf-ospf-ospfv3-autoconfig-10
review-ietf-ospf-ospfv3-autoconfig-10-secdir-lc-montville-2015-01-15-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 draft is ready with comments/nits.

Comments
The document describes necessary mechanisms for OSPFv3 to be self-configuring
in environments requiring such (e.g. IPv6 home networks).

A couple of things stood out to me.  First, I inferred from the document that
the uniqueness of Router IDs is so within the context of the present deployment
and not, for example, unique between domains.  This may be common knowledge in
the world of OSPF, but wasn’t to me (at least not initially).  It could be good
to add a sentence about the context of Router ID uniqueness early on in the
document.

Also regarding uniqueness of the ID, Section 5, “OSPFv3 Router ID Selection”,
indicates that a pseudo-random number SHOULD be used to derive the Router ID. 
Later in that first paragraph: “The generation should be seeded with a variable
that is likely to be unique in the applicable OSPFv3 router deployment.” 
Should that “should” be “SHOULD”?

The document clearly recognizes the possibility for Router ID collisions, and
there does not appear to be a need for a cryptographically sound pseudo-random
number generation - just enough entropy to make the Router ID unique within the
deployment domain, and the Router-Hardware-Fingerprint TLV (Section 7.2.2) is
presented as being enough.

Because this document essentially explains the OSPFv3 defaults a router should
have in order to support auto-configuration, I presumed that the security
considerations provided in previous OSPFv3 documents would essentially be in
effect here.  This isn’t explicitly stated in the Security Considerations
section, but could be without harm, should they apply here.  The bottom line
for me is that it seems that OSPFv3 auto-configuration favors usability over
security, but without ignoring security entirely (e.g. “auto-configuration can
also be combined with password configuration or future extensions for automatic
pairing between devices.”).