Subject: Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jun 2014 15:41:10 +0200

Hi, Eric,

Thanks so much for your feedback!

Please find my responses in-line...

On 05/12/2014 03:09 PM, Eric Vyncke (evyncke) wrote:
> KK, Gunter, Fernando & Will,
> 
> I have reviewed the document and here are my comments (some cosmetic):
> 
>   * section 1: "on a specified port of the layer-2 device" => "on
>     specific port(s) of the layer-2 device" (plural form)
>   * Section 1: "Only those ports to which a DHCPv6 server" => "Only
>     those ports to which a DHCPv6 server or relay" (relays should be
>     allowed as well)

I have applied these two. Thanks!

>   * Section 3: not sure whether it is relevant here, this is well-known
>     and accepted terminology, I am always uneasy when information is
>     duplicated as it is an open door for inconsistency

FWIW, the reason for which we added this is because we were requested to
define these terms for other documents (e.g., RFC 7112). Acording to
6man discussions, this was needed. But we could (alternatively just
reference the corresponding section of RFC7112.

>   * Section 3: should define what a 'DHCP shield device' is

Done.

>   * Section 5: I do not agree with point 1) if the specific platform
>     cannot handle a long ext header chain, it should be allowed to drop
>     the packet (the MUST NOT should be SHOULD NOT or even a MAY —
>     reversing the proposed policy). Of course, such platforms cannot
>     claim compatibility with DHCP-shield

I agree with you. :-) This comes from past discussions surrounding
RA-Guard. I've removed the "must not drop" claim. i.e., the text now looks:

     RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a limit
     on the number of bytes they can inspect (starting from the
     beginning of the IPv6 packet), since this could introduce false-
     positives: legitimate packets could be dropped simply because the
     DHCPv6-Shield device does not parse the entire IPv6 header chain
     present in the packet. An implementation that has such an
     implementation-specific limit MUST NOT claim compliance with this
     specification.

>   * Section 5: "SHOULD be logged in an implementation-specific manner as
>     security fault" => "security alert" or "security event"

Done.

>   * Section 7: the whole I-D is only handling the physical/wired
>     switched case while in the introduction it is stated to be
>     'broadcast network'. The security section and/or introduction should
>     mention this.

I've s/broadcast/switched/

>   * Section 7: should also mention other DHCP related threats? Such as
>     DoS attack against DHCP servers? Amplification/reflection attacks?
>     Of course, the mitigation techniques are out of scope, but, I think
>     that the threats should be mentioned

Changed to:

---- cut here ----
The mechanism specified in this document can be used to mitigate
DHCPv6-based attacks against hosts. Attack vectors based on other
messages meant for network configuration (such as ICMPv6 Router
Advertisements) are out of the scope of this document. Additionally, the
mechanism specified in this document does not mitigate attacks against
DHCPv6 servers (e.g., DoS).
---- cut here ----

>   * Add a reference to SAVI-DHCP ?

SAVI-DHCP seems rather orthogonal... but I might be wrong. i.e.,
savi-dhcp seems to be about building state on the layer-2 device based
on DHCPv6 exchanges, rather than about preventing malicious DHCPv6
exchanges. Am I right?

In any case, I guess one could add an informational reference as follows:
"The security of a site employing DHCPv6 Shield could be further
improved by deploying [SAVI-DHCP], to mitigate IPv6 address spoofing".

Thoughts?

> Else, good document, pretty much like the well-known rogue DHCPv4

That was the intent (porting dhcpv4 guard). :-)

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 6 Jun 2014 07:20:50 +0000

Fernando

Thanks for your feedback, as you kindly requested my thoughts on some
changes, see in-line

>improved by deploying [SAVI-DHCP], to mitigate IPv6 address spoofing".

This is indeed mostly orthogonal, each technique can be deployed without
the other one. But, you proposed paragraph is correct and will be helpful
for the readers/implementers.

-éric

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Jun 2014 10:40:30 +0200

> for the readers/implementers.

Perfect. I will add the paragraph above to the next rev.

Regarding the only remaining proposed change (about the terminology),
I'd like to know if you have any further thoughts. Me, I wouldn't have a
problem with removing the definition of those terms, nad pointing to the
specific section of RFC7112. However, I think that explicitly including
the definitions makes the document more self-contained. Also.. I wonder
what would happen if, say, RFC7112 were to be replaced by some other RFC
(the DHCPv6 SHield would now have a pointer to e.g. an obsoleted RFC?)
-- just me thinking out loud.

Thanks so much!

Cheers,

---

From: KK Chittimaneni <[email-masked]>
Date: Sat, 7 Jun 2014 09:54:06 -0700

Dear Opsec WG,

The co-chairs assessed the discussion on the list and now feel that there
was sufficient review to move this document forward.

Thanks,
KK (as Opsec WG co-chair)

On Sat, May 10, 2014 at 8:12 PM, KK Chittimaneni <[email-masked]>
wrote:

> Dear Opsec WG,
>
> The WGLC for this draft technically ended last month with just one
> response received. Not enough to move forward.
>
> The co-chairs chatted about this and noted that there was a lot more
> support for this doc during earlier stages. Given that, we'd like to give
> the WG a bit more time to review this and extend the LC to the 24th of May.
> Ideally, we'd like to get at least two volunteers who could do a thorough
> review of this doc and post their comments to the list.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/
>
> <https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/>
> Please read it now and report to the list whether you support publication
> or not. Insufficient responses will be taken as an indication of lack of
> interest and we'll stop from proceeding further.
>
> Regards,
> KK (as Opsec WG co-chair)
>