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 >> >> >
- [secdir] SecDir review of draft-ietf-ospf-ospfv3-… Adam W. Montville
- Re: [secdir] SecDir review of draft-ietf-ospf-osp… Acee Lindem (acee)
- Re: [secdir] SecDir review of draft-ietf-ospf-osp… Acee Lindem (acee)
- Re: [secdir] SecDir review of draft-ietf-ospf-osp… Jari Arkko
- Re: [secdir] SecDir review of draft-ietf-ospf-osp… Adam W. Montville