Re: Gen-ART LC Review of draft-ietf-opsec-dhcpv6-shield-04

Fernando Gont <fgont@si6networks.com> Mon, 19 January 2015 07:59 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEDA1ACEBD; Sun, 18 Jan 2015 23:59:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 TAcnkvm78DCo; Sun, 18 Jan 2015 23:59:41 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8401AD241; Sun, 18 Jan 2015 23:59:37 -0800 (PST)
Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1YD7Eg-00006M-7p; Mon, 19 Jan 2015 08:58:58 +0100
Message-ID: <54BCB932.30609@si6networks.com>
Date: Mon, 19 Jan 2015 04:58:42 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
Subject: Re: Gen-ART LC Review of draft-ietf-opsec-dhcpv6-shield-04
References: <E5BE273D-3996-4086-B5D9-FFFB437774DE@nostrum.com> <547D9C86.6040701@si6networks.com> <64775586-CC1E-4360-9122-F000EB45F475@nostrum.com>
In-Reply-To: <64775586-CC1E-4360-9122-F000EB45F475@nostrum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/wFMJzwpw_b0wI8zTcOGiB4_foCQ>
Cc: "gen-art@ietf.org Team (gen-art@ietf.org)" <gen-art@ietf.org>, draft-ietf-opsec-dhcpv6-shield.all@ietf.org, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jan 2015 07:59:42 -0000

Hi, Ben,

It looks like I never responded to this one. -- My apologies for that.
Please find my comments in-line...


On 12/11/2014 06:56 PM, Ben Campbell wrote:
>>> Minor issues:
>>> 
>>> -- abstract, last sentence:
>>> 
>>> I didn't find this assertion in the body itself. It would be nice
>>> to see support for it (perhaps with citations).
>> 
>> I guess one could provide references to some vendor's manuals? Is
>> that what you have in mind? (although I'd prefer not to do so).
> 
> The citations part was more of a nice to have. But it would be worth
> putting some words around that in the body, even if there's nothing
> to reference.

ANy suggestions on this one?




>>> -- section 4:
>>> 
>>> Am I correct in understanding that this is opt in only? You
>>> would disallow a rule of the form of "allow on any port except
>>> [list]"?
>> 
>> Not sure what you mean.
>> 
>> The idea is that if you want to enable dhcpv6 shield, you need to 
>> specify on which port(s) the dhcpv6 server(s) is/are connected.
> 
> Would a rule of the form "Allow DHCPv6 on all ports except port X" be
> allowed?

Yes. That's another way of saying: "Enable DHCPv6-Shield. Allow DHCPv6
on ports 1-7" -- when a device has ports 1-8.  i.e., DHCPv6-Shield is,
when enabled, a "default deny" -- and you need to specify on which
port(s) DHCPv6 should be allowed.



>>> -- section 1, 3rd paragraph:
>>> 
>>> It would be helpful to define what a "DHCP-Shield device" is,
>>> prior to talking about deploying and configuring them.
>> 
>> How about adding (in Section 1) the following text:
>> 
>> This document specifies DHCPv6 Shield: a set of filtering rules
>> meant to mitigate attacks that employ DHCPv6-server packets.
>> Throughout this document we refer to a device implementing the
>> DHCPv6 Shield filtering rules as the "DHCPv6 Shield device"
>> 
>> ?
> 
> Yes, thanks.

FWIW, we ended up adding all these definitions to the "Terminology" section.



>>> -- section 3, paragraph ending with  with "... used as follows 
>>> [RFC7112]:"
>>> 
>>> I'm a bit confused by the citation. Are these defined "as
>>> follows", or in 7112?
>>> 
> 
> You did not respond to this one. I note that my next few comments
> might no longer apply if the 7112 reference is clarified. Is the
> point to say that 7112 contains the following definitions, which are
> repeated here for the sake of convenience?

Yes, that's the point. And we've updated the text to say "..used as
defined in [RFC7112]".




>>> Also, while this section talks about some aspects of header
>>> chains, it never actually defines the term.
>> 
>> Which one?
> 
> The term "header chain".  That is, something of the form of "The IPv6
> header chain is a linked-list of IPv6 headers. It contains ...".

We never use "header chain" alone, but rather "IPv6 header chain".



>>> -- section 3, "Upper-Layer Header"
>>> 
>>> Again, this section talks about the term without defining it.
>>> 
>>> -- section 5, list entry "1": "... the IPv6 entire header chain
>>> ..."
>> 
>> Not sure what you mean: Section 3 is all about defining the terms.
>> Am I missing something?
> 
> Again, the definition doesn't actually define the term. For example,
> "An upper-layer header is a header belonging to an upper-layer
> protocol"

mm.. but that wouldn't be correct. The current definition seems to be
more correct than that. Not sure what is missing...

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492