draft-ietf-opsec-dhcpv6-shield-05.txt   draft-ietf-opsec-dhcpv6-shield-06.txt 
opsec F. Gont opsec F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Intended status: Best Current Practice W. Liu Intended status: Best Current Practice W. Liu
Expires: July 23, 2015 Huawei Technologies Expires: August 29, 2015 G. Van de Velde
G. Van de Velde Huawei Technologies
Cisco Systems February 25, 2015
January 19, 2015
DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers
draft-ietf-opsec-dhcpv6-shield-05 draft-ietf-opsec-dhcpv6-shield-06
Abstract Abstract
This document specifies a mechanism for protecting hosts connected to This document specifies a mechanism for protecting hosts connected to
a switched network against rogue DHCPv6 servers. It is based on a switched network against rogue DHCPv6 servers. It is based on
DHCPv6 packet-filtering at the layer-2 device at which the packets DHCPv6 packet-filtering at the layer-2 device at which the packets
are received. A similar mechanism has been widely deployed in IPv4 are received. A similar mechanism has been widely deployed in IPv4
networks ('DHCP snooping'), and hence it is desirable that similar networks ('DHCP snooping'), and hence it is desirable that similar
functionality be provided for IPv6 networks. This document specifies functionality be provided for IPv6 networks. This document specifies
a Best Current Practice for the implementation of DHCPv6 Shield. a Best Current Practice for the implementation of DHCPv6 Shield.
skipping to change at page 1, line 39 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2015. This Internet-Draft will expire on August 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 22
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DHCPv6-Shield Configuration . . . . . . . . . . . . . . . . . 4 4. DHCPv6-Shield Configuration . . . . . . . . . . . . . . . . . 4
5. DHCPv6-Shield Implementation Advice . . . . . . . . . . . . . 4 5. DHCPv6-Shield Implementation Advice . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document specifies DHCPv6-Shield: a mechanism for protecting This document specifies DHCPv6-Shield: a mechanism for protecting
hosts connected to a switched network against rogue DHCPv6 servers hosts connected to a switched network against rogue DHCPv6 servers
[RFC3315]. The basic concept behind DHCPv6-Shield is that a layer-2 [RFC3315]. The basic concept behind DHCPv6-Shield is that a layer-2
device filters DHCPv6 messages meant to DHCPv6 clients (henceforth device filters DHCPv6 messages meant to DHCPv6 clients (henceforth
"DHCPv6-server messages"), according to a number of different "DHCPv6-server messages"), according to a number of different
criteria. The most basic filtering criterion is that DHCPv6-server criteria. The most basic filtering criterion is that DHCPv6-server
messages are discarded by the layer-2 device unless they are received messages are discarded by the layer-2 device unless they are received
skipping to change at page 4, line 29 skipping to change at page 4, line 29
Neither the upper-layer payload, nor any protocol data following Neither the upper-layer payload, nor any protocol data following
the upper-layer payload, is considered to be part of the header the upper-layer payload, is considered to be part of the header
chain. In a simple example, if the upper-layer header is a TCP chain. In a simple example, if the upper-layer header is a TCP
header, the TCP payload is not part of the header chain. In a header, the TCP payload is not part of the header chain. In a
more complex example, if the upper-layer header is an ESP header, more complex example, if the upper-layer header is an ESP header,
neither the payload data, nor any of the fields that follow the neither the payload data, nor any of the fields that follow the
payload data in the ESP header are part of the header chain. payload data in the ESP header are part of the header chain.
4. DHCPv6-Shield Configuration 4. DHCPv6-Shield Configuration
Before being deployed for production, the DHCPv6-Shield device MUST Before being deployed for production, the DHCPv6-Shield device is
be explicitly configured with respect to which layer-2 ports are explicitly configured with respect to which layer-2 ports are allowed
allowed to receive DHCPv6 packets destined to DHCPv6 clients (i.e. to receive DHCPv6 packets destined to DHCPv6 clients (i.e.
DHCPv6-server messages). Only those layer-2 ports explicitly DHCPv6-server messages). Only those layer-2 ports explicitly
configured for such purpose will be allowed to receive DHCPv6 packets configured for such purpose will be allowed to receive DHCPv6 packets
to DHCPv6 clients. to DHCPv6 clients.
5. DHCPv6-Shield Implementation Advice 5. DHCPv6-Shield Implementation Advice
The following filtering rules MUST be enforced as part of a The following are the filtering rules that are enforced as part of a
DHCPv6-Shield implementation on those ports that are not allowed to DHCPv6-Shield implementation on those ports that are not allowed to
receive DHCPv6 packets to DHCPv6 clients: receive DHCPv6 packets to DHCPv6 clients:
1. DHCPv6-Shield MUST parse the entire IPv6 header chain present in 1. DHCPv6-Shield MUST parse the entire IPv6 header chain present in
the packet, to identify whether it is a DHCPv6 packet meant for a the packet, to identify whether it is a DHCPv6 packet meant for a
DHCPv6 client (i.e., a DHCPv6-server message). DHCPv6 client (i.e., a DHCPv6-server message).
RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a
limit on the number of bytes they can inspect (starting from limit on the number of bytes they can inspect (starting from
the beginning of the IPv6 packet), since this could introduce the beginning of the IPv6 packet), since this could introduce
false-negatives: DHCP6-server packets received on ports not false-negatives: DHCP6-server packets received on ports not
allowed to receive such packets could be allowed simply allowed to receive such packets could be allowed simply
because the DHCPv6-Shield device does not parse the entire because the DHCPv6-Shield device does not parse the entire
IPv6 header chain present in the packet. IPv6 header chain present in the packet.
2. When parsing the IPv6 header chain, if the packet is a first- 2. When parsing the IPv6 header chain, if the packet is a first-
fragment (i.e., a packet containing a Fragment Header with the fragment (i.e., a packet containing a Fragment Header with the
Fragment Offset set to 0) and it fails to contain the entire IPv6 Fragment Offset set to 0) and it fails to contain the entire IPv6
header chain (i.e., all the headers starting from the IPv6 header header chain (i.e., all the headers starting from the IPv6 header
up to, and including, the upper-layer header), DHCPv6-Shield MUST up to, and including, the upper-layer header), DHCPv6-Shield MUST
drop the packet, and SHOULD log the packet drop event in an drop the packet, and ought to log the packet drop event in an
implementation-specific manner as a security fault. implementation-specific manner as a security fault.
RATIONALE: Packets that fail to contain the IPv6 header chain RATIONALE: Packets that fail to contain the IPv6 header chain
could otherwise be leveraged for circumventing DHCPv6-Shield. could otherwise be leveraged for circumventing DHCPv6-Shield.
[RFC7112] specifies that the first-fragment (i.e., the [RFC7112] requires that the first-fragment (i.e., the fragment
fragment with the Fragment Offset set to 0) MUST contain the with the Fragment Offset set to 0) contains the entire IPv6
entire IPv6 header chain, and allows intermediate systems such header chain, and allows intermediate systems such as routers
as routers to drop those packets that fail to comply with this to drop those packets that fail to comply with this
requirement. requirement.
NOTE: This rule should only be applied to IPv6 fragments with NOTE: This rule should only be applied to IPv6 fragments with
a Fragment Offset of 0 (non-first fragments can be safely a Fragment Offset of 0 (non-first fragments can be safely
passed, since they will never reassemble into a complete passed, since they will never reassemble into a complete
datagram if they are part of a DHCPv6 packet meant for a datagram if they are part of a DHCPv6 packet meant for a
DHCPv6 client received on a port where such packets are not DHCPv6 client received on a port where such packets are not
allowed). allowed).
3. When parsing the IPv6 header chain, if the packet is identified 3. DHCPv6-Shield MUST provide a configuration knob that controls
to be a DHCPv6 packet meant for a DHCPv6 client or the packet
contains an unrecognized Next Header value, DHCPv6-Shield MUST
drop the packet, and SHOULD log the packet drop event in an
implementation-specific manner as a security alert.
DHCPv6-Shield MUST provide a configuration knob that controls
whether packets with unrecognized Next Header values are dropped; whether packets with unrecognized Next Header values are dropped;
this configuration knob MUST default to "drop". this configuration knob MUST default to "drop". When parsing the
IPv6 header chain, if the packet contains an unrecognized Next
Header value and the configuration knob is configured to "drop",
DHCPv6-Shield MUST drop the packet, and ought to log the packet
drop event in an implementation-specific manner as a security
alert.
RATIONALE: An unrecognized Next Header value could possibly RATIONALE: An unrecognized Next Header value could possibly
identify an IPv6 Extension Header, and thus be leveraged to identify an IPv6 Extension Header, and thus be leveraged to
conceal a DHCPv6-server packet (since there is no way for conceal a DHCPv6-server packet (since there is no way for
DHCPv6-Shield to parse past unrecognized Next Header values DHCPv6-Shield to parse past unrecognized Next Header values
[I-D.gont-6man-rfc6564bis]). [RFC7045] requires that nodes be [I-D.gont-6man-rfc6564bis]). [RFC7045] requires that nodes be
configurable with respect to whether packets with unrecognized configurable with respect to whether packets with unrecognized
headers are forwarded, and allows the default behavior to be headers are forwarded, and allows the default behavior to be
that such packets be dropped. that such packets be dropped.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
"upper-layer protocol" (that is, it should be considered the last "upper-layer protocol" (that is, it should be considered the last
header in the IPv6 header chain). This means that packets header in the IPv6 header chain). This means that packets
employing ESP would be passed by the DHCPv6-Shield device to the employing ESP would be passed by the DHCPv6-Shield device to the
intended destination. If the destination host does not have a intended destination. If the destination host does not have a
security association with the sender of the aforementioned IPv6 security association with the sender of the aforementioned IPv6
packet, the packet would be dropped. Otherwise, if the packet is packet, the packet would be dropped. Otherwise, if the packet is
considered valid by the IPsec implementation at the receiving host considered valid by the IPsec implementation at the receiving host
and encapsulates a DHCPv6 message, it is up to the receiving host and encapsulates a DHCPv6 message, it is up to the receiving host
what to do with such packet. what to do with such packet.
The above rules require that if a packet is dropped due to this The above indicates that if a packet is dropped due to this filtering
filtering policy, the packet drop event be logged in an policy, the packet drop event be logged in an implementation-specific
implementation-specific manner as a security fault. The logging manner as a security fault. It is useful for the logging mechanism
mechanism SHOULD include a per -port drop counter dedicated to to include a per-port drop counter dedicated to DHCPv6-Shield packet
DHCPv6-Shield packet drops. drops.
In order to protect current end-node IPv6 implementations, Rule #2 In order to protect current end-node IPv6 implementations, Rule #2
has been defined as a default rule to drop packets that cannot be has been defined as a default rule to drop packets that cannot be
positively identified as not being DHCPv6-server packets (because the positively identified as not being DHCPv6-server packets (because the
packet is a fragment that fails to include the entire IPv6 header packet is a fragment that fails to include the entire IPv6 header
chain). This means that, at least in theory, DHCPv6-Shield could chain). This means that, at least in theory, DHCPv6-Shield could
result in false-positive blocking of some legitimate (non result in false-positive blocking of some legitimate (non
DHCPv6-server) packets. However, as noted in [RFC7112], IPv6 packets DHCPv6-server) packets. However, as noted in [RFC7112], IPv6 packets
that fail to include the entire IPv6 header chain are virtually that fail to include the entire IPv6 header chain are virtually
impossible to police with state-less filters and firewalls, and hence impossible to police with state-less filters and firewalls, and hence
skipping to change at page 7, line 7 skipping to change at page 7, line 7
IPv6 implementations [SI6-FRAG] with respect to their fragment IPv6 implementations [SI6-FRAG] with respect to their fragment
reassembly policy seems to indicate that most current implementations reassembly policy seems to indicate that most current implementations
comply with [RFC5722]. comply with [RFC5722].
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Security Considerations 7. Security Considerations
The recommendations in this document represent the ideal behavior of
a DHCPv6 shield device. However, in order to implement DHCPv6 shield
on the fast path, it may be necessary to limit the depth into the
packet that can be scanned before giving up. In circumstances where
there is such a limitation, it is recommended that implementations
drop packets after attempting to find a protocol header up to that
limit, whatever it is. Ideally, such devices should be configurable
with a list of protocol header identifiers so that if new transport
protocols are standardized after the device is released, they can be
added to the list of protocol header types that the device
recognizes. Since any protocol header that is not a UDP header would
be passed by the DHCPv6 shield algorithm, this would allow such
devices to avoid blocking the use of new transport protocols. When
an implementation must stop searching for recognizable header types
in a packet due to such limitations, whether the device passes or
drop that packet SHOULD be configurable.
The mechanism specified in this document can be used to mitigate The mechanism specified in this document can be used to mitigate
DHCPv6-based attacks against hosts. Attack vectors based on other DHCPv6-based attacks against hosts. Attack vectors based on other
messages meant for network configuration (such as ICMPv6 Router messages meant for network configuration (such as ICMPv6 Router
Advertisements) are out of the scope of this document. Additionally, Advertisements) are out of the scope of this document. Additionally,
the mechanism specified in this document does not mitigate attacks the mechanism specified in this document does not mitigate attacks
against DHCPv6 servers (e.g., Denial of Service). against DHCPv6 servers (e.g., Denial of Service).
If deployed in layer-2 domain with several cascading switches, there If deployed in layer-2 domain with several cascading switches, there
will be an ingress port on the host's local switch which will need to will be an ingress port on the host's local switch which will need to
be enabled for receiving DHCPv6-server messages. However, this local be enabled for receiving DHCPv6-server messages. However, this local
skipping to change at page 8, line 8 skipping to change at page 8, line 25
Finally, we note that other mechanisms for mitigating attacks based Finally, we note that other mechanisms for mitigating attacks based
on DHCPv6-server messages are available that have different on DHCPv6-server messages are available that have different
deployment considerations. For example, [I-D.ietf-dhc-secure-dhcpv6] deployment considerations. For example, [I-D.ietf-dhc-secure-dhcpv6]
allows for authentication of DHCPv6-server packets if the IPv6 allows for authentication of DHCPv6-server packets if the IPv6
addresses of the DHCPv6 servers can be pre-configured at the client addresses of the DHCPv6 servers can be pre-configured at the client
nodes. nodes.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank (in alphabetical order) Ben Campbell, The authors would like to thank (in alphabetical order) Ben Campbell,
Jean-Michel Combes, Sheng Jiang, Juergen Schoenwaelder, Carsten Jean-Michel Combes, Sheng Jiang, Ted Lemon, Pete Resnick, Juergen
Schmoll, Robert Sleigh, Donald Smith, Mark Smith, Hannes Tschofenig, Schoenwaelder, Carsten Schmoll, Robert Sleigh, Donald Smith, Mark
Eric Vyncke, and Qin Wu, for providing valuable comments on earlier Smith, Hannes Tschofenig, Eric Vyncke, and Qin Wu, for providing
versions of this document. valuable comments on earlier versions of this document.
Part of Section 3 of this document was borrowed from [RFC7112], Part of Section 3 of this document was borrowed from [RFC7112],
authored by Fernando Gont, Vishwas Manral, and Ron Bonica. authored by Fernando Gont, Vishwas Manral, and Ron Bonica.
This document is heavily based on the document [RFC7113] authored by This document is heavily based on the document [RFC7113] authored by
Fernando Gont. Thus, the authors would like to thank Ran Atkinson, Fernando Gont. Thus, the authors would like to thank Ran Atkinson,
Karl Auer, Robert Downie, Washam Fan, David Farmer, Mike Heard, Marc Karl Auer, Robert Downie, Washam Fan, David Farmer, Mike Heard, Marc
Heuse, Nick Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, Heuse, Nick Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault,
Arturo Servin, Gunter van de Velde, James Woodyatt, and Bjoern A. Arturo Servin, Gunter van de Velde, James Woodyatt, and Bjoern A.
Zeeb, for providing valuable comments on [RFC7113], on which this Zeeb, for providing valuable comments on [RFC7113], on which this
skipping to change at page 9, line 40 skipping to change at page 10, line 13
numbers/protocol-numbers.txt>. numbers/protocol-numbers.txt>.
[SI6-FRAG] [SI6-FRAG]
SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6
fragmentation/reassembly", 2012, fragmentation/reassembly", 2012,
<http://blog.si6networks.com/2012/02/ <http://blog.si6networks.com/2012/02/
ipv6-nids-evasion-and-improvements-in.html>. ipv6-nids-evasion-and-improvements-in.html>.
[I-D.ietf-savi-dhcp] [I-D.ietf-savi-dhcp]
Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
DHCP", draft-ietf-savi-dhcp-31 (work in progress), January DHCP", draft-ietf-savi-dhcp-34 (work in progress),
2015. February 2015.
[CPNI-IPv6] [CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request). National Infrastructure, (available on request).
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
skipping to change at page 10, line 23 skipping to change at page 10, line 42
Will Liu Will Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China P.R. China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
Gunter Van de Velde Gunter Van de Velde
Cisco Systems Huawei Technologies
De Kleetlaan 6a
Diegem 1831
Belgium
Phone: +32 2704 5473 Email: gunterv.velde@huawei.com
Email: gunter@cisco.com
 End of changes. 17 change blocks. 
38 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/