Last Call Review of draft-ietf-opsec-dhcpv6-shield-04
review-ietf-opsec-dhcpv6-shield-04-genart-lc-campbell-2014-12-02-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-opsec-dhcpv6-shield-04-genart-lc-campbell-2014-12-02

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsec-dhcpv6-shield-04
Reviewer: Ben Campbell
Review Date: 2014-12-01
IETF LC End Date: 2014-12-01

Summary: This draft is almost ready for publication.I have some questions and comments that might should be considered prior to publication. (I am leaving off my usual "ready for publication as an XXX" part, because I have questions on that, below.)

Major issues:

(Note: This is not so much a "major issue" as a meta-concern that doesn't fit well in the major/minor/nit structure.)

I have questions about the intended status. The draft lists BCP. It's not clear to me if we intend to say that it's a "best practice" to implement DHCPv6 filtering, or that, if you do implement it, it's a best practice to do it like this. Given the strength of a BCP, I think it's worth clarifying that.

As far as I can tell, DHCP snooping for v4 is not documented in an RFC at all, and that RA-Guard, which this draft lists as analogous, is informational.

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


-- 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]"?

Nits/editorial comments:

-- section 1, 2nd paragraph:

This is the first mention of "DHCP-Shield" I found, not counting the doc name and headers. It would be helpful to have an early mention that "DHCP-Shield" is the name of the thing that this draft defines.

-- section 1, 3rd paragraph:

It would be helpful to define what a "DHCP-Shield device" is, prior to talking about deploying and configuring them.

-- 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?

-- section 3, "Extension Header"

-- these are IPv6 extension headers, right?

-- section 3, "IPv6 Header chain"

Is there a relevant citation for this?

Also, while this section talks about some aspects of header chains, it never actually defines the term.

-- 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 ..."

should this be "... the entire IPv6 header chain ..."?

-- section 3, rational for item 1: "An implementation that has such an implementation-specific limit MUST NOT claim compliance with this specification."

That's an odd use of 2119 language; I assume this to be true anytime an implementation violates a MUST/MUST NOT assertion.

-- section 3, rational for list item 3:

It would be helpful if this rational said why dropping unrecognized next header values is needed for the purpose, not just the fact that 7045 allows it to be dropped.

-- section 3, list item 4:

Am I correct in assuming that there might be other (non-dhcp) reasons a device might still drop packets that otherwise pass the dhcpv6-shield tests?

-- section 3, paragraph after list item 4:

The comment that dropped packets SHOULD be logged is redundant with the same statement in the numbered rules.

-- section 7, first paragraph:

Please expand DoS on first mention.

-- section 7, 2nd to last paragraph: "... on a port not allowed to send such packets ..." 

Should that be "forward" or "receive"?  (I assume this still talks about L2 switch "ports", not UDP ports?)