Re: [secdir] SecDir review of draft-ietf-ospf-ospfv3-autoconfig

["Acee Lindem (acee)" <[e-mail]>]

Hi Adam, 

On 1/13/15, 12:26 PM, "Adam W. Montville" <[e-mail]>
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.
>
>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.

I will add a statement to section 5.

>
>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²?

Yes - these two sentences definitely SHOULD be consistent.

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

Do you feel that a statement with respect to the pseudo-random algorithm
is necessary? If so, can you suggest some text?


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

I agree with the above except that the document doesn't address all the
available OSPFv3 security options. Let me add a paragraph.

I will provide some updated text for review prior to republishing.

Thanks,
Acee