draft-ietf-opsec-dhcpv6-shield-07.txt   draft-ietf-opsec-dhcpv6-shield-08.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: November 16, 2015 Huawei Technologies Expires: January 7, 2016 Huawei Technologies
G. Van de Velde G. Van de Velde
Alcatel-Lucent Alcatel-Lucent
May 15, 2015 July 6, 2015
DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers
draft-ietf-opsec-dhcpv6-shield-07 draft-ietf-opsec-dhcpv6-shield-08
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 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 November 16, 2015. This Internet-Draft will expire on January 7, 2016.
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 17 skipping to change at page 2, line 17
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 Requirements . . . . . . . . . . 4 5. DHCPv6-Shield Implementation Requirements . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
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 intended for DHCPv6 clients device filters DHCPv6 messages intended for DHCPv6 clients
(henceforth "DHCPv6-server messages"), according to a number of (henceforth "DHCPv6-server messages"), according to a number of
skipping to change at page 5, line 15 skipping to change at page 5, line 15
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 ought to 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 entire IPv6 header
could otherwise be leveraged for circumventing DHCPv6-Shield. chain could otherwise be leveraged for circumventing
[RFC7112] requires that the first-fragment (i.e., the fragment DHCPv6-Shield. [RFC7112] requires that the first-fragment
with the Fragment Offset set to 0) contains the entire IPv6 (i.e., the fragment with the Fragment Offset set to 0)
header chain, and allows intermediate systems such as routers contains the entire IPv6 header chain, and allows intermediate
to drop those packets that fail to comply with this systems such as routers to drop those packets that fail to
requirement. comply with this 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. 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;
skipping to change at page 5, line 48 skipping to change at page 5, line 48
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.
4. In all other cases, DHCPv6-Shield MUST pass the packet as usual. 4. When parsing the IPv6 header chain, if the packet is identified
to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield
MUST drop the packet, and SHOULD log the packet drop event in an
implementation-specific manner as a security alert.
RATIONALE: Ultimately, the goal of DHCPv6-Shield is drop
DHCPv6 packets destined to DHCPv6 clients (i.e. DHCPv6-server
messages) that are received on ports that have not been
explicitly configured to allow the receipt of such packets.
5. In all other cases, DHCPv6-Shield MUST pass the packet as usual.
NOTE: For the purpose of enforcing the DHCPv6-Shield filtering NOTE: For the purpose of enforcing the DHCPv6-Shield filtering
policy, an ESP header [RFC4303] should be considered to be an policy, an ESP header [RFC4303] should be considered to be an
"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
skipping to change at page 8, line 24 skipping to change at page 8, line 32
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 Mike Heard, who provided detailed
feedback on earlier versions of this document and helped a lot in
producing a technically-sound document throughout the whole
publication process.
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, Ted Lemon, Pete Resnick, Juergen Jean-Michel Combes, Sheng Jiang, Ted Lemon, Pete Resnick, Juergen
Schoenwaelder, Carsten Schmoll, Robert Sleigh, Donald Smith, Mark Schoenwaelder, Carsten Schmoll, Robert Sleigh, Donald Smith, Mark
Smith, Hannes Tschofenig, Eric Vyncke, and Qin Wu, for providing Smith, Hannes Tschofenig, Eric Vyncke, and Qin Wu, for providing
valuable comments on earlier 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
 End of changes. 9 change blocks. 
15 lines changed or deleted 30 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/