idnits 2.17.1 draft-gont-opsec-dhcpv6-shield-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 23, 2012) is 4193 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) == Unused Reference: 'RFC3315' is defined on line 254, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-6man-oversized-header-chain-01 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ra-guard-implementation-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for F. Gont 3 IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH 4 Internet-Draft W. Liu 5 Intended status: BCP Huawei Technologies 6 Expires: April 26, 2013 October 23, 2012 8 DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers 9 draft-gont-opsec-dhcpv6-shield-01 11 Abstract 13 This document specifies a mechanism for protecting hosts connected to 14 a broadcast network against rogue DHCPv6 servers. The aforementioned 15 mechanism is based on DHCPv6 packet-filtering at the layer-2 device 16 on which the packets are received. The aforementioned mechanism has 17 been widely deployed in IPv4 networks ('DHCP snooping'), and hence it 18 is desirable that similar functionality be provided for IPv6 19 networks. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, and it may not be 26 published except as an Internet-Draft. 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 26, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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. DHCPv6-Shield Configuration . . . . . . . . . . . . . . . . . 4 59 3. DHCPv6-Shield Implementation Advice . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 68 1. Introduction 70 This document specifies a mechanism for protecting hosts connected to 71 a broadcast network against rogue DHCPv6 servers. This mechanism is 72 analogous to the RA-Guard mechanism [RFC6104] [RFC6105] 73 [I-D.ietf-v6ops-ra-guard-implementation] intended for protection 74 against rogue Router Advertisement messages. 76 The basic concept behind DHCPv6-Shield is that a layer-2 device 77 filters DHCPv6 messages meant to DHCPv6 clients, according to a 78 number of different criteria. The most basic filtering criterion 79 being that the aforementioned DHCPv6 messages are discarded by the 80 layer-2 device unless they are received on a specified port of the 81 layer-2 device. 83 Before the DCHPv6-Shield device is deployed, the administrator 84 specifies the layer-2 port(s) on which DHCPv6 packets meant for 85 DHCPv6 clients are allowed. Only those ports to which a DHCPv6 86 server is to be connected should be specified as such. Once 87 deployed, the DHCPv6-Shield device inspects received packets, and 88 allows (i.e. passes) DHCPv6 messages meant for DHCPv6 clients only if 89 they are received on layer-2 ports that have been explicitly 90 configured for such purpose. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. DHCPv6-Shield Configuration 98 Before being deployed for production, the DHCPv6-Shield device MUST 99 me configured with respect to which layer-2 ports are allowed to send 100 DHCPv6 packets to DHCPv6 clients. Only those layer-2 ports 101 explicitly configured for such purpose will be allowed to send DHCPv6 102 packets to DHCPv6 clients. 104 3. DHCPv6-Shield Implementation Advice 106 The following filtering rules MUST be enforced as part of an DHCPv6- 107 Shield implementation on those ports that are not allowed to send 108 DHCPv6 packets to DHCPv6 clients: 110 1. DHCPv6-Shield MUST parse the IPv6 entire header chain present in 111 the packet, to identify whether it is a DHCPv6 packet meant for a 112 DHCPv6 client. 114 RATIONALE: [RFC6564] specifies a uniform format for IPv6 115 Extension Header, thus meaning that an IPv6 node can parse an 116 IPv6 header chain even if it contains Extension Headers that 117 are not currently supported by that node. Additionally, 118 [I-D.ietf-6man-oversized-header-chain] requires that if a 119 packet is fragmented, the first fragment contains the entire 120 IPv6 header chain. 122 DHCPv6-Shield implementations MUST NOT enforce a limit on the 123 number of bytes they can inspect (starting from the beginning 124 of the IPv6 packet), since this could introduce false- 125 positives: legitimate packets could be dropped simply because 126 the DHCPv6-Shield device does not parse the entire IPv6 header 127 chain present in the packet. An implementation that has such 128 an implementation-specific limit MUST NOT claim compliance 129 with this specification, and MUST pass the packet when such 130 implementation-specific limit is reached. 132 2. When parsing the IPv6 header chain, if the packet is a first- 133 fragment (i.e., a packet containing a Fragment Header with the 134 Fragment Offset set to 0) and it fails to contain the entire IPv6 135 header chain (i.e., all the headers starting from the IPv6 header 136 up to, and including, the upper-layer header), DHCPv6-Shield MUST 137 drop the packet, and SHOULD log the packet drop event in an 138 implementation-specific manner as a security fault. 140 RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies 141 that the first-fragment (i.e., the fragment with the Fragment 142 Offset set to 0) MUST contain the entire IPv6 header chain, 143 and allows intermediate systems such as routers to drop those 144 packets that fail to comply with this requirement. 146 NOTE: This rule should only be applied to IPv6 fragments with 147 a Fragment Offset of 0 (non-first fragments can be safely 148 passed, since they will never reassemble into a complete 149 datagram if they are part of a DHCPv6 packet meant for a 150 DHCPv6 client received on a port where such packets are not 151 allowed). 153 3. When parsing the IPv6 header chain, if the packet is identified 154 to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield 155 MUST drop the packet, and SHOULD log the packet drop event in an 156 implementation-specific manner as a security fault. 158 4. In all other cases, RA-Guard MUST pass the packet as usual. 160 NOTE: For the purpose of enforcing the DHCPv6-Shield filtering 161 policy, an ESP header [RFC4303] should be considered to be an 162 "upper-layer protocol" (that is, it should be considered the last 163 header in the IPv6 header chain). This means that packets 164 employing ESP would be passed by the DHCPv6-Shield device to the 165 intended destination. If the destination host does not have a 166 security association with the sender of the aforementioned IPv6 167 packet, the packet would be dropped. Otherwise, if the packet is 168 considered valid by the IPsec implementation at the receiving host 169 and encapsulates a DHCPv6 message, it is up to the receiving host 170 what to do with such packet. 172 If a packet is dropped due to this filtering policy, then the packet 173 drop event SHOULD be logged in an implementation-specific manner as a 174 security fault. The logging mechanism SHOULD include a drop counter 175 dedicated to DHCPv6-Shield packet drops. 177 In order to protect current end-node IPv6 implementations, Rule #2 178 has been defined as a default rule to drop packets that cannot be 179 positively identified as not being DHCPv6 packets meant for DHCPv6 180 clients (because the packet is a fragment that fails to include the 181 entire IPv6 header chain). This means that, at least in theory, 182 DHCPv6-Shield could result in false-positive blocking of some 183 legitimate (non DHCPv6-server) packets. However, as noted in 184 [I-D.ietf-6man-oversized-header-chain], IPv6 packets that fail to 185 include the entire IPv6 header chain are virtually impossible to 186 police with state-less filters and firewalls, and hence are unlikely 187 to survive in real networks. [I-D.ietf-6man-oversized-header-chain] 188 requires that hosts employing fragmentation include the entire IPv6 189 header chain in the first fragment (the fragment with the Fragment 190 Offset set to 0), thus eliminating the aforementioned false 191 positives. 193 The aforementioned filtering rules implicitly handle the case of 194 fragmented packets: if the DHCPv6-Shield device fails to identify the 195 upper-layer protocol as a result of the use of fragmentation, the 196 corresponding packets would be dropped. 198 Finally, we note that IPv6 implementations that allow overlapping 199 fragments (i.e. that do not comply with [RFC5722]) might still be 200 subject of DHCPv6-based attacks. However, a recent assessment of 201 IPv6 implementations [SI6-FRAG] with respect to their fragment 202 reassembly policy seems to indicate that most current implementations 203 comply with [RFC5722]. 205 4. IANA Considerations 207 This document has no actions for IANA. 209 5. Security Considerations 211 The mechanism specified in this document can be used to mitigate 212 DHCPv6-based attacks. Attack vectors based on other messages (such 213 as ICMPv6 Router Advertisements) are out of the scope of this 214 document. 216 As noted in Section 3, IPv6 implementations that allow overlapping 217 fragments (i.e. that do not comply with [RFC5722]) might still be 218 subject of DHCPv6-based attacks. However, most current 219 implementations seem to comply with [RFC5722], and hence forbid IPv6 220 overlapping fragments. 222 We note that if an attacker sends a fragmented DHCPv6 packets on a 223 port not allowed to send such packets, the first-fragment would be 224 dropped, and the rest of the fragments would be passed. This means 225 that the victim node would tie memory buffers for the aforementioned 226 fragments, which would never reassemble into a complete datagram. If 227 a large number of such packets were sent by an attacker, and the 228 victim node failed to implement proper resource management for the 229 fragment reassembly buffer, this could lead to a Denial of Service 230 (DoS). However, this does not really introduce a new attack vector, 231 since an attacker could always perform the same attack by sending 232 forged fragmented datagram in which at least one of the fragments is 233 missing. [CPNI-IPv6] discusses some resource management strategies 234 that could be implemented for the fragment reassembly buffer. 236 6. Acknowledgements 238 This document is heavily based on the document 239 [I-D.ietf-v6ops-ra-guard-implementation] authored by Fernando Gont. 240 Thus, the author would like to thank Ran Atkinson, Karl Auer, Robert 241 Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray 242 Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de 243 Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable 244 comments on [I-D.ietf-v6ops-ra-guard-implementation], on which this 245 document is based. 247 7. References 249 7.1. Normative References 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 255 and M. Carney, "Dynamic Host Configuration Protocol for 256 IPv6 (DHCPv6)", RFC 3315, July 2003. 258 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 259 RFC 4303, December 2005. 261 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 262 RFC 5722, December 2009. 264 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 265 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 266 RFC 6564, April 2012. 268 7.2. Informative References 270 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 271 Problem Statement", RFC 6104, February 2011. 273 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 274 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 275 February 2011. 277 [I-D.ietf-6man-oversized-header-chain] 278 Gont, F. and V. Manral, "Security and Interoperability 279 Implications of Oversized IPv6 Header Chains", 280 draft-ietf-6man-oversized-header-chain-01 (work in 281 progress), July 2012. 283 [I-D.ietf-v6ops-ra-guard-implementation] 284 Gont, F., "Implementation Advice for IPv6 Router 285 Advertisement Guard (RA-Guard)", 286 draft-ietf-v6ops-ra-guard-implementation-04 (work in 287 progress), May 2012. 289 [SI6-FRAG] 290 SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 291 fragmentation/reassembly", 2012, . 295 [CPNI-IPv6] 296 Gont, F., "Security Assessment of the Internet Protocol 297 version 6 (IPv6)", UK Centre for the Protection of 298 National Infrastructure, (available on request). 300 Authors' Addresses 302 Fernando Gont 303 SI6 Networks / UTN-FRH 304 Evaristo Carriego 2644 305 Haedo, Provincia de Buenos Aires 1706 306 Argentina 308 Phone: +54 11 4650 8472 309 Email: fgont@si6networks.com 310 URI: http://www.si6networks.com 312 Will Liu 313 Huawei Technologies 314 Bantian, Longgang District 315 Shenzhen 518129 316 P.R. China 318 Email: liushucheng@huawei.com