RFC 7610

DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers

📅 published August 2015, from ietf

DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers 🛡️💖

RFC 7610 is a Best Current Practice (that's BCP 199 🎀), dated August 2015, with ISSN 2070-1721. Its authors are F. Gont (SI6 Networks / UTN-FRH), W. Liu (Huawei Technologies), and G. Van de Velde (Alcatel-Lucent). The header doesn't list any Obsoletes or Updates line, so it doesn't claim to replace or amend another RFC 🦋

Abstract 📝

This document specifies a mechanism for protecting hosts on a switched network from rogue DHCPv6 servers. It works by filtering DHCPv6 packets at the layer 2 device where they arrive. Something similar already exists in IPv4 networks, called 'DHCP snooping', so it makes sense for IPv6 to get the same kind of protection ✨ This document specifies a Best Current Practice for implementing DHCPv6-Shield.

Status of This Memo 🌸

This memo documents an Internet Best Current Practice.

This is a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741.

For the current status, any errata, or to send feedback, check http://www.rfc-editor.org/info/rfc7610 💅

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.

Table of Contents 🗂️

1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Terminology .....................................................3
4. DHCPv6-Shield Configuration .....................................5
5. DHCPv6-Shield Implementation Requirements .......................5
6. Security Considerations .........................................7
7. References ......................................................9
   7.1. Normative References .......................................9
   7.2. Informative References ....................................10
Acknowledgements ..................................................11
Authors' Addresses ................................................12

1. Introduction ✨

This document specifies DHCPv6-Shield, a mechanism that protects hosts on a switched network from rogue DHCPv6 servers [RFC3315]. The core idea is that a layer 2 device filters DHCPv6 messages that are meant for DHCPv6 clients (we're calling these "DHCPv6-server messages" 🍓) using several different criteria. The most basic one: DHCPv6-server messages get discarded by the layer 2 device unless they arrive on specific ports of that device.

Before the DHCPv6-Shield device goes live, the administrator picks which layer 2 ports are allowed to carry DHCPv6-server messages. Only the ports where a DHCPv6 server or relay is actually going to be plugged in should be marked that way. Once it's deployed, the device inspects incoming packets and only lets (i.e., passes) DHCPv6-server messages through if they arrive on ports that were explicitly set up for that purpose 🔥

DHCPv6-Shield is basically the same energy as the Router Advertisement Guard (RA-Guard) mechanism [RFC6104] [RFC6105] [RFC7113], which protects against rogue Router Advertisement [RFC4861] messages 💜

Quick reality check 🙈 DHCPv6-Shield only covers DHCPv6-based attacks against hosts. Attacks that use other network-configuration messages (like ICMPv6 Router Advertisements) aren't handled by DHCPv6-Shield itself. Same goes for attacks on the DHCPv6 servers, like Denial of Service. Those are out of scope here.

2. Requirements Language 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. Terminology 📚

For the purposes of this doc, the terms "IPv6 Extension Header", "First Fragment", "IPv6 Header Chain", and "Upper-Layer Header" are used as specified in [RFC7112]. Here's how they go:

DHCPv6-Shield: The set of filtering rules in this document, meant to mitigate attacks that use DHCPv6-server packets.

DHCPv6-Shield device: A layer 2 device (typically a layer 2 switch) that enforces the filtering policy in this document.

IPv6 Extension Header: IPv6 Extension Headers are defined in Section 4 of [RFC2460]. Because of [RFC7045], [IANA-PROTO] gives a list of assigned Internet Protocol Numbers and marks which of those numbers also represent IPv6 Extension Headers 🦋

First Fragment: An IPv6 fragment with a Fragment Offset equal to 0.

IPv6 Header Chain: The IPv6 Header Chain contains an initial IPv6 header, zero or more IPv6 Extension Headers, and optionally a single Upper-Layer Header. If an Upper-Layer Header is present, it terminates the IPv6 Header Chain. Otherwise, the "No Next Header" value (Next Header = 59) terminates it.

The first member of the IPv6 Header Chain is always an IPv6 header. For a later header to count as a member of the chain, it must be referenced by the "Next Header" field of the previous member. But if a second IPv6 header shows up in the chain (like when IPv6 is tunneled over IPv6), that second IPv6 header is treated as an Upper-Layer Header and terminates the chain. Same deal if an Encapsulating Security Payload (ESP) header appears in the chain: it's treated as an Upper-Layer Header and ends the chain 🌸

Upper-Layer Header: In the general case, the Upper-Layer Header is the first member of the Header Chain that is neither an IPv6 header nor an IPv6 Extension Header. However, if either an ESP header or a second IPv6 header occurs in the IPv6 Header Chain, that header is treated as the Upper-Layer Header and terminates the chain 👑

Neither the upper-layer payload nor any protocol data after the upper-layer payload counts as part of the IPv6 Header Chain. Simple example: if the Upper-Layer Header is a TCP header, the TCP payload isn't part of the chain. A more complex one: if the Upper-Layer Header is an ESP header, neither the payload data nor any fields that follow the payload data in the ESP header are part of the IPv6 Header Chain 🧚

4. DHCPv6-Shield Configuration ⚙️

Before the DHCPv6-Shield device is deployed for production, it gets explicitly configured on which layer 2 ports are allowed to receive DHCPv6 packets destined for DHCPv6 clients (i.e., DHCPv6-server messages). Only the layer 2 ports explicitly configured for that purpose are allowed to receive DHCPv6 packets and pass them on to DHCPv6 clients. Config is the gatekeeper here, bestie 🫶

5. DHCPv6-Shield Implementation Requirements ✨

okay so here's the filtering rulebook that DHCPv6-Shield enforces on ports that are NOT allowed to receive DHCPv6 packets aimed at DHCPv6 clients 🛡️💅

  1. DHCPv6-Shield implementations MUST parse the entire IPv6 Header Chain in the packet to figure out whether it's a DHCPv6 packet meant for a DHCPv6 client (aka a DHCPv6-server message) 🔍
RATIONALE: DHCPv6-Shield implementations MUST NOT put a cap on how many bytes they inspect (counting from the start of the IPv6 packet). bestie, a cap could cause false negatives 😭 DHCP6-server packets arriving on ports that aren't allowed to get them could slip through just because the device stopped reading before it reached the whole IPv6 Header Chain. that's a total loophole, not it 🙅‍♀️
  1. When parsing the IPv6 Header Chain, if the packet is a First Fragment (a packet with a Fragment Header whose Fragment Offset is set to 0) AND it doesn't contain the whole IPv6 Header Chain (every header from the IPv6 header through the Upper-Layer Header, inclusive), DHCPv6-Shield MUST drop the packet and ought to log the drop as a security fault, in whatever way the implementation handles logging 🚫
RATIONALE: Packets missing part of the IPv6 Header Chain could otherwise be used to dodge DHCPv6-Shield. [RFC7112] says the First Fragment (the one with Fragment Offset set to 0) MUST contain the entire IPv6 Header Chain. [RFC7112] also lets intermediate systems like routers drop packets that don't follow this rule 🧚
NOTE: This rule should only apply to IPv6 fragments whose Fragment Offset is 0. Non-First Fragments can be safely passed, because they'll never reassemble into a complete datagram if they're part of a DHCPv6 packet meant for a DHCPv6 client that arrived on a port where those packets aren't allowed 🦋
  1. DHCPv6-Shield MUST provide a configuration knob that controls whether packets with unrecognized Next Header values get dropped. This knob MUST default to drop. When parsing the IPv6 Header Chain, if the packet has an unrecognized Next Header value and the knob is set to drop, DHCPv6-Shield MUST drop the packet and ought to log the drop as a security fault 🎛️
RATIONALE: An unrecognized Next Header value could be an IPv6 Extension Header, which means someone could hide a DHCPv6-server packet behind it. DHCPv6-Shield can't parse past unrecognized Next Header values [IPV6-UEH]. [RFC7045] says nodes must be configurable about forwarding packets with unrecognized headers, and it lets the default be dropping them 🙈
  1. When parsing the IPv6 Header Chain, if the packet is identified as a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield MUST drop the packet and SHOULD log the drop as a security alert 🚨
RATIONALE: The whole point of DHCPv6-Shield is to drop DHCPv6 packets destined for DHCPv6 clients (aka DHCPv6-server messages) that show up on ports that haven't been explicitly set up to accept them 💖
  1. In all other cases, DHCPv6-Shield MUST pass the packet as usual ✅
NOTE: When DHCPv6-Shield enforces this filtering policy, an ESP header [RFC4303] should be treated as an "upper-layer protocol", meaning it should count as the last header in the IPv6 Header Chain. So packets using ESP get passed along to the intended destination by the DHCPv6-Shield device. If the destination host has no security association with the sender, the packet gets dropped. But if the IPsec implementation on the receiving host considers the packet valid AND it wraps a DHCPv6 message, what happens next is up to the receiving host 🔐

if a packet gets dropped because of this filtering policy, the drop should be logged as a security fault in an implementation-specific way. it's also useful for the logging to include a per-port drop counter that's dedicated to DHCPv6-Shield drops 📊

now here's the tea ☕ Rule #2 exists to protect current end-node IPv6 implementations. by default, packets that can't be positively identified as NOT being DHCPv6-server packets (because they're fragments missing part of the IPv6 Header Chain) get dropped. so, at least in theory, DHCPv6-Shield could falsely block some legit non-DHCPv6-server packets 😬 BUT as [RFC7112] points out, IPv6 packets missing part of the IPv6 Header Chain are basically impossible to police with stateless filters and firewalls, so they're unlikely to survive on real networks 💀 [RFC7112] also says hosts that fragment MUST include the entire IPv6 Header Chain in the First Fragment (the one with Fragment Offset set to 0), which gets rid of those false positives entirely 🫶

the filtering rules also handle fragmented packets implicitly. if DHCPv6-Shield can't identify the upper-layer protocol because of fragmentation, those packets get dropped 🧩

last thing!! IPv6 implementations that allow overlapping fragments (ie, ones that don't comply with [RFC5722]) might still be vulnerable to DHCPv6-based attacks. BUT a recent assessment of IPv6 implementations [SI6-FRAG] on their fragment reassembly policy seems to show that most current implementations DO comply with [RFC5722] 🙌

6. Security Considerations 🔐😤

the recommendations in this document describe the ideal behavior of a DHCPv6-Shield device. however, to run DHCPv6-Shield on the fast path, it may be necessary to limit how deep into the packet the device scans before giving up. when there's a limit like that, it is recommended that implementations drop packets after trying to find a protocol header up to that limit, whatever that limit is 🚧

ideally, these devices should be configurable with a list of protocol header identifiers. that way, if new transport protocols get standardized after the device ships, they can be added to the list of header types the device recognizes 🧚‍♀️ since any header that isn't a UDP header gets passed by the DHCPv6-Shield algorithm, this lets the devices avoid blocking new transport protocols 🌈 when an implementation has to stop searching for recognizable header types because of these limits, the device SHOULD be configurable to either pass or drop that packet 🎀

the mechanism in this document can mitigate DHCPv6-based attacks against hosts. attack vectors based on other network-configuration messages (like ICMPv6 Router Advertisements) are out of scope for this document 🙅‍♀️ also, this mechanism does NOT mitigate attacks against DHCPv6 servers (like Denial of Service) 🛑

if DHCPv6-Shield is deployed in a layer 2 domain with several cascading switches, the host's local switch will need an ingress port enabled for receiving DHCPv6-server messages. BUT that local switch relies on the upstream devices to filter out rogue DHCPv6-server messages, since the local switch has no way of knowing which upstream DHCP-server messages are valid 🧐 so, to be effective, DHCPv6-Shield should be deployed and enabled on ALL layer 2 switches in a given layer 2 domain 🫶

as noted in Section 5, IPv6 implementations that allow overlapping fragments (ie, ones that don't comply with [RFC5722]) might still be subject to DHCPv6-based attacks. most current implementations seem to comply with [RFC5722], though, and so they forbid overlapping IPv6 fragments 🙌

Heads up: if an attacker sends a fragmented DHCPv6 packet on a port that isn't allowed to receive such packets, the First Fragment gets dropped but the rest of the fragments get passed along. That means the victim node ends up tying up memory buffers for fragments that will never reassemble into a complete datagram. if an attacker sends a LOT of these and the victim doesn't have proper resource management for its fragment reassembly buffer, this could lead to a Denial of Service (DoS) 😱 BUT this doesn't really add a new attack vector, since an attacker could always do the same thing by sending a forged fragmented datagram where at least one fragment is missing. [CPNI-IPv6] discusses some resource management strategies that could be implemented for the fragment reassembly buffer 🧠

also!! the security of a site using DHCPv6-Shield can be further improved by deploying [RFC7513] to mitigate IPv6 address spoofing attacks 💜

finally, other mechanisms for mitigating attacks based on DHCPv6-server messages exist, with different deployment considerations 🦋 for example, [SECURE-DHCPV6] allows authentication of DHCPv6-server packets if the IPv6 addresses of the DHCPv6 servers can be pre-configured at the client nodes ✨

7. References 📚

7.1. Normative References

Okay, bestie, these are the must-read docs the spec leans on. 📚✨

7.2. Informative References

These ones are extra reading, so go deep if you're obsessed. 🔍💅

Acknowledgements ✨

The authors would like to thank Mike Heard, who provided detailed feedback on earlier draft 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, Jean-Michel Combes, Sheng Jiang, Ted Lemon, Pete Resnick, Carsten Schmoll, Juergen Schoenwaelder, Robert Sleigh, Donald Smith, Mark Smith, Hannes Tschofenig, Eric Vyncke, and Qin Wu for providing valuable comments on earlier draft versions of this document. 💖

Part of Section 3 of this document was borrowed from [RFC7112], authored by Fernando Gont, Vishwas Manral, and Ron Bonica. 🤝

This document is heavily based on [RFC7113], authored by Fernando Gont. Thus, the authors would like to thank the following individuals for providing valuable comments on [RFC7113]: Ran Atkinson, Karl Auer, Robert Downie, Washam Fan, David Farmer, Mike Heard, Marc Heuse, Nick Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter Van de Velde, James Woodyatt, and Bjoern A. Zeeb. 🙌

The authors would like to thank Joel Jaeggli for his advice and guidance throughout the IETF process. 👑

Fernando Gont would like to thank Diego Armando Maradona for his magic and inspiration. ⚽✨

Authors' Addresses 💌

Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI:   http://www.si6networks.com


Will (Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen  518129
China

Email: liushucheng@huawei.com


Gunter Van de Velde
Alcatel-Lucent
Copernicuslaan 50
Antwerp, Antwerp  2018
Belgium

Phone: +32 476 476 022
Email: gunter.van_de_velde@alcatel-lucent.com

That's the whole RFC, bestie! 🌈🎀 Thanks for sticking with me through all three parts. You're iconic. 💅💖

📦 where this page comes from