[email protected] <mailto:[email protected]>
17 November 2014 20:52
Send OPSEC mailing list submissions to
[email protected]
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 protected]
You can reach the person managing the list at
[email protected]
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 protected]>
To: IETF-Announce <[email protected]>
Cc: [email protected]
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 protected]>
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 protected] mailing lists by 2014-12-01. Exceptionally, comments may be
sent to [email protected] 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 protected]
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
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
