idnits 2.17.1 draft-gont-opsec-ipv6-implications-on-ipv4-nets-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 24, 2012) is 4385 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: 'RFC2460' is defined on line 351, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 5214 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ra-guard-implementation-02 Summary: 3 errors (**), 0 flaws (~~), 7 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) UK CPNI 4 Internet-Draft April 24, 2012 5 Intended status: BCP 6 Expires: October 26, 2012 8 Security Implications of IPv6 on IPv4 networks 9 draft-gont-opsec-ipv6-implications-on-ipv4-nets-00 11 Abstract 13 This document discusses the security implications of native IPv6 14 support and IPv6 transition/co-existence technologies on "IPv4-only" 15 networks, and describes possible mitigations for the aforementioned 16 issues. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, and it may not be 23 published except as an Internet-Draft. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 26, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Security Implications of native IPv6 support . . . . . . . . . 4 56 3. Security Implications of tunneling Mechanisms . . . . . . . . 5 57 3.1. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 7 60 3.4. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 1. Introduction 70 Most general-purpose operating systems implement and enable by 71 default native IPv6 support and a number of transition-co-existence 72 technologies. In those cases in which such devices are deployed on 73 networks that are assumed to be IPv4-only, the aforementioned 74 technologies could be leveraged by local or remote attackers for a 75 number of (illegitimate) purposes. 77 For example, a Network Intrusion Detection System (NIDS) might be 78 prepared to detect attack patterns for IPv4 traffic, but might be 79 unable to detect the same attack patterns when a transition/ 80 co-existence technology is leveraged for that purpose. Additionally, 81 an IPv4 firewall might enforce a specific security policy in IPv4, 82 but might be unable to enforce the same policy in IPv6. Finally, 83 some transition/co-existence mechanisms (notably Teredo) are designed 84 to traverse Network Address Translators (NATs), which in many 85 deployments provide a minimum level of protection by only allowing 86 those instances of communication that have been initiated from the 87 internal network. Thus, these mechanisms might cause an internal 88 host with otherwise limited IPv4 connectivity to become globally 89 reachable over IPv6, therefore resulting in increased (and possibly 90 unexpected) host exposure. That is, the aforementioned technologies 91 might inadvertently allow incoming IPv6 connections from the Internet 92 to hosts behind the organizational firewall. 94 In general, the aforementioned security implications can be mitigated 95 by enforcing security controls on native IPv6 traffic and on IPv4- 96 tunneled traffic. Among such controls is the enforcement of 97 filtering policies, such that undesirable traffic is blocked. 99 This document discusses the security implications of IPv6 and IPv6 100 transition/co-existence technologies on (allegedly) IPv4-only 101 networks, and provides guidance on how to mitigate the aforementioned 102 issues. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Security Implications of native IPv6 support 110 Most popular operating systems include IPv6 support that is enabled 111 by default. This means that even if a network is expected to be 112 IPv4-only, much of its infrastructure is nevertheless likely to be 113 IPv6 enabled. For example, hosts are likely to have at least link- 114 local IPv6 connectivity which might be exploited by attackers with 115 access to the local network. 117 [CORE2007] is a security advisory about a buffer overflow which 118 could be remotely-exploited by leveraging link-local IPv6 119 connectivity that is enabled by default. 121 Additionally, unless appropriate measures are taken, an attacker with 122 access to an 'IPv4-only' local network could impersonate a local 123 router and cause local hosts to enable their IPv6 connectivity (e.g. 124 by sending Router Advertisement messages), possibly circumventing 125 security controls that were are enforced only on IPv4 communications. 127 [Waters2011] provides an example of how this could be achieved 128 using publicly available tools. 130 SLAAC-based attacks [RFC3756] can be mitigated with technologies such 131 as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. 132 However, RA-Guard cannot mitigate attack vectors that employ IPv6 133 link-local addresses, since configuration of such addresses does not 134 rely on Router Advertisement messages. 136 In order to mitigate attacks based on native IPv6 traffic, IPv6 137 security controls should be enforced on both IPv4 and IPv6 networks. 138 The aforementioned controls might include: deploying IPv6-enabled 139 NIDS, implementing IPv6 firewalling, etc. 141 In some very specific scenarios (e.g., military operations 142 networks) in which only IPv4 service might be desired, a network 143 administrator might disable IPv6 support in all the communicating 144 devices. 146 3. Security Implications of tunneling Mechanisms 148 Unless properly managed, tunneling mechanisms may result in negative 149 security implication. [RFC6169] describes the security implications 150 of tunneling mechanisms in detail. Therefore, tunneling mechanisms 151 should be a concern not only to network administrators that have 152 consciously deployed them, but also to network and security 153 administrators whose security policies might be bypassed by 154 exploiting these mechanisms. 156 [CERT2009] contains some examples of how tunnels can be leveraged 157 to bypass firewall rules. 159 To help mitigate these issues, a good security practice is to only 160 allow traffic deemed as "necessary" (i.e., the so-called "default 161 deny" policy). Therefore, security administrators should only allow 162 IPv6 transition co-existence traffic as a result of an explicit 163 decision, rather than as a result of lack of awareness about such 164 traffic. 166 It should be noted that this recommendation is aimed at a network 167 that is the target of such traffic (such as an enterprise 168 network). IPv6-transition traffic should not be filtered e.g. by 169 an ISP when it is transit traffic. 171 Additionally, it is highly recommended that in those networks where 172 specific transition mechanisms are not explicitly deployed, not only 173 the corresponding traffic should be filtered at the organizational 174 perimeter, but also the corresponding mechanisms disabled on each 175 node connected to the organizational network. This not only prevents 176 security breaches resulting from accidental use of these mechanisms, 177 but also disables this functionality altogether, possibly mitigating 178 vulnerabilities that might be present in the host implementation of 179 this transition/co-existence mechanisms. 181 IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured 182 tunnels) can generally be blocked by dropping IPv4 packets that 183 contain a Protocol field set to 41. Security devices such as NIDS 184 might also include signatures that detect such transition/ 185 co-existence traffic. 187 3.1. Filtering 6to4 189 6to4 [RFC3056] is an address assignment and router-to-router, host- 190 to-router, and router-to-host automatic tunnelling mechanism that is 191 meant to provide IPv6 connectivity between IPv6 sites and hosts 192 across the IPv4 Internet. 194 As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, 195 could be easily blocked by filtering IPv4 that contain their Protocol 196 field set to 41. This is the most effective way of filtering such 197 traffic. 199 Additional filtering rules that might be incorporated include: 201 o Filter outgoing IPv4 packets that have their Destination Address 202 set to an address that belongs to the prefix 192.88.99.0/24. 204 o Filter incoming IPv4 packets that have their Source Address set to 205 an address that belongs to the prefix 192.88.99.0/24. 207 It has been suggested that 6to4 relays send their packets with 208 their IPv4 Source Address set to 192.88.99.1. 210 o Filter outgoing IPv4 packets that have their Destination Address 211 set to the IPv4 address of well-known 6to4 relays. 213 o Filter incoming IPv4 packets that have their Destination Address 214 set to the IPv4 address of well-known 6to4 relays. 216 These last two filtering policies will generally be unnecessary, and 217 possibly unfeasible to enforce (given the number of potential 6to4 218 relays, and the fact that many relays may remain unknown to the 219 network administrator). If anything, they should be applied with the 220 additional requirement that such IPv4 packets have their Protocol 221 field set to 41, to avoid the case where other services available at 222 the same IPv4 address as a 6to4 relay are mistakenly made 223 inaccessible. 225 If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 226 traffic is allowed, then the following filtering rules could be 227 applied: 229 o Filter outgoing IPv4 packets that have their Protocol field set to 230 41, and that have an IPv6 Source Address (embedded in the IPv4 231 payload) that belongs to the prefix 2002::/16. 233 o Filter incoming IPv4 packets that have their Protocol field set to 234 41, and that have an IPv6 Destination address (embedded in the 235 IPv4 payload) that belongs to the prefix 2002::/16. 237 3.2. Filtering ISATAP 239 ISATAP [RFC5214] is an Intra-site tunnelling protocol, and thus it is 240 generally expected that such traffic will not traverse the 241 organizational firewall of an IPv4-only. Nevertheless, ISATAP 242 traffic is easily filtered as described in Section 3 of this 243 document. 245 3.3. Filtering Teredo 247 Teredo [RFC4380] is an address assignment and automatic tunnelling 248 technology that provides IPv6 connectivity to dual-stack nodes that 249 are behind one or more Network Address Translators (NATs), by 250 encapsulating IPv6 packets in IPv4-based UDP datagrams. Teredo is 251 meant to be a 'last resort' IPv6 connectivity technology, to be used 252 only when other technologies such as 6to4 cannot be deployed (e.g., 253 because the edge device has not been assigned a public IPv4 address). 255 As noted in [RFC4380], in order for a Teredo client to configure its 256 Teredo IPv6 address, it must contact a Teredo server, through the 257 Teredo service port (UDP port number 3544). 259 To prevent the Teredo initialization process from succeeding, and 260 hence prevent the use of Teredo, an organizational firewall could 261 filter outgoing UDP packets with a Destination Port of 3544. 263 It is clear that such a filtering policy does not prevent an attacker 264 from running its own Teredo server in the public Internet, using a 265 non-standard UDP port for the Teredo service port (i.e., a port 266 number other than 3544). 268 The most popular operating system that includes an implementation of 269 Teredo in the default installation is Microsoft Windows. Microsoft 270 Windows obtains the Teredo server addresses (primary and secondary) 271 by resolving the domain name teredo.ipv6.microsoft.com into DNS A 272 records. A network administrator may want to prevent Microsoft 273 Windows hosts from obtaining Teredo service by filtering at the 274 organizational firewall outgoing UDP datagrams (i.e., IPv4 packets 275 with the Protocol field set to 17) that contain in the IPv4 276 Destination Address any of the IPv4 addresses that the domain name 277 teredo.ipv6.microsoft.com maps to. Additionally, the firewall would 278 filter incoming UDP datagrams from any of the IPv4 addresses to which 279 the domain names of well-known Teredo servers (such as 280 teredo.ipv6.microsoft.com) resolve. 282 As these IPv4 addresses might change over time, an administrator 283 should obtain these addresses himself when implementing the 284 filtering policy, and should also be prepared to maintain this 285 list updated over time. 287 The corresponding addresses can be easily obtained from a UNIX 288 host by issuing the command 'dig teredo.ipv6.microsoft.com a' 289 (without quotes). 291 It should be noted that even with all these filtering policies in 292 place, a node in the internal network might still be able to 293 communicate with some Teredo clients. That is, it could configure an 294 IPv6 address itself (without even contacting a Teredo server), and 295 might send Teredo traffic to those peers for which intervention of 296 the host's Teredo server is not required (e.g., Teredo clients behind 297 a cone NAT). 299 3.4. Filtering 6over4 301 [RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' 302 (or colloquially as 'virtual Ethernet'), which comprises a set of 303 mechanisms and policies to allow isolated IPv6 hosts located on 304 physical links with no directly-connected IPv6 router, to become 305 fully functional IPv6 hosts by using an IPv4 domain that supports 306 IPv4 multicast as their virtual local link. 308 This transition technology has never been widely deployed, because 309 of the low level of deployment of multicast in most networks. 311 6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol 312 field set to 41. As a result, simply filtering all IPv4 packets that 313 have a Protocol field equal to 41 will filter 6over4 (along with many 314 other transition technologies). 316 A more selective filtering could be enforced such that 6over4 traffic 317 is filtered while other transition traffic is still allowed. Such a 318 filtering policy would block all IPv4 packets that have their 319 Protocol field set to 41, and that have a Destination Address that 320 belongs to the prefix 239.0.0.0/8. 322 This filtering policy basically blocks 6over4 Neighbor Discovery 323 traffic directed to multicast addresses, thus preventing Stateless 324 Address Auto-configuration (SLAAC), address resolution, etc. 325 Additionally, it would prevent the 6over multicast addresses from 326 being leveraged for the purpose of network reconnaissance. 328 4. Security Considerations 330 This document discusses the security implications of IPv6 on IPv4 331 networks, and describes a number of techniques to mitigate the 332 aforementioned issues. 334 5. Acknowledgements 336 This document resulted from the project "Security Assessment of the 337 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by 338 Fernando Gont on behalf of the UK Centre for the Protection of 339 National Infrastructure (CPNI). 341 Fernando Gont would like to thank the UK CPNI for their continued 342 support. 344 6. References 346 6.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 352 (IPv6) Specification", RFC 2460, December 1998. 354 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 355 Network Address Translations (NATs)", RFC 4380, 356 February 2006. 358 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 359 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 360 March 2008. 362 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 363 via IPv4 Clouds", RFC 3056, February 2001. 365 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 366 Domains without Explicit Tunnels", RFC 2529, March 1999. 368 6.2. Informative References 370 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 371 Discovery (ND) Trust Models and Threats", RFC 3756, 372 May 2004. 374 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 375 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 376 February 2011. 378 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 379 Concerns with IP Tunneling", RFC 6169, April 2011. 381 [I-D.ietf-v6ops-ra-guard-implementation] 382 Gont, F., "Implementation Advice for IPv6 Router 383 Advertisement Guard (RA-Guard)", 384 draft-ietf-v6ops-ra-guard-implementation-02 (work in 385 progress), March 2012. 387 [CERT2009] 388 CERT, "Bypassing firewalls with IPv6 tunnels", 2009, . 392 [CORE2007] 393 CORE, "OpenBSD's IPv6 mbufs remote kernel buffer 394 overflow", 2007, 395 . 397 [CPNI-IPv6] 398 Gont, F., "Security Assessment of the Internet Protocol 399 version 6 (IPv6)", UK Centre for the Protection of 400 National Infrastructure, (available on request). 402 [Waters2011] 403 Waters, A., "SLAAC Attack - 0day Windows Network 404 Interception Configuration Vulnerability", 2011, 405 . 407 Author's Address 409 Fernando Gont 410 UK Centre for the Protection of National Infrastructure 412 Email: fernando@gont.com.ar 413 URI: http://www.cpni.gov.uk