[secdir] Secdir review of draft-ietf-roll-mpl-parameter-configuration-04

"Brian Weis (bew)" <bew@cisco.com> Thu, 25 June 2015 20:18 UTC

Return-Path: <bew@cisco.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 4ADE01ACEB4; Thu, 25 Jun 2015 13:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cgu4UHvhzGxv; Thu, 25 Jun 2015 13:18:06 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146831ACEAB; Thu, 25 Jun 2015 13:18:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1435263486; x=1436473086; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EM/NiGa/xG10Ws5MNWZ5BB1wdpMVQ4YFSJa79rbKDFs=; b=F/KSa40X/xcKtw3Q09HxD+v/P7kjhewRV7nHs0L3qwW3RceUHPUec9HE OCmc4F9jhJkVi6M0e8mNmp9U4puhJ8oQCxxXLeBZLrD1L33RAg+TbuK4D q6GEVTG+VWUlckxv1BklfGZSIZMJ8RY+BshT6UX20AHdx1tZVhvtdcfcr 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,679,1427760000"; d="scan'208";a="162983272"
Received: from alln-core-8.cisco.com ([]) by alln-iport-4.cisco.com with ESMTP; 25 Jun 2015 20:18:05 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com []) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5PKI4uT008493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 20:18:05 GMT
Received: from xmb-aln-x04.cisco.com ([]) by xhc-aln-x02.cisco.com ([]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 15:18:05 -0500
From: "Brian Weis (bew)" <bew@cisco.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir review of draft-ietf-roll-mpl-parameter-configuration-04
Thread-Index: AQHQr4QKL7yMzuQ4YkCLPi20wdm6Hg==
Date: Thu, 25 Jun 2015 20:18:04 +0000
Message-ID: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <55559D70BC1BA741BF320287835EF8D6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/4K5yZVwQBHP3tcSwXOoyNT8y62U>
Cc: "draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org" <draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org>
Subject: [secdir] Secdir review of draft-ietf-roll-mpl-parameter-configuration-04
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 25 Jun 2015 20:18:07 -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 defines a new DHCPv6 option, whereby a DHCP server can configure a client with  Multicast Protocol for Low power and Lossy Networks (MPL) policy. The option definition seems straightforward. Security Considerations outlines three items which seem useful:

1. Describing a resource consumption threat ("excessive layer-2 broadcasting“) resulting from a man-in-the-middle modifying policy sent within an option. If there is a suggested mitigation (e.g., a means of integrity protecting the DHCPv6 traffic between the client and server) this would be worth noting. But I’m not sure if there any available mitigation in a ROLL environment.

2. Making a requirement that a server implementation choose reasonable policy values. This might be more useful if it were phrased as a threat, something like “Server implementations need to take care in setting reasonable bounds for each parameter in order to avoid overloading the network."

3. Making a requirement that the "DHCP server or the network itself shall be trusted by some means including network access control or DHCP authentication”.  Is this this “shall” intended to be an RFC 2119  “MUST”?

I consider this draft to be Ready with nits.