idnits 2.17.1 draft-ietf-v6ops-security-overview-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1854. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- == There are 1 instance 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 private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-00 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-icmpv6-filtering-recs-02 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-nap-04 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-scanning-implications-00 == Outdated reference: A later version (-08) exists of draft-ietf-vrrp-ipv6-spec-07 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations E. Davies 3 Internet-Draft Consultant 4 Intended status: Informational S. Krishnan 5 Expires: April 25, 2007 Ericsson 6 P. Savola 7 CSC/Funet 8 October 22, 2006 10 IPv6 Transition/Co-existence Security Considerations 11 draft-ietf-v6ops-security-overview-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 25, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The transition from a pure IPv4 network to a network where IPv4 and 45 IPv6 co-exist brings a number of extra security considerations that 46 need to be taken into account when deploying IPv6 and operating the 47 dual-protocol network and the associated transition mechanisms. This 48 document attempts to give an overview of the various issues grouped 49 into three categories: 50 o issues due to the IPv6 protocol itself, 51 o issues due to transition mechanisms, and 52 o issues due to IPv6 deployment. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4 58 2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 5 59 2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5 60 2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6 61 2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 7 62 2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7 63 2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8 64 2.1.6. Anycast Traffic Identification and Security . . . . . 9 65 2.1.7. Address Privacy Extensions Interact with DDoS 66 Defenses . . . . . . . . . . . . . . . . . . . . . . . 10 67 2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, 68 Privacy Extensions and SEND . . . . . . . . . . . . . 10 69 2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11 70 2.1.10. Fragmentation: Reassembly and Deep Packet 71 Inspection . . . . . . . . . . . . . . . . . . . . . . 14 72 2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15 73 2.1.12. Link-Local Addresses and Securing Neighbor 74 Discovery . . . . . . . . . . . . . . . . . . . . . . 15 75 2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17 76 2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 18 77 2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18 78 2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 18 79 2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20 80 2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20 81 2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 20 82 2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22 83 3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 22 84 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 22 85 3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23 86 3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 87 Network Security Assumptions . . . . . . . . . . . . . . . 24 88 4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 25 89 4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 25 90 4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 27 91 4.3. Addressing Schemes and Securing Routers . . . . . . . . . 27 92 4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 27 93 4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 28 94 4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 29 95 4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 29 96 4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 30 97 4.8. Operational Factors when Enabling IPv6 in the Network . . 30 98 4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 31 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 104 8.2. Informative References . . . . . . . . . . . . . . . . . . 33 105 Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 36 106 Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 37 107 B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 37 108 B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 38 109 B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 38 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 111 Intellectual Property and Copyright Statements . . . . . . . . . . 40 113 1. Introduction 115 The transition from a pure IPv4 network to a network where IPv4 and 116 IPv6 co-exist brings a number of extra security considerations that 117 need to be taken into account when deploying IPv6 and operating the 118 dual-protocol network with its associated transition mechanisms. 119 This document attempts to give an overview of the various issues 120 grouped into three categories: 121 o issues due to the IPv6 protocol itself, 122 o issues due to transition mechanisms, and 123 o issues due to IPv6 deployment. 125 It is important to understand that deployments are unlikely to be 126 replacing IPv4 with IPv6 (in the short term), but rather will be 127 adding IPv6 to be operated in parallel with IPv4 over a considerable 128 period, so that security issues with transition mechanisms and dual 129 stack networks will be of ongoing concern. This extended transition 130 and coexistence period stems primarily from the scale of the current 131 IPv4 network. It is unreasonable to expect that the many millions of 132 IPv4 nodes will be converted overnight. It is more likely that it 133 will take two or three capital equipment replacement cycles (between 134 nine and 15 years) for IPv6 capabilities to spread through the 135 network and many services will remain available over IPv4 only for a 136 significant period whilst others are offered either just on IPv6 or 137 on both protocols. To maintain current levels of service, 138 enterprises and service providers will need to support IPv4 and IPv6 139 in parallel for some time. 141 This document also describes two matters that have been wrongly 142 identified as potential security concerns for IPv6 in the past and 143 explains why they are unlikely to cause problems: considerations 144 about probing/mapping IPv6 addresses (Appendix A), and considerations 145 with respect to privacy in IPv6 (Appendix B). 147 2. Issues Due to IPv6 Protocol 149 Administrators should be aware that some of the rules suggested in 150 this section could potentially lead to a small amount of legitimate 151 traffic being dropped because the source has made unusual and 152 arguably unreasonable choices when generating the packet. The IPv6 153 specification [RFC2460] contains a number of areas where choices are 154 available to packet originators that will result in packets that 155 conform to the specification but are unlikely to be the result of a 156 rational packet generation policy for legitimate traffic (e.g., 157 sending a fragmented packet in a much larger than necessary number of 158 small segments). This document highlights choices that could be made 159 by malicious sources with the intention of damaging the target host 160 or network, and suggests rules that try to differentiate 161 specification conforming packets that are legitimate traffic from 162 conforming packets that may be trying to subvert the specification to 163 cause damage. The differentiation tries to offer a reasonable 164 compromise between securing the network and passing every possible 165 conforming packet. To avoid loss of important traffic, 166 administrators are advised to log packets dropped according to these 167 rules and examine these logs periodically to ensure that they are 168 having the desired effect, and are not excluding traffic 169 inappropriately. 171 The built-in flexibility of the IPv6 protocol may also lead to 172 changes in the boundaries between legitimate and malicious traffic as 173 identified by these rules. New options may be introduced in future 174 and rules may need to be altered to allow the new capabilities to be 175 (legitimately) exploited by applications. The document therefore 176 recommends that filtering needs to be configurable to allow 177 administrators the flexibility to update rules as new pieces of IPv6 178 specification are standardized. 180 2.1. IPv6 Protocol-specific Issues 182 There are significant differences between the features of IPv6 and 183 IPv4: some of these specification changes may result in potential 184 security issues. Several of these issues have been discussed in 185 separate drafts but are summarized here to avoid normative references 186 that may not become RFCs. The following specification-related 187 problems have been identified, but this is not necessarily a complete 188 list: 190 2.1.1. Routing Headers and Hosts 192 All IPv6 nodes must be able to process Routing Headers [RFC2460]. 193 This RFC can be interpreted, although it is not clearly stated, to 194 mean that all nodes (including hosts) must have this processing 195 enabled. The Requirements for Internet Hosts [RFC1122] permits 196 implementations to perform "local source routing", that is forwarding 197 a packet with a routing header through the same interface on which it 198 was received: no restrictions are placed on this operation even on 199 hosts. In combination, these rules can result in hosts forwarding 200 received traffic to another node if there are segments left in the 201 Routing Header when it arrives at the host. 203 A number of potential security issues associated with this behavior 204 have been identified. Some of these issues have been resolved (a 205 separate routing header (Type 2) has been standardized for Mobile 206 IPv6 [RFC3775] and ICMP Traceback has not been standardized), but two 207 issues remain: 209 o Both existing types of routing header can be used to evade access 210 controls based on destination addresses. This could be achieved 211 by sending a packet ostensibly to a publicly accessible host 212 address but with a routing header containing a 'forbidden' 213 address. If the publicly accessible host is processing routing 214 headers it will forward the packet to the destination address in 215 the routing header that would have been forbidden by the packet 216 filters if the address had been in the destination field when the 217 packet was checked. 218 o If the packet source address can be spoofed when using a Type 0 219 routing header, the mechanism described in the previous bullet 220 could be used with any host to mediate an anonymous reflection 221 denial-of-service attack by having any publicly accessible host 222 redirect the attack packets. (This attack cannot use Type 2 223 routing headers because the packet cannot be forwarded outside the 224 host that processes the routing header, i.e., the original 225 destination of the packet.) 226 To counteract these threats, if a device is enforcing access controls 227 based on destination addresses, it needs to examine both the 228 destination address in the base IPv6 header and any waypoint 229 destinations in a routing header that have not yet been reached by 230 the packet at the point where it is being checked. 232 Various forms of amplification attack on routers and firewalls using 233 the routing header could be envisaged. A simple form involves 234 repeating the address of a waypoint several times in the routing 235 header. More complex forms could involve alternating waypoint 236 addresses that would result in the packet re-transiting the router or 237 firewall. These attacks can be counteracted by ensuring that routing 238 headers do not contain the same waypoint address more than once, and 239 performing ingress/egress filtering to check that the source address 240 is appropriate to the destination: packets made to reverse their path 241 will fail this test. 243 2.1.2. Routing Headers for Mobile IPv6 and Other Purposes 245 In addition to the basic Routing Header (Type 0), which is intended 246 to influence the trajectory of a packet through a network by 247 specifying a sequence of router 'waypoints', Routing Header (Type 2) 248 has been defined as part of the Mobile IPv6 specifications in 249 [RFC3775]. The Type 2 Routing Header is intended for use by hosts to 250 handle 'interface local' forwarding needed when packets are sent to 251 the care-of address of a mobile node that is away from its home 252 address. 254 It is important that nodes treat the different types of routing 255 header appropriately. It should be possible to apply separate 256 filtering rules to the different types of Routing Header. By design, 257 hosts must process Type 2 Routing Headers to support Mobile IPv6 but 258 routers should not: to avoid the issues in Section 2.1.1 it may be 259 desirable to forbid or limit the processing of Type 0 Routing Headers 260 in hosts and some routers. 262 Routing Headers are an extremely powerful and general capability. 263 Alternative future uses of Routing Headers need to be carefully 264 assessed to ensure that they do not open new avenues of attack that 265 can be exploited. 267 2.1.3. Site-scope Multicast Addresses 269 IPv6 supports multicast addresses with site scope that can 270 potentially allow an attacker to identify certain important resources 271 on the site if misused. 273 Particular examples are the 'all routers' (FF05::2) and 'all Dynamic 274 Host Configuration Protocol (DHCP) servers' (FF05::1:3) addresses 275 defined in [RFC2375]: an attacker that is able to infiltrate a 276 message destined for these addresses on to the site will potentially 277 receive in return information identifying key resources on the site. 278 This information can then be the target of directed attacks ranging 279 from simple flooding to more specific mechanisms designed to subvert 280 the device. 282 Some of these addresses have current legitimate uses within a site. 283 The risk can be minimized by ensuring that all firewalls and site 284 boundary routers are configured to drop packets with site scope 285 destination addresses. Also nodes should not join multicast groups 286 for which there is no legitimate use on the site and site routers 287 should be configured to drop packets directed to these unused 288 addresses. 290 2.1.4. ICMPv6 and Multicast 292 It is possible to launch a Denial-of-Service (DoS) attack using IPv6 293 that could be amplified by the multicast infrastructure. 295 Unlike ICMP for IPv4, ICMPv6 [RFC4443] allows error notification 296 responses to be sent when certain unprocessable packets are sent to 297 multicast addresses. 299 The cases in which responses are sent are: 300 o The received packet is longer than the next link Maximum 301 Transmission Unit (MTU): 'Packet Too Big' responses are needed to 302 support Path MTU Discovery for multicast traffic. 304 o The received packet contains an unrecognized option in a hop-by- 305 hop or destination options extension header with the first two 306 bits of the option type set to binary '10': 'Parameter Problem' 307 responses are intended to inform the source that some or all of 308 the recipients cannot handle the option in question. 310 If an attacker can craft a suitable packet sent to a multicast 311 destination, it may be possible to elicit multiple responses directed 312 at the victim (the spoofed source of the multicast packet). On the 313 other hand, the use of 'reverse path forwarding' checks to eliminate 314 loops in multicast forwarding automatically limits the range of 315 addresses that can be spoofed. 317 In practice an attack using oversize packets is unlikely to cause 318 much amplification unless the attacker is able to carefully tune the 319 packet size to exploit a network with smaller MTU in the edge than 320 the core. Similarly a packet with an unrecognized hop-by-hop option 321 would be dropped by the first router without resulting in multiple 322 responses. However a packet with an unrecognized destination option 323 could generate multiple responses. 325 In addition to amplification, this kind of attack would potentially 326 consume large amounts of forwarding state resources in routers on 327 multicast-enabled networks. 329 2.1.5. Bogus Errored Packets in ICMPv6 Error Messages 331 Apart from the spurious load on the network, routers and hosts, bogus 332 ICMPv6 error messages (types 0 to 127) containing a spoofed errored 333 packet can impact higher layer protocols when the alleged errored 334 packet is referred to the higher layer at the destination of the 335 ICMPv6 packet [RFC4443]. The potentially damaging effects on TCP 336 connections and some ways to mitigate the threats are documented in 337 [I-D.ietf-tcpm-icmp-attacks]. 339 Specific countermeasures for particular higher layer protocols are 340 beyond the scope of this document but firewalls may be able to help 341 counter the threat by inspecting the alleged errored packet embedded 342 in the ICMPv6 error message. Measures to mitigate the threat 343 include: 344 o The receiving host should test that the embedded packet is all or 345 part of a packet that was transmitted by the host. 346 o The firewall may be able to test that the embedded packet contains 347 addresses that would have been legitimate (i.e., would have passed 348 ingress/egress filtering) for a packet sent from the receiving 349 host but the possibility of asymmetric routing of the outgoing and 350 returning packets may prevent this sort of test depending on the 351 topology of the network, the location of the firewall, and whether 352 state synchronization between firewalls is in use. 353 o If the firewall is stateful and the test is not prevented by 354 asymmetric routing, the firewall may also be able to check that 355 the embedded packet is all or part of a packet which recently 356 transited the firewall in the opposite direction. 357 o Firewalls and destination hosts should be suspicious of ICMPv6 358 error messages with unnecessarily truncated errored packets (e.g., 359 those that only carry the address fields of the IPv6 base header.) 360 The specification of ICMPv6 requires that error messages carry as 361 much of the errored packet as possible (unlike ICMP for IPv4 which 362 requires only a minimum amount of the errored packet) and IPv6 363 networks must have a guaranteed minimum MTU of 1280 octets. 364 Accordingly, the ICMPv6 message should normally carry all the 365 header fields of the errored packet together with a significant 366 amount of the payload allowing robust comparison against the 367 outgoing packet. 369 2.1.6. Anycast Traffic Identification and Security 371 IPv6 introduces the notion of anycast addresses and services. 372 Originally the IPv6 standards disallowed using an anycast address as 373 the source address of a packet. Responses from an anycast server 374 would therefore supply a unicast address for the responding server. 375 To avoid exposing knowledge about the internal structure of the 376 network, it is recommended that anycast servers now take advantage of 377 the ability to return responses with the anycast address as the 378 source address if possible. 380 If the server needs to use a unicast address for any reason, it may 381 be desirable to consider using specialized addresses for anycast 382 servers, which are not used for any other part of the network, to 383 restrict the information exposed. Alternatively operators may wish 384 to restrict the use of anycast services from outside the domain, thus 385 requiring firewalls to filter anycast requests. For this purpose, 386 firewalls need to know which addresses are being used for anycast 387 services: these addresses are arbitrary and not distinguishable from 388 any other IPv6 unicast address by structure or pattern. 390 One particular class of anycast addresses that should be given 391 special attention is the set of Subnet-Router anycast addresses 392 defined in The IPv6 Addressing Architecture [RFC4291]. All routers 393 are required to support these addresses for all subnets for which 394 they have interfaces. For most subnets using global unicast 395 addresses, filtering anycast requests to these addresses can be 396 achieved by dropping packets with the lower 64 bits (the Interface 397 Identifier) set to all zeros. 399 2.1.7. Address Privacy Extensions Interact with DDoS Defenses 401 The purpose of the privacy extensions for stateless address auto- 402 configuration [I-D.ietf-ipv6-privacy-addrs-v2] is to change the 403 interface identifier (and hence the global scope addresses generated 404 from it) from time to time. By varying the addresses used, 405 eavesdroppers and other information collectors find it more difficult 406 to identify which transactions actually relate to a specific node. 408 A security issue may result from this if the frequency of node 409 address change is sufficiently great to achieve the intended aim of 410 the privacy extensions: with a relatively high rate of change, the 411 observed behavior has some characteristics of a node or nodes 412 involved in a Distributed Denial-of-Service (DDoS) attack. It should 413 be noted, however, that addresses created in this way are 414 topologically correct and that the other characteristics of the 415 traffic may reveal that there is no malicious intent. 417 This issue can be addressed in most cases by tuning the rate of 418 change in an appropriate manner. 420 Note that even if a node is well behaved, a change in the address 421 could make it harder for a security administrator to define an 422 address-based policy rule (e.g., access control list). However, 423 nodes that employ privacy addresses do not have to use them for all 424 communications. 426 2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, Privacy 427 Extensions and SEND 429 The introduction of Stateless Address Auto-Configuration (SLAAC) 430 [RFC2462] with IPv6 provides an additional challenge to the security 431 of Dynamic Domain Name System (DDNS). With manual addressing or the 432 use of DHCP, the number of security associations that need to be 433 maintained to secure access to the Domain Name Service (DNS) server 434 is limited, assuming any necessary updates are carried out by the 435 DHCP server. This is true equally for IPv4 and IPv6. 437 Since SLAAC does not make use of a single and potentially trusted 438 DHCP server, but depends on the node obtaining the address, securing 439 the insertion of updates into DDNS may need a security association 440 between each node and the DDNS server. This is discussed further in 441 [RFC4472]. 443 Using the Privacy Extensions to SLAAC 444 [I-D.ietf-ipv6-privacy-addrs-v2] may significantly increase the rate 445 of updates of DDNS. Even if a node using the Privacy Extensions does 446 not publish its address for 'forward' lookup (as that would 447 effectively compromise the privacy which it is seeking), it may still 448 need to update the reverse DNS records. If the reverse DNS records 449 are not updated servers that perform reverse DNS checks will not 450 accept connections from the node and it will not be possible to gain 451 access to IP Security (IPsec) keying material stored in DNS 452 [RFC4025]. If the rate of change needed to achieve real privacy has 453 to be increased (see Section 2.1.7) the update rate for DDNS may be 454 excessive. 456 Similarly, the cryptographically generated addresses used by SEND 457 [RFC3971] are expected to be periodically regenerated in line with 458 recommendations for maximum key lifetimes. This regeneration could 459 also impose a significant extra load on DDNS. 461 2.1.9. Extension Headers 463 A number of security issues relating to IPv6 Extension headers have 464 been identified. Several of these are as a result of ambiguous or 465 incomplete specification in the base IPv6 specification [RFC2460]. 467 2.1.9.1. Processing Extension Headers in Middleboxes 469 In IPv4 deep packet inspection techniques are used to implement 470 policing and filtering both as part of routers and in middleboxes 471 such as firewalls. Fully extending these techniques to IPv6 would 472 require inspection of all the extension headers in a packet. This is 473 essential to ensure that policy constraints on the use of certain 474 headers and options are enforced and to remove, at the earliest 475 opportunity, packets containing potentially damaging unknown options. 477 This requirement appears to conflict with Section 4 of the IPv6 478 specification in [RFC2460] which requires that only hop-by-hop 479 options are processed at any node through which the packet passes 480 until the packet reaches the appropriate destination (either the 481 final destination or a routing header waypoint). 483 Also [RFC2460] forbids processing the headers other than in the order 484 in which they appear in the packet. 486 A further ambiguity relates to whether an intermediate node should 487 discard a packet that contains a header or destination option which 488 it does not recognize. If the rules above are followed slavishly, it 489 is not (or may not be) legitimate for the intermediate node to 490 discard the packet because it should not be processing those headers 491 or options. 493 [RFC2460] therefore does not appear to take account of the behavior 494 of middleboxes and other non-final destinations that may be 495 inspecting the packet, and thereby potentially limits the security 496 protection of these boxes. Firewall vendors and administrators may 497 choose to ignore these rules in order to provide enhanced security as 498 this does not appear to have any serious consequences with the 499 currently defined set of extensions, but administrators should be 500 aware that future extensions might require different treatment. 502 2.1.9.2. Processing Extension Header Chains 504 There is a further problem for middleboxes that want to examine the 505 transport headers that are located at the end of the IPv6 header 506 chain. In order to locate the transport header or other protocol 507 data unit, the node has to parse the header chain. 509 The IPv6 specification [RFC2460] does not mandate the use of the 510 Type-Length-Value (TLV) format with a fixed layout for the start of 511 each header although it is used for the majority of headers currently 512 defined. (Only the Type field is guaranteed in size and offset). 514 A middlebox cannot therefore guarantee to be able to process header 515 chains that may contain headers defined after the box was 516 manufactured. As discussed further in Section 2.1.9.3, middleboxes 517 ought not to have to know the detailed layout of all header types in 518 use but still need to be able to skip over such headers to find the 519 transport payload start. If this is not possible, it either limits 520 the security policy that can be applied in firewalls or makes it 521 difficult to deploy new extension header types. 523 At the time of writing, only the Fragment Header does not fully 524 conform to the TLV format used for other extension headers. In 525 practice, many firewalls reconstruct fragmented packets before 526 performing deep packet inspection, so this divergence is less 527 problematic than it might have been, and is at least partially 528 justified because the full header chain is not present in all 529 fragments. 531 Hop-by-hop and Destination Options may also contain unknown options. 532 However, the options are required to be encoded in TLV format so that 533 intermediate nodes can skip over them during processing, unlike the 534 enclosing extension headers. 536 2.1.9.3. Unknown Headers/Destination Options and Security Policy 538 A strict security policy might dictate that packets containing either 539 unknown headers or destination options are discarded by firewalls or 540 other filters. This requires the firewall to process the whole 541 extension header chain, which may be currently in conflict with the 542 IPv6 specification as discussed in Section 2.1.9.1. 544 Even if the firewall does inspect the whole header chain, it may not 545 be sensible to discard packets with items unrecognized by the 546 firewall: the intermediate node has no knowledge of which options and 547 headers are implemented in the destination node and IPv6 has been 548 deliberately designed to be extensible through adding new header 549 options. This poses a dilemma for firewall administrators. On the 550 one hand admitting packets with 'unknown' options is a security risk 551 but dropping them may disable a useful new extension. The best 552 compromise appears to be to select firewalls that provide a 553 configurable discard policy based on the types of the extensions. 554 Then, if a new extension is standardized, administrators can 555 reconfigure firewalls to pass packets with legitimate items that they 556 would otherwise not recognize because their hardware or software is 557 not aware of a new definition. Provided that the new extensions 558 conform to the TLV layout followed by current extensions the firewall 559 would not need detailed knowledge of the function or layout of the 560 extension header. 562 2.1.9.4. Excessive Hop-by-Hop Options 564 IPv6 does not limit the number of hop-by-hop options that can be 565 present in a hop-by-hop option header and any option can appear 566 multiple times. The lack of a limit and the provision of 567 extensibility bits that force nodes to ignore classes of options 568 which they do not understand can be used to mount denial of service 569 attacks affecting all nodes on a path. A packet with large numbers 570 of unknown hop-by-hop options will be processed at every node through 571 which it is forwarded, consuming significant resources to determine 572 what action should be taken for each option. Current options with 573 the exception of Pad1 and PadN should not appear more than once so 574 that packets with inappropriately repeated options can be dropped but 575 keeping track of which options have been seen adds complexity to 576 firewalls and may not apply to future extensions. See 577 Section 2.1.9.3 for a discussion of the advisability of dropping 578 packets with unknown options in firewalls. 580 2.1.9.5. Misuse of Pad1 and PadN Options 582 IPv6 allows multiple padding options of arbitrary sizes to be placed 583 in both Hop-by-Hop and Destination option headers. 585 PadN options are required to contain zero octets as 'payload': there 586 is, however, no incentive for receivers to check this. It may 587 therefore be possible to use the 'payload' of padding options as a 588 covert channel. Firewalls and receiving hosts should actively check 589 that PadN only has zero octets in its 'payload'. 591 There is no legitimate reason for padding beyond the next eight octet 592 boundary since the whole option header is aligned on a eight octet 593 boundary but cannot be guaranteed to be on a 16 (or higher power of 594 two) octet boundary. The IPv6 specification allows multiple Pad1 and 595 PadN options to be combined in any way that the source chooses to 596 make up the required padding. Reasonable design choices would appear 597 to be using however many Pad1 options (i.e., zero octets) are needed 598 or using a single PadN option of the required size (two up to seven 599 octets). Administrators should consider at least logging unusual 600 padding patterns, and may consider dropping packets that contain 601 unusual patterns if they are certain of expected source behavior. 603 2.1.9.6. Overuse of Router Alert Option 605 The IPv6 router alert option specifies a hop-by-hop option that, if 606 present, signals the router to take a closer look at the packet. 607 This can be used for denial of service attacks. By sending a large 608 number of packets containing a router alert option an attacker can 609 deplete the processor cycles on the routers available to legitimate 610 traffic. 612 2.1.10. Fragmentation: Reassembly and Deep Packet Inspection 614 The current specifications of IPv6 in [RFC2460] do not mandate any 615 minimum packet size for the fragments of a packet before the last 616 one, except for the need to carry the unfragmentable part in all 617 fragments. 619 The unfragmentable part does not include the transport port numbers 620 so that it is possible that the first fragment does not contain 621 sufficient information to carry out deep packet inspection involving 622 the port numbers. 624 Packets with overlapping fragments are considered to be a major 625 security risk, but the reassembly rules for fragmented packets in 626 [RFC2460] do not mandate behavior that would minimize the effects of 627 overlapping fragments. 629 In order to ensure that deep packet inspection can be carried out 630 correctly on fragmented packets, many firewalls and other nodes that 631 use deep packet inspection will collect the fragments and reassemble 632 the packet before examining the packet. Depending on the 633 implementation of packet reassembly and the treatment of packet 634 fragments in these nodes, the specification issues mentioned 635 potentially leave IPv6 open to the sort of attacks described in 636 [RFC1858] and [RFC3128] for IPv4. 638 The following steps can be taken to mitigate these threats: 640 o Although permitted in [RFC2460] there is no reason for a source to 641 generate overlapping packet fragments and overlaps could be 642 prohibited in a future revision of the protocol specification. 643 Firewalls should drop all packets with overlapped fragments: 644 certain implementations both in firewalls and other nodes already 645 drop such packets. 646 o Specifying a minimum size for packet fragments does not help in 647 the same way as it does for IPv4 because IPv6 extension headers 648 can be made to appear very long: an attacker could insert one or 649 more undefined destination options with long lengths and the 650 'ignore if unknown' bit set. Given the guaranteed minimum MTU of 651 IPv6 it seems reasonable that hosts should be able to ensure that 652 the transport port numbers are in the first fragment in almost all 653 cases and that deep packet inspection should be very suspicious of 654 first fragments that do not contain them (see also the discussion 655 of fragment sizes in Section 2.1.11). 657 2.1.11. Fragmentation Related DoS Attacks 659 Packet reassembly in IPv6 hosts also opens up the possibility of 660 various fragment-related security attacks. Some of these are 661 analogous to attacks identified for IPv4. Of particular concern is a 662 DoS attack based on sending large numbers of small fragments without 663 a terminating last fragment that would potentially overload the 664 reconstruction buffers and consume large amounts of CPU resources. 666 Mandating the size of packet fragments could reduce the impact of 667 this kind of attack by limiting the rate at which fragments could 668 arrive and limiting the number of fragments that need to be processed 669 but this is not currently specified by the IPv6 standard. In 670 practice reasonable design choices in protocol stacks are likely to 671 either maximise the size of all fragments except the final one using 672 the path MTU (most likely choice), or distribute the data evenly in 673 the required minimum number of fragments. In either case the 674 smallest non-final fragment would be at least half the guaranteed 675 minimum MTU (640 octets) - the worst case arises when a payload is 676 just too large for a single packet and is divided approximately 677 equally between two packets. Administrators should consider 678 configuring firewalls and hosts to drop non-final fragments smaller 679 than 640 octets. 681 2.1.12. Link-Local Addresses and Securing Neighbor Discovery 683 All IPv6 nodes are required to configure a link-local address on each 684 interface. This address is used to communicate with other nodes 685 directly connected to the link accessed via the interface, especially 686 during the neighbor discovery and auto-configuration processes. 687 Link-local addresses are fundamental to the operation of the Neighbor 688 Discovery Protocol (NDP) [RFC2461] and Stateless Address 689 Autoconfiguration (SLAAC) [RFC2462]. NDP also provides the 690 functionality of associating link layer and IP addresses provided by 691 the Address Resolution Protocol (ARP) in IPv4 networks. 693 The standard version of NDP is subject to a number of security 694 threats related to ARP spoofing attacks on IPv4. These threats have 695 been documented in [RFC3756] and mechanisms to combat them specified 696 in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional 697 mechanism that is particularly applicable to wireless and other 698 environments where it is difficult to physically secure the link. 700 Because the link-local address can, by default, be acquired without 701 external intervention or control, it allows an attacker to commence 702 communication on the link without needing to acquire information 703 about the address prefixes in use or communicate with any authorities 704 on the link. This feature gives a malicious node the opportunity to 705 mount an attack on any other node that is attached to this link; this 706 vulnerability exists in addition to possible direct attacks on NDP. 707 Link-local addresses may also facilitate the unauthorized use of the 708 link bandwidth ('bandwidth theft') to communicate with another 709 unauthorized node on the same link. 711 The vulnerabilities of IPv6 link local addresses in NDP can be 712 mitigated in several ways. A general solution will require 713 o authenticating the link layer connectivity, for example by using 714 IEEE 802.1X functionality [IEEE.802-1X.2004] or physical security, 715 and 716 o using SEcure Neighbor Discovery (SEND) to create a 717 cryptographically generated link-local address as described in 718 [RFC3971] that is tied to the authenticated link layer address. 719 This solution would be particularly appropriate in wireless LAN 720 deployments where it is difficult to physically secure the 721 infrastructure, but may not be considered necessary in wired 722 environments where the physical infrastructure can be kept secure by 723 other means. 725 Limiting the potentiality for abuse of link local addresses in 726 general packet exchanges is more problematic because there may be 727 circumstances, such as isolated networks, where usage is appropriate 728 and discrimination between use and abuse requires complex filtering 729 rules which have to be implemented on hosts. The risk of misuse may 730 be deemed too small compared with the effort needed to control it, 731 but special attention should be paid to tunnel end-points (see 732 Section 2.4, Section 3.2 and Section 3.3). 734 Any filtering has to be provided by a host-based or bridging 735 firewall. In general link local addresses are expected to be used by 736 applications that are written to deal with specific interfaces and 737 links. Typically these application are used for control and 738 management, A node which is attached to multiple links has to deal 739 with the potentially overlapping link local address spaces associated 740 with these links. IPv6 provides for this through zone identifiers 741 that are used to discriminate between the different address scopes 742 [RFC4007] and the scope identifier that can be associated with a 743 socket address structure [RFC3493]. Most users are unfamiliar with 744 these issues and general purpose applications are not intended to 745 handle this kind of discrimination. Link local addresses are not 746 normally used with the Domain Name System (DNS) and DNS cannot supply 747 zone identifiers. If it is considered necessary to prevent the use 748 of link local addresses by other than control and management 749 protocols, administrators may wish to consider limiting the protocols 750 that can be used with link local addresses. At a minimum ICMPv6 and 751 any intra-domain routing protocol (such as Open Shortest Path First 752 (OSPF) or Routing Information Protocol (RIP)) in use need to be 753 allowed but other protocols may also be needed. RIP illustrates the 754 complexity of the filtering problem: its messages are encapsulated as 755 User Datagram Protocol (UDP) payloads and filtering needs to 756 distinguish RIP messages addressed to UDP port 521 from other UDP 757 messages. 759 2.1.13. Securing Router Advertisements 761 As part of the Neighbor Discovery process, routers on a link 762 advertise their capabilities in Router Advertisement messages. The 763 version of NDP defined in [RFC2461] does not protect the integrity of 764 these messages or validate the assertions made in the messages with 765 the result that any node that connects to the link can maliciously 766 claim to offer routing services that it will not fulfil, and 767 advertise inappropriate prefixes and parameters. These threats have 768 been documented in [RFC3756]. 770 A malicious node may also be able to carry out a DoS attack by 771 deprecating an established valid prefix (by advertising it with a 772 zero lifetime). Similar DoS attacks are possible if the optional 773 Router Selection mechanism is implemented as described in the 774 security considerations of [RFC4191]. 776 SEND [RFC3971] can be used to provide verification that routers are 777 authorized to provide the services they advertise through a 778 certificate-based mechanism. This capability of SEND is also 779 particularly appropriate for wireless environments where clients are 780 reliant on the assertions of the routers rather than a physically 781 secured connection. 783 2.1.14. Host to Router Load Sharing 785 If a host deploys the optional Host to Router Load Sharing mechanism 786 [RFC4311] a malicious application could carry out a DoS attack on one 787 or more of the load sharing routers if the application is able to use 788 knowledge of the load sharing algorithm to synthesize traffic that 789 subverts the load sharing algorithm and directs a large volume of 790 bogus traffic towards a subset of the routers. The likelihood of 791 such an attack can be reduced if the implementation uses a 792 sufficiently sophisticated load sharing algorithm as described in the 793 security considerations of [RFC4311]. 795 2.1.15. Mobile IPv6 797 Mobile IPv6 offers significantly enhanced security compared with 798 Mobile IPv4 especially when using optimized routing and care-of 799 addresses. Return routability checks are used to provide relatively 800 robust assurance that the different addresses that a mobile node uses 801 as it moves through the network do indeed all refer to the same node. 802 The threats and solutions are described in [RFC3775] and a more 803 extensive discussion of the security aspects of the design can be 804 found in [RFC4225]. 806 2.1.15.1. Obsolete Home Address Option in Mobile IPv6 808 The Home Address option specified in early drafts of Mobile IPv6 809 would have allowed a trivial source spoofing attack: hosts were 810 required to substitute the source address of incoming packets with 811 the address in the option, thereby potentially evading checks on the 812 packet source address. The version of Mobile IPv6 as standardized in 813 [RFC3775] has removed this issue by ensuring that the Home Address 814 destination option is only processed if there is a corresponding 815 binding cache entry and securing Binding Update messages. 817 A number of pre-standard implementations of Mobile IPv6 were 818 available that implemented this obsolete and insecure option: care 819 should be taken to avoid running such obsolete systems. 821 2.2. IPv4-mapped IPv6 Addresses 823 Overloaded functionality is always a double-edged sword: it may yield 824 some deployment benefits, but often also incurs the price that comes 825 with ambiguity. 827 One example of such is IPv4-mapped IPv6 addresses (::ffff/96): a 828 representation of an IPv4 address as an IPv6 address inside an 829 operating system as defined in [RFC3493]. Since the original 830 specification, the use of IPv4-mapped addresses has been extended to 831 a transition mechanism, Stateless IP/ICMP Translation algorithm 832 (SIIT) [RFC2765], where they are potentially used in the addresses of 833 packets on the wire. 835 Therefore, it becomes difficult to unambiguously discern whether an 836 IPv4 mapped address is really an IPv4 address represented in the IPv6 837 address format (basic API behavior ) *or* an IPv6 address received 838 from the wire (which may be subject to address forgery, etc.) (SIIT 839 behavior). The security issues that arise from the ambiguous 840 behavior when IPv4-mapped addresses are used on the wire include: 841 o If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in 842 the IPv6 source address field, he might be able to bypass a node's 843 access controls by deceiving applications into believing that the 844 packet is from the node itself (specifically, the IPv4 loopback 845 address, 127.0.0.1). The same attack might be performed using the 846 node's IPv4 interface address instead. 847 o If an attacker transmits an IPv6 packet with IPv4-mapped addresses 848 in the IPv6 destination address field corresponding to IPv4 849 addresses inside a site's security perimeter (e.g., ::ffff: 850 10.1.1.1), he might be able to bypass IPv4 packet filtering rules 851 and traverse a site's firewall. 852 o If an attacker transmits an IPv6 packet with IPv4-mapped addresses 853 in the IPv6 source and destination fields to a protocol that swaps 854 IPv6 source and destination addresses, he might be able to use a 855 node as a proxy for certain types of attacks. For example, this 856 might be used to construct broadcast multiplication and proxy TCP 857 port scan attacks. 859 In addition, special cases like these, while giving deployment 860 benefits in some areas, require a considerable amount of code 861 complexity (e.g., in the implementations of bind() system calls and 862 reverse DNS lookups) that is probably undesirable but can be managed 863 in this case. 865 In practice, although the packet translation mechanisms of SIIT are 866 specified for use in the Network Address Translator - Protocol 867 Translator (NAT-PT) [RFC2766], NAT-PT uses a mechanism different from 868 IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses 869 in IPv6 addresses. Also SIIT is not recommended for use as a 870 standalone transition mechanism. Given the issues that have been 871 identified, it seems appropriate that mapped addresses should not be 872 used on the wire. However, changing application behavior by 873 deprecating the use of mapped addresses in the operating system 874 interface would have significant impact on application porting 875 methods as described in [RFC4038] and it is expected that IPv4-mapped 876 IPv6 addresses will continue to be used within the API to aid 877 application portability. 879 Using the basic API behavior has some security implications in that 880 it adds additional complexity to address-based access controls. The 881 main issue that arises is that an IPv6 (AF_INET6) socket will accept 882 IPv4 packets even if the node has no IPv4 (AF_INET) sockets open. 883 This has to be taken into account by application developers and may 884 allow a malicious IPv4 peer to access a service even if there are no 885 open IPv4 sockets. This violates the security principle of "least 886 surprise". 888 2.3. Increased End-to-End Transparency 890 One of the major design aims of IPv6 has been to maintain the 891 original IP architectural concept of end-to-end transparency. 892 Transparency can help foster technological innovation in areas such 893 as peer-to-peer communication but maintaining the security of the 894 network at the same time requires some modifications in the network 895 architecture. Ultimately, it is also likely to need changes in the 896 security model as compared with the norms for IPv4 networks. 898 2.3.1. IPv6 Networks without NATs 900 The necessity of introducing Network Address Translators (NATs) into 901 IPv4 networks, resulting from a shortage of IPv4 addresses, has 902 removed the end-to-end transparency of most IPv4 connections: the use 903 of IPv6 would restore this transparency. However, the use of NATs, 904 and the associated private addressing schemes, has become 905 inappropriately linked to the provision of security in enterprise 906 networks. The restored end-to-end transparency of IPv6 networks can 907 therefore be seen as a threat by poorly informed enterprise network 908 managers. Some seem to want to limit the end-to-end capabilities of 909 IPv6, for example by deploying private, local addressing and 910 translators, even when it is not necessary because of the abundance 911 of IPv6 addresses. 913 Recommendations for designing an IPv6 network to meet the perceived 914 security and connectivity requirements implicit in the current usage 915 of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end 916 transparency are described in IPv6 Network Architecture Protection 917 [I-D.ietf-v6ops-nap]. 919 2.3.2. Enterprise Network Security Model for IPv6 921 The favored model for enterprise network security in IPv4 stresses 922 the use of a security perimeter policed by autonomous firewalls and 923 incorporating the NATs. Both perimeter firewalls and NATs introduce 924 asymmetry and reduce the transparency of communications through these 925 perimeters. The symmetric bidirectionality and transparency that are 926 extolled as virtues of IPv6 may seem to be at odds with this model. 928 Consequently network managers may even see them as undesirable 929 attributes, in conflict with their need to control threats to and 930 attacks on the networks they administer. 932 It is worth noting that IPv6 does not *require* end-to-end 933 connectivity. It merely provides end-to-end addressability; the 934 connectivity can still be controlled using firewalls (or other 935 mechanisms), and it is indeed wise to do so. 937 A number of matters indicate that IPv6 networks should migrate 938 towards an improved security model, which will increase the overall 939 security of the network while at the same time facilitating end-to- 940 end communication: 941 o Increased usage of end-to-end security especially at the network 942 layer. IPv6 mandates the provision of IPsec capability in all 943 nodes and increasing usage of end-to-end security is a challenge 944 to current autonomous firewalls that are unable to perform deep 945 packet inspection on encrypted packets. It is also incompatible 946 with NATs because they modify the packets, even when packets are 947 only authenticated rather than encrypted. 948 o Acknowledgement that over-reliance on the perimeter model is 949 potentially dangerous. An attacker who can penetrate today's 950 perimeters will have free rein within the perimeter, in many 951 cases. Also a successful attack will generally allow the attacker 952 to capture information or resources and make use of them. 953 o Development of mechanisms such as 'Trusted Computing' [TCGARCH] 954 that will increase the level of trust that network managers are 955 able to place on hosts. 956 o Development of centralized security policy repositories and secure 957 distribution mechanisms that, in conjunction with trusted hosts, 958 will allow network managers to place more reliance on security 959 mechanisms at the end points. The mechanisms are likely to 960 include end-node firewalling and intrusion detection systems as 961 well as secure protocols that allow end points to influence the 962 behavior of perimeter security devices. 963 o Review of the role of perimeter devices with increased emphasis on 964 intrusion detection, network resource protection and coordination 965 to thwart distributed denial of service attacks. 967 Several of the technologies required to support an enhanced security 968 model are still under development, including secure protocols to 969 allow end points to control firewalls: the complete security model 970 utilizing these technologies is now emerging but still requires some 971 development. 973 In the meantime, initial deployments will need to make use of similar 974 firewalling and intrusion detection techniques to IPv4 that may limit 975 end-to-end transparency temporarily, but should be prepared to use 976 the new security model as it develops and avoid the use of NATs by 977 the use of the architectural techniques described in 978 [I-D.ietf-v6ops-nap]. In particular, using NAT-PT [RFC2766] as a 979 general purpose transition mechanism should be avoided as it is 980 likely to limit the exploitation of end-to-end security and other 981 IPv6 capabilities in future as explained in 982 [I-D.ietf-v6ops-natpt-to-exprmntl]. 984 2.4. IPv6 in IPv6 Tunnels 986 IPv6 in IPv6 tunnels can be used to circumvent security checks, so it 987 is essential to filter packets both at tunnel ingress and egress 988 points (the encapsulator and decapsulator) to ensure that both the 989 inner and outer addresses are acceptable, and the tunnel is not being 990 used to carry inappropriate traffic. The security discussions in 991 [RFC3964], which is primarily about the 6to4 transition tunneling 992 mechanism (see Section 3.1) contains useful discussion of possible 993 attacks and ways to counteract these threats. 995 3. Issues Due to Transition Mechanisms 997 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues 999 The more complicated the IPv6 transition/co-existence becomes, the 1000 greater the danger that security issues will be introduced either 1001 o in the mechanisms themselves, 1002 o in the interaction between mechanisms, or 1003 o by introducing unsecured paths through multiple mechanisms. 1004 These issues may or may not be readily apparent. Hence it would be 1005 desirable to keep the mechanisms simple, as few in number as possible 1006 and built from as small pieces as possible to simplify analysis. 1008 One case where such security issues have been analyzed in detail is 1009 the 6to4 tunneling mechanism [RFC3964]. 1011 As tunneling has been proposed as a model for several more cases than 1012 are currently being used, its security properties should be analyzed 1013 in more detail. There are some generic dangers to tunneling: 1015 o it may be easier to avoid ingress filtering checks 1016 o it is possible to attack the tunnel interface: several IPv6 1017 security mechanisms depend on checking that Hop Limit equals 255 1018 on receipt and that link-local addresses are used. Sending such 1019 packets to the tunnel interface is much easier than gaining access 1020 to a physical segment and sending them there. 1022 o automatic tunneling mechanisms are typically particularly 1023 dangerous as there is no pre-configured association between end 1024 points. Accordingly, at the receiving end of the tunnel packets 1025 have to be accepted and decapsulated from any source. 1026 Consequently, special care should be taken when specifying 1027 automatic tunneling techniques. 1029 3.2. Automatic Tunneling and Relays 1031 Two mechanisms have been specified that use automatic tunneling and 1032 are intended for use outside a single domain. These mechanisms 1033 encapsulate the IPv6 packet directly in an IPv4 packet in the case of 1034 6to4 [RFC3056] or in an IPv4 UDP packet in the case of Teredo 1035 [RFC4380]. In each case packets can be sent and received by any 1036 similarly equipped nodes in the IPv4 Internet. 1038 As mentioned in Section 3.1, a major vulnerability in such approaches 1039 is that receiving nodes must allow decapsulation of traffic sourced 1040 from anywhere in the Internet. This kind of decapsulation function 1041 must be extremely well secured because of the wide range of potential 1042 sources. 1044 An even more difficult problem is how these mechanisms are able to 1045 establish communication with native IPv6 nodes or between the 1046 automatic tunneling mechanisms: such connectivity requires the use of 1047 some kind of "relay". These relays could be deployed in various 1048 locations such as: 1049 o all native IPv6 nodes, 1050 o native IPv6 sites, 1051 o in IPv6-enabled ISPs, or 1052 o just somewhere in the Internet. 1054 Given that a relay needs to trust all the sources (e.g., in the 6to4 1055 case, all 6to4 routers) that are sending it traffic, there are issues 1056 in achieving this trust and at the same time scaling the relay system 1057 to avoid overloading a small number of relays. 1059 As authentication of such a relay service is very difficult to 1060 achieve, and particularly so in some of the possible deployment 1061 models, relays provide a potential vehicle for address spoofing, 1062 (reflected) Denial-of-Service attacks, and other threats. 1064 Threats related to 6to4 and measures to combat them are discussed in 1065 [RFC3964]. [RFC4380] incorporates extensive discussion of the 1066 threats to Teredo and measures to combat them. 1068 3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 Network 1069 Security Assumptions 1071 NATs and firewalls have been deployed extensively in the IPv4 1072 Internet, as discussed in Section 2.3. Operators who deploy them 1073 typically have some security/operational requirements in mind (e.g., 1074 a desire to block inbound connection attempts), which may or may not 1075 be misguided. 1077 The addition of tunneling can change the security model that such 1078 deployments are seeking to enforce. IPv6-over-IPv4 tunneling using 1079 protocol 41 is typically either explicitly allowed, or disallowed 1080 implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes 1081 a more difficult problem as UDP must usually be allowed to pass 1082 through NATs and firewalls. Consequently, using UDP implies the 1083 ability to punch holes in NAT's and firewalls although, depending on 1084 the implementation, this ability may be limited or only achieved in a 1085 stateful manner. In practice, the mechanisms have been explicitly 1086 designed to traverse both NATs and firewalls in a similar fashion. 1088 One possible view is that use of tunneling is especially questionable 1089 in home and SOHO (small office/home office) environments where the 1090 level of expertise in network administration is typically not very 1091 high; in these environments the hosts may not be as tightly managed 1092 as in others (e.g., network services might be enabled unnecessarily), 1093 leading to possible security break-ins or other vulnerabilities. 1095 Holes allowing tunneled traffic through NATs and firewalls can be 1096 punched both intentionally and unintentionally. In cases where the 1097 administrator or user makes an explicit decision to create the hole, 1098 this is less of a problem, although (for example) some enterprises 1099 might want to block IPv6 tunneling explicitly if employees were able 1100 to create such holes without reference to administrators. On the 1101 other hand, if a hole is punched transparently, it is likely that a 1102 proportion of users will not understand the consequences: this will 1103 very probably result in a serious threat sooner or later. 1105 When deploying tunneling solutions, especially tunneling solutions 1106 that are automatic and/or can be enabled easily by users who do not 1107 understand the consequences, care should be taken not to compromise 1108 the security assumptions held by the users. 1110 For example, NAT traversal should not be performed by default unless 1111 there is a firewall producing a similar by-default security policy to 1112 that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is 1113 less of a problem, as it is easier to block if necessary; however, if 1114 the host is protected in IPv4, the IPv6 side should be protected as 1115 well. 1117 As is shown in Appendix A, it is relatively easy to determine the 1118 IPv6 address corresponding to an IPv4 address in tunneling 1119 deployments. It is therefore vital NOT to rely on "security by 1120 obscurity" i.e., assuming that nobody is able to guess or determine 1121 the IPv6 address of the host especially when using automatic 1122 tunneling transition mechanisms. 1124 The network architecture must provide separate IPv4 and IPv6 1125 firewalls with tunnelled IPv6 traffic arriving encapsulated in IPv4 1126 packets routed through the IPv4 firewall before being decapsulated, 1127 and then through the IPv6 firewall as shown in Figure 1. 1129 +--------+ +--------+ +--------+ 1130 Site | Native | IPv6 |v6 in v4| IPv4 | Native | Public 1131 Network <--->| IPv6 |<---->| Tunnel |<---->| IPv4 |<---> Internet 1132 |Firewall| |Endpoint| |Firewall| 1133 +--------+ +--------+ +--------+ 1135 Figure 1: Tunnelled Traffic and Firewalls 1137 4. Issues Due to IPv6 Deployment 1139 4.1. Avoiding the Trap of Insecure IPv6 Service Piloting 1141 Because IPv6 is a new service for many networks, network managers 1142 will often opt to make a pilot deployment in a part of the network to 1143 gain experience and understand the problems as well as the benefits 1144 that may result from a full production quality IPv6 service. 1146 Unless IPv6 service piloting is done in a manner that is as secure as 1147 possible there is a risk that if security in the pilot does not match 1148 up to what is achievable with current IPv4 production service the 1149 comparison can adversely impact the overall assessment of the IPv6 1150 pilot deployment. This may result in a decision to delay or even 1151 avoid deploying an IPv6 production service. For example, hosts and 1152 routers might not be protected by IPv6 firewalls, even if the 1153 corresponding IPv4 service is fully protected by firewalls. The use 1154 of tunneling transition mechanisms (see Section 3.3) and the 1155 interaction with virtual private networks also need careful attention 1156 to ensure that site security is maintained. This is particularly 1157 critical where IPv6 capabilities are turned on by default in new 1158 equipment or new releases of operating systems: network managers may 1159 not be fully aware of the security exposure that this creates. 1161 In some cases a perceived lack of availability of IPv6 firewalls and 1162 other security capabilities, such as intrusion detection systems may 1163 have lead network managers to resist any kind of IPv6 service 1164 deployment. These problems may be partly due to the relatively slow 1165 development and deployment of IPv6-capable security equipment, but 1166 the major problems appear to have been a lack of information, and 1167 more importantly a lack of documented operational experience on which 1168 managers can draw. In actual fact, as of the time of writing (2006) 1169 there are a significant number of alternative IPv6 packet filters and 1170 firewalls already in existence, which could be used for provide 1171 sufficient access controls. 1173 However, there are a small number of areas that where the available 1174 equipment and capabilities may still be a barrier to secure 1175 deployment as of the time of writing (2006): 1176 o 'Personal firewalls' with support for IPv6 and intended for use on 1177 hosts are not yet widely available. 1178 o Enterprise firewalls are at an early stage of development and may 1179 not provide the full range of capabilities needed to implement the 1180 necessary IPv6 filtering rules. Network managers often expect the 1181 same devices that support and are used for IPv4 today to also 1182 become IPv6-capable -- even though this is not really required and 1183 the equipment may not have the requisite hardware capabilities to 1184 support fast packet filtering for IPv6. Suggestions for the 1185 appropriate deployment of firewalls are given in Section 3.3 -- as 1186 will be seen from this section it is usually desirable that the 1187 firewalls are in separate boxes and there is no necessity for them 1188 to be same model of equipment. 1189 o A lesser factor may be that some design decisions in the IPv6 1190 protocol make it more difficult for firewalls to be implemented 1191 and work in all cases, and to be fully future proof (e.g., when 1192 new extension headers are used) as discussed in Section 2.1.9: it 1193 is significantly more difficult for intermediate nodes to process 1194 the IPv6 header chains than IPv4 packets. 1195 o Adequate Intrusion Detection Systems (IDS) are more difficult to 1196 construct for IPv6. IDSs are now beginning to become available 1197 but the pattern-based mechanisms used for IPv4 may not be the most 1198 appropriate for long-term development of these systems as end-to- 1199 end encryption becomes more prevalent. Future systems may be more 1200 reliant on traffic flow pattern recognition. 1201 o Implementations of high availability capabilities supporting IPv6 1202 are also in short supply. In particular, development of the IPv6 1203 version of the Virtual Router Redundancy Protocol (VRRP) 1204 [I-D.ietf-vrrp-ipv6-spec] has lagged the development of the main 1205 IPv6 protocol although alternatives may be available for some 1206 environments. 1208 In all these areas developments are ongoing and they should not be 1209 considered a long-term bar to the deployment of IPv6 either as a 1210 pilot or production service. The necessary tools are now available 1211 to make a secure IPv6 deployment and with careful selection of 1212 components and design of the network architecture a successful pilot 1213 or production IPv6 service can be deployed. Recommendations for 1214 secure deployment and appropriate management of IPv6 networks can be 1215 found in the documentation archives of the European Union 6net 1216 project [SIXNET] and in the Deployment Guide published by the IPv6 1217 Promotion Council of Japan [JpIPv6DC]. 1219 4.2. DNS Server Problems 1221 Some DNS server implementations have flaws that severely affect DNS 1222 queries for IPv6 addresses as discussed in [RFC4074]. These flaws 1223 can be used for DoS attacks affecting both IPv4 and IPv6 by inducing 1224 caching DNS servers to believe that a domain is broken and causing 1225 the server to block access to all requests for the domain for a 1226 precautionary period. 1228 4.3. Addressing Schemes and Securing Routers 1230 Whilst in general terms brute force scanning of IPv6 subnets is 1231 essentially impossible due to the enormously larger address space of 1232 IPv6 and the 64 bit interface identifiers (see Appendix A), this will 1233 be obviated if administrators do not take advantage of the large 1234 space to use unguessable interface identifiers. 1236 Because the unmemorability of complete IPv6 addresses there is a 1237 temptation for administrators to use small integers as interface 1238 identifiers when manually configuring them, as might happen on point- 1239 to-point links or when provisioning complete addresses from a DHCPv6 1240 server. Such allocations make it easy for an attacker to find active 1241 nodes that they can then port scan. 1243 To make use of the larger address space properly, administrators 1244 should be very careful when entering IPv6 addresses in their 1245 configurations (e.g., Access Control Lists), since numerical IPv6 1246 addresses are more prone to human error than IPv4 due to their length 1247 and unmemorability. 1249 It is also essential to ensure that the management interfaces of 1250 routers are well secured (e.g., allowing remote access using Secure 1251 Shell (SSH) only and ensuring that local craft interfaces have non- 1252 default passwords) as the router will usually contain a significant 1253 cache of neighbor addresses in its neighbor cache. 1255 4.4. Consequences of Multiple Addresses in IPv6 1257 One positive consequence of IPv6 is that nodes that do not require 1258 global access can communicate locally just by the use of a link-local 1259 address (if very local access is sufficient) or across the site by 1260 using a Unique Local Address (ULA). In either case it is easy to 1261 ensure that access outside the assigned domain of activity can be 1262 controlled by simple filters (which should be the default for link- 1263 locals). However, the security hazards of using link-local addresses 1264 for general purposes, as documented in Section 2.1.12, should be 1265 borne in mind. 1267 On the other hand, the possibility that a node or interface can have 1268 multiple global scope addresses makes access control filtering both 1269 on ingress and egress more complex and requires higher maintenance 1270 levels. Vendors and network administrators need to be aware that 1271 multiple addresses are the norm rather than the exception in IPv6: 1272 when building and selecting tools for security and management a 1273 highly desirable feature is the ability to be able to 'tokenize' 1274 access control lists and configurations in general to cater for 1275 multiple addresses and/or address prefixes. 1277 The addresses could be from the same network prefix (for example, 1278 privacy mechanisms [I-D.ietf-ipv6-privacy-addrs-v2] will periodically 1279 create new addresses taken from the same prefix and two or more of 1280 these may be active at the same time), or from different prefixes 1281 (for example, when a network is multihomed, when for management 1282 purposes a node belongs to several subnets on the same link or is 1283 implementing anycast services). In all these cases, it is possible 1284 that a single host could be using several different addresses with 1285 different prefixes and/or different interface identifiers. It would 1286 be desirable that the security administrator should be able to 1287 identify that the same host is behind all these addresses. 1289 Some network administrators may find the mutability of addresses when 1290 privacy mechanisms are used in their network to be undesirable 1291 because of the current difficulties in maintaining access control 1292 lists and knowing the origin of traffic. In general, disabling the 1293 use of privacy addresses is only possible if the full stateful DHCPv6 1294 mechanism [RFC3315] is used to allocate IPv6 addresses and DHCPv6 1295 requests for privacy addresses are not honored. 1297 4.5. Deploying ICMPv6 1299 In IPv4 it is commonly accepted that some filtering of ICMP packets 1300 by firewalls is essential to maintain security. Because of the 1301 extended use that is made of ICMPv6 [RFC2461] with a multitude of 1302 functions, the simple set of dropping rules that are usually applied 1303 in IPv4 need to be significantly developed for IPv6. The blanket 1304 dropping of all ICMP messages that is used in some very strict 1305 environments is simply not possible for IPv6. 1307 In an IPv6 firewall, policy needs to allow some messages through the 1308 firewall but also has to permit certain messages to and from the 1309 firewall, especially those with link-local sources on links to which 1310 the firewall is attached. These messages must be permitted to ensure 1311 that Neighbor Discovery [RFC2462], Multicast Listener Discovery 1312 [RFC2710], [RFC3810] and Stateless Address Configuration [RFC4443] 1313 work as expected. 1315 Recommendations for filtering ICMPv6 messages can be found in 1316 [I-D.ietf-v6ops-icmpv6-filtering-recs]. 1318 4.5.1. Problems Resulting from ICMPv6 Transparency 1320 As described in Section 4.5, certain ICMPv6 error packets need to be 1321 passed through a firewall in both directions. This means that some 1322 ICMPv6 error packets can be exchanged between inside and outside 1323 without any filtering. 1325 Using this feature, malicious users can communicate between the 1326 inside and outside of a firewall bypassing the administrator's 1327 inspection (proxy, firewall etc.). For example it might be possible 1328 to carry out a covert conversation through the payload of ICMPv6 1329 error messages or tunnel inappropriate encapsulated IP packets in 1330 ICMPv6 error messages. This problem can be alleviated by filtering 1331 ICMPv6 errors using a stateful packet inspection mechanism to ensure 1332 that the packet carried as a payload is associated with legitimate 1333 traffic to or from the protected network. 1335 4.6. IPsec Transport Mode 1337 IPsec provides security to end-to-end communications at the network 1338 layer (layer 3). The security features available include access 1339 control, connectionless integrity, data origin authentication, 1340 protection against replay attacks, confidentiality, and limited 1341 traffic flow confidentiality (see [RFC4301] section 2.1). IPv6 1342 mandates the implementation of IPsec in all conforming nodes, making 1343 the usage of IPsec to secure end-to-end communication possible in a 1344 way that is generally not available to IPv4. 1346 To secure IPv6 end-to-end communications, IPsec transport mode would 1347 generally be the solution of choice. However, use of these IPsec 1348 security features can result in novel problems for network 1349 administrators and decrease the effectiveness of perimeter firewalls 1350 because of the increased prevalence of encrypted packets on which the 1351 firewalls cannot perform deep packet inspection and filtering. 1353 One example of such problems is the lack of security solutions in the 1354 middlebox, including effective content-filtering, ability to provide 1355 DoS prevention based on the expected TCP protocol behavior, and 1356 intrusion detection. Future solutions to this problem are discussed 1357 in Section 2.3.2. Another example is an IPsec-based DoS (e.g., 1358 sending malformed ESP/AH packets) that can be especially detrimental 1359 to software-based IPsec implementations. 1361 4.7. Reduced Functionality Devices 1363 With the deployment of IPv6 we can expect the attachment of a very 1364 large number of new IPv6-enabled devices with scarce resources and 1365 low computing capacity. The resource limitations are generally 1366 because of a market requirement for cost reduction. Although the 1367 IPv6 Node Requirements [RFC4294] specifies some mandatory security 1368 capabilities for every conformant node, these do not include 1369 functions required for a node to be able to protect itself. 1370 Accordingly, some such devices may not be able even to perform the 1371 minimum set of functions required to protect themselves (e.g., 1372 'personal' firewall, automatic firmware update, enough CPU power to 1373 endure DoS attacks). This means a different security scheme may be 1374 necessary for such reduced functionality devices. 1376 4.8. Operational Factors when Enabling IPv6 in the Network 1378 There are a number of reasons that make it essential to take 1379 particular care when enabling IPv6 in the network equipment: 1381 Initially, IPv6-enabled router software may be less mature than 1382 current IPv4-only implementations and there is less experience with 1383 configuring IPv6 routing, which can result in disruptions to the IPv6 1384 routing environment and (IPv6) network outages. 1386 IPv6 processing may not happen at (near) line speed (or at a 1387 comparable performance level to IPv4 in the same equipment). A high 1388 level of IPv6 traffic (even legitimate, e.g., Network News Transport 1389 Protocol, NNTP) could easily overload IPv6 processing especially when 1390 it is software-based without the hardware support typical in high-end 1391 routers. This may potentially have deleterious knock-on effects on 1392 IPv4 processing, affecting availability of both services. 1393 Accordingly, if people don't feel confident enough in the IPv6 1394 capabilities of their equipment, they will be reluctant to enable it 1395 in their "production" networks. 1397 Sometimes essential features may be missing from early releases of 1398 vendors' software; an example is provision of software enabling IPv6 1399 telnet/SSH access (e.g., to the configuration application of a 1400 router), but without the ability to turn it off or limit access to 1401 it! 1403 Sometimes the default IPv6 configuration is insecure. For example, 1404 in one vendor's implementation, if you have restricted IPv4 telnet to 1405 only a few hosts in the configuration, you need to be aware that IPv6 1406 telnet will be automatically enabled, that the configuration commands 1407 used previously do not block IPv6 telnet, IPv6 telnet is open to the 1408 world by default, and that you have to use a separate command to also 1409 lock down the IPv6 telnet access. 1411 Many operator networks have to run interior routing protocols for 1412 both IPv4 and IPv6. It is possible to run the both in one routing 1413 protocol, or have two separate routing protocols; either approach has 1414 its tradeoffs [RFC4029]. If multiple routing protocols are used, one 1415 should note that this causes double the amount of processing when 1416 links flap or recalculation is otherwise needed -- which might more 1417 easily overload the router's CPU, causing slightly slower convergence 1418 time. 1420 4.9. Security Issues Due to Neighbor Discovery Proxies 1422 In order to span a single subnet over multiple physical links, a new 1423 experimental capability is being trialled in IPv6 to proxy Neighbor 1424 Discovery messages. A node with this capability will be called an 1425 NDProxy (see [RFC4389]. NDProxies are susceptible to the same 1426 security issues as the ones faced by hosts using unsecured Neighbor 1427 Discovery or ARP. These proxies may process unsecured messages, and 1428 update the neighbor cache as a result of such processing, thus 1429 allowing a malicious node to divert or hijack traffic. This may 1430 undermine the advantages of using SEND [RFC3971]. 1432 If a form of NDProxy is standardized, SEND will need to be extended 1433 to support this capability. 1435 5. IANA Considerations 1437 This memo does not contain any actions for IANA. 1439 6. Security Considerations 1441 This memo attempts to give an overview of security considerations of 1442 the different aspects of IPv6, particularly as they relate to the 1443 transition to a network in which IPv4- and IPv6-based communications 1444 need to coexist. 1446 7. Acknowledgements 1448 This document draws together the work of many people who have 1449 contributed security-related drafts to the ipv6 and v6ops working 1450 groups. Alain Durand, Alain Baudot, Luc Beloeil, Sharon Chisholm, 1451 Tim Chown, Lars Eggert, Andras Kis-Szabo, Vishwas Manral, Janos 1452 Mohacsi, Mark Smith, Alvaro Vives and Margaret Wassermann provided 1453 feedback to improve this document. Satoshi Kondo, Shinsuke Suzuki 1454 and Alvaro Vives provided additional inputs in cooperation with the 1455 Deployment Working Group of the Japanese IPv6 Promotion Council and 1456 the Euro6IX IST co-funded project, together with inputs from Jordi 1457 Palet, Brian Carpenter, and Peter Bieringer. Michael Wittsend and 1458 Michael Cole discussed issues relating to probing/mapping and 1459 privacy. Craig Metz and Jun-ichiro itojun Hagino did the original 1460 work identifying the problems of using IPv4-mapped IPv6 addresses on 1461 the wire. Vishwas Manral made further investigations of the impact 1462 of tiny fragments on IPv6 security. Francis Dupont raised the issues 1463 relating to IPv6 Privacy Addresses. Finally, Pekka Savola wrote a 1464 number of drafts on aspects IPv6 security which have been subsumed 1465 into this work. His draft on "Firewalling Considerations for IPv6" 1466 (draft-savola-v6ops-firewalling-02.txt) originally identified many of 1467 the issues with the base IPv6 specification which are documented 1468 here. 1470 8. References 1472 8.1. Normative References 1474 [I-D.ietf-ipv6-privacy-addrs-v2] 1475 Narten, T., "Privacy Extensions for Stateless Address 1476 Autoconfiguration in IPv6", 1477 draft-ietf-ipv6-privacy-addrs-v2-05 (work in progress), 1478 October 2006. 1480 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1481 Communication Layers", STD 3, RFC 1122, October 1989. 1483 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 1484 Assignments", RFC 2375, July 1998. 1486 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1487 (IPv6) Specification", RFC 2460, December 1998. 1489 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1490 Discovery for IP Version 6 (IPv6)", RFC 2461, 1491 December 1998. 1493 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1494 Autoconfiguration", RFC 2462, December 1998. 1496 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1497 Listener Discovery (MLD) for IPv6", RFC 2710, 1498 October 1999. 1500 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1501 via IPv4 Clouds", RFC 3056, February 2001. 1503 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1504 in IPv6", RFC 3775, June 2004. 1506 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1507 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1509 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1510 6to4", RFC 3964, December 2004. 1512 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1513 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1514 March 2005. 1516 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1517 Architecture", RFC 4291, February 2006. 1519 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1520 Network Address Translations (NATs)", RFC 4380, 1521 February 2006. 1523 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1524 Message Protocol (ICMPv6) for the Internet Protocol 1525 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1527 8.2. Informative References 1529 [FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc. 1530 Second Internet Measurement Workshop , November 2002, 1531 . 1533 [I-D.ietf-tcpm-icmp-attacks] 1534 Gont, F., "ICMP attacks against TCP", 1535 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 1536 February 2006. 1538 [I-D.ietf-v6ops-icmpv6-filtering-recs] 1539 Davies, E. and J. Mohacsi, "Recommendations for Filtering 1540 ICMPv6 Messages in Firewalls", 1541 draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in 1542 progress), July 2006. 1544 [I-D.ietf-v6ops-nap] 1545 Velde, G., "Network Architecture Protection for IPv6", 1546 draft-ietf-v6ops-nap-04 (work in progress), October 2006. 1548 [I-D.ietf-v6ops-natpt-to-exprmntl] 1549 Aoun, C. and E. Davies, "Reasons to Move NAT-PT to 1550 Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work 1551 in progress), October 2005. 1553 [I-D.ietf-v6ops-scanning-implications] 1554 Chown, T., "IPv6 Implications for Network Scanning", 1555 draft-ietf-v6ops-scanning-implications-00 (work in 1556 progress), June 2006. 1558 [I-D.ietf-vrrp-ipv6-spec] 1559 Hinden, R., "Virtual Router Redundancy Protocol for IPv6", 1560 draft-ietf-vrrp-ipv6-spec-07 (work in progress), 1561 October 2004. 1563 [IEEE.802-1X.2004] 1564 Institute of Electrical and Electronics Engineers, "Port- 1565 Based Network Access Control", IEEE Standard for Local and 1566 Metropolitan Area Networks 802.1X-2004, December 2004. 1568 [JpIPv6DC] 1569 Deployment WG, "IPv6 Deployment Guideline (2005 Edition)", 1570 IPv6 Promotion Council (Japan) Deployment Working Group, 1571 2005, . 1573 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1574 Considerations for IP Fragment Filtering", RFC 1858, 1575 October 1995. 1577 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1578 (SIIT)", RFC 2765, February 2000. 1580 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1581 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1582 February 2000. 1584 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1585 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1587 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1588 and M. Carney, "Dynamic Host Configuration Protocol for 1589 IPv6 (DHCPv6)", RFC 3315, July 2003. 1591 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1593 Stevens, "Basic Socket Interface Extensions for IPv6", 1594 RFC 3493, February 2003. 1596 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1597 Discovery (ND) Trust Models and Threats", RFC 3756, 1598 May 2004. 1600 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1601 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1603 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1604 Material in DNS", RFC 4025, March 2005. 1606 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 1607 Savola, "Scenarios and Analysis for Introducing IPv6 into 1608 ISP Networks", RFC 4029, March 2005. 1610 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 1611 Castro, "Application Aspects of IPv6 Transition", 1612 RFC 4038, March 2005. 1614 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 1615 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 1617 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1618 More-Specific Routes", RFC 4191, November 2005. 1620 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1621 Nordmark, "Mobile IP Version 6 Route Optimization Security 1622 Design Background", RFC 4225, December 2005. 1624 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 1625 April 2006. 1627 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1628 Internet Protocol", RFC 4301, December 2005. 1630 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 1631 Sharing", RFC 4311, November 2005. 1633 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1634 Proxies (ND Proxy)", RFC 4389, April 2006. 1636 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 1637 Considerations and Issues with IPv6 DNS", RFC 4472, 1638 April 2006. 1640 [SIXNET] 6Net, "Large Scale International IPv6 Pilot Network", EU 1641 Information Society Technologies Project , 2005, 1642 . 1644 [TCGARCH] The Trusted Computing Group, "TCG Specification 1645 Architecture Overview", April 2004, . 1649 Appendix A. IPv6 Probing/Mapping Considerations 1651 One school of thought wanted the IPv6 numbering topology (either at 1652 network or node level) to match IPv4 as exactly as possible, whereas 1653 others see IPv6 as giving more flexibility to the address plans, not 1654 wanting to constrain the design of IPv6 addressing. Mirroring the 1655 address plans is now generally seen as a security threat because an 1656 IPv6 deployment may have different security properties from IPv4. 1658 Given the relatively immature state of IPv6 network security, if an 1659 attacker knows the IPv4 address of the node and believes it to be 1660 dual-stacked with IPv4 and IPv6, he might want to try to probe the 1661 corresponding IPv6 address, based on the assumption that the security 1662 defenses might be lower. This might be the case particularly for 1663 nodes which are behind a NAT in IPv4, but globally addressable in 1664 IPv6. Naturally, this is not a concern if similar and adequate 1665 security policies are in place. 1667 On the other hand, brute-force scanning or probing of addresses is 1668 computationally infeasible due to the large search space of interface 1669 identifiers on most IPv6 subnets (somewhat less than 64 bits wide, 1670 depending on how identifiers are chosen), always provided that 1671 identifiers are chosen at random out of the available space, as 1672 discussed in [I-D.ietf-v6ops-scanning-implications]. 1674 For example, automatic tunneling mechanisms typically use 1675 deterministic methods for generating IPv6 addresses, so probing/ 1676 port-scanning an IPv6 node is simplified. The IPv4 address is 1677 embedded at least in 6to4, Teredo and ISATAP addresses. 1678 Additionally, it is possible (in the case of 6to4 in particular) to 1679 learn the address behind the prefix; for example, Microsoft 6to4 1680 implementation uses the address 2002:V4ADDR::V4ADDR while older Linux 1681 and FreeBSD implementations default to 2002:V4ADDR::1. This could 1682 also be used as one way to identify an implementation and hence 1683 target any specific weaknesses. 1685 One proposal has been to randomize the addresses or subnet identifier 1686 in the address of the 6to4 router. This does not really help, as the 1687 6to4 router (whether a host or a router) will return an ICMPv6 Hop 1688 Limit Exceeded message, revealing the IP address. Hosts behind the 1689 6to4 router can use methods such as privacy addresses 1690 [I-D.ietf-ipv6-privacy-addrs-v2]to conceal themselves, provided that 1691 they are not meant to be reachable by sessions started from 1692 elsewhere: they would still require a globally accessible static 1693 address if they wish to receive communications initiated elsewhere. 1695 To conclude, it seems that when an automatic tunneling mechanism is 1696 being used, given an IPv4 address, the corresponding IPv6 address 1697 could possibly be guessed with relative ease. This has significant 1698 implications if the IPv6 security policy is less adequate than that 1699 for IPv4. 1701 Appendix B. IPv6 Privacy Considerations 1703 The generation of IPv6 addresses from MAC addresses potentially 1704 allows the behavior of users to be tracked in a way which may 1705 infringe their privacy. [I-D.ietf-ipv6-privacy-addrs-v2] specifies 1706 mechanisms which can be used to reduce the risk of infringement. It 1707 has also been claimed that IPv6 harms the privacy of the user, either 1708 by exposing the MAC address, or by exposing the number of nodes 1709 connected to a site. 1711 Additional discussion of privacy issues can be found in the IPv6 1712 Network Architecture Protection document [I-D.ietf-v6ops-nap]. 1714 B.1. Exposing MAC Addresses 1716 Using stateless address autoconfiguration results in the MAC address 1717 being incorporated in an EUI64 that exposes the model of network 1718 card. The concern has been that a user might not want to expose the 1719 details of the system to outsiders, e.g., fearing a resulting 1720 burglary if a thief identifies expensive equipment from the vendor 1721 identifier embedded in MAC addresses, or allowing the type of 1722 equipment in use to be identified so facilitating an attack on 1723 specific security weaknesses. 1725 In most cases, this seems completely unfounded. First, such an 1726 address must be learned somehow -- this is a non-trivial process; the 1727 addresses are visible e.g., in web site access logs, but the chances 1728 that a random web site owner is collecting this kind of information 1729 (or whether it would be of any use) are quite slim. Being able to 1730 eavesdrop the traffic to learn such addresses (e.g., by the 1731 compromise of DSL (Digital Subscriber Line) or Cable modem physical 1732 media) seems also quite far-fetched. Further, using statically 1733 configured interface identifiers or privacy addresses 1734 [I-D.ietf-ipv6-privacy-addrs-v2] for such purposes is straightforward 1735 if worried about the risk. Second, the burglar would have to be able 1736 to map the IP address to the physical location; typically this would 1737 only be possible with information from the private customer database 1738 of the Internet Service Provider (ISP) and, for large sites, the 1739 administrative records of the site, although some physical address 1740 information may be available from the WHOIS database of Internet 1741 registries. 1743 B.2. Exposing Multiple Devices 1745 Another concern that has been aired involves the user wanting to 1746 conceal the presence of a large number of computers or other devices 1747 connected to a network; NAT can "hide" all this equipment behind a 1748 single address, but is not perfect either [FNAT]. 1750 One practical reason why some administrators may find this desirable 1751 is being able to thwart certain ISPs' business models. These models 1752 require payment based on the number of connected computers, rather 1753 than the connectivity as a whole. 1755 Similar feasibility issues as described above apply. To a degree, 1756 the number of machines present could be obscured by the sufficiently 1757 frequent re-use of privacy addresses [I-D.ietf-ipv6-privacy-addrs-v2] 1758 -- that is, if during a short period, dozens of generated addresses 1759 seem to be in use, it's difficult to estimate whether they are 1760 generated by just one host or multiple hosts. 1762 B.3. Exposing the Site by a Stable Prefix 1764 When an ISP provides IPv6 connectivity to its customers, including 1765 home or consumer users, it delegates a fixed global routing prefix 1766 (usually a /48) to them. This is in contrast to the typical IPv4 1767 situation where home users typically receive a dynamically allocated 1768 address that may be stable only for period of hours. 1770 Due to this fixed allocation, it is easier to correlate the global 1771 routing prefix to a network site. In case of consumer users, this 1772 correlation leads to a privacy issue, since a site is often 1773 equivalent to an individual or a family in such a case. Consequently 1774 some users might be concerned about being able to be tracked based on 1775 their /48 allocation if it is static 1776 [I-D.ietf-ipv6-privacy-addrs-v2]. On the other hand many users may 1777 find having a static allocation desirable as it allows them to offer 1778 services hosted in their network more easily. 1780 This situation is not affected even if a user changes his/her 1781 interface ID or subnet ID, because malicious users can still discover 1782 this binding. On larger sites the situation can be mitigated by 1783 using "untraceable" IPv6 addresses as described in 1784 [I-D.ietf-v6ops-nap] and it is possible that in future ISPs might be 1785 prepared to offer untraceable addresses to their consumer customers 1786 to minimize the privacy issues. 1788 This privacy issue is common to both IPv4 and IPv6 and is inherent in 1789 the use of IP addresses as both identifiers for node interfaces and 1790 locators for the nodes. 1792 Authors' Addresses 1794 Elwyn B. Davies 1795 Consultant 1796 Soham, Cambs 1797 UK 1799 Phone: +44 7889 488 335 1800 Email: elwynd@dial.pipex.com 1802 Suresh Krishnan 1803 Ericsson 1804 8400 Decarie Blvd. 1805 Town of Mount Royal, QC H4P 2N2 1806 Canada 1808 Phone: +1 514-345-7900 1809 Email: suresh.krishnan@ericsson.com 1811 Pekka Savola 1812 CSC/Funet 1814 Email: psavola@funet.fi 1816 Full Copyright Statement 1818 Copyright (C) The Internet Society (2006). 1820 This document is subject to the rights, licenses and restrictions 1821 contained in BCP 78, and except as set forth therein, the authors 1822 retain all their rights. 1824 This document and the information contained herein are provided on an 1825 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1826 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1827 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1828 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1829 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1832 Intellectual Property 1834 The IETF takes no position regarding the validity or scope of any 1835 Intellectual Property Rights or other rights that might be claimed to 1836 pertain to the implementation or use of the technology described in 1837 this document or the extent to which any license under such rights 1838 might or might not be available; nor does it represent that it has 1839 made any independent effort to identify any such rights. Information 1840 on the procedures with respect to rights in RFC documents can be 1841 found in BCP 78 and BCP 79. 1843 Copies of IPR disclosures made to the IETF Secretariat and any 1844 assurances of licenses to be made available, or the result of an 1845 attempt made to obtain a general license or permission for the use of 1846 such proprietary rights by implementers or users of this 1847 specification can be obtained from the IETF on-line IPR repository at 1848 http://www.ietf.org/ipr. 1850 The IETF invites any interested party to bring to its attention any 1851 copyrights, patents or patent applications, or other proprietary 1852 rights that may cover technology that may be required to implement 1853 this standard. Please address the information to the IETF at 1854 ietf-ipr@ietf.org. 1856 Acknowledgment 1858 Funding for the RFC Editor function is provided by the IETF 1859 Administrative Support Activity (IASA).