idnits 2.17.1 draft-gont-opsec-ipv6-implications-on-ipv4-nets-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 : ---------------------------------------------------------------------------- ** 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 date (April 27, 2012) is 4374 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 425, 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 3053 ** Downref: Normative reference to an Informational RFC: RFC 5214 ** Downref: Normative reference to an Informational RFC: RFC 5569 ** Downref: Normative reference to an Experimental RFC: RFC 5572 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ra-guard-implementation-02 Summary: 6 errors (**), 0 flaws (~~), 6 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 27, 2012 5 Intended status: BCP 6 Expires: October 29, 2012 8 Security Implications of IPv6 on IPv4 Networks 9 draft-gont-opsec-ipv6-implications-on-ipv4-nets-01 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 29, 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 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4 57 3. Security Implications of tunneling Mechanisms . . . . . . . . 6 58 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 7 60 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7 61 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 7 62 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 9 63 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 9 64 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol 65 (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 Most general-purpose operating systems implement and enable by 76 default native IPv6 support and a number of transition-co-existence 77 technologies. In those cases in which such devices are deployed on 78 networks that are assumed to be IPv4-only, the aforementioned 79 technologies could be leveraged by local or remote attackers for a 80 number of (illegitimate) purposes. 82 For example, a Network Intrusion Detection System (NIDS) might be 83 prepared to detect attack patterns for IPv4 traffic, but might be 84 unable to detect the same attack patterns when a transition/ 85 co-existence technology is leveraged for that purpose. Additionally, 86 an IPv4 firewall might enforce a specific security policy in IPv4, 87 but might be unable to enforce the same policy in IPv6. Finally, 88 some transition/co-existence mechanisms (notably Teredo) are designed 89 to traverse Network Address Translators (NATs), which in many 90 deployments provide a minimum level of protection by only allowing 91 those instances of communication that have been initiated from the 92 internal network. Thus, these mechanisms might cause an internal 93 host with otherwise limited IPv4 connectivity to become globally 94 reachable over IPv6, therefore resulting in increased (and possibly 95 unexpected) host exposure. That is, the aforementioned technologies 96 might inadvertently allow incoming IPv6 connections from the Internet 97 to hosts behind the organizational firewall. 99 In general, the aforementioned security implications can be mitigated 100 by enforcing security controls on native IPv6 traffic and on IPv4- 101 tunneled traffic. Among such controls is the enforcement of 102 filtering policies, such that undesirable traffic is blocked. 104 This document discusses the security implications of IPv6 and IPv6 105 transition/co-existence technologies on (allegedly) IPv4-only 106 networks, and provides guidance on how to mitigate the aforementioned 107 issues. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Security Implications of native IPv6 support 115 Most popular operating systems include IPv6 support that is enabled 116 by default. This means that even if a network is expected to be 117 IPv4-only, much of its infrastructure is nevertheless likely to be 118 IPv6 enabled. For example, hosts are likely to have at least link- 119 local IPv6 connectivity which might be exploited by attackers with 120 access to the local network. 122 [CORE2007] is a security advisory about a buffer overflow which 123 could be remotely-exploited by leveraging link-local IPv6 124 connectivity that is enabled by default. 126 Additionally, unless appropriate measures are taken, an attacker with 127 access to an 'IPv4-only' local network could impersonate a local 128 router and cause local hosts to enable their IPv6 connectivity (e.g. 129 by sending Router Advertisement messages), possibly circumventing 130 security controls that were are enforced only on IPv4 communications. 132 [THC-IPV6] is the first publicly-available toolkit that 133 implemented this attack vector (along with many others). 135 [Waters2011] provides an example of how this could be achieved 136 using publicly available tools (besides incorrectly claiming the 137 discovery of a "0day vulnerability"). 139 In general, network SHOULD enforce on native IPv6 traffic the same 140 security policies they currently enforce on IPv4 traffic. However, 141 in those networks in which IPv6 has not yet been deployed, and 142 enforcing the aforementioned policies is deemed as unfeasible, a 143 network administrator MAY mitigate IPv6-based attack vectors by means 144 of appropriate packet filtering. 146 2.1. Filtering Native IPv6 Traffic 148 Some layer-2 devices may have the ability to selectively filter 149 packets based on the type of layer-2 payload. When such 150 functionality is available, IPv6 traffic could be blocked at those 151 layer-2 devices by blocking e.g. Ethernet frames with the Protocol 152 Type field set to 0x86dd [IANA-ETHER]. 154 SLAAC-based attacks [RFC3756] can be mitigated with technologies such 155 as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. 156 However, RA-Guard cannot mitigate attack vectors that employ IPv6 157 link-local addresses, since configuration of such addresses does not 158 rely on Router Advertisement messages. 160 In order to mitigate attacks based on native IPv6 traffic, IPv6 161 security controls should be enforced on both IPv4 and IPv6 networks. 162 The aforementioned controls might include: deploying IPv6-enabled 163 NIDS, implementing IPv6 firewalling, etc. 165 In some very specific scenarios (e.g., military operations 166 networks) in which only IPv4 service might be desired, a network 167 administrator might MAY disable IPv6 support in all the 168 communicating devices. 170 3. Security Implications of tunneling Mechanisms 172 Unless properly managed, tunneling mechanisms may result in negative 173 security implications ([RFC6169] describes the security implications 174 of tunneling mechanisms in detail). Therefore, tunneling mechanisms 175 should be a concern not only to network administrators that have 176 consciously deployed them, but also to network and security 177 administrators whose security policies might be bypassed by 178 exploiting these mechanisms. 180 [CERT2009] contains some examples of how tunnels can be leveraged 181 to bypass firewall rules. 183 To help mitigate these issues, a good security practice is to only 184 allow traffic deemed as "necessary" (i.e., the so-called "default 185 deny" policy). Therefore, security administrators SHOULD block (by 186 default)IPv6 transition/co-existence traffic, and SHOULD only allow 187 it as a result of an explicit decision, rather than as a result of 188 lack of awareness about such traffic. 190 It should be noted that this recommendation is aimed at a network 191 that is the target of such traffic (such as an enterprise 192 network). IPv6-transition traffic should not be filtered e.g. by 193 an ISP when it is transit traffic. 195 Additionally, it is highly recommended that in those networks where 196 specific transition mechanisms are not explicitly deployed, not only 197 the corresponding traffic should be filtered at the organizational 198 perimeter, but also the corresponding mechanisms disabled on each 199 node connected to the organizational network. This not only prevents 200 security breaches resulting from accidental use of these mechanisms, 201 but also disables this functionality altogether, possibly mitigating 202 vulnerabilities that might be present in the host implementation of 203 this transition/co-existence mechanisms. 205 IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured 206 tunnels) can generally be blocked by dropping IPv4 packets that 207 contain a Protocol field set to 41. Security devices such as NIDS 208 might also include signatures that detect such transition/ 209 co-existence traffic. 211 3.1. Filtering 6in4 213 Probably the most basic type of tunnel employed for connecting IPv6 214 "islands" is the so-called "6in4", in which IPv6 packets are 215 encapsulated within IPv4 packets. These tunnels are typically result 216 from manual configuration at the two tunnel endpoints. 218 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol 219 field of 41. 221 3.2. Filtering 6over4 223 [RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' 224 (or colloquially as 'virtual Ethernet'), which comprises a set of 225 mechanisms and policies to allow isolated IPv6 hosts located on 226 physical links with no directly-connected IPv6 router, to become 227 fully functional IPv6 hosts by using an IPv4 domain that supports 228 IPv4 multicast as their virtual local link. 230 This transition technology has never been widely deployed, because 231 of the low level of deployment of multicast in most networks. 233 6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol 234 field set to 41. As a result, simply filtering all IPv4 packets that 235 have a Protocol field equal to 41 will filter 6over4 (along with many 236 other transition technologies). 238 A more selective filtering could be enforced such that 6over4 traffic 239 is filtered while other transition traffic is still allowed. Such a 240 filtering policy would block all IPv4 packets that have their 241 Protocol field set to 41, and that have a Destination Address that 242 belongs to the prefix 239.0.0.0/8. 244 This filtering policy basically blocks 6over4 Neighbor Discovery 245 traffic directed to multicast addresses, thus preventing Stateless 246 Address Auto-configuration (SLAAC), address resolution, etc. 247 Additionally, it would prevent the 6over multicast addresses from 248 being leveraged for the purpose of network reconnaissance. 250 3.3. Filtering 6rd 252 6rd builds upon the mechanisms of 6to4 to enable the rapid deployment 253 of IPv6 on IPv4 infrastructures, while avoiding some downsides of 254 6to4. Usage of 6rd was originally documented in [RFC5569], and the 255 mechanism was generalized to other access technologies and formally 256 standardized in [RFC5969]. 258 6rd can be blocked by blocking IPv4 packets with the Protocol field 259 set to 41. 261 3.4. Filtering 6to4 263 6to4 [RFC3056] is an address assignment and router-to-router, host- 264 to-router, and router-to-host automatic tunnelling mechanism that is 265 meant to provide IPv6 connectivity between IPv6 sites and hosts 266 across the IPv4 Internet. 268 As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, 269 could be easily blocked by filtering IPv4 that contain their Protocol 270 field set to 41. This is the most effective way of filtering such 271 traffic. 273 Additional filtering rules that might be incorporated include: 275 o Filter outgoing IPv4 packets that have their Destination Address 276 set to an address that belongs to the prefix 192.88.99.0/24. 278 o Filter incoming IPv4 packets that have their Source Address set to 279 an address that belongs to the prefix 192.88.99.0/24. 281 It has been suggested that 6to4 relays send their packets with 282 their IPv4 Source Address set to 192.88.99.1. 284 o Filter outgoing IPv4 packets that have their Destination Address 285 set to the IPv4 address of well-known 6to4 relays. 287 o Filter incoming IPv4 packets that have their Destination Address 288 set to the IPv4 address of well-known 6to4 relays. 290 These last two filtering policies will generally be unnecessary, and 291 possibly unfeasible to enforce (given the number of potential 6to4 292 relays, and the fact that many relays may remain unknown to the 293 network administrator). If anything, they should be applied with the 294 additional requirement that such IPv4 packets have their Protocol 295 field set to 41, to avoid the case where other services available at 296 the same IPv4 address as a 6to4 relay are mistakenly made 297 inaccessible. 299 If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 300 traffic is allowed, then the following filtering rules could be 301 applied: 303 o Filter outgoing IPv4 packets that have their Protocol field set to 304 41, and that have an IPv6 Source Address (embedded in the IPv4 305 payload) that belongs to the prefix 2002::/16. 307 o Filter incoming IPv4 packets that have their Protocol field set to 308 41, and that have an IPv6 Destination address (embedded in the 309 IPv4 payload) that belongs to the prefix 2002::/16. 311 3.5. Filtering ISATAP 313 ISATAP [RFC5214] is an Intra-site tunnelling protocol, and thus it is 314 generally expected that such traffic will not traverse the 315 organizational firewall of an IPv4-only. Nevertheless, ISATAP 316 traffic is easily filtered as described in Section 3 of this 317 document. 319 3.6. Filtering Teredo 321 Teredo [RFC4380] is an address assignment and automatic tunnelling 322 technology that provides IPv6 connectivity to dual-stack nodes that 323 are behind one or more Network Address Translators (NATs), by 324 encapsulating IPv6 packets in IPv4-based UDP datagrams. Teredo is 325 meant to be a 'last resort' IPv6 connectivity technology, to be used 326 only when other technologies such as 6to4 cannot be deployed (e.g., 327 because the edge device has not been assigned a public IPv4 address). 329 As noted in [RFC4380], in order for a Teredo client to configure its 330 Teredo IPv6 address, it must contact a Teredo server, through the 331 Teredo service port (UDP port number 3544). 333 To prevent the Teredo initialization process from succeeding, and 334 hence prevent the use of Teredo, an organizational firewall could 335 filter outgoing UDP packets with a Destination Port of 3544. 337 It is clear that such a filtering policy does not prevent an attacker 338 from running its own Teredo server in the public Internet, using a 339 non-standard UDP port for the Teredo service port (i.e., a port 340 number other than 3544). 342 The most popular operating system that includes an implementation of 343 Teredo in the default installation is Microsoft Windows. Microsoft 344 Windows obtains the Teredo server addresses (primary and secondary) 345 by resolving the domain name teredo.ipv6.microsoft.com into DNS A 346 records. A network administrator may want to prevent Microsoft 347 Windows hosts from obtaining Teredo service by filtering at the 348 organizational firewall outgoing UDP datagrams (i.e., IPv4 packets 349 with the Protocol field set to 17) that contain in the IPv4 350 Destination Address any of the IPv4 addresses that the domain name 351 teredo.ipv6.microsoft.com maps to. Additionally, the firewall would 352 filter incoming UDP datagrams from any of the IPv4 addresses to which 353 the domain names of well-known Teredo servers (such as 354 teredo.ipv6.microsoft.com) resolve. 356 As these IPv4 addresses might change over time, an administrator 357 should obtain these addresses when implementing the filtering 358 policy, and should also be prepared to maintain this list up to 359 date. 361 The corresponding addresses can be easily obtained from a UNIX 362 host by issuing the command 'dig teredo.ipv6.microsoft.com a' 363 (without quotes). 365 It should be noted that even with all these filtering policies in 366 place, a node in the internal network might still be able to 367 communicate with some Teredo clients. That is, it could configure an 368 IPv6 address itself (without even contacting a Teredo server), and 369 might send Teredo traffic to those peers for which intervention of 370 the host's Teredo server is not required (e.g., Teredo clients behind 371 a cone NAT). 373 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 375 The tunnel broker model enables dynamic configuration of tunnels 376 between a tunnel client and a tunnel server. The tunnel broker 377 provides a control channel for creating, deleting or updating a 378 tunnel between the tunnel client and the tunnel server. 379 Additionally, the tunnel broker may register the user IPv6 address 380 and name in the DNS. Once the tunnel is configured, data can flow 381 between the tunnel client and the tunnel server. [RFC3053] describes 382 the Tunnel Broker model, while [RFC5572] specifies the Tunnel Setup 383 Protocol (TSP), which can be used by clients to communicate with the 384 Tunnel Broker. 386 TSP can use either TCP or UDP as the transport protocol. In both 387 cases TSP uses port number 3653, which has been assigned by the IANA 388 for this purpose. As a result, TSP (the Tunnel Broker control 389 channel) can be blocked by blocking TCP and UDP packets originating 390 from the local network and destined to UDP port 3653 or TCP port 391 3653. Additionally, the data channel can be blocked by blocking UDP 392 packets originated from the local network and destined to UDP port 393 3653, and IPv4 packets with a Protocol field set to 41. 395 4. Security Considerations 397 This document discusses the security implications of IPv6 on IPv4 398 networks, and describes a number of techniques to mitigate the 399 aforementioned issues. In general, the possible mitigations boil 400 down to enforcing on native IPv6 and IPv6 transition/co-existence 401 traffic the same security policies currently enforced for IPv4 402 traffic, and/or blocking the aforementioned traffic when it is deemed 403 as undesirable. 405 5. Acknowledgements 407 The author would like to thank (in alphabetical order) Arturo Servin, 408 for providing valuable comments on earlier versions of this document. 410 This document resulted from the project "Security Assessment of the 411 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by 412 Fernando Gont on behalf of the UK Centre for the Protection of 413 National Infrastructure (CPNI). 415 Fernando Gont would like to thank the UK CPNI for their continued 416 support. 418 6. References 420 6.1. Normative References 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, March 1997. 425 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 426 (IPv6) Specification", RFC 2460, December 1998. 428 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 429 Domains without Explicit Tunnels", RFC 2529, March 1999. 431 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 432 Tunnel Broker", RFC 3053, January 2001. 434 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 435 via IPv4 Clouds", RFC 3056, February 2001. 437 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 438 Network Address Translations (NATs)", RFC 4380, 439 February 2006. 441 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 442 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 443 March 2008. 445 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 446 Infrastructures (6rd)", RFC 5569, January 2010. 448 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 449 Infrastructures (6rd) -- Protocol Specification", 450 RFC 5969, August 2010. 452 [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the 453 Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. 455 6.2. Informative References 457 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 458 Discovery (ND) Trust Models and Threats", RFC 3756, 459 May 2004. 461 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 462 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 463 February 2011. 465 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 466 Concerns with IP Tunneling", RFC 6169, April 2011. 468 [I-D.ietf-v6ops-ra-guard-implementation] 469 Gont, F., "Implementation Advice for IPv6 Router 470 Advertisement Guard (RA-Guard)", 471 draft-ietf-v6ops-ra-guard-implementation-02 (work in 472 progress), March 2012. 474 [IANA-ETHER] 475 IANA, "Ether Types", 2012, 476 . 478 [CERT2009] 479 CERT, "Bypassing firewalls with IPv6 tunnels", 2009, . 483 [CORE2007] 484 CORE, "OpenBSD's IPv6 mbufs remote kernel buffer 485 overflow", 2007, 486 . 488 [CPNI-IPv6] 489 Gont, F., "Security Assessment of the Internet Protocol 490 version 6 (IPv6)", UK Centre for the Protection of 491 National Infrastructure, (available on request). 493 [THC-IPV6] 494 "The Hacker's Choice IPv6 Attack Toolkit", 495 . 497 [Waters2011] 498 Waters, A., "SLAAC Attack - 0day Windows Network 499 Interception Configuration Vulnerability", 2011, 500 . 502 Author's Address 504 Fernando Gont 505 UK Centre for the Protection of National Infrastructure 507 Email: fernando@gont.com.ar 508 URI: http://www.cpni.gov.uk