idnits 2.17.1 draft-ietf-v6ops-security-overview-00.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 1476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1466. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (May 12, 2005) is 6922 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2710' is defined on line 1157, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dnsop-misbehavior-against-aaaa' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-ndproxy' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-v6onbydefault' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'I-D.savola-v6ops-6bone-mess' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: 'RFC4038' is defined on line 1306, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2375 ** 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 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3964 == Outdated reference: A later version (-02) exists of draft-chown-v6ops-port-scanning-implications-01 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-ipv6-dns-issues-10 == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-ndproxy-01 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-02 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-nap-00 == Outdated reference: A later version (-05) exists of draft-krishnan-ipv6-hopbyhop-00 == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-02 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) Summary: 13 errors (**), 0 flaws (~~), 17 warnings (==), 9 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 Expires: November 13, 2005 S. Krishnan 5 Ericsson 6 P. Savola 7 CSC/Funet 8 May 12, 2005 10 IPv6 Transition/Co-existence Security Considerations 11 draft-ietf-v6ops-security-overview-00.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 November 13, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . 4 59 2.1.1 Routing Headers and Hosts . . . . . . . . . . . . . . 4 60 2.1.2 Routing Headers for Mobile IPv6 and Other Purposes . . 5 61 2.1.3 Site-scope Multicast Addresses . . . . . . . . . . . . 5 62 2.1.4 ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 6 63 2.1.5 Anycast Traffic Identification and Security . . . . . 7 64 2.1.6 Address Privacy Extensions Interact with DDoS 65 Defenses . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1.7 Dynamic DNS: Stateless Address Auto-Configuration, 67 Privacy Extensions and SEND . . . . . . . . . . . . . 8 68 2.1.8 Extension Headers . . . . . . . . . . . . . . . . . . 8 69 2.1.9 Fragmentation: Reassembly and Deep Packet Inspection . 10 70 2.1.10 Fragmentation Related DoS Attacks . . . . . . . . . 11 71 2.1.11 Link-Local Addresses and Securing Neighbor 72 Discovery . . . . . . . . . . . . . . . . . . . . . 11 73 2.1.12 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 13 74 2.2 IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 13 75 2.3 Increased End-to-End Transparency . . . . . . . . . . . . 14 76 2.3.1 IPv6 Networks without NATs . . . . . . . . . . . . . . 14 77 2.3.2 Enterprise Network Security Model for IPv6 . . . . . . 15 78 3. Issues Due to Transition Mechanisms . . . . . . . . . . . . 16 79 3.1 IPv6 Transition/Co-existence Mechanism-specific Issues . . 16 80 3.2 Automatic Tunneling and Relays . . . . . . . . . . . . . . 16 81 3.3 Tunneling May Break Security Assumptions . . . . . . . . . 17 82 4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . 18 83 4.1 IPv6 Service Piloting Done Insecurely . . . . . . . . . . 18 84 4.2 Enabling IPv6 by Default Reduces Usability . . . . . . . . 19 85 4.3 Addressing Schemes and Securing Routers . . . . . . . . . 20 86 4.4 Consequences of Multiple Addresses in IPv6 . . . . . . . . 20 87 4.5 Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 21 88 4.5.1 Problems Resulting from ICMPv6 Transparency . . . . . 22 89 4.6 IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 22 90 4.7 Reduced Functionality Devices . . . . . . . . . . . . . . 23 91 4.8 Operational Factors when Enabling IPv6 in the Network . . 23 92 4.9 Ingress Filtering Issues Due to Privacy Addresses . . . . 24 93 4.10 Security Issues Due to ND Proxies . . . . . . . . . . . 24 94 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 95 6. Security Considerations . . . . . . . . . . . . . . . . . . 25 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 7.1 Normative References . . . . . . . . . . . . . . . . . . . 25 98 7.2 Informative References . . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 100 A. IPv6 Probing/Mapping Considerations . . . . . . . . . . . . 29 101 B. IPv6 Privacy Considerations . . . . . . . . . . . . . . . . 30 102 B.1 Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 30 103 B.2 Exposing Multiple Devices . . . . . . . . . . . . . . . . 31 104 B.3 Exposing the Site by a Stable Prefix . . . . . . . . . . . 31 105 Intellectual Property and Copyright Statements . . . . . . . 32 107 1. Introduction 109 The transition from a pure IPv4 network to a network where IPv4 and 110 IPv6 co-exist brings a number of extra security considerations that 111 need to be taken into account when deploying IPv6 and operating the 112 dual-protocol network with its associated transition mechanisms. 113 This document attempts to give an overview of the various issues 114 grouped into three categories: 115 o issues due to the IPv6 protocol itself, 116 o issues due to transition mechanisms, and 117 o issues due to IPv6 deployment. 119 It is important to understand that we have to be concerned not about 120 replacing IPv4 with IPv6 (in the short term), but with adding IPv6 to 121 be operated in parallel with IPv4 [I-D.savola-v6ops-transarch]. 123 This document also describes two matters which have have been wrongly 124 identified as potential security concerns for IPv6 in the past and 125 explains why they are unlikely to cause problems: considerations 126 about probing/mapping IPv6 addresses (Appendix A), and considerations 127 with respect to privacy in IPv6 (Appendix B). 129 2. Issues Due to IPv6 Protocol 131 2.1 IPv6 Protocol-specific Issues 133 There are significant differences between the features of IPv6 and 134 IPv4: some of these specification changes may result in potential 135 security issues. Several of these issues have been discussed in 136 separate drafts but are summarised here to avoid normative references 137 which may not become RFCs. The following specification-related 138 problems have been identified, but this is not necessarily a complete 139 list: 141 2.1.1 Routing Headers and Hosts 143 All IPv6 nodes must be able to process Routing Headers [RFC2460]. 144 This RFC can be interpreted, although it is not clearly stated, to 145 mean that all nodes (including hosts) must have this processing 146 enabled. This can result in hosts forwarding received traffic if 147 there are segments left in the Routing Header when it arrives at the 148 host. 150 A number of potential security issues associated with this behavior 151 were documented in [I-D.savola-ipv6-rh-hosts]. Some of these issues 152 have been resolved (a separate routing header type is now used for 153 Mobile IPv6 [RFC3775] and ICMP Traceback has not been standardized), 154 but two issues remain: 156 o Routing headers can be used to evade access controls based on 157 destination addresses. This could be achieved by sending a packet 158 ostensibly to a publically accessible host address but with a 159 routing header which will cause the publically accessible host to 160 forward the packet to a destination which would have been 161 forbidden by the packet filters if the address had been in the 162 destination field when the packet was checked. 163 o If the packet source address in the previous case can be spoofed, 164 any host could be used to mediate an anonymous reflection denial- 165 of-service attack by having any publically accessible host 166 redirect the attack packets. 168 2.1.2 Routing Headers for Mobile IPv6 and Other Purposes 170 In addition to the basic Routing Header (Type 0), which is intended 171 to influence the trajectory of a packet through a network by 172 specifying a sequence of router 'waypoints', Routing Header (Type 2) 173 has been defined as part of the Mobile IPv6 specifications in 174 [RFC3775]. The Type 2 Routing Header is intended for use by hosts to 175 handle 'interface local' forwarding needed when packets are sent to 176 the care-of address of a mobile node which is away from its home 177 address. 179 It is important that nodes treat the different types of routing 180 header appropriately. It should be possible to apply separate 181 filtering rules to the different types of Routing Header. By design 182 hosts must process Type 2 Routing Headers to support Mobile IPv6 but 183 routers should not: to avoid the issues in Section 2.1.1 it may be 184 desirable to forbid or limit the processing of Type 0 Routing Headers 185 in hosts and some routers. 187 Routing Headers are an extremely powerful and general capability. 188 Alternative future uses of Routing Headers need to be carefully 189 assessed to ensure that they do not open new avenues of attack that 190 can be exploited. 192 2.1.3 Site-scope Multicast Addresses 194 IPv6 supports multicast addresses with site scope which can 195 potentially allow an attacker to identify certain important resources 196 on the site if misused. 198 Particular examples are the 'all routers' (FF05::2) and 'all DHCP 199 servers' (FF05::1:3) addresses defined in [RFC2375]: an attacker that 200 is able to infiltrate a message destined for these addresses on to 201 the site will potentially receive in return information identifying 202 key resources on the site. This information can then be the target 203 of directed attacks ranging from simple flooding to more specific 204 mechanisms designed to subvert the device. 206 Some of these addresses have current legitimate uses within a site. 207 The risk can be minimised by ensuring that all firewalls and site 208 boundary routers are configured to drop packets with site scope 209 destination addresses. Also nodes should not join multicast groups 210 for which there is no legitimate use on the site and site routers 211 should be configured to drop packets directed to these unused 212 addresses. 214 2.1.4 ICMPv6 and Multicast 216 It is possible to launch a denial-of-service (DoS) attack using IPv6 217 which could be amplified by the multicast infrastructure. 219 Unlike ICMP for IPv4, ICMPv6 [RFC2463] allows error notification 220 responses to be sent when certain unprocessable packets are sent to 221 multicast addresses. 223 The cases in which responses are sent are: 224 o The received packet is longer than the next link MTU: 'Packet Too 225 Big' responses are needed to support Path MTU Discovery for 226 multicast traffic. 227 o The received packet contains an unrecognised option in a hop-by- 228 hop or destination options extension header with the first two 229 bits of the option type set to binary '10': 'Parameter Problem' 230 responses are intended to inform the source that some or all of 231 the receipients cannot handle the option in question. 233 If an attacker can craft a suitable packet sent to a multicast 234 destination, it may be possible to elicit multiple responses directed 235 at the victim (the spoofed source of the multicast packet). On the 236 other hand, the use of 'reverse path forwarding' checks to eliminate 237 loops in multicast forwarding automatically limits the range of 238 addresses which can be spoofed. 240 In practice an attack using oversize packets is unlikely to cause 241 much amplification unless the attacker is able to carefully tune the 242 packet size to exploit a network with smaller MTU in the edge than 243 the core. Similarly a packet with an unrecognised hop-by-hop option 244 would be dropped by the first router. However a packet with an 245 unrecognised destination option could generate multiple responses. 247 In addition to amplification, this kind of attack would potentially 248 consume large amounts of forwarding state resources in routers on 249 multicast-enabled networks. These attacks are discussed in more 250 detail in [I-D.savola-v6ops-firewalling]. 252 2.1.5 Anycast Traffic Identification and Security 254 IPv6 introduces the notion of anycast addresses and services. 255 Originally the IPv6 standards diasallowed using an anycast address as 256 the source address of a packet, so that responses from an anycast 257 server would supply a unicast address for the server in responses. 258 To avoid exposing knowledge about the internal structure of the 259 network, it is recommended that anycast servers now take advantage of 260 the ability to return responses with the anycast address as the 261 source address if possible. 263 If the server needs to use a unicast address for any reason, it may 264 be desirable to consider using specialised addresses for anycast 265 servers which are not used for any other part of the network to 266 restrict the information exposed. Alternatively operators may wish 267 to restrict the use of anycast services from outside the domain, thus 268 requiring firewalls to filter anycast requests. For this purpose, 269 firewalls need to know which addresses are being used for anycast 270 services: these addresses are arbitrary and look just like any other 271 IPv6 unicast address. 273 One particular class of anycast addresses that should be given 274 special attention is the set of Subnet-Router anycast addresses 275 defined in The IPv6 Addressing Architecture [RFC3513]. All routers 276 are required to support these addresses for all subnets for which 277 they have interfaces. For most subnets using global unicast 278 addresses, filtering anycast requests to these addresses can be 279 achieved by dropping packets with the lower 64 bits (the Interface 280 Identifier) set to all zeroes. 282 2.1.6 Address Privacy Extensions Interact with DDoS Defenses 284 The purpose of the privacy extensions for stateless address auto- 285 configuration [RFC3041] is to change the interface identifier (and 286 hence the global scope addresses generated from it) from time to time 287 in order to make it more difficult for eavesdroppers and other 288 information collectors to identify when different addresses used in 289 different transactions actually correspond to the same node. 291 The security issue resulting from this is that if the frequency of 292 change of the addresses used by a node is sufficiently great to 293 achieve the intended aim of the privacy extensions, the observed 294 behavior of the node could look very like that of a compromised node 295 which was being used as the source of a distributed denial-of-service 296 (DDoS). It would thus be difficult to for any future defenses 297 against DDoS attacks to distinguish between a high rate change of 298 addresses resulting from genuine use of the privacy extensions and a 299 compromised node being used as the source of a DDoS with 'in-prefix' 300 spoofed source addresses as described in [I-D.dupont-ipv6- 301 rfc3041harmful]. 303 Even if a node is well behaved, the change in the address could make 304 it harder for a security administrator to define a policy rule (e.g. 305 access control list) that takes into account a specific node. 307 2.1.7 Dynamic DNS: Stateless Address Auto-Configuration, Privacy 308 Extensions and SEND 310 The introduction of Stateless Address Auto-Configuration (SLAAC) 311 [RFC2462] with IPv6 provides an additional challenge to the security 312 of Dynamic DNS (DDNS). With manual addressing or the use of DHCP, 313 the number of security associations that need to be maintained to 314 secure access to the DNS server is limited, assuming any necessary 315 updates are carried out by the DHCP server. This is true equally for 316 IPv4 and IPv6. 318 Since SLAAC does not make use of a single and potentially trusted 319 DHCP server, but depends on the node obtaining the address, securing 320 the insertion of updates into DDNS may need a security association 321 between each node and the DDNS server. This is discussed further in 322 [I-D.ietf-dnsop-ipv6-dns-issues]. 324 Using the Privacy Extensions to SLAAC [RFC3041] may significantly 325 increase the rate of updates of DDNS. Even if a node using the 326 Privacy Extensions does not publish its address for 'forward' lookup 327 (as that would effectively compromise the privacy which it is 328 seeking), it may still need to update the reverse DNS records so that 329 reverse routability checks can be carried out. If the rate of change 330 needed to achieve real privacy has to be increased as is mentioned in 331 Section 2.1.6 the update rate for DDNS may be excessive. 333 Similarly, the cryptographically generated addresses used by SEND 334 [RFC3971] are expected to be periodically regenerated in line with 335 recommendations for maximum key lifetimes. This regeneration could 336 also impose a significant extra load on DDNS. 338 2.1.8 Extension Headers 340 A number of issues relating to the specification of IPv6 Extension 341 headers have been identified. Several of these are discussed in 342 [I-D.savola-v6ops-firewalling]. 344 2.1.8.1 Processing Extension Headers in Middleboxes 346 In IPv4 deep packet inspection techniques are used to implement 347 policing and filtering both as part of routers and in middleboxes 348 such as firewalls. Fully extending these techniques to IPv6 would 349 require inspection of all the extension headers in a packet to ensure 350 that policy constraints on the use of certain headers and options 351 were enforced and to remove packets containing potentially damaging 352 unknown options at the earliest opportunity. 354 This requirement appears to conflict with Section 4 of the IPv6 355 specification in [RFC2460] which requires that destination options 356 are not processed at all until the packet reaches the appropriate 357 destination (either the final destination or a routing header 358 waypoint). 360 Also [RFC2460] forbids processing the headers other than in the order 361 in which they appear in the packet. 363 A further ambiguity relates to whether an intermediate node should 364 discard a packet which contains a header or destination option which 365 it does not recognise. If the rules above are followed slavishly, it 366 is not (or may not be) legitimate for the intermediate node to 367 discard the packet because it should not be processing those headers 368 or options. 370 [RFC2460] therefore does not appear to take account of the behavior 371 of middleboxes and other non-final destinations which may be 372 inspecting the packet, and thereby potentially limits the security 373 protection of these boxes. 375 2.1.8.2 Processing Extension Header Chains 377 There is a further problem for middleboxes that want to examine the 378 transport headers which are located at the end of the IPv6 header 379 chain. In order to locate the transport header or other protocol 380 data unit, the node has to parse the header chain. 382 The IPv6 specification [RFC2460] does not mandate the use of the 383 Type-Length-Value format with a fixed layout for the start of each 384 header although it is used for the majority of headers currently 385 defined. (Only the Type field is guaranteed in size and offset). 386 For example the fragment header does not conform to the TLV format 387 used for all the other headers. 389 A middlebox cannot therefore guarantee to be able to process header 390 chains which may contain headers defined after the box was 391 manufactured. As noted in Section 2.1.8.1, middleboxes ought not to 392 have to know about all header types in use but still need to be able 393 to skip over such headers to find the transport PDU start. This 394 either limits the security which can be applied in firewalls or makes 395 it difficult to deploy new extension header types. 397 Destination Options may also contain unknown options. However, the 398 options are encoded in TLV format so that intermediate nodes can skip 399 over them during processing, unlike the enclosing extension headers. 401 2.1.8.3 Unknown Headers/Destination Options and Security Policy 403 A strict security policy might dictate that packets containing either 404 unknown headers or destination options are discarded by firewalls or 405 other filters. This requires the firewall to process the whole 406 extension header chain which may be currently in conflict with the 407 IPv6 specification as discussed in Section 2.1.8.1. 409 Even if the firewall does inspect the whole header chain, it may not 410 be sensible to discard packets with items unrecognised by the 411 firewall because the intermediate node has no knowledge of which 412 options and headers are implemented in the destination node. Hence 413 it is highly desirable to make the discard policy configurable to 414 avoid firewalls dropping packets with legitimate items that they do 415 not recognise because their hardware or software is not aware of a 416 new definition. 418 2.1.8.4 Excessive Hop-by-Hop Options 420 IPv6 does not limit the number of hop by hop options which can be 421 present in a hop-by-hop option header. This can be used for mounting 422 denial of service attacks affecting all nodes on a path as described 423 in [I-D.krishnan-ipv6-hopbyhop]. 425 2.1.8.5 Overuse of Router Alert Option 427 The IPv6 router alert option specifies a hop-by-hop option that, if 428 present, signals the router to take a closer look at the packet. 429 This can be used for denial of service attacks. By sending a large 430 number of packets with the router alert option present an attacker 431 can deplete the processor cycles on the routers available to 432 legitimate traffic. 434 2.1.9 Fragmentation: Reassembly and Deep Packet Inspection 436 The current specifications of IPv6 in [RFC2460] do not mandate any 437 minimum packet size for the fragments of a packet before the last 438 one, except for the need to carry the unfragmentable part in all 439 fragments. 441 The unfragmentable part does not include the transport port numbers 442 so that it is possible that the first fragment does not contain 443 sufficient information to carry out deep packet inspection involving 444 the port numbers. 446 Also the reassembly rules for fragmented packets in [RFC2460] do not 447 mandate behavior which would minimise the effects of overlapping 448 fragments. 450 Depending on the implementation of packet reassembly and the 451 treatment of packet fragments in firewalls and other nodes which use 452 deep packet inspection for traffic filtering, this potentially leaves 453 IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128] 454 for IPv4. 456 There is no reason to allow overlapping packet fragments and overlaps 457 could be prohibited in a future revision of the protocol 458 specification. Some implementations already drop all packets with 459 overlapped fragments. 461 Specifying a minimum size for packet fragments does not help in the 462 same way as it does for IPv4 because IPv6 extension headers can be 463 made to appear very long: an attacker could insert one or more 464 undefined destination options with long lengths and the 'ignore if 465 unknown' bit set. Given the guaranteed minimum MTU of IPv6 it seems 466 reasonable that hosts should be able to ensure that the transport 467 port numbers are in the first fragment in almost all cases and that 468 deep packet inspection should be very suspicious of first fragments 469 that do not contain them. 471 2.1.10 Fragmentation Related DoS Attacks 473 Packet reassembly in IPv6 hosts also opens up the possibility of 474 various fragment-related security attacks. Some of these are 475 analogous to attacks identified for IPv4. Of particular concern is a 476 DoS attack based on sending large numbers of small fragments without 477 a terminating last fragment which would potentially overload the 478 reconstruction buffers and consume large amounts of CPU resources. 480 Mandating the size of packet fragments could reduce the impact of 481 this kind of attack by limiting the rate at which fragments could 482 arrive. 484 2.1.11 Link-Local Addresses and Securing Neighbor Discovery 486 All IPv6 nodes are required to configure a link-local address on each 487 interface which they have in order to communicate with other nodes 488 directly connected to the link accessed via the interface, especially 489 during the neighbor discovery and auto-configuration processes. 490 Link-local addresses are fundamental to the operation of the Neighbor 491 Discovery Protocol (NDP) [RFC2461] and SLAAC [RFC2462]. NDP also 492 provides the functionality of associating link layer and IP addresses 493 for which the Address Resolution Protocol (ARP) was needed in IPv4 494 networks. 496 The standard version of NDP is subject to a number of security 497 threats related to ARP spoofing attacks on IPv4. These threats have 498 been documented in [RFC3756] and mechanisms to combat them specified 499 in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional 500 mechanism which is particularly applicable to wireless and other 501 environments where it is difficult to physically secure the link. 503 Because the link-local address can, by default, be acquired without 504 external intervention or control, it allows an attacker to commence 505 communication on the link without needing to acquire information 506 about the address prefixes in use or communicate with any authorities 507 on the link. This feature gives a malicious node the opportunity to 508 mount an attack on any other node which is attached to this link; 509 this vulnerability exists in addition to possible direct attacks on 510 NDP. 512 Link-local addresses allocated from the prefix 169.254.0.0/16 are 513 available in IPv4 as well and procedures for using them are described 514 in [I-D.ietf-zeroconf-ipv4-linklocal] but the security issues were 515 not as pronounced as for IPv6 for the following reasons: 516 o link-local addresses are not mandatory in IPv4 and are primarily 517 intended for isolated or ad hoc networks that cannot acquire a 518 routable IPv4 address by other means, 519 o IPv4 link local addresses are not universally supported across 520 operating systems, and 521 o the IPv4 link local address should be removed when a non-link 522 local address is configured on the interface and will generally 523 not be allocated unless other means of acquiring an address are 524 not available. 526 This vulnerability can be mitigated in several ways. A general 527 solution will require 528 o authenticating the link layer connectivity, for example by using 529 IEEE 802.1x functionality, port-based MAC address security 530 (locking), or physical security, and 531 o using SEcure Neighbor Discovery (SEND) to create a 532 cryptographically generated link-local address as described in 533 [RFC3972] which is tied to the authenticated link layer address. 534 This solution would be particularly appropriate in wireless LAN 535 deployments where it is difficult to physically secure the 536 infrastructure 538 In wired environments, where the physical infrastructure is 539 reasonably secure, it may be sufficient to ignore communication 540 requests originating from a link-local address for other than local 541 network management purposes. This requires that nodes should only 542 accept packets with link-local addresses for a limited set of 543 protocols including NDP, MLD and other functions of ICMPv6. 545 2.1.12 Mobile IPv6 547 Mobile IPv6 offers significantly enhanced security compared with 548 Mobile IPv4 especially when using optimized routing and care-of 549 addresses. Return routability checks are used to provide relatively 550 robust assurance that the different addresses which a mobile node 551 uses as it moves through the network do indeed all refer to the same 552 node. The threats and solutions are described in [RFC3775] and a 553 more extensive discussion of the security aspects of the design can 554 be be found in [I-D.ietf-mip6-ro-sec]. 556 2.1.12.1 Obsolete Home Address Option in Mobile IPv6 558 The Home Address option specified in early drafts of Mobile IPv6 559 would have allowed a trivial source spoofing attack: hosts were 560 required to substitute the source address of incoming packets with 561 the address in the option, thereby potentially evading checks on the 562 packet source address. This is discussed at greater length in 563 [I-D.savola-ipv6-rh-ha-security]. The version of Mobile IPv6 as 564 standardised in [RFC3775] has removed this issue by ensuring that the 565 Home Address destination option is only processed if there is a 566 corresponding binding cache entry and securing Binding Update 567 messages. 569 A number of pre-standard implementations of Mobile IPv6 were 570 available which implemented this obsolete and insecure option: care 571 should be taken to avoid running such obsolete systems. 573 2.2 IPv4-mapped IPv6 Addresses 575 Overloaded functionality is always a double-edged sword: it may yield 576 some deployment benefits, but often also incurs the price which comes 577 with ambiguity. 579 One example of such is IPv4-mapped IPv6 addresses: a representation 580 of an IPv4 address as an IPv6 address inside an operating system. 581 Since the original specification, the use of IPv4-mapped addresses 582 has been extended to a transition mechanism, Stateless IP/ICMP 583 Translation algorithm (SIIT) [RFC2765], where they are potentially 584 used in the addresses of packets on the wire. 586 Therefore, it becomes difficult to unambiguously discern whether an 587 IPv4 mapped address is really an IPv4 address represented in the IPv6 588 address format *or* an IPv6 address received from the wire (which may 589 be subject to address forgery, etc.). 591 In addition, special cases like these, while giving deployment 592 benefits in some areas, require a considerable amount of code 593 complexity (e.g. in the implementations of bind() system calls and 594 reverse DNS lookups) which is probably undesirable. Some of these 595 issues are discussed in [I-D.cmetz-v6ops-v4mapped-api-harmful] and 596 [I-D.itojun-v6ops-v4mapped-harmful]. 598 In practice, although the packet translation mechanisms of SIIT are 599 specified for use in the Network Address Translator - Protocol 600 Translator (NAT-PT) [RFC2765], NAT-PT uses a mechanism different from 601 IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses 602 in IPv6 addresses. Also SIIT is not recommended for use as a 603 standalone transition mechanism. Given the issues that have been 604 identified, it seems appropriate that mapped addresses should not be 605 used on the wire. However, changing application behavior by 606 deprecating the use of mapped addresses in the operating system 607 interface would have significant impact on application porting 608 methods [RFC4038]and needs further study. 610 2.3 Increased End-to-End Transparency 612 One of the major design aims of IPv6 has been to maintain the 613 original IP architectural concept of end-to-end transparency. To 614 fully utilize this capability for further innovation in technologies 615 such as peer-to-peer communication whilst maintaining the security of 616 the network requires some modifications in the network architecture 617 and, ultimately, in the security model as compared with the norms for 618 IPv4 networks 620 2.3.1 IPv6 Networks without NATs 622 The necessity of introducing Network Address Translators (NATs) into 623 IPv4 networks, resulting from a shortage of IPv4 addresses, has 624 removed the end-to-end transparency of most IPv4 connections: the use 625 of IPv6 would restore this transparency. However, the use of NATs, 626 and the associated private addressing schemes, has become 627 inappropriately linked to the provision of security in enterprise 628 networks. The restored end-to-end transparency of IPv6 networks can 629 therefore be seen as a threat by poorly informed enterprise network 630 managers. Some seem to want to limit the end-to-end capabilities of 631 IPv6, for example by deploying private, local addressing and 632 translators, even when it is not necessary because of the abundance 633 of IPv6 addresses. 635 Recommendations for designing an IPv6 network to meet the perceived 636 security and connectivity requirements implicit in the current usage 637 of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end 638 transparency are described in IPv6 Network Architecture Protection 640 [I-D.ietf-v6ops-nap]. 642 2.3.2 Enterprise Network Security Model for IPv6 644 The favoured model for enterprise network security in IPv4 stresses 645 the use of a security perimeter policed by autonomous firewalls and 646 incorporating the NATs. Both perimeter firewalls and NATs introduce 647 asymmetry and reduce the transparency of communications through these 648 perimeters. The symmetric bidirectionality and transparency which 649 are extolled as virtues of IPv6 may seem to be at odds with this 650 model, and hence may even be seen as undesirable attributes, given 651 the threats to and attacks on networks which network managers have to 652 control as a major component of their work. 654 It is worth noting that IPv6 does not *require* end-to-end 655 connectivity. It merely provides end-to-end addressability; the 656 connectivity can still be controlled using firewalls (or other 657 mechanisms), and it is indeed wise to do so. 659 A number of matters indicate that IPv6 networks should migrate 660 towards an improved security model, which will increase the overall 661 security of the network but facilitate end-to-end communication: 662 o Increased usage of end-to-end security especially at the network 663 layer. IPv6 mandates the provision of IPsec capability in all 664 nodes and increasing usage of end-to-end security is a challenge 665 to current autonomous firewalls which are unable to perform deep 666 packet inspection on encrypted packets. It is also incompatible 667 with NATs because they modify the packets, even when packets are 668 only authenticated rather than encrypted. 669 o Acknowledgement that over-reliance on the perimeter model is 670 potentially dangerous. An attacker who can penetrate today's 671 perimeters will have free rein within the perimeter, in many 672 cases. Also a successful attack will generally allow the attacker 673 to capture information or resources and make use of them 674 o Development of mechanisms such as 'Trusted Computing' which will 675 increase the level of trust which network managers are able to 676 place on hosts. 677 o Development of centralized security policy repositories and 678 distribution mechanisms which, in conjunction with trusted hosts, 679 will allow network managers to place more reliance on security 680 mechanisms at the end points and allow end points to influence the 681 behavior of perimeter firewalls. 683 Several of the technologies required to support an enhanced security 684 model are still under development, including secure protocols to 685 allow end points to control firewalls: the complete security model 686 utilizing these technologies is now emerging but still requires some 687 development. 689 In the meantime, initial deployments will need to make use of similar 690 firewalling and intrusion detection techniques to IPv4 which may 691 limit end-to-end transparency temporarily, but should be prepared to 692 use the new security model as it develops and avoid the use of NATs 693 by the use of the architectural techniques described in [I-D.ietf- 694 v6ops-nap]. 696 3. Issues Due to Transition Mechanisms 698 3.1 IPv6 Transition/Co-existence Mechanism-specific Issues 700 The more complicated the IPv6 transition/co-existence becomes, the 701 greater the danger that security issues will be introduced either 702 o in the mechanisms themselves, 703 o in the interaction between mechanisms, or 704 o by introducing unsecured paths through multiple mechanisms. 705 These issues may or may not be readily apparent. Hence it would be 706 desirable to keep the mechanisms simple, as few in number as possible 707 and built from as small pieces as possible to simplify analysis. 709 One case where such security issues have been analyzed in detail is 710 the 6to4 tunneling mechanism [RFC3964]. 712 As tunneling has been proposed as a model for several more cases than 713 are currently being used, its security properties should be analyzed 714 in more detail. There are some generic dangers to tunneling: 716 o it may be easier to avoid ingress filtering checks 717 o it is possible to attack the tunnel interface: several IPv6 718 security mechanisms depend on checking that Hop Limit equals 255 719 on receipt and that link-local addresses are used. Sending such 720 packets to the tunnel interface is much easier than gaining access 721 to a physical segment and sending them there. 722 o automatic tunneling mechanisms are typically particularly 723 dangerous as there is no pre-configured association between end 724 points. Accordingly, at the receiving end of the tunnel packets 725 have to be accepted and decapsulated from any source. 726 Consequently, special care should be taken when specifying 727 automatic tunneling techniques. 729 3.2 Automatic Tunneling and Relays 731 Two mechanisms have been (or are being) specified which use automatic 732 tunneling and are intended for use outside a single domain. These 733 mechanisms encapsulate the IPv6 packet directly in an IPv4 packet in 734 the case of 6to4 [RFC3056] or in an IPv4 UDP packet in the case of 735 Teredo [I-D.huitema-v6ops-teredo]. In each case packets can be sent 736 and received by any similarly equipped nodes in the IPv4 Internet. 738 As mentioned in Section 3.1, a major vulnerability in such approaches 739 is that receiving nodes must allow decapsulation of traffic sourced 740 from anywhere in the Internet. This kind of decapsulation function 741 must be extremely well secured because of the wide range of potential 742 sources. 744 An even more difficult problem is how these mechanisms are able to 745 establish communication with native IPv6 nodes or between the 746 automatic tunneling mechanisms: such connectivity requires the use of 747 some kind of "relay". These relays could be deployed in various 748 locations such as: 749 o all native IPv6 nodes, 750 o native IPv6 sites, 751 o in IPv6-enabled ISPs, or 752 o just somewhere in the Internet. 754 Given that a relay needs to trust all the sources (e.g., in the 6to4 755 case, all 6to4 routers) which are sending it traffic, there are 756 issues in achieving this trust and at the same time scaling the relay 757 system to avoid overloading a small number of relays. 759 As authentication of such a relay service is very difficult to 760 achieve, and particularly so in some of the possible deployment 761 models, relays provide a potential vehicle for address spoofing, 762 (reflected) Denial-of-Service attacks, and other threats. 764 Threats related to 6to4 and measures to combat them are discussed in 765 [RFC3964]. [I-D.huitema-v6ops-teredo] incorporates extensive 766 discussion of the threats to Teredo and measures to combat them. 768 3.3 Tunneling May Break Security Assumptions 770 NATs and firewalls have been deployed extensively in the IPv4 771 Internet, as discussed in Section 2.3. Operators who deploy them 772 typically have some security/operational requirements in mind (e.g. a 773 desire to block inbound connection attempts), which may or may not be 774 misguided. 776 The addition of tunneling can change the security model which such 777 deployments are seeking to enforce. IPv6-over-IPv4 tunneling using 778 protocol 41 is typically either explicitly allowed, or disallowed 779 implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes 780 a more difficult problem: as UDP must usually be allowed to pass 781 through NATs and firewalls, at least in part and in a possibly 782 stateful manner, one can "punch holes" in NAT's and firewalls using 783 UDP. In practice, the mechanisms have been explicitly designed to 784 traverse both NATs and firewalls in a similar fashion. 786 One possible view is that use of tunneling is especially questionable 787 in home/SOHO environments where the level of expertise in network 788 administration is typically not very high; in these environments the 789 hosts may not be as tightly managed as in others (e.g., network 790 services might be enabled unnecessarily), leading to possible 791 security break-ins or other vulnerabilities. 793 Holes can be punched both intentionally and unintentionally. In 794 cases where the administrator or user makes an explicit decision to 795 create the hole, this is less of a problem, although (for example) 796 some enterprises might want to block IPv6 tunneling explicitly if 797 employees were able to create such holes without reference to 798 administrators. On the other hand, if a hole is punched 799 transparently, it is likely that a proportion of users will not 800 understand the consequences: this will very probably result in a 801 serious threat sooner or later. 803 When deploying tunneling solutions, especially tunneling solutions 804 which are automatic and/or can be enabled easily by users who do not 805 understand the consequences, care should be taken not to compromise 806 the security assumptions held by the users. 808 For example, NAT traversal should not be performed by default unless 809 there is a firewall producing a similar by-default security policy to 810 that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is 811 less of a problem, as it is easier to block if necessary; however, if 812 the host is protected in IPv4, the IPv6 side should be protected as 813 well. 815 As has been shown in Appendix A, it is relatively easy to determine 816 the IPv6 address corresponding to an IPv4 address, so especially if 817 one is using automatic tunneling mechanisms, one should not rely on 818 "security by obscurity" i.e., relying that nobody is able to guess or 819 determine the IPv6 address of the host. 821 4. Issues Due to IPv6 Deployment 823 4.1 IPv6 Service Piloting Done Insecurely 825 In many cases, IPv6 service piloting is done in a manner which is 826 less secure than can be achieved for an IPv4 production service. For 827 example, hosts and routers might not be protected by IPv6 firewalls, 828 even if the corresponding IPv4 service is fully protected by 829 firewalls. 831 The other possible alternative, in some instances, is that no service 832 piloting is permitted because IPv6 firewalls and other security 833 capabilities, such as intrusion detection systems may not be widely 834 available. Consequently, IPv6 deployment suffers and expertise 835 accumulates less rapidly. 837 These problems may be partly due to the relatively slow development 838 and deployment of IPv6-capable firewall equipment, but there is also 839 a lack of information: actually, there are quite a few IPv6 packet 840 filters and firewalls already in existence, which could be used for 841 provide sufficient access controls, but network administrators may 842 not be aware of them yet and there is a lack of documented 843 operational practice. 845 However, there appears to be a real lack in the area of 'personal 846 firewalls'. Also enterprise firewalls are at an early stage of 847 development and may not provide all the capabilities needed to 848 implement the necessary IPv6 filtering rules. The same devices that 849 support and are used for IPv4 today are often expected to also become 850 IPv6-capable -- even though this is not really required and the 851 equipment may not have the requisite hardware capabilities to support 852 fast packet filtering for IPv6. That is, IPv4 access could be 853 filtered by one firewall, and when IPv6 access is added, it could be 854 protected by another firewall; they don't have to be the same box, 855 and even their models don't have to be the same. 857 A lesser factor may be that some design decisions in the IPv6 858 protocol make it more difficult for firewalls to be implemented and 859 work in all cases and to be fully future proof (e.g. when new 860 extension headers are used) as discussed in Section 2.1.8: it is 861 significantly more difficult for intermediate nodes to process the 862 IPv6 header chains than IPv4 packets. 864 A similar argument, which is often quoted as hindering IPv6 865 deployment, has been the lack of Intrusion Detection Systems (IDS). 866 It is not clear whether this is more of an excuse than a real reason. 868 4.2 Enabling IPv6 by Default Reduces Usability 870 A practical disadvantage of enabling IPv6 at the time of writing is 871 that it typically reduces the observed service level by a small 872 fraction; that is, the usability suffers. 874 There are at least three factors contributing to this effect: 876 o global IPv6 routing is still rather unstable, leading to packet 877 loss, lower throughput, and higher delay (this was discussed with 878 respect to the experimental 6Bone network in [I-D.savola-v6ops- 879 6bone-mess]) 881 o some applications cannot properly handle both IPv4 and IPv6 or may 882 have problems handling all the fallbacks and failure modes (and in 883 some cases, e.g. if the TCP timeout kicks in, this may result in 884 very poor performance) 885 o some DNS server implementations have flaws that severely affect 886 DNS queries for IPv6 addresses as discussed in [I-D.ietf-dnsop- 887 misbehavior-against-aaaa] 889 Actually, some providers are fully ready to offer IPv6 services (e.g. 890 web) today, but because that would (or, at least, might) result in 891 problems for many of their customers or users who are, by default, 892 using active dual-stack systems the services are not turned on: as a 893 compromise,the services are often published under a separate domain 894 or subdomain, and are, in practice, not much used as a consequence. 896 These issues are also described at some length in [I-D.ietf-v6ops- 897 v6onbydefault]. 899 4.3 Addressing Schemes and Securing Routers 901 Whilst in general terms brute force scanning of IPv6 subnets is 902 essentially impossible due to the enormously larger address space of 903 IPv6 and the 64 bit interface identifiers (see Appendix A), this will 904 be obviated if administrators do not take advantage of the large 905 space to use unguessable interface identifiers. 907 Because the unmemorability of complete IPv6 addresses there is a 908 temptation for administrators to use small integers as interface 909 identifiers when manually configuring them, as might happen on point- 910 to-point links. Such allocations make it easy for an attacker to 911 find active nodes that they can then port scan. 913 To make use of the larger address space properly, administrators 914 should be very careful when entering IPv6 addresses in their 915 configurations (e.g. Access Control List), since numerical IPv6 916 addresses are more prone to human error than IPv4 due to their length 917 and unmemorability. 919 It is also essential to ensure that the management interfaces of 920 routers are well secured as the router will usually contain a 921 significant cache of neighbor addresses in its neighbor cache. 923 4.4 Consequences of Multiple Addresses in IPv6 925 One positive consequence of IPv6 is that nodes which do not require 926 global access can communicate locally just by the use of a link-local 927 address (if very local access is sufficient) or across the site by 928 using a Unique Local Address (ULA). In either case it is easy to 929 ensure that access outside the assigned domain of activity can be 930 controlled by simple filters (which may be the default for link- 931 locals). However, the security hazards of using link-local addresses 932 for non-management purposes as documented in Section 2.1.11 should be 933 borne in mind. 935 On the other hand, the possibility that a node or interface can have 936 multiple global scope addresses makes access control filtering both 937 on ingress and egress more complex and requires higher maintenance 938 levels. 940 The addresses could be from the same network prefix (for example, 941 privacy mechanisms [RFC3041] will periodically create new addresses 942 taken from the same prefix and two or more of these may be active at 943 the same time), or from different prefixes (for example, when a 944 network is multihomed or is implementing anycast services). In 945 either case, it is possible that a single host could be using several 946 different addresses with different prefixes. It would be desirable 947 that the Security Administrator should be able to identify that the 948 same host is behind all these addresses. 950 4.5 Deploying ICMPv6 952 In IPv4 it is generally accepted that some filtering of ICMP packets 953 by firewalls is essential to maintain security. Because of the 954 extended use that is made of ICMPv6 with a multitude of functions, 955 the simple set of dropping rules that are usually applied in IPv4 956 need to be significantly developed for IPv6. The blanket dropping of 957 all ICMP messages that is used in some very strict environments is 958 simply not possible for IPv6. 960 In an IPv6 firewall, policy needs to allow some messages through the 961 firewall but also has to permit certain messages to and from the 962 firewall, especially those with link local sources on links to which 963 the firewall is attached. 965 AUTHOR'S NOTE: It may not be the place of this document to specify 966 BCP as regards what ICMPv6 messages should be filtered by firewalls. 967 We solicit input on whether this should be incorporated in a separate 968 document. 970 In order for the firewall to function correctly as an IPv6 node, it 971 must accept and process ICMPv6 messages from link local addresses 972 received on its interfaces. It also needs to accept at least some 973 ICMPv6 messages directed to global unicast addresses of the firewall: 974 o ICMPv6 Type 2 - packet too big - The firewall itself has to 975 participate in Path MTU Discovery. 977 o ICMPv6 Type 4 - Parameter Problem - Needs further investigation 978 because of possible abuse. 980 To support effective functioning of IPv6, firewalls should typically 981 allow the following messages (defined in [RFC2463]) to pass through 982 the firewall (the first four are equivalent to the typical IPv4 983 filtering allowance): 984 o ICMPv6 Type 1, Code 0 - No route to destination error 985 o ICMPv6 Type 3 - Time exceeded error 986 o ICMPv6 Type 128 - Echo request 987 o ICMPv6 Type 129 - Echo response 988 o ICMPv6 Type 2 - Packet too big (required for Path MTU Discovery) 989 o ICMPv6 Type 4 - Parameter problem (this type needs to be 990 investigated further as it is possible that it can be abused. 992 4.5.1 Problems Resulting from ICMPv6 Transparency 994 As described in Section 4.5, certain ICMPv6 error packets need to be 995 passed through a firewall in both directions. This means that the 996 ICMPv6 error packets can be exchanged between inside and outside 997 without any filtering. 999 Using this feature, malicious users can communicate between the 1000 inside and outside of a firewall bypassing the administrator's 1001 inspection (proxy, firewall etc.). For example in might be possible 1002 to carry out a covert conversation through the payload of ICMPv6 1003 error messages or tunnel inappropriate encapsulated IP packets in 1004 ICMPv6 error messages. This problem can be alleviated by filtering 1005 ICMPv6 errors using a stateful packet inspection mechanism to ensure 1006 that the packet carried as a payload is associated with legitimate 1007 traffic to or from the protected network. 1009 4.6 IPsec Transport Mode 1011 IPsec provides security to end-to-end communications at the network 1012 layer (layer 3). The security features available include access 1013 control, connectionless integrity, data origin authentication, 1014 protection against replay attacks, confidentiality, and limited 1015 traffic flow confidentiality (see [RFC2401] section 2.1). IPv6 1016 mandates the implementation of IPsec in all conforming nodes, making 1017 the usage of IPsec to secure end-to-end communication possible in a 1018 way which is generally not available to IPv4. 1020 To secure IPv6 end-to-end communications, IPsec transport mode would 1021 generally be the solution of choice. However, use of these IPsec 1022 security features can result in novel problems for network 1023 administrators and decrease the effectiveness of perimeter firewalls 1024 because of the increased prevalence of encrypted packets on which the 1025 firewalls cannot perform deep packet inspection and filtering. 1027 One example of such problems is the lack of security solutions in the 1028 middle-box, including effective content-filtering, ability to provide 1029 DoS prevention based on the expected TCP protocol behavior, and 1030 intrusion detection. Future solutions to this problem are discussed 1031 in Section 2.3.2. Another example is an IPsec-based DoS (e.g., 1032 sending malformed ESP/AH packets) which can be especially detrimental 1033 to software-based IPsec implementations. 1035 4.7 Reduced Functionality Devices 1037 With the deployment of IPv6 we can expect the attachment of a very 1038 large number of new IPv6-enabled devices with scarce resources and 1039 low computing capacity. However, they tend to have scarce resources 1040 and low computing capacity because of a market requirement for cost 1041 reduction. Some such devices may not be able even to perform the 1042 minimum set of functions required to protect themselves (e.g. 1043 'personal' firewall, automatic firmware update, enough CPU power to 1044 endure DoS attacks). This means a different security scheme may be 1045 necessary for such embedded devices. 1047 4.8 Operational Factors when Enabling IPv6 in the Network 1049 There are a number of reasons which make it essential to take 1050 particular care when enabling IPv6 in the network equipment: 1052 Initially, IPv6-enabled router software may be less stable than 1053 current IPv4 only implementations and there is less experience with 1054 configuring IPv6 routing, which can result in disruptions to the IPv6 1055 routing environment and (IPv6) network outages. 1057 IPv6 processing may not happen at (near) line speed (or at a 1058 comparable performance level to IPv4 in the same equipment). A high 1059 level of IPv6 traffic (even legitimate, e.g. NNTP) could easily 1060 overload IPv6 processing especially when it is software-based without 1061 the hardware support typical in high-end routers. This may 1062 potentially have deleterious knock-on effects on IPv4 processing, 1063 affecting availability of both services. Accordingly, if people 1064 don't feel confident enough in the IPv6 capabilities of their 1065 equipment, they will be reluctant to enable it in their "production" 1066 networks. 1068 Sometimes essential features may be missing from early releases of 1069 vendors' software; an example is provision of software enabling IPv6 1070 telnet/SSH access, but without the ability to turn it off or limit 1071 access to it! 1072 Sometimes the default IPv6 configuration is insecure. For example, 1073 in one vendor's implementation, if you have restricted IPv4 telnet to 1074 only a few hosts in the configuration, you need to be aware that IPv6 1075 telnet will be automatically enabled, that the configuration commands 1076 used previously do not block IPv6 telnet, IPv6 telnet is open to the 1077 world by default, and that you have to use a separate command to also 1078 lock down the IPv6 telnet access. 1080 Many operator networks have to run interior routing protocols for 1081 both IPv4 and IPv6. It is possible to run the both in one routing 1082 protocol, or have two separate routing protocols; either approach has 1083 its tradeoffs [RFC4029]. If multiple routing protocols are used, one 1084 should note that this causes double the amount of processing when 1085 links flap or recalculation is otherwise needed -- which might more 1086 easily overload the router's CPU, causing slightly slower convergence 1087 time. 1089 4.9 Ingress Filtering Issues Due to Privacy Addresses 1091 [RFC3041] describes a method for creating temporary addresses on IPv6 1092 nodes to address privacy issues created by the use of a constant 1093 identifier. In a network, which implements such a mechanism, with a 1094 large number of nodes, new temporary addresses may be created at a 1095 fairly high rate. This might make it hard for ingress filtering 1096 mechanisms to distinguish between legitimately changing temporary 1097 addresses and spoofed source addresses, which are "in-prefix" (They 1098 use a topologically correct prefix and non-existent interface ID). 1099 This can be addressed by using finer grained access control 1100 mechanisms on the network egress point. 1102 4.10 Security Issues Due to ND Proxies 1104 In order to span a single subnet over multiple physical links, a new 1105 capability is being introduced in IPv6 to proxy Neighbor Discovery 1106 messages. This node will be called an NDProxy (see [I-D.ietf-ipv6- 1107 ndproxy]. NDProxies are susceptible to the same security issues as 1108 the ones faced by hosts using unsecured Neighbor Discovery or ARP. 1109 These proxies may process unsecured messages, and update the neighbor 1110 cache as a result of such processing, thus allowing a malicious node 1111 to divert or hijack traffic. This may undermine the advantages of 1112 using SEND [RFC3971]. 1114 To resolve the security issues introduced by NDProxies, SEND needs to 1115 be extended to be NDProxy aware. 1117 5. Acknowledgements 1119 Alain Durand, Alain Baudot, Luc Beloeil, and Andras Kis-Szabo 1120 provided feedback to improve this memo. SUSZUKI Shinsuke provided a 1121 number of additional issues in cooperation with the Deployment 1122 Working Group of the Japanese IPv6 Promotion Council. Michael 1123 Wittsend and Michael Cole discussed issues relating to probing/ 1124 mapping and privacy. 1126 6. Security Considerations 1128 This memo attempts to give an overview of security considerations of 1129 the different aspects of IPv6. 1131 7. References 1133 7.1 Normative References 1135 [I-D.huitema-v6ops-teredo] 1136 Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1137 NATs", draft-huitema-v6ops-teredo-05 (work in progress), 1138 April 2005. 1140 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 1141 Assignments", RFC 2375, July 1998. 1143 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1144 (IPv6) Specification", RFC 2460, December 1998. 1146 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1147 Discovery for IP Version 6 (IPv6)", RFC 2461, 1148 December 1998. 1150 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1151 Autoconfiguration", RFC 2462, December 1998. 1153 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 1154 Protocol (ICMPv6) for the Internet Protocol Version 6 1155 (IPv6) Specification", RFC 2463, December 1998. 1157 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1158 Listener Discovery (MLD) for IPv6", RFC 2710, 1159 October 1999. 1161 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1162 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1163 January 2001. 1165 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1166 via IPv4 Clouds", RFC 3056, February 2001. 1168 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1169 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1171 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1172 in IPv6", RFC 3775, June 2004. 1174 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1175 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1177 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1178 6to4", RFC 3964, December 2004. 1180 7.2 Informative References 1182 [FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc. 1183 Second Internet Measurement Workshop , November 2002, 1184 . 1186 [I-D.chown-v6ops-port-scanning-implications] 1187 Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", 1188 draft-chown-v6ops-port-scanning-implications-01 (work in 1189 progress), July 2004. 1191 [I-D.cmetz-v6ops-v4mapped-api-harmful] 1192 Metz, C. and J. Hagino, "IPv4-Mapped Address API 1193 Considered Harmful", 1194 draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in 1195 progress), October 2003. 1197 [I-D.dupont-ipv6-rfc3041harmful] 1198 Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", 1199 draft-dupont-ipv6-rfc3041harmful-05 (work in progress), 1200 June 2004. 1202 [I-D.ietf-dnsop-ipv6-dns-issues] 1203 Durand, A., Ihren, J., and P. Savola, "Operational 1204 Considerations and Issues with IPv6 DNS", 1205 draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress), 1206 October 2004. 1208 [I-D.ietf-dnsop-misbehavior-against-aaaa] 1209 Morishita, Y. and T. Jinmei, "Common Misbehavior against 1210 DNS Queries for IPv6 Addresses", 1211 draft-ietf-dnsop-misbehavior-against-aaaa-02 (work in 1212 progress), October 2004. 1214 [I-D.ietf-ipv6-ndproxy] 1215 Thaler, D., "Bridge-like Neighbor Discovery Proxies (ND 1216 Proxy)", draft-ietf-ipv6-ndproxy-01 (work in progress), 1217 February 2005. 1219 [I-D.ietf-mip6-ro-sec] 1220 Nikander, P., "Mobile IP version 6 Route Optimization 1221 Security Design Background", draft-ietf-mip6-ro-sec-02 1222 (work in progress), October 2004. 1224 [I-D.ietf-v6ops-nap] 1225 Velde, G., "IPv6 Network Architecture Protection", 1226 draft-ietf-v6ops-nap-00 (work in progress), March 2005. 1228 [I-D.ietf-v6ops-v6onbydefault] 1229 Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack 1230 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 1231 (work in progress), July 2004. 1233 [I-D.ietf-zeroconf-ipv4-linklocal] 1234 Aboba, B., "Dynamic Configuration of Link-Local IPv4 1235 Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in 1236 progress), July 2004. 1238 [I-D.itojun-v6ops-v4mapped-harmful] 1239 Metz, C. and J. Hagino, "IPv4-Mapped Addresses on the Wire 1240 Considered Harmful", 1241 draft-itojun-v6ops-v4mapped-harmful-02 (work in progress), 1242 October 2003. 1244 [I-D.krishnan-ipv6-hopbyhop] 1245 Krishnan, S., "Arrangement of Hop-by-Hop options", 1246 draft-krishnan-ipv6-hopbyhop-00 (work in progress), 1247 June 2004. 1249 [I-D.savola-ipv6-rh-ha-security] 1250 Savola, P., "Security of IPv6 Routing Header and Home 1251 Address Options", draft-savola-ipv6-rh-ha-security-02 1252 (work in progress), March 2002. 1254 [I-D.savola-ipv6-rh-hosts] 1255 Savola, P., "Note about Routing Header Processing on IPv6 1256 Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress), 1257 February 2002. 1259 [I-D.savola-v6ops-6bone-mess] 1260 Savola, P., "Moving from 6bone to IPv6 Internet", 1261 draft-savola-v6ops-6bone-mess-01 (work in progress), 1262 November 2002. 1264 [I-D.savola-v6ops-firewalling] 1265 Savola, P., "Firewalling Considerations for IPv6", 1266 draft-savola-v6ops-firewalling-02 (work in progress), 1267 October 2003. 1269 [I-D.savola-v6ops-transarch] 1270 Savola, P., "A View on IPv6 Transition Architecture", 1271 draft-savola-v6ops-transarch-03 (work in progress), 1272 January 2004. 1274 [I-D.schild-v6ops-guide-v4mapping] 1275 Schild, C., "Guide to Mapping IPv4 to IPv6 Subnets", 1276 draft-schild-v6ops-guide-v4mapping-00 (work in progress), 1277 January 2004. 1279 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1280 Considerations for IP Fragment Filtering", RFC 1858, 1281 October 1995. 1283 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1284 Internet Protocol", RFC 2401, November 1998. 1286 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1287 (SIIT)", RFC 2765, February 2000. 1289 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1290 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1292 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1293 Discovery (ND) Trust Models and Threats", RFC 3756, 1294 May 2004. 1296 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1297 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1299 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1300 RFC 3972, March 2005. 1302 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 1303 Savola, "Scenarios and Analysis for Introducing IPv6 into 1304 ISP Networks", RFC 4029, March 2005. 1306 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 1307 Castro, "Application Aspects of IPv6 Transition", 1308 RFC 4038, March 2005. 1310 Authors' Addresses 1312 Elwyn B. Davies 1313 Consultant 1314 Soham, Cambs 1315 UK 1317 Phone: +44 7889 488 335 1318 Email: elwynd@dial.pipex.com 1320 Suresh Krishnan 1321 Ericsson 1322 8400 Decarie Blvd. 1323 Town of Mount Royal, QC H4P 2N2 1324 Canada 1326 Phone: +1 514-345-7900 1327 Email: suresh.krishnan@ericsson.com 1329 Pekka Savola 1330 CSC/Funet 1332 Email: psavola@funet.fi 1334 Appendix A. IPv6 Probing/Mapping Considerations 1336 One school of thought wants the IPv6 numbering topology (either at 1337 network or node level) [I-D.schild-v6ops-guide-v4mapping] match IPv4 1338 as exactly as possible, whereas others see IPv6 as giving more 1339 flexibility to the address plans, not wanting to constrain the design 1340 of IPv6 addressing. Mirroring the address plans may also be seen as 1341 a security threat because an IPv6 deployment may have different 1342 security properties from IPv4. 1344 Given the relatively immature state of IPv6 network security, if an 1345 attacker knows the IPv4 address of the node and believes it to be 1346 dual-stacked with IPv4 and IPv6, he might want to try to probe the 1347 corresponding IPv6 address, based on the assumption that the security 1348 defenses might be lower. This might be the case particularly for 1349 nodes which are behind a NAT in IPv4, but globally addressable in 1350 IPv6. Naturally, this is not a concern if similar and adequate 1351 security policies are in place. 1353 On the other hand, brute-force scanning or probing of addresses is 1354 computationally infeasible due to the large search space of interface 1355 identifiers on most IPv6 subnets (somewhat less than 64 bits wide, 1356 depending on how identifiers are chosen), always provided that 1357 identifiers are chosen at random out of the available space, as 1358 discussed in [I-D.chown-v6ops-port-scanning-implications]. 1360 For example, automatic tunneling mechanisms use rather deterministic 1361 methods for generating IPv6 addresses, so probing/port-scanning an 1362 IPv6 node is simplified. The IPv4 address is embedded at least in 1363 6to4, Teredo and ISATAP address. Further than that, it's possible 1364 (in the case of 6to4 in particular) to learn the address behind the 1365 prefix; for example, Microsoft 6to4 implementation uses the address 1366 2002:V4ADDR::V4ADDR while Linux and BSD implementations default to 1367 2002:V4ADDR::1. This could also be used as one way to identify an 1368 implementation. 1370 One proposal has been to randomize the addresses or subnet identifier 1371 in the address of the 6to4 router. This doesn't really help, as the 1372 6to4 router (whether a host or a router) will return an ICMPv6 Hop 1373 Limit Exceeded message, revealing the IP address. Hosts behind the 1374 6to4 router can use methods such as RFC 3041 addresses to conceal 1375 themselves, though. 1377 To conclude, it seems that when automatic tunneling mechanism is 1378 being used, given an IPv4 address, the corresponding IPv6 address 1379 could possibly be guessed with relative ease. This has significant 1380 implications if the IPv6 security policy is less adequate than that 1381 for IPv4. 1383 Appendix B. IPv6 Privacy Considerations 1385 It has been claimed that IPv6 harms the privacy of the user, either 1386 by exposing the MAC address, or by exposing the number of nodes 1387 connected to a site. 1389 B.1 Exposing MAC Addresses 1391 The MAC address, which with stateless address autoconfiguration, 1392 results in an EUI64, exposes the model of network card. The concern 1393 has been that a user might not want to expose the details of the 1394 system to outsiders, e.g., in the fear of a resulting burglary (e.g., 1395 if a crook identifies expensive equipment from the MAC addresses). 1397 In most cases, this seems completely unfounded. First, such an 1398 address must be learned somehow -- this is a non-trivial process; the 1399 addresses are visible e.g., in web site access logs, but the chances 1400 that a random web site owner is collecting this kind of information 1401 (or whether it would be of any use) are quite slim. Being able to 1402 eavesdrop the traffic to learn such addresses (e.g., by the 1403 compromise of DSL or Cable modem physical media) seems also quite 1404 far-fetched. Further, using RFC 3041 addresses for such purposes is 1405 straightforward if worried about the risk. Second, the burglar would 1406 have to be able to map the IP address to the physical location; this 1407 is typically only available in the private customer database of the 1408 ISP. 1410 B.2 Exposing Multiple Devices 1412 Another presented concern is whether the user wants to show off as 1413 having a lot of computers or other devices at a network; NAT "hides" 1414 everything behind an address, but is not perfect either [FNAT]. 1416 One practical reason why some may find this desirable is being able 1417 to thwart certain ISPs' business models, where one should pay extra 1418 for additional computers (and not the connectivity as a whole). 1420 Similar feasibility issues as described above apply. To a degree, 1421 the counting avoidance could be performed by the sufficiently 1422 frequent re-use of RFC 3041 addresses -- that is, if during a short 1423 period, dozens of generated addresses seem to be in use, it's 1424 difficult to estimate whether they are generated by just one host or 1425 multiple hosts. 1427 B.3 Exposing the Site by a Stable Prefix 1429 When an ISP provides an IPv6 connectivity to its customers, it 1430 delegates a fixed global routing prefix (usually a /48) to them. 1432 Due to this fixed allocation, it is easier to correlate the global 1433 routing prefix to a network site. In case of consumer users, this 1434 correlation leads to a privacy issue, since a site is often equal to 1435 an individual or a family in such a case. That is, some users might 1436 be concerned about being able to be tracked based on their /48 1437 allocation if it is static [I-D.dupont-ipv6-rfc3041harmful]. 1439 This problem remains unsolved even when a user changes his/her 1440 interface ID or subnet ID, because malicious users can still discover 1441 this binding. This problem can be solved by untraceable IPv6 1442 addresses as described in [I-D.ietf-v6ops-nap]. 1444 Intellectual Property Statement 1446 The IETF takes no position regarding the validity or scope of any 1447 Intellectual Property Rights or other rights that might be claimed to 1448 pertain to the implementation or use of the technology described in 1449 this document or the extent to which any license under such rights 1450 might or might not be available; nor does it represent that it has 1451 made any independent effort to identify any such rights. Information 1452 on the procedures with respect to rights in RFC documents can be 1453 found in BCP 78 and BCP 79. 1455 Copies of IPR disclosures made to the IETF Secretariat and any 1456 assurances of licenses to be made available, or the result of an 1457 attempt made to obtain a general license or permission for the use of 1458 such proprietary rights by implementers or users of this 1459 specification can be obtained from the IETF on-line IPR repository at 1460 http://www.ietf.org/ipr. 1462 The IETF invites any interested party to bring to its attention any 1463 copyrights, patents or patent applications, or other proprietary 1464 rights that may cover technology that may be required to implement 1465 this standard. Please address the information to the IETF at 1466 ietf-ipr@ietf.org. 1468 Disclaimer of Validity 1470 This document and the information contained herein are provided on an 1471 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1472 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1473 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1474 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1475 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1478 Copyright Statement 1480 Copyright (C) The Internet Society (2005). This document is subject 1481 to the rights, licenses and restrictions contained in BCP 78, and 1482 except as set forth therein, the authors retain all their rights. 1484 Acknowledgment 1486 Funding for the RFC Editor function is currently provided by the 1487 Internet Society.