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