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

"Adam W. Montville" <adam.w.montville@gmail.com> Tue, 13 January 2015 17:27 UTC

Return-Path: <adam.w.montville@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D271B1A8BB2; Tue, 13 Jan 2015 09:27:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j2ZSRWcKwk3G; Tue, 13 Jan 2015 09:27:14 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7504A1A8FD7; Tue, 13 Jan 2015 09:27:12 -0800 (PST)
Received: by mail-oi0-f48.google.com with SMTP id u20so3360976oif.7; Tue, 13 Jan 2015 09:27:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=OyAoOByTxZT41AIgYy1RUj6/w61PgnUxmNtAFty6ejs=; b=oSg3/3xr0+lp0YYMbT9p9iaC9SpKDoPq9fr9MJt412OhYTyUTM6DwQF9dw+nRhF4TI mozHgLOfHzOnwy5a3rEiFGtcOllTW3KE09getciuo3YmhX0QU909pGHHibfj9ixJS20k ZR8Bs1LuKV4Rn9PLgiOZNRTwVUg5YIaB4fEWBM6mqyrIqZqm4Y6ptUl+4TX5Rt7E9qel sxafTWdVdZ1NW/K51lx95WI6kU99EcBNOgMTA1P6Y5SvN3iJlgQzeexYlhlLWHB5vWho /T13msaLM8/vLjWA1X3VEXaH7Xh0itX9UicOmWwD+MAt7PoBZtP/tWKSz0e2+yCB5rYc jdCg==
X-Received: by with SMTP id pc13mr21789152oeb.68.1421170031735; Tue, 13 Jan 2015 09:27:11 -0800 (PST)
Received: from ?IPv6:2602:306:3406:4f00:f929:6fd:8d3d:951a? ([2602:306:3406:4f00:f929:6fd:8d3d:951a]) by mx.google.com with ESMTPSA id si7sm10856185obc.20.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 09:27:10 -0800 (PST)
From: "Adam W. Montville" <adam.w.montville@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <47E19730-5BE8-4CC1-9DB3-A341465A5BDB@gmail.com>
Date: Tue, 13 Jan 2015 11:26:33 -0600
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/zM1G5rNuZf2GiIY5Bs0GLXg4idg>
Subject: [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: Tue, 13 Jan 2015 17:27:18 -0000

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.

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