[Roll] 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: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org
Delivered-To: roll@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9561C1ACECB; Thu, 25 Jun 2015 13:18:14 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7299B1ACEBF for <xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com>; Thu, 25 Jun 2015 13:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.5
X-Spam-Level:
X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable
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 42KMQZVjlU1Q for <xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com>; Thu, 25 Jun 2015 13:18:13 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AEB1ACEC7 for <draft-ietf-roll-mpl-parameter-configuration.all@ietf.org>; Thu, 25 Jun 2015 13:18:13 -0700 (PDT)
Received: from alln-iport-4.cisco.com ([173.37.142.91]:60237) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from <bew@cisco.com>) id 1Z8DbA-0003Lr-8J for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 25 Jun 2015 13:18:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1435263492; x=1436473092; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EM/NiGa/xG10Ws5MNWZ5BB1wdpMVQ4YFSJa79rbKDFs=; b=aLOAbJ4zt5RGshhbqy2cmSaY8r0WZ7VaWZr7m+w2D71Z8YnWuBbPptef bnmK8B7UywKs5TrfRKXDrTtTzHyrP2Dq2FLK/j9502c/MbP3dvtn7TMoM l/aM0nzXt9bqfM7Tq1VJDXft5yYprz73UvnikQNnGoCc7C6MAb46qZQSt A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BOBQBTYYxV/40NJK1cgxGBOb0Wh16BQjoSAQEBAQEBAYEKhCUEeRIBgQAnBAENiDTMIAEBAQEBAQEBAQEBAQEBAQEBAQEZkAEES4MegRQFlAYBhy+EIpg5JoN6gjWBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.13,679,1427760000"; d="scan'208";a="162983272"
Received: from alln-core-8.cisco.com ([173.36.13.141]) 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 [173.36.12.76]) 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 ([169.254.9.136]) by xhc-aln-x02.cisco.com ([173.36.12.76]) 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-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.154.49.63]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <55559D70BC1BA741BF320287835EF8D6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SA-Exim-Connect-IP: 173.37.142.91
X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org
X-SA-Exim-Mail-From: bew@cisco.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org
Resent-Message-Id: <20150625201813.38AEB1ACEC7@ietfa.amsl.com>
Resent-Date: Thu, 25 Jun 2015 13:18:13 -0700 (PDT)
Resent-From: bew@cisco.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/draft-ietf-roll-mpl-parameter-configuration.all@tools/wGkm1AACs2FT0xSPtZElQowi9iU>
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/wVso_YwPS7Tmu9rjVMbzkjct8Pk>
X-Mailman-Approved-At: Thu, 25 Jun 2015 21:45:45 -0700
Cc: "draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org" <draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org>
Subject: [Roll] Secdir review of draft-ietf-roll-mpl-parameter-configuration-04
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 20:18:14 -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.

Brian