idnits 2.17.1 draft-ietf-opsec-dhcpv6-shield-02.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 (February 4, 2014) is 3727 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: Best Current Practice W. Liu 5 Expires: August 8, 2014 Huawei Technologies 6 G. Van de Velde 7 Cisco Systems 8 February 4, 2014 10 DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers 11 draft-ietf-opsec-dhcpv6-shield-02 13 Abstract 15 This document specifies a mechanism for protecting hosts connected to 16 a broadcast 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 August 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. DHCPv6-Shield Configuration . . . . . . . . . . . . . . . . . 4 61 5. DHCPv6-Shield Implementation Advice . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 9.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document specifies a mechanism for protecting hosts connected to 73 a broadcast network against rogue DHCPv6 servers [RFC3315]. This 74 mechanism is analogous to the RA-Guard mechanism [RFC6104] [RFC6105] 75 [I-D.ietf-v6ops-ra-guard-implementation] intended for protection 76 against rogue Router Advertisement [RFC4861] messages. 78 The basic concept behind DHCPv6-Shield is that a layer-2 device 79 filters DHCPv6 messages meant to DHCPv6 clients (henceforth 80 "DHCPv6-server messages"), according to a number of different 81 criteria. The most basic filtering criterion is that DHCPv6-server 82 messages are discarded by the layer-2 device unless they are received 83 on a specified port 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 is to be 88 connected should be specified as such. Once deployed, the 89 DHCPv6-Shield device inspects received packets, and allows (i.e. 90 passes) DHCPv6-server messages only if they are received on layer-2 91 ports 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 For the purposes of this document, the terms Extension Header, Header 102 Chain, First Fragment, and Upper-layer Header are used as follows 103 [RFC7112]: 105 Extension Header: 107 Extension Headers are defined in Section 4 of [RFC2460]. As a 108 result of [RFC7045], [IANA-PROTO] provides a list of assigned 109 Internet Protocol Numbers and designates which of those protocol 110 numbers also represent extension headers. 112 First Fragment: 114 An IPv6 fragment with fragment offset equal to 0. 116 IPv6 Header Chain: 118 The header chain contains an initial IPv6 header, zero or more 119 IPv6 extension headers, and optionally, a single upper-layer 120 header. If an upper-layer header is present, it terminates the 121 header chain; otherwise the "No Next Header" value (Next Header = 122 59) terminates it. 124 The first member of the header chain is always an IPv6 header. 125 For a subsequent header to qualify as a member of the header 126 chain, it must be referenced by the "Next Header" field of the 127 previous member of the header chain. However, if a second IPv6 128 header appears in the header chain, as is the case when IPv6 is 129 tunneled over IPv6, the second IPv6 header is considered to be an 130 upper-layer header and terminates the header chain. Likewise, if 131 an Encapsulating Security Payload (ESP) header appears in the 132 header chain it is considered to be an upper-layer header and it 133 terminates the header chain. 135 Upper-layer Header: 137 In the general case, the upper-layer header is the first member of 138 the header chain that is neither an IPv6 header nor an IPv6 139 extension header. However, if either an ESP header, or a second 140 IPv6 header occur in the header chain, they are considered to be 141 upper layer headers and they terminate the header chain. 143 Neither the upper-layer payload, nor any protocol data following 144 the upper-layer payload, is considered to be part of the header 145 chain. In a simple example, if the upper-layer header is a TCP 146 header, the TCP payload is not part of the header chain. In a 147 more complex example, if the upper-layer header is an ESP header, 148 neither the payload data, nor any of the fields that follow the 149 payload data in the ESP header are part of the header chain. 151 4. DHCPv6-Shield Configuration 153 Before being deployed for production, the DHCPv6-Shield device MUST 154 be explicitly configured with respect to which layer-2 ports are 155 allowed to send DHCPv6 packets to DHCPv6 clients (i.e. DHCPv6-server 156 messages). Only those layer-2 ports explicitly configured for such 157 purpose will be allowed to send DHCPv6 packets to DHCPv6 clients. 159 5. DHCPv6-Shield Implementation Advice 161 The following filtering rules MUST be enforced as part of a 162 DHCPv6-Shield implementation on those ports that are not allowed to 163 send DHCPv6 packets to DHCPv6 clients: 165 1. DHCPv6-Shield MUST parse the IPv6 entire header chain present in 166 the packet, to identify whether it is a DHCPv6 packet meant for a 167 DHCPv6 client (i.e., a DHCPv6-server message). 169 RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a 170 limit on the number of bytes they can inspect (starting from 171 the beginning of the IPv6 packet), since this could introduce 172 false-positives: legitimate packets could be dropped simply 173 because the DHCPv6-Shield device does not parse the entire 174 IPv6 header chain present in the packet. An implementation 175 that has such an implementation-specific limit MUST NOT claim 176 compliance with this specification, and MUST pass the packet 177 when such implementation-specific limit is reached. 179 2. When parsing the IPv6 header chain, if the packet is a first- 180 fragment (i.e., a packet containing a Fragment Header with the 181 Fragment Offset set to 0) and it fails to contain the entire IPv6 182 header chain (i.e., all the headers starting from the IPv6 header 183 up to, and including, the upper-layer header), DHCPv6-Shield MUST 184 drop the packet, and SHOULD log the packet drop event in an 185 implementation-specific manner as a security fault. 187 RATIONALE: [RFC7112] specifies that the first-fragment (i.e., 188 the fragment with the Fragment Offset set to 0) MUST contain 189 the entire IPv6 header chain, and allows intermediate systems 190 such as routers to drop those packets that fail to comply with 191 this requirement. 193 NOTE: This rule should only be applied to IPv6 fragments with 194 a Fragment Offset of 0 (non-first fragments can be safely 195 passed, since they will never reassemble into a complete 196 datagram if they are part of a DHCPv6 packet meant for a 197 DHCPv6 client received on a port where such packets are not 198 allowed). 200 3. When parsing the IPv6 header chain, if the packet is identified 201 to be a DHCPv6 packet meant for a DHCPv6 client or the packet 202 contains an unrecognized Next Header value, DHCPv6-Shield MUST 203 drop the packet, and SHOULD log the packet drop event in an 204 implementation-specific manner as a security fault. 205 DHCPv6-Shield MUST provide a configuration knob that controls 206 whether packets with unrecognized Next Header values are dropped; 207 this configuration knob MUST default to "drop". 209 RATIONALE: [RFC7045] requires that nodes be configurable with 210 respect to whether packets with unrecognized headers are 211 forwarded, and allows the default behavior to be that such 212 packets be dropped. 214 4. In all other cases, DHCPv6-Shield MUST pass the packet as usual. 216 NOTE: For the purpose of enforcing the DHCPv6-Shield filtering 217 policy, an ESP header [RFC4303] should be considered to be an 218 "upper-layer protocol" (that is, it should be considered the last 219 header in the IPv6 header chain). This means that packets 220 employing ESP would be passed by the DHCPv6-Shield device to the 221 intended destination. If the destination host does not have a 222 security association with the sender of the aforementioned IPv6 223 packet, the packet would be dropped. Otherwise, if the packet is 224 considered valid by the IPsec implementation at the receiving host 225 and encapsulates a DHCPv6 message, it is up to the receiving host 226 what to do with such packet. 228 If a packet is dropped due to this filtering policy, then the packet 229 drop event SHOULD be logged in an implementation-specific manner as a 230 security fault. The logging mechanism SHOULD include a drop counter 231 dedicated to DHCPv6-Shield packet drops. 233 In order to protect current end-node IPv6 implementations, Rule #2 234 has been defined as a default rule to drop packets that cannot be 235 positively identified as not being DHCPv6-server packets (because the 236 packet is a fragment that fails to include the entire IPv6 header 237 chain). This means that, at least in theory, DHCPv6-Shield could 238 result in false-positive blocking of some legitimate (non 239 DHCPv6-server) packets. However, as noted in [RFC7112], IPv6 packets 240 that fail to include the entire IPv6 header chain are virtually 241 impossible to police with state-less filters and firewalls, and hence 242 are unlikely to survive in real networks. [RFC7112] requires that 243 hosts employing fragmentation include the entire IPv6 header chain in 244 the first fragment (the fragment with the Fragment Offset set to 0), 245 thus eliminating the aforementioned false positives. 247 The aforementioned filtering rules implicitly handle the case of 248 fragmented packets: if the DHCPv6-Shield device fails to identify the 249 upper-layer protocol as a result of the use of fragmentation, the 250 corresponding packets would be dropped. 252 Finally, we note that IPv6 implementations that allow overlapping 253 fragments (i.e. that do not comply with [RFC5722]) might still be 254 subject of DHCPv6-based attacks. However, a recent assessment of 255 IPv6 implementations [SI6-FRAG] with respect to their fragment 256 reassembly policy seems to indicate that most current implementations 257 comply with [RFC5722]. 259 6. IANA Considerations 261 This document has no actions for IANA. 263 7. Security Considerations 265 The mechanism specified in this document can be used to mitigate 266 DHCPv6-based attacks. Attack vectors based on other messages (such 267 as ICMPv6 Router Advertisements) are out of the scope of this 268 document. 270 As noted in Section 5, IPv6 implementations that allow overlapping 271 fragments (i.e. that do not comply with [RFC5722]) might still be 272 subject of DHCPv6-based attacks. However, most current 273 implementations seem to comply with [RFC5722], and hence forbid IPv6 274 overlapping fragments. 276 We note that if an attacker sends a fragmented DHCPv6 packet on a 277 port not allowed to send such packets, the first-fragment would be 278 dropped, and the rest of the fragments would be passed. This means 279 that the victim node would tie memory buffers for the aforementioned 280 fragments, which would never reassemble into a complete datagram. If 281 a large number of such packets were sent by an attacker, and the 282 victim node failed to implement proper resource management for the 283 fragment reassembly buffer, this could lead to a Denial of Service 284 (DoS). However, this does not really introduce a new attack vector, 285 since an attacker could always perform the same attack by sending 286 forged fragmented datagram in which at least one of the fragments is 287 missing. [CPNI-IPv6] discusses some resource management strategies 288 that could be implemented for the fragment reassembly buffer. 290 8. Acknowledgements 292 The authors would like to thank (in alphabetical order) Jean-Michel 293 Combes, Juergen Schoenwaelder, and Mark Smith, for providing valuable 294 comments on earlier versions of this document. 296 Section 3 of this document was borrowed from [RFC7112], authored by 297 Fernando Gont, Vishwas Manral, and Ron Bonica. 299 This document is heavily based on the document 300 [I-D.ietf-v6ops-ra-guard-implementation] authored by Fernando Gont. 301 Thus, the authors would like to thank Ran Atkinson, Karl Auer, Robert 302 Downie, Washam Fan, David Farmer, Mike Heard, Marc Heuse, Nick 303 Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, 304 Gunter van de Velde, James Woodyatt, and Bjoern A. Zeeb, for 305 providing valuable comments on 306 [I-D.ietf-v6ops-ra-guard-implementation], on which this document is 307 based. 309 9. References 311 9.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 317 (IPv6) Specification", RFC 2460, December 1998. 319 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 320 and M. Carney, "Dynamic Host Configuration Protocol for 321 IPv6 (DHCPv6)", RFC 3315, July 2003. 323 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 324 4303, December 2005. 326 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 327 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 328 September 2007. 330 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 331 RFC 5722, December 2009. 333 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 334 Oversized IPv6 Header Chains", RFC 7112, January 2014. 336 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 337 of IPv6 Extension Headers", RFC 7045, December 2013. 339 9.2. Informative References 341 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 342 Problem Statement", RFC 6104, February 2011. 344 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 345 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 346 February 2011. 348 [I-D.ietf-v6ops-ra-guard-implementation] 349 Gont, F., "Implementation Advice for IPv6 Router 350 Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra- 351 guard-implementation-07 (work in progress), November 2012. 353 [IANA-PROTO] 354 Internet Assigned Numbers Authority, "Protocol Numbers", 355 February 2013, . 358 [SI6-FRAG] 359 SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 360 fragmentation/reassembly", 2012, 361 . 364 [CPNI-IPv6] 365 Gont, F., "Security Assessment of the Internet Protocol 366 version 6 (IPv6)", UK Centre for the Protection of 367 National Infrastructure, (available on request). 369 Authors' Addresses 370 Fernando Gont 371 SI6 Networks / UTN-FRH 372 Evaristo Carriego 2644 373 Haedo, Provincia de Buenos Aires 1706 374 Argentina 376 Phone: +54 11 4650 8472 377 Email: fgont@si6networks.com 378 URI: http://www.si6networks.com 380 Will Liu 381 Huawei Technologies 382 Bantian, Longgang District 383 Shenzhen 518129 384 P.R. China 386 Email: liushucheng@huawei.com 388 Gunter Van de Velde 389 Cisco Systems 390 De Kleetlaan 6a 391 Diegem 1831 392 Belgium 394 Phone: +32 2704 5473 395 Email: gunter@cisco.com