draft-ietf-opsec-dhcpv6-shield-06.txt   draft-ietf-opsec-dhcpv6-shield-07.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: August 29, 2015 G. Van de Velde Expires: November 16, 2015 Huawei Technologies
Huawei Technologies G. Van de Velde
February 25, 2015 Alcatel-Lucent
May 15, 2015
DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers
draft-ietf-opsec-dhcpv6-shield-06 draft-ietf-opsec-dhcpv6-shield-07
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 38 skipping to change at page 1, line 39
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 August 29, 2015. This Internet-Draft will expire on November 16, 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 15 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 Requirements . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 10 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 intended for DHCPv6 clients
"DHCPv6-server messages"), according to a number of different (henceforth "DHCPv6-server messages"), according to a number of
criteria. The most basic filtering criterion is that DHCPv6-server different criteria. The most basic filtering criterion is that
messages are discarded by the layer-2 device unless they are received DHCPv6-server messages are discarded by the layer-2 device unless
on a specific ports of the layer-2 device. they are received on specific ports of the layer-2 device.
Before the DCHPv6-Shield device is deployed, the administrator Before the DHCPv6-Shield device is deployed, the administrator
specifies the layer-2 port(s) on which DHCPv6-server messages are to specifies the layer-2 port(s) on which DHCPv6-server messages are to
be allowed. Only those ports to which a DHCPv6 server or relay is to be allowed. Only those ports to which a DHCPv6 server or relay is to
be connected should be specified as such. Once deployed, the be connected should be specified as such. Once deployed, the
DHCPv6-Shield device inspects received packets, and allows (i.e. DHCPv6-Shield device inspects received packets, and allows (i.e.
passes) DHCPv6-server messages only if they are received on layer-2 passes) DHCPv6-server messages only if they are received on layer-2
ports that have been explicitly configured for such purpose. ports that have been explicitly configured for such purpose.
DHCPv6-Shield is analogous to the RA-Guard mechanism [RFC6104] DHCPv6-Shield is analogous to the RA-Guard mechanism [RFC6104]
[RFC6105] [RFC7113], intended for protection against rogue Router [RFC6105] [RFC7113], intended for protection against rogue Router
Advertisement [RFC4861] messages. Advertisement [RFC4861] messages.
We note that DHCPv6-Shield only mitigates only DHCPv6-based attacks We note that DHCPv6-Shield mitigates only DHCPv6-based attacks
against hosts. Attack vectors based on other messages meant for against hosts. Attack vectors based on other messages meant for
network configuration (such as ICMPv6 Router Advertisements) are not network configuration (such as ICMPv6 Router Advertisements) are not
addressed by DHCPv6-Shield itself. In a similar vein, addressed by DHCPv6-Shield itself. In a similar vein,
DHCPv6-Shielddoes not mitigate attacks against DHCPv6 servers (e.g., DHCPv6-Shielddoes not mitigate attacks against DHCPv6 servers (e.g.,
Denial of Service). Denial of Service).
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 36 skipping to change at page 4, line 36
4. DHCPv6-Shield Configuration 4. DHCPv6-Shield Configuration
Before being deployed for production, the DHCPv6-Shield device is Before being deployed for production, the DHCPv6-Shield device is
explicitly configured with respect to which layer-2 ports are allowed explicitly configured with respect to which layer-2 ports are 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 Requirements
The following are the filtering rules that are 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 implementations MUST parse the entire IPv6 header
the packet, to identify whether it is a DHCPv6 packet meant for a chain present in the packet, to identify whether it is a DHCPv6
DHCPv6 client (i.e., a DHCPv6-server message). packet meant for a 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-
skipping to change at page 5, line 37 skipping to change at page 5, line 37
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. DHCPv6-Shield MUST provide a configuration knob that controls 3. 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". When parsing the this configuration knob MUST default to "drop". When parsing the
IPv6 header chain, if the packet contains an unrecognized Next IPv6 header chain, if the packet contains an unrecognized Next
Header value and the configuration knob is configured to "drop", Header value and the configuration knob is configured to "drop",
DHCPv6-Shield MUST drop the packet, and ought to log the packet DHCPv6-Shield MUST drop the packet, and ought to log the packet
drop event in an implementation-specific manner as a security drop event in an implementation-specific manner as a security
alert. fault.
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 8, line 41 skipping to change at page 8, line 41
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
document is based. document is based.
The authors would like to thank Joel Jaeggli for his advice and
guidance throughout the IETF process.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
skipping to change at page 10, line 40 skipping to change at page 11, line 4
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
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
Huawei Technologies Alcatel-Lucent
Copernicuslaan 50
Antwerp, Antwerp 2018
Belgium
Email: gunterv.velde@huawei.com Phone: +32 476 476 022
Email: gunter.van_de_velde@alcatel-lucent.com
 End of changes. 14 change blocks. 
20 lines changed or deleted 26 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/