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

From: "Adam W. Montville" <[email-masked]>
Date: Tue, 13 Jan 2015 11:26:33 -0600

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 14 Jan 2015 01:14:13 +0000

Hi Adam, 

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 14 Jan 2015 02:07:54 +0000

Hi Adam, 
Here are the updates I’m proposing to address your comments:

*** 180,185 ****
--- 180,188 ----
     Thanks to Martin Vigoureux for Routing Area Directorate review and
     comments.
  
+    Thanks to Adam Montville for Security Area Directorate review and
+    comments.
+
     Special thanks go to Markus Stenberg for his implementation of this
     specification in Bird.
  
***************

*** 451,464 ****

5.  OSPFv3 Router ID Selection

!    An OSPFv3 router requires a unique Router ID for correct protocol
!    operation.  An OSPFv3 router implementing this specification will
!    select a router-id that has a high probability of uniqueness.  A
!    pseudo-random number SHOULD be used for the OSPFv3 Router ID.  The
!    generation should be seeded with a variable that is likely to be
!    unique in the applicable OSPFv3 router deployment.  A good choice of
!    seed would be some portion or hash of the Router-Hardware-Fingerprint
!    as described in Section 7.2.2.

    Since there is a possibility of a Router ID collision, duplicate
    Router ID detection and resolution are required as described in
--- 451,465 ----

5.  OSPFv3 Router ID Selection

!    An OSPFv3 router requires a unique Router ID within the OSPFv3
!    routing domain for correct protocol operation.  An OSPFv3 router
!    implementing this specification will select a router-id that has a
!    high probability of uniqueness.  A pseudo-random number SHOULD be
!    used for the OSPFv3 Router ID.  The generation SHOULD be seeded with
!    a variable that is likely to be unique in the applicable OSPFv3
!    router deployment.  A good choice of seed would be some portion or
!    hash of the Router-Hardware-Fingerprint as described in
!    Section 7.2.2.

    Since there is a possibility of a Router ID collision, duplicate
    Router ID detection and resolution are required as described in
***************

*** 799,810 ****
    automatic pairing between devices.  These mechanisms can help provide
    an automatically configured, securely routed network.

!
!
!
!
!
!

--- 799,810 ----
    automatic pairing between devices.  These mechanisms can help provide
    an automatically configured, securely routed network.

!    In deployments where stronger authentification or encryption is
!    required, OSPFv3 IPsec [OSPFV3-IPSEC] or stronger OSPFv3
!    Authentication trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be used
!    at the expense of additional configuration.  The configuration and
!    operational description of such deployments is beyond the scope of
!    this document.

***************

Thanks,
Acee

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Jan 2015 13:08:20 +0200

Adam,

Many thanks for your review. I agree with Acee’s suggested edits.

Jari

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 14 Jan 2015 11:35:12 -0600

Glad to be of service.  It all looks good to me.

> On Jan 14, 2015, at 5:08 AM, Jari Arkko <[email-masked]> wrote:
> 
> Adam,
>