idnits 2.17.1 draft-ietf-opsec-dhcpv6-shield-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 5, 2014) is 3613 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsec F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: BCP W. Liu 5 Expires: December 7, 2014 Huawei Technologies 6 G. Van de Velde 7 Cisco Systems 8 June 5, 2014 10 DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers 11 draft-ietf-opsec-dhcpv6-shield-03 13 Abstract 15 This document specifies a mechanism for protecting hosts connected to 16 a switched network against rogue DHCPv6 servers. The aforementioned 17 mechanism is based on DHCPv6 packet-filtering at the layer-2 device 18 at which the packets are received. The aforementioned mechanism has 19 been widely deployed in IPv4 networks ('DHCP snooping'), and hence it 20 is desirable that similar functionality be provided for IPv6 21 networks. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 7, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. DHCPv6-Shield Configuration . . . . . . . . . . . . . . . . . 7 61 5. DHCPv6-Shield Implementation Advice . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 70 1. Introduction 72 This document specifies a mechanism for protecting hosts connected to 73 a switched network against rogue DHCPv6 servers [RFC3315]. This 74 mechanism is analogous to the RA-Guard mechanism [RFC6104] [RFC6105] 75 [RFC7113] intended for protection against rogue Router Advertisement 76 [RFC4861] messages. 78 The basic concept behind DHCPv6-Shield is that a layer-2 device 79 filters DHCPv6 messages meant to DHCPv6 clients (henceforth "DHCPv6- 80 server messages"), according to a number of different criteria. The 81 most basic filtering criterion is that DHCPv6-server messages are 82 discarded by the layer-2 device unless they are received on a 83 specific ports of the layer-2 device. 85 Before the DCHPv6-Shield device is deployed, the administrator 86 specifies the layer-2 port(s) on which DHCPv6-server messages are to 87 be allowed. Only those ports to which a DHCPv6 server or relay is to 88 be connected should be specified as such. Once deployed, the DHCPv6- 89 Shield device inspects received packets, and allows (i.e. passes) 90 DHCPv6-server messages only if they are received on layer-2 ports 91 that have been explicitly configured for such purpose. 93 2. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 3. Terminology 101 DHCPv6 Shield device: 103 A layer-2 device (typically a layer-2 switch) that enforces the 104 filtering policy specified in this document. 106 For the purposes of this document, the terms Extension Header, Header 107 Chain, First Fragment, and Upper-layer Header are used as follows 108 [RFC7112]: 110 Extension Header: 112 Extension Headers are defined in Section 4 of [RFC2460]. As a 113 result of [RFC7045], [IANA-PROTO] provides a list of assigned 114 Internet Protocol Numbers and designates which of those protocol 115 numbers also represent extension headers. 117 First Fragment: 119 An IPv6 fragment with fragment offset equal to 0. 121 IPv6 Header Chain: 123 The header chain contains an initial IPv6 header, zero or more 124 IPv6 extension headers, and optionally, a single upper-layer 125 header. If an upper-layer header is present, it terminates the 126 header chain; otherwise the "No Next Header" value (Next Header = 127 59) terminates it. 129 The first member of the header chain is always an IPv6 header. 130 For a subsequent header to qualify as a member of the header 131 chain, it must be referenced by the "Next Header" field of the 132 previous member of the header chain. However, if a second IPv6 133 header appears in the header chain, as is the case when IPv6 is 134 tunneled over IPv6, the second IPv6 header is considered to be an 135 upper-layer header and terminates the header chain. Likewise, if 136 an Encapsulating Security Payload (ESP) header appears in the 137 header chain it is considered to be an upper-layer header and it 138 terminates the header chain. 140 Upper-layer Header: 142 In the general case, the upper-layer header is the first member of 143 the header chain that is neither an IPv6 header nor an IPv6 144 extension header. However, if either an ESP header, or a second 145 IPv6 header occur in the header chain, they are considered to be 146 upper layer headers and they terminate the header chain. 148 Neither the upper-layer payload, nor any protocol data following 149 the upper-layer payload, is considered to be part of the header 150 chain. In a simple example, if the upper-layer header is a TCP 151 header, the TCP payload is not part of the header chain. In a 152 more complex example, if the upper-layer header is an ESP header, 153 neither the payload data, nor any of the fields that follow the 154 payload data in the ESP header are part of the header chain. 156 4. DHCPv6-Shield Configuration 158 Before being deployed for production, the DHCPv6-Shield device MUST 159 be explicitly configured with respect to which layer-2 ports are 160 allowed to send DHCPv6 packets to DHCPv6 clients (i.e. DHCPv6-server 161 messages). Only those layer-2 ports explicitly configured for such 162 purpose will be allowed to send DHCPv6 packets to DHCPv6 clients. 164 5. DHCPv6-Shield Implementation Advice 166 The following filtering rules MUST be enforced as part of a DHCPv6- 167 Shield implementation on those ports that are not allowed to send 168 DHCPv6 packets to DHCPv6 clients: 170 1. DHCPv6-Shield MUST parse the IPv6 entire header chain present in 171 the packet, to identify whether it is a DHCPv6 packet meant for a 172 DHCPv6 client (i.e., a DHCPv6-server message). 174 RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a 175 limit on the number of bytes they can inspect (starting from 176 the beginning of the IPv6 packet), since this could introduce 177 false-positives: legitimate packets could be dropped simply 178 because the DHCPv6-Shield device does not parse the entire 179 IPv6 header chain present in the packet. An implementation 180 that has such an implementation-specific limit MUST NOT claim 181 compliance with this specification. 183 2. When parsing the IPv6 header chain, if the packet is a first- 184 fragment (i.e., a packet containing a Fragment Header with the 185 Fragment Offset set to 0) and it fails to contain the entire IPv6 186 header chain (i.e., all the headers starting from the IPv6 header 187 up to, and including, the upper-layer header), DHCPv6-Shield MUST 188 drop the packet, and SHOULD log the packet drop event in an 189 implementation-specific manner as a security fault. 191 RATIONALE: [RFC7112] specifies that the first-fragment (i.e., 192 the fragment with the Fragment Offset set to 0) MUST contain 193 the entire IPv6 header chain, and allows intermediate systems 194 such as routers to drop those packets that fail to comply with 195 this requirement. 197 NOTE: This rule should only be applied to IPv6 fragments with 198 a Fragment Offset of 0 (non-first fragments can be safely 199 passed, since they will never reassemble into a complete 200 datagram if they are part of a DHCPv6 packet meant for a 201 DHCPv6 client received on a port where such packets are not 202 allowed). 204 3. When parsing the IPv6 header chain, if the packet is identified 205 to be a DHCPv6 packet meant for a DHCPv6 client or the packet 206 contains an unrecognized Next Header value, DHCPv6-Shield MUST 207 drop the packet, and SHOULD log the packet drop event in an 208 implementation-specific manner as a security alert. DHCPv6- 209 Shield MUST provide a configuration knob that controls whether 210 packets with unrecognized Next Header values are dropped; this 211 configuration knob MUST default to "drop". 213 RATIONALE: [RFC7045] requires that nodes be configurable with 214 respect to whether packets with unrecognized headers are 215 forwarded, and allows the default behavior to be that such 216 packets be dropped. 218 4. In all other cases, DHCPv6-Shield MUST pass the packet as usual. 220 NOTE: For the purpose of enforcing the DHCPv6-Shield filtering 221 policy, an ESP header [RFC4303] should be considered to be an 222 "upper-layer protocol" (that is, it should be considered the last 223 header in the IPv6 header chain). This means that packets 224 employing ESP would be passed by the DHCPv6-Shield device to the 225 intended destination. If the destination host does not have a 226 security association with the sender of the aforementioned IPv6 227 packet, the packet would be dropped. Otherwise, if the packet is 228 considered valid by the IPsec implementation at the receiving host 229 and encapsulates a DHCPv6 message, it is up to the receiving host 230 what to do with such packet. 232 If a packet is dropped due to this filtering policy, then the packet 233 drop event SHOULD be logged in an implementation-specific manner as a 234 security fault. The logging mechanism SHOULD include a drop counter 235 dedicated to DHCPv6-Shield packet drops. 237 In order to protect current end-node IPv6 implementations, Rule #2 238 has been defined as a default rule to drop packets that cannot be 239 positively identified as not being DHCPv6-server packets (because the 240 packet is a fragment that fails to include the entire IPv6 header 241 chain). This means that, at least in theory, DHCPv6-Shield could 242 result in false-positive blocking of some legitimate (non DHCPv6- 243 server) packets. However, as noted in [RFC7112], IPv6 packets that 244 fail to include the entire IPv6 header chain are virtually impossible 245 to police with state-less filters and firewalls, and hence are 246 unlikely to survive in real networks. [RFC7112] requires that hosts 247 employing fragmentation include the entire IPv6 header chain in the 248 first fragment (the fragment with the Fragment Offset set to 0), thus 249 eliminating the aforementioned false positives. 251 The aforementioned filtering rules implicitly handle the case of 252 fragmented packets: if the DHCPv6-Shield device fails to identify the 253 upper-layer protocol as a result of the use of fragmentation, the 254 corresponding packets would be dropped. 256 Finally, we note that IPv6 implementations that allow overlapping 257 fragments (i.e. that do not comply with [RFC5722]) might still be 258 subject of DHCPv6-based attacks. However, a recent assessment of 259 IPv6 implementations [SI6-FRAG] with respect to their fragment 260 reassembly policy seems to indicate that most current implementations 261 comply with [RFC5722]. 263 6. IANA Considerations 265 This document has no actions for IANA. 267 7. Security Considerations 269 The mechanism specified in this document can be used to mitigate 270 DHCPv6-based attacks against hosts. Attack vectors based on other 271 messages meant for network configuration (such as ICMPv6 Router 272 Advertisements) are out of the scope of this document. Additionally, 273 the mechanism specified in this document does not mitigate attacks 274 against DHCPv6 servers (e.g., DoS). 276 If deployed in layer-2 domain with several cascading switches, there 277 will be an ingress port on the host's local switch which will need to 278 be enabled for receiving DHCPv6-server messages. However, this local 279 switch will be reliant on the upstream devices to have filtered out 280 rogue DHCPv6-server messages, as the local switch has no way of 281 determining which upstream DHCP-server messages are valid. 282 Therefore, in order to be effective DHCPv6 Shield should be deployed 283 and enabled on all layer-2 switches of a given layer-2 domain. 285 As noted in Section 5, IPv6 implementations that allow overlapping 286 fragments (i.e. that do not comply with [RFC5722]) might still be 287 subject of DHCPv6-based attacks. However, most current 288 implementations seem to comply with [RFC5722], and hence forbid IPv6 289 overlapping fragments. 291 We note that if an attacker sends a fragmented DHCPv6 packet on a 292 port not allowed to send such packets, the first-fragment would be 293 dropped, and the rest of the fragments would be passed. This means 294 that the victim node would tie memory buffers for the aforementioned 295 fragments, which would never reassemble into a complete datagram. If 296 a large number of such packets were sent by an attacker, and the 297 victim node failed to implement proper resource management for the 298 fragment reassembly buffer, this could lead to a Denial of Service 299 (DoS). However, this does not really introduce a new attack vector, 300 since an attacker could always perform the same attack by sending 301 forged fragmented datagram in which at least one of the fragments is 302 missing. [CPNI-IPv6] discusses some resource management strategies 303 that could be implemented for the fragment reassembly buffer. 305 8. Acknowledgements 307 The authors would like to thank (in alphabetical order) Jean-Michel 308 Combes, Juergen Schoenwaelder, Crsten Schmoll, Robert Sleigh, Mark 309 Smith, and Eric Vyncke, for providing valuable comments on earlier 310 versions of this document. 312 Part of Section 3 of this document was borrowed from [RFC7112], 313 authored by Fernando Gont, Vishwas Manral, and Ron Bonica. 315 This document is heavily based on the document [RFC7113] authored by 316 Fernando Gont. Thus, the authors would like to thank Ran Atkinson, 317 Karl Auer, Robert Downie, Washam Fan, David Farmer, Mike Heard, Marc 318 Heuse, Nick Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, 319 Arturo Servin, Gunter van de Velde, James Woodyatt, and Bjoern A. 320 Zeeb, for providing valuable comments on [RFC7113], on which this 321 document is based. 323 9. References 325 9.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 331 (IPv6) Specification", RFC 2460, December 1998. 333 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 334 and M. Carney, "Dynamic Host Configuration Protocol for 335 IPv6 (DHCPv6)", RFC 3315, July 2003. 337 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 338 RFC 4303, December 2005. 340 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 341 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 342 September 2007. 344 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 345 RFC 5722, December 2009. 347 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 348 Oversized IPv6 Header Chains", RFC 7112, January 2014. 350 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 351 of IPv6 Extension Headers", RFC 7045, December 2013. 353 9.2. Informative References 355 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 356 Problem Statement", RFC 6104, February 2011. 358 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 359 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 360 February 2011. 362 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 363 Advertisement Guard (RA-Guard)", RFC 7113, February 2014. 365 [IANA-PROTO] 366 Internet Assigned Numbers Authority, "Protocol Numbers", 367 February 2013, . 370 [SI6-FRAG] 371 SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 372 fragmentation/reassembly", 2012, . 376 [CPNI-IPv6] 377 Gont, F., "Security Assessment of the Internet Protocol 378 version 6 (IPv6)", UK Centre for the Protection of 379 National Infrastructure, (available on request). 381 Authors' Addresses 383 Fernando Gont 384 SI6 Networks / UTN-FRH 385 Evaristo Carriego 2644 386 Haedo, Provincia de Buenos Aires 1706 387 Argentina 389 Phone: +54 11 4650 8472 390 Email: fgont@si6networks.com 391 URI: http://www.si6networks.com 393 Will Liu 394 Huawei Technologies 395 Bantian, Longgang District 396 Shenzhen 518129 397 P.R. China 399 Email: liushucheng@huawei.com 401 Gunter Van de Velde 402 Cisco Systems 403 De Kleetlaan 6a 404 Diegem 1831 405 Belgium 407 Phone: +32 2704 5473 408 Email: gunter@cisco.com