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

Jari Arkko <jari.arkko@piuha.net> Wed, 14 January 2015 11:08 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0B1B2C4E; Wed, 14 Jan 2015 03:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUu3WfaLuJJM; Wed, 14 Jan 2015 03:08:40 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A6A851B2C4B; Wed, 14 Jan 2015 03:08:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 88E2C2CC5F; Wed, 14 Jan 2015 13:08:37 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aed7SFMvQdTh; Wed, 14 Jan 2015 13:08:36 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 3C80F2CC4D; Wed, 14 Jan 2015 13:08:23 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_4523D412-E52D-4825-A1B9-BEE1DD302479"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <D0DB3988.B91C%acee@cisco.com>
Date: Wed, 14 Jan 2015 13:08:20 +0200
Message-Id: <E6065BA2-29AD-4B7A-A444-F50A37B19B35@piuha.net>
References: <47E19730-5BE8-4CC1-9DB3-A341465A5BDB@gmail.com> <D0DB2787.B8DE%acee@cisco.com> <D0DB3988.B91C%acee@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/net9AXZJolLd4SIe-CZDMByKTBo>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org" <draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-ospf-ospfv3-autoconfig
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jan 2015 11:08:46 -0000

Adam,

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

Jari

On 14 Jan 2015, at 04:07, Acee Lindem (acee) <acee@cisco.com> wrote:

> 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 
> 
> On 1/13/15, 8:14 PM, "Acee Lindem (acee)" <acee@cisco.com> wrote:
> 
>> Hi Adam, 
>> 
>> On 1/13/15, 12:26 PM, "Adam W. Montville" <adam.w.montville@gmail.com>
>> 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 
>> 
>> 
>