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

[Jari Arkko <[e-mail]>]

Ben, Fernando,

Thanks for the review and responses. I have placed a no-objection position for this draft in tonight’s IESG telechat.

Jari

On 19 Jan 2015, at 08:58, Fernando Gont <[e-mail]> wrote:

> 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: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
>