idnits 2.17.1 draft-ietf-opsec-dhcpv6-shield-01.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 (October 22, 2013) is 3839 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) == Outdated reference: A later version (-09) exists of draft-ietf-6man-oversized-header-chain-08 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: April 25, 2014 Huawei Technologies 6 G. Van de Velde 7 Cisco Systems 8 October 22, 2013 10 DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers 11 draft-ietf-opsec-dhcpv6-shield-01 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 April 25, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . 2 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 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 3. Terminology 100 For the purposes of this document, the terms Extension Header, Header 101 Chain, First Fragment, and Upper-layer Header are used as follows 102 [I-D.ietf-6man-oversized-header-chain]: 104 Extension Header: 106 Extension Headers are defined in Section 4 of [RFC2460]. As a 107 result of [I-D.ietf-6man-ext-transmit], [IANA-PROTO] provides a 108 list of assigned Internet Protocol Numbers and designates which of 109 those protocol numbers also represent extension headers. 111 First Fragment: 113 An IPv6 fragment with fragment offset equal to 0. 115 IPv6 Header Chain: 117 The header chain contains an initial IPv6 header, zero or more 118 IPv6 extension headers, and optionally, a single upper-layer 119 header. If an upper-layer header is present, it terminates the 120 header chain; otherwise the "No Next Header" value (Next Header = 121 59) terminates it. 123 The first member of the header chain is always an IPv6 header. 124 For a subsequent header to qualify as a member of the header 125 chain, it must be referenced by the "Next Header" field of the 126 previous member of the header chain. However, if a second IPv6 127 header appears in the header chain, as is the case when IPv6 is 128 tunneled over IPv6, the second IPv6 header is considered to be an 129 upper-layer header and terminates the header chain. Likewise, if 130 an Encapsulating Security Payload (ESP) header appears in the 131 header chain it is considered to be an upper-layer header and it 132 terminates the header chain. 134 Upper-layer Header: 136 In the general case, the upper-layer header is the first member of 137 the header chain that is neither an IPv6 header nor an IPv6 138 extension header. However, if either an ESP header, or a second 139 IPv6 header occur in the header chain, they are considered to be 140 upper layer headers and they terminate the header chain. 142 Neither the upper-layer payload, nor any protocol data following 143 the upper-layer payload, is considered to be part of the header 144 chain. In a simple example, if the upper-layer header is a TCP 145 header, the TCP payload is not part of the header chain. In a 146 more complex example, if the upper-layer header is an ESP header, 147 neither the payload data, nor any of the fields that follow the 148 payload data in the ESP header are part of the header chain. 150 4. DHCPv6-Shield Configuration 152 Before being deployed for production, the DHCPv6-Shield device MUST 153 be explicitly configured with respect to which layer-2 ports are 154 allowed to send DHCPv6 packets to DHCPv6 clients (i.e. DHCPv6-server 155 messages). Only those layer-2 ports explicitly configured for such 156 purpose will be allowed to send DHCPv6 packets to DHCPv6 clients. 158 5. DHCPv6-Shield Implementation Advice 160 The following filtering rules MUST be enforced as part of a 161 DHCPv6-Shield implementation on those ports that are not allowed to 162 send DHCPv6 packets to DHCPv6 clients: 164 1. DHCPv6-Shield MUST parse the IPv6 entire header chain present in 165 the packet, to identify whether it is a DHCPv6 packet meant for a 166 DHCPv6 client (i.e., a DHCPv6-server message). 168 RATIONALE: [RFC6564] specifies a uniform format for IPv6 169 Extension Headers, thus meaning that an IPv6 node can parse 170 an IPv6 header chain even if it contains Extension Headers 171 that are not currently supported by that node. 172 Additionally, [I-D.ietf-6man-oversized-header-chain] 173 requires that if a packet is fragmented, the first fragment 174 contains the entire IPv6 header chain. 176 DHCPv6-Shield implementations MUST NOT enforce a limit on 177 the number of bytes they can inspect (starting from the 178 beginning of the IPv6 packet), since this could introduce 179 false-positives: legitimate packets could be dropped simply 180 because the DHCPv6-Shield device does not parse the entire 181 IPv6 header chain present in the packet. An implementation 182 that has such an implementation-specific limit MUST NOT 183 claim compliance with this specification, and MUST pass the 184 packet when such implementation-specific limit is reached. 186 2. When parsing the IPv6 header chain, if the packet is a first- 187 fragment (i.e., a packet containing a Fragment Header with the 188 Fragment Offset set to 0) and it fails to contain the entire IPv6 189 header chain (i.e., all the headers starting from the IPv6 header 190 up to, and including, the upper-layer header), DHCPv6-Shield MUST 191 drop the packet, and SHOULD log the packet drop event in an 192 implementation-specific manner as a security fault. 194 RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies 195 that the first-fragment (i.e., the fragment with the 196 Fragment Offset set to 0) MUST contain the entire IPv6 197 header chain, and allows intermediate systems such as 198 routers to drop those packets that fail to comply with this 199 requirement. 201 NOTE: This rule should only be applied to IPv6 fragments 202 with a Fragment Offset of 0 (non-first fragments can be 203 safely passed, since they will never reassemble into a 204 complete datagram if they are part of a DHCPv6 packet meant 205 for a DHCPv6 client received on a port where such packets 206 are not allowed). 208 3. When parsing the IPv6 header chain, if the packet is identified 209 to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield 210 MUST drop the packet, and SHOULD log the packet drop event in an 211 implementation-specific manner as a security fault. 213 4. In all other cases, DHCPv6-Shield MUST pass the packet as usual. 215 NOTE: For the purpose of enforcing the DHCPv6-Shield filtering 216 policy, an ESP header [RFC4303] should be considered to be an 217 "upper-layer protocol" (that is, it should be considered the last 218 header in the IPv6 header chain). This means that packets 219 employing ESP would be passed by the DHCPv6-Shield device to the 220 intended destination. If the destination host does not have a 221 security association with the sender of the aforementioned IPv6 222 packet, the packet would be dropped. Otherwise, if the packet is 223 considered valid by the IPsec implementation at the receiving host 224 and encapsulates a DHCPv6 message, it is up to the receiving host 225 what to do with such packet. 227 If a packet is dropped due to this filtering policy, then the packet 228 drop event SHOULD be logged in an implementation-specific manner as a 229 security fault. The logging mechanism SHOULD include a drop counter 230 dedicated to DHCPv6-Shield packet drops. 232 In order to protect current end-node IPv6 implementations, Rule #2 233 has been defined as a default rule to drop packets that cannot be 234 positively identified as not being DHCPv6-server packets (because the 235 packet is a fragment that fails to include the entire IPv6 header 236 chain). This means that, at least in theory, DHCPv6-Shield could 237 result in false-positive blocking of some legitimate (non 238 DHCPv6-server) packets. However, as noted in 239 [I-D.ietf-6man-oversized-header-chain], IPv6 packets that fail to 240 include the entire IPv6 header chain are virtually impossible to 241 police with state-less filters and firewalls, and hence are unlikely 242 to survive in real networks. [I-D.ietf-6man-oversized-header-chain] 243 requires that hosts employing fragmentation include the entire IPv6 244 header chain in the first fragment (the fragment with the Fragment 245 Offset set to 0), thus eliminating the aforementioned false 246 positives. 248 The aforementioned filtering rules implicitly handle the case of 249 fragmented packets: if the DHCPv6-Shield device fails to identify the 250 upper-layer protocol as a result of the use of fragmentation, the 251 corresponding packets would be dropped. 253 Finally, we note that IPv6 implementations that allow overlapping 254 fragments (i.e. that do not comply with [RFC5722]) might still be 255 subject of DHCPv6-based attacks. However, a recent assessment of 256 IPv6 implementations [SI6-FRAG] with respect to their fragment 257 reassembly policy seems to indicate that most current implementations 258 comply with [RFC5722]. 260 6. IANA Considerations 262 This document has no actions for IANA. 264 7. Security Considerations 266 The mechanism specified in this document can be used to mitigate 267 DHCPv6-based attacks. Attack vectors based on other messages (such 268 as ICMPv6 Router Advertisements) are out of the scope of this 269 document. 271 As noted in Section 5, IPv6 implementations that allow overlapping 272 fragments (i.e. that do not comply with [RFC5722]) might still be 273 subject of DHCPv6-based attacks. However, most current 274 implementations seem to comply with [RFC5722], and hence forbid IPv6 275 overlapping fragments. 277 We note that if an attacker sends a fragmented DHCPv6 packet on a 278 port not allowed to send such packets, the first-fragment would be 279 dropped, and the rest of the fragments would be passed. This means 280 that the victim node would tie memory buffers for the aforementioned 281 fragments, which would never reassemble into a complete datagram. If 282 a large number of such packets were sent by an attacker, and the 283 victim node failed to implement proper resource management for the 284 fragment reassembly buffer, this could lead to a Denial of Service 285 (DoS). However, this does not really introduce a new attack vector, 286 since an attacker could always perform the same attack by sending 287 forged fragmented datagram in which at least one of the fragments is 288 missing. [CPNI-IPv6] discusses some resource management strategies 289 that could be implemented for the fragment reassembly buffer. 291 8. Acknowledgements 293 The authors would like to thank (in alphabetical order) Jean-Michel 294 Combes, Juergen Schoenwaelder, and Mark Smith, for providing valuable 295 comments on earlier versions of this document. 297 Section 3 of this document was borrowed from 298 [I-D.ietf-6man-oversized-header-chain], authored by Fernando Gont, 299 Vishwas Manral, and Ron Bonica. 301 This document is heavily based on the document 302 [I-D.ietf-v6ops-ra-guard-implementation] authored by Fernando Gont. 303 Thus, the authors would like to thank Ran Atkinson, Karl Auer, Robert 304 Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray 305 Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de 306 Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable 307 comments on [I-D.ietf-v6ops-ra-guard-implementation], on which this 308 document is based. 310 9. References 312 9.1. Normative References 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 318 (IPv6) Specification", RFC 2460, December 1998. 320 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 321 and M. Carney, "Dynamic Host Configuration Protocol for 322 IPv6 (DHCPv6)", RFC 3315, July 2003. 324 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 325 4303, December 2005. 327 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 328 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 329 September 2007. 331 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 332 RFC 5722, December 2009. 334 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 335 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 336 RFC 6564, April 2012. 338 [I-D.ietf-6man-ext-transmit] 339 Carpenter, B. and S. Jiang, "Transmission and Processing 340 of IPv6 Extension Headers", draft-ietf-6man-ext- 341 transmit-05 (work in progress), October 2013. 343 9.2. Informative References 345 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 346 Problem Statement", RFC 6104, February 2011. 348 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 349 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 350 February 2011. 352 [I-D.ietf-6man-oversized-header-chain] 353 Gont, F., Manral, V., and R. Bonica, "Implications of 354 Oversized IPv6 Header Chains", draft-ietf-6man-oversized- 355 header-chain-08 (work in progress), October 2013. 357 [I-D.ietf-v6ops-ra-guard-implementation] 358 Gont, F., "Implementation Advice for IPv6 Router 359 Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra- 360 guard-implementation-07 (work in progress), November 2012. 362 [IANA-PROTO] 363 Internet Assigned Numbers Authority, "Protocol Numbers", 364 February 2013, . 367 [SI6-FRAG] 368 SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 369 fragmentation/reassembly", 2012, . 373 [CPNI-IPv6] 374 Gont, F., "Security Assessment of the Internet Protocol 375 version 6 (IPv6)", UK Centre for the Protection of 376 National Infrastructure, (available on request). 378 Authors' Addresses 379 Fernando Gont 380 SI6 Networks / UTN-FRH 381 Evaristo Carriego 2644 382 Haedo, Provincia de Buenos Aires 1706 383 Argentina 385 Phone: +54 11 4650 8472 386 Email: fgont@si6networks.com 387 URI: http://www.si6networks.com 389 Will Liu 390 Huawei Technologies 391 Bantian, Longgang District 392 Shenzhen 518129 393 P.R. China 395 Email: liushucheng@huawei.com 397 Gunter Van de Velde 398 Cisco Systems 399 De Kleetlaan 6a 400 Diegem 1831 401 Belgium 403 Phone: +32 2704 5473 404 Email: gunter@cisco.com