Subject: Re: [OPSEC] OPSEC Digest, Vol 83, Issue 6

From: Ray Hunter <[email-masked]>
Date: Tue, 18 Nov 2014 12:17:01 +0100

> [email-masked] <mailto:[email-masked]>
> 17 November 2014 20:52
> Send OPSEC mailing list submissions to
> [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/opsec
> or, via email, send a message with subject or body 'help' to
> [email-masked]
>
> You can reach the person managing the list at
> [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OPSEC digest..."
>
>
> Today's Topics:
>
> 1. Last Call: <draft-ietf-opsec-dhcpv6-shield-04.txt>
> (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best
> Current Practice (The IESG)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Nov 2014 11:52:09 -0800
> From: The IESG <[email-masked]>
> To: IETF-Announce <[email-masked]>
> Cc: [email-masked]
> Subject: [OPSEC] Last Call: <draft-ietf-opsec-dhcpv6-shield-04.txt>
> (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best
> Current Practice
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
>
> The IESG has received a request from the Operational Security
> Capabilities for IP Network Infrastructure WG (opsec) to consider the
> following document:
> - 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers'
> <draft-ietf-opsec-dhcpv6-shield-04.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-12-01. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document specifies a mechanism for protecting hosts connected to
> a switched network against rogue DHCPv6 servers. The aforementioned
> mechanism is based on DHCPv6 packet-filtering at the layer-2 device
> at which the packets are received. The aforementioned mechanism has
> been widely deployed in IPv4 networks ('DHCP snooping'), and hence it
> is desirable that similar functionality be provided for IPv6
> networks.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>
>
> ------------------------------
>
> End of OPSEC Digest, Vol 83, Issue 6
> ************************************
> ------------------------------------------------------------------------
I have read this draft and think it is useful. I also realise that this 
is very late in the day to make comments, but I have a number of issues.

Substantive comment:
/Before being deployed for production, the DHCPv6-Shield device MUST
    be explicitly configured with respect to which layer-2 ports are
    allowed to send DHCPv6 packets to DHCPv6 clients (i.e.  DHCPv6-server
    messages)./

IMHO DHCPv6-Shield is an optional service. Suggest /Unless explicitly 
configured with one or more ports to which DHCPv6 servers or relays are 
attached, the DHCPv6-Shield service SHOULD NOT filter any packets./

I also think the terminology of "send" and "receive" is used in a rather 
confusing and inconsistent manner. Suggest using receive from the 
perspective of the switch performing the filtering.

s/Only those layer-2 ports explicitly configured for such purpose will 
be allowed to send DHCPv6 packets to DHCPv6 clients/Only those layer-2 
ports explicitly configured for such purpose will be allowed to receive 
DHCPv6 packets for forwarding to other ports where DHCPv6 clients may be 
connected/

[the L2 switch management process itself will also likely not see the 
DHCPv6 packet if it is performing ingress filtering, and DHCPv6 servers 
could theoretically send packets to each other]

/on those ports that are not allowed to send DHCPv6 packets to DHCPv6 
clients/

Text is confusing. Is the switch blocking ALL DHCPv6 traffic, or ONLY 
packet originated from a DHCPv6 server?

Suggest /on those ports that are not allowed to receive packets 
originated from a DHCPv6 server/

Also /as not being DHCPv6-server packets/

suggest

/packets not originated from a DHCPv6-server/

s/ We note that if an attacker sends a fragmented DHCPv6 packet on a 
port not allowed to send such packets/We note that if an attacker 
originates a fragmented DHCPv6 packet that arrives on a switch port not 
allowed to receive such packets/

There are also a number of textual errors.

s/connected to a switched network/connected to a layer-2 switched network/

s/The basic concept behind DHCPv6-Shield is that a layer-2 device
    filters DHCPv6 messages meant to DHCPv6 clients (henceforth
    "DHCPv6-server messages"), according to a number of different
    criteria./The basic concept behind DHCPv6-Shield is that a layer-2 
device
    filters DHCPv6 messages sent to DHCPv6 clients (henceforth
    "DHCPv6-server messages"), according to a number of different
    criteria./

s/are received on a specific ports/are received on specific ports/

s/ Before the DCHPv6-Shield device is deployed, the administrator
    specifies the layer-2 port(s) on which DHCPv6-server messages are to
    be allowed/ Before the DCHPv6-Shield device is deployed, the 
administrator
    specifies the layer-2 port(s) on which messages originated from a 
DHCPv6-server are expected to be received/

s/(e.g., DoS)/(e.g. DoS)/

s/ If deployed in layer-2 domain with several cascading switches/ If 
deployed in a layer-2 domain with several cascaded switches/

-- 
Regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Nov 2014 04:24:17 -0300

Hi, Ray,

Thanks so much for your feedback! Please find my comments in-line...

> attached, the DHCPv6-Shield service SHOULD NOT filter any packets./

FWIW, I personally have no issues with modifying the I-D as indicated.
It looks like you're essentially arguing that "by default,
DHCPv6-Shieled should be off", whereas the current text essentially
means "Do not deploy this unless you've explicitly configured
DHCPv6-Shield".

At the end of the day, it looks like both phrases essentially have the
same end result -- i.e., you could argue that if DHCPv6-shield is not
filtering any packets, then it is not enabled/not deployed.

Thoughts?

> DHCPv6 packets for forwarding to other ports where DHCPv6 clients may be

Maybe also s/receive/accept/? -- because you do receive them anyway
(even if you later drop them)

> packet originated from a DHCPv6 server?

The text should read "DHCPv6-server packets". -- Will fix this in the
next rev.

> /packets not originated from a DHCPv6-server/

Not sure what you mean here....

> allowed to receive such packets/

s/receive/accept/?

>    "DHCPv6-server messages"), according to a number of different

Will do.

> s/are received on a specific ports/are received on specific ports/

Will fix this.

> DHCPv6-server are expected to be received/

Maybe
"vBefore the DCHPv6-Shield device is deployed, the administrator
specifies the layer-2 port(s) on which DHCPv6-server messages should be
accepted"

instead?

> deployed in a layer-2 domain with several cascaded switches/

Will fix this.

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