idnits 2.17.1 draft-vyncke-opsec-v6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4299 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-14 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-01 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-6to4-to-historic-05 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ra-guard-implementation-04 == Outdated reference: A later version (-19) exists of draft-templin-v6ops-isops-17 -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6506 (Obsoleted by RFC 7166) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for K. Chittimaneni 3 IPv6 Network Infrastructure Google 4 Internet-Draft M. Kaeo 5 Intended status: Informational ISC 6 Expires: January 17, 2013 E. Vyncke 7 Cisco Systems 8 July 16, 2012 10 Operational Security Considerations for IPv6 Networks 11 draft-vyncke-opsec-v6-01 13 Abstract 15 Network managers know how to operate securely IPv4 network: whether 16 it is the Internet or an enterprise internal network. IPv6 presents 17 some new security challenges. RFC 4942 describes the security issues 18 in the protocol but network managers need also a more practical, 19 operation-minded best common practices. 21 This document analyzes the operational security issues in all places 22 of a network (service providers, enterprises and residential users) 23 and proposes technical and procedural mitigations techniques. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 17, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. Generic Security Considerations . . . . . . . . . . . . . . . 4 62 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 63 2.1.1. Overall Structure . . . . . . . . . . . . . . . . . . 4 64 2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . . 5 66 2.1.4. Privacy Addresses . . . . . . . . . . . . . . . . . . 5 67 2.1.5. DHCP/DNS Considerations . . . . . . . . . . . . . . . 6 68 2.2. Link Layer Security . . . . . . . . . . . . . . . . . . . 6 69 2.2.1. SeND and CGA . . . . . . . . . . . . . . . . . . . . . 6 70 2.2.2. DHCP Snooping . . . . . . . . . . . . . . . . . . . . 7 71 2.2.3. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 7 72 2.2.4. ND/RA Filtering . . . . . . . . . . . . . . . . . . . 8 73 2.3. Control Plane Security . . . . . . . . . . . . . . . . . . 9 74 2.3.1. Control Protocols . . . . . . . . . . . . . . . . . . 10 75 2.3.2. Management Protocols . . . . . . . . . . . . . . . . . 10 76 2.3.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 11 77 2.4. Routing Security . . . . . . . . . . . . . . . . . . . . . 11 78 2.4.1. Authenticating Neighbors/Peers . . . . . . . . . . . . 12 79 2.4.2. Securing Routing Updates Between Peers . . . . . . . . 12 80 2.4.3. Route Filtering . . . . . . . . . . . . . . . . . . . 12 81 2.5. Logging/Monitoring . . . . . . . . . . . . . . . . . . . . 13 82 2.5.1. Data Sources . . . . . . . . . . . . . . . . . . . . . 14 83 2.5.2. Use of Collected Data . . . . . . . . . . . . . . . . 17 84 2.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18 85 2.6. Transition/Coexistence Technologies . . . . . . . . . . . 19 86 2.6.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . . 19 87 2.6.2. Tunneling Mechanisms . . . . . . . . . . . . . . . . . 19 88 2.6.3. Translation Mechanisms . . . . . . . . . . . . . . . . 22 89 2.7. General Device Hardening . . . . . . . . . . . . . . . . . 23 90 3. Enterprises Specific Security Considerations . . . . . . . . . 23 91 3.1. External Security Considerations: . . . . . . . . . . . . 24 92 3.2. Internal Security Considerations: . . . . . . . . . . . . 24 93 4. Service Providers Security Considerations . . . . . . . . . . 25 94 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 4.1.1. Remote Triggered Black Hole . . . . . . . . . . . . . 25 97 4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . . 25 98 4.2.1. 6PE and 6VPE . . . . . . . . . . . . . . . . . . . . . 25 99 4.2.2. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 4.2.3. DS-lite . . . . . . . . . . . . . . . . . . . . . . . 25 101 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . . 25 102 5. Residential Users Security Considerations . . . . . . . . . . 25 103 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 108 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 Running an IPv6 network is new for most operators not only because 114 they are not yet used to large scale IPv6 network but also because 115 there are subtle differences between IPv4 and IPv6 especially with 116 respect to security. For example, all layer-2 interactions are now 117 done by Neighbor Discovery Protocol [RFC4861] rather than by Address 118 Resolution Protocol [RFC0826]. Moreover, for end-users that usually 119 combination in a single box Customer Premice Equipment (CPE) of 120 firewall and Network Address and Port Translation [RFC3022] has lead 121 to the common feeling that NATPT equals security and with IPv6 NATPT 122 is no more needed. 124 The deployment of IPv6 network is commonly done with the dual-stack 125 technique [RFC4213] which also leads to specific security issues. 127 This document complements [RFC4942] by listing all security issues 128 when operating a network. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119] when they 135 appear in ALL CAPS. These words may also appear in this document in 136 lower case as plain English words, absent their normative meanings. 138 2. Generic Security Considerations 140 2.1. Addressing Architecture 142 IPv6 address allocations and overall architecture are an import part 143 of securing IPv6. 145 2.1.1. Overall Structure 147 Once an address allocation has been assigned, there should be some 148 thought given to an overall address allocation plan. A structured 149 address allocation plan can lead to more concise and simpler firewall 150 filtering rules. With the abundance of address space available, an 151 address allocation may be structured around services along with 152 geographic locations, which then can be a basis for more structured 153 network filters to permit or deny services between geographic 154 regions. 156 An important consideration for manually configured addressing is to 157 make them hard to guess whenever possible. When manually configuring 158 interface ID's, the more common forms of starting at the beginning or 159 end of a subnet boundary (i.e using a 1 or FF for routers) should be 160 avoided. This will make any potential reconnaissance attack attempt 161 much more difficult. Although some common multicast groups are 162 defined for important networked devices and use of commonly repeated 163 addresses make it easy figure out what the name servers, routers or 164 other critical devices are, a non-random manual address scheme also 165 makes it easy for a potential attacker using a "dictionary attack" of 166 commonly used interface IDs to find your critical infrastructure. 168 2.1.2. Use of ULAs 170 ULAs are intended for scenarios where IP addresses will not have 171 global scope. The implicit expectation from the RFC is that all ULAs 172 will be randomly created as /48s. However, in practice some 173 environments have chosen to create ULAs as a /32. While ULAs can be 174 useful for infrastructure hiding, it may create an issue in future if 175 the decision at some point is to make the machines using ULAs 176 globally reachable. This would require renumbering or perhaps even 177 stateful IPv6 Network Address Translation (NAT). The latter would 178 again be problematic in trying to track specific machines that may 179 source malware. It is important to carefully weigh the benefits of 180 using ULAs versus utilizing a section of the global allocation and 181 creating a more effective filtering strategy. A typical argument is 182 that there are too many mistakes made with filters and ULAs make 183 things easier to hide machines. 185 2.1.3. Point-to-Point Links 187 RFC3627 indicates that the use of a /64 is the best solution for 188 point-to-point links while a /112 can be used if that's not possible. 189 However, in current deployments where it is felt that using a /64 is 190 wasteful for point-to-point links, many opt to use a /127 or /126 191 subnet boundary and create manually defined IPv6 addresses for the 192 point-to-point or tunnel endpoints. 194 2.1.4. Privacy Addresses 196 Randomly generating an interface ID, as described in RFC 3041, is 197 part of stateless autoconfiguration and used to address some security 198 concerns. Stateless autoconfiguration relies on the automatically 199 generated EUI-64 node address, which together with the /64 prefix 200 make up the global unique IPv6 address. The EUI-64 address is 201 generated from the MAC address. Since MAC addresses for specific 202 vendor equipment can be know, it may be easy for a potential attacker 203 to perform a more directed intelligent scan to try and ascertain 204 specific vendor device reachability for exploitation. Privacy 205 addressing attempts to mitigate this threat. 207 As privacy addressing could also be used to hide illegal and unsavory 208 activities, privacy addressing can be assigned, audited, and 209 controlled in managed enterprise networks via DHCPv6. 211 Some people also feel that stateless addressing means that we may not 212 know addresses operating in our networks ahead of time in order to to 213 build access control lists (ACLs) of authorized users. While privacy 214 addresses are truly generated randomly to protect against user 215 tracking, but assuming that nodes use the EUI-64 format for global 216 addressing, a list of expected pre-authorized host addresses can be 217 generated. 219 2.1.5. DHCP/DNS Considerations 221 Some text 223 2.2. Link Layer Security 225 Link layer security is quite possibly the most important and visible 226 security consideration for most operators. IPv6 relied heavily on 227 the Neighbor Discovery protocol (NDP) [RFC4861] to perform a variety 228 of link operations such as discovering other nodes not he link, 229 resolving their link-layer addresses, and finding routers on the 230 link. If not secured, NDP is vulnerable to various attacks such as 231 router/neighbor message spoofing, redirect attacks, Duplicate Address 232 Detection (DAD) DoS attacks, etc. many of these security threats to 233 NDP have been documented in IPv6 ND Trust Models and Threats 234 [RFC3756] 236 2.2.1. SeND and CGA 238 The original NDP specification called for using IPsec to protect 239 Neighbor Discovery messages. However, manually configuring security 240 associations among multiple hosts on a large network can be very 241 challenging. SEcure Neighbor Discovery (SEND), as described in 242 [RFC3971], is a mechanism designed to secure ND messages without 243 having to rely on manual IPsec configuration. Cryptographically 244 Generated Addresses (CGA), as described in [RFC3972], are used to 245 ensure that the sender of a Neighbor Discovery message is the actual 246 "owner" of the claimed address. A new NDP option, the CGA option, is 247 used to carry the public key and associated parameters. Another NDP 248 option, the RSA Signature option, is used to protect all messages 249 relating to neighbor and Router discovery. 251 SEND protects against: 253 o Neighbor Solicitation/Advertisement Spoofing 254 o Neighbor Unreachability Detection Failure 256 o Duplicate Address Detection DoS Attack 258 o Router Solicitation and Advertisement Attacks 260 o Replay Attacks 262 o Neighbor Discovery DoS Attacks 264 SEND does NOT: 266 o Protect statically configured addresses 268 o Protect addresses configured using fixed identifiers (i.e. 269 EUI-64) 271 o Provide confidentiality for NDP communications 273 o Compensate for an unsecured link - SEND does not require that the 274 addresses on the link and Neighbor Advertisements correspond 276 2.2.2. DHCP Snooping 278 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in 279 [RFC3315], enables DHCP servers to pass configuration parameters such 280 as IPv6 network addresses and other configuration information to IPv6 281 nodes. DHCP plays an important role in any large network by 282 providing robust stateful autoconfiguration and autoregistration of 283 DNS Host Names. Misconfigured (rogue) or malicious DHCP servers can 284 be leveraged to attack IPv6 nodes either by denying nodes from 285 getting a valid address/prefix or by disseminating incorrect 286 information to end nodes for malicious purposes. Some of these 287 scenarios are discussed in [RFC3315] 289 The Source Address Validation Improvements (SAVI) group is currently 290 working on ways to mitigate the effects of such attacks. 291 [I-D.ietf-savi-dhcp] would help in creating bindings between a DHCPv4 292 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a binding 293 anchor [I-D.ietf-savi-framework] on SAVI (Source Address Validation 294 Improvements) device. [RFC6620] describes how to glean similar 295 bindings when DHCP is not used. The bindings can be used to filter 296 packets generated on the local link with forged source IP address. 298 2.2.3. ND/RA Rate Limiting 300 Neighbor Discovery (ND) can be vulnerable to denial of service (DoS) 301 attacks in which a router is forced to perform address resolution for 302 a large number of unassigned addresses. Possible side effects of 303 this attack preclude new devices from joining the network or even 304 worse rendering the last hop router ineffective due to high CPU 305 usage. Easy mitigative steps include rate limiting Neighbor 306 Solicitations, restricting the amount of state reserved for 307 unresolved solicitations, and clever cache/timer management. 309 [RFC6583] discusses the potential for DOS in detail and suggests 310 mplementation improvements and operational mitigation techniques that 311 may be used to mitigate or alleviate the impact of such attacks. 313 Additionally, IPv6 ND uses multicast extensively for signaling 314 messages on the local link to avoid broadcast messages for on-the- 315 wire efficiency. However, this has some side effects on wifi 316 networks, especially a negative impact on battery life of smartphones 317 and other battery operated devices that are connected to such 318 networks. The following drafts are actively discussing methods to 319 rate limit RAs and other ND messages on wifi networks in order to 320 address this issue: 322 o [I-D.thubert-savi-ra-throttler] 324 o [I-D.chakrabarti-nordmark-energy-aware-nd] 326 2.2.4. ND/RA Filtering 328 Router Advertising spoofing is a well known attack vector and has 329 been extensively documented. The presence of rogue RAs, either 330 intentional or malicious, can cause partial or complete failure of 331 operation of hosts on an IPv6 link. For example, a host can select 332 an incorrect router address which can be used as a man-in-the-middle 333 (MITM) attack or can assume wrong prefixes to be used for stateless 334 address configuration (SLAAC). [RFC6104] summarizes the scenarios in 335 which rogue RAs may be observed and presents a list of possible 336 solutions to the problem. [RFC6105] describes a solution framework 337 for the rogue RA problem where network segments are designed around 338 switching devices that are capable of identifying invalid RAs and 339 blocking them before the attack packets actually reach the target 340 nodes. This mechanism is commonly employed as a first line of 341 defense against common attack vectors. 343 However, several evasion techniques that circumvent the protection 344 provided by RA Guard have surfaced. A key challenge to this 345 mitigation technique is introduced by IPv6 fragmentation. An 346 attacker can conceal the attack by fragmenting his packets into 347 multiple fragments such that the switching device that is responsible 348 for blocking invalid RAs cannot find all the necessary information to 349 perform packet filtering in the same packet. 351 [I-D.ietf-v6ops-ra-guard-implementation] describes such evasion 352 techniques, and provides advice to RA-Guard implementers such that 353 the aforementioned evasion vectors can be eliminated. 355 [I-D.gont-6man-nd-extension-headers] attempts to analyze the security 356 implications of using IPv6 Extension Headers with Neighbor Discovery 357 (ND) messages. The ultimate goal of this doc is to update RFC 4861 358 such that use of the IPv6 Fragmentation Header is forbidden in all 359 Neighbor Discovery messages, thus allowing for simple and effective 360 measures to counter Neighbor Discovery attacks. 362 2.3. Control Plane Security 364 [RFC6192] defines the router control plane and this definition is 365 repeated here for the reader's convenience. 367 Modern router architecture design maintains a strict separation of 368 forwarding and router control plane hardware and software. The 369 router control plane supports routing and management functions. It 370 is generally described as the router architecture hardware and 371 software components for handling packets destined to the device 372 itself as well as building and sending packets originated locally on 373 the device. The forwarding plane is typically described as the 374 router architecture hardware and software components responsible for 375 receiving a packet on an incoming interface, performing a lookup to 376 identify the packet's IP next hop and determine the best outgoing 377 interface towards the destination, and forwarding the packet out 378 through the appropriate outgoing interface. 380 While the forwarding plane is usually implemented in high-speed 381 hardware, the control plane is implemented by a generic processor 382 (named router processor RP) and cannot process packets at a high 383 rate. Hence, this processor can be attacked by flooding its input 384 queue with more packets than it can process. The control plane 385 processor is then unable to process valid control packets and the 386 router can lose OSPF or BGP adjacencies which can cause a severe 387 network disruption. 389 The mitigation technique is: 391 o To drop non legit control packet before they are queued to the RP 392 (this can be done by a forwarding plane ACL) and 394 o To rate limit the remaining packets to a rate that the RP can 395 sustain. 397 This section will consider several classes of control packets: 399 o Control protocols: routing protocols: such as OSPFv3, BGP and by 400 extension Neighbor Discovery and ICMP 402 o Management protocols: SSH, SNMP, IPfix, etc 404 o Packet exceptions: which are normal data packets which requires a 405 specific processing such as generating a packet-too-big ICMP 406 message or having the hop-by-hop extension header. 408 2.3.1. Control Protocols 410 This class includes OSPFv3, BGP, NDP, ICMP. 412 An ingress ACL to be applied on all the router interfaces SHOULD be 413 configured such as: 415 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 416 (identified by UDP port 521) packets from a non link-local address 418 o allow BGP (identified by TCP port 179) packets from all BGP 419 neighbors and drop the others 421 o allow all ICMP packets (transit and to the router interfaces) 423 Note: dropping OSPFv3 packets which are authenticated by IPsec could 424 be impossible on some routers which are unable to parse the IPsec ESP 425 or AH extension headers. 427 Rate limiting of the valid packets SHOULD be done. The exact 428 configuration obviously depends on the power of the Route Processor. 430 2.3.2. Management Protocols 432 This class includes: SSH, SNMP, syslog, IPfix, NTP, etc 434 An ingress ACL to be applied on all the router interfaces SHOULD be 435 configured such as: 437 o Drop packets destined to the routers except those belonging to 438 protocols which are used (for example, permit TCP 22 and drop all 439 when only SSH is used); 441 o Drop packets where the source does not match the security policy, 442 for example if SSH connections should only be originated from the 443 NOC, then the ACL should permit TCP port 22 packets only from the 444 NOC prefix. 446 Rate limiting of the valid packets SHOULD be done. The exact 447 configuration obviously depends on the power of the Route Processor. 449 2.3.3. Packet Exceptions 451 This class covers multiple cases where a data plane packet is punted 452 to the route processor because it requires specific processing: 454 o generation of an ICMP packet-too-big message when a data plane 455 packet cannot be forwarded because it is too large; 457 o generation of an ICMP hop-limit-expired message when a data plane 458 packet cannot be forwarded because its hop-limit field has reached 459 0; 461 o generation of an ICMP destination-unreachable message when a data 462 plane packet cannot be forwarded for any reason; 464 o processing of the hop-by-hop extension header. See 465 [I-D.krishnan-ipv6-hopbyhop] 467 On some routers, not everything can be done by the specialized data 468 plane hardware.. then some packets are 'punted' to the generic RP. 469 This could include for example the processing of a long extension 470 header chain in order to apply an ACL based on layer 4 information. 472 An ingress ACL cannot help to mitigate a control plane attack using 473 those packet exceptions. The only protection for the RP is to limit 474 the rate of those packet exceptions forwarded to the RP, this means 475 that some data plane packets will be dropped with any ICMP messages 476 back to the source which will cause Path MTU holes. But, there is no 477 other solution. 479 In addition to limiting the rate of data plane packets queued to the 480 RP, it is also important to limit the generation rate of ICMP 481 messages both the save the RP but also to prevent an amplification 482 attack using the router as a reflector. 484 2.4. Routing Security 486 Routing security in general can be broadly divided into three 487 sections: 489 1. Authenticating neighbors/peers 491 2. Securing routing updates between peers 493 3. Route filtering 495 2.4.1. Authenticating Neighbors/Peers 497 A basic element of routing is the process of forming adjacencies, 498 neighbor, or peering relationships with other routers. From a 499 security perspective, it is very important to establish such 500 relationships only with routers and/or administrative domains that 501 one trusts. A traditional approach has been to use MD5 passwords, 502 which allows routers to authenticate each other prior to establishing 503 a routing relationship. Most open standard protocols, with the 504 notable exception of OSPFv3, are able to provide this type of 505 authentication mechanism. 507 OSPFv3 relies on IPSEC to fulfill the authentication function. 508 However, it should be noted that IPSEC support is not standard on all 509 routing platforms. In some cases, this requires specialized hardware 510 that offloads crypto over to dedicated ASICs or enhanced software 511 images (both of which often come with added financial cost) to 512 provide such functionality. [RFC6506] changes OSPFv3's reliance on 513 IPSEC by appending an authentication trailer to the end of the OSPFv3 514 packets. This document does not specifically provide for a mechanism 515 that will authenticate the specific originator of a packet. Rather, 516 it will allow a router to confirm that the packet has indeed been 517 issued by a router that had access to the authentication key. 519 2.4.2. Securing Routing Updates Between Peers 521 IPv6 mandates the provisioning of IPSEC capability in all nodes. 522 Theoretically it is possible, and recommended, that communication 523 between two IPv6 nodes, including routers exchanging routing 524 information be encrypted using IPSEC. In practice however, deploying 525 IPSEC is not always feasible given hardware and software limitations 526 of various platforms deployed, as described in the earlier section. 527 Additionally, most key management mechanisms are designed for a one- 528 to-one communication model. However, in a protocol such as OSPFv3 529 where adjacencies are formed on a one-to-many basis, IPSEC key 530 management becomes difficult to maintain. 532 2.4.3. Route Filtering 534 At a minimum, IPv6 routing policy as it pertains to routing between 535 different administrative domains should aim to maintain parity with 536 IPv4 from a policy perspective e.g., 538 o Filter internal-use, non-globally routable IPv6 addresses at the 539 perimeter 541 o Discard packets from and to bogon and reserved space 542 o Configure ingress route filters that validate route origin, prefix 543 ownership, etc. through the use of various routing databases, 544 e.g., RADB. There is additional work being done in this area to 545 formally validate the origin ASs of BGP announcements in 546 [I-D.ietf-sidr-rpki-rtr] 548 2.5. Logging/Monitoring 550 In order to perform forensic research in case of any security 551 incident or to detect abnormal behaviors, network operator should log 552 multiple pieces of information. 554 This includes: 556 o logs of all applications when available (for example web servers); 558 o use of IP Flow Information Export [RFC5102]also known as IPfix; 560 o use of SNMP MIB [RFC4293]; 562 o use of the Neighbor cache; 564 o use of stateful DHCPv6 [RFC3315] lease cache. 566 Please note that there are privacy issues related to how those logs 567 are collected, kept and safely discarded. Operators are urged to 568 check their country legislation. 570 All those pieces of information will be used to do: 572 o forensic (Section 2.5.2.1) research to answer questions such as 573 who did what and when? 575 o correlation (Section 2.5.2.3): which IP addresses were used by a 576 specific node (assuming the use of privacy extensions addresses 577 [RFC4941]) 579 o inventory (Section 2.5.2.2): which IPv6 nodes are on my network? 581 o abnormal behavior detection (Section 2.5.2.4): unusual traffic 582 patterns are often the symptoms of a abnormal behavior which is in 583 turn a potential attack (denial of services, network scan, a node 584 being part of a botnet, ...) 586 2.5.1. Data Sources 588 This section lists the most important sources of data that are useful 589 for operational security. 591 2.5.1.1. Logs of Applications 593 Those logs are usually text files where the remote IPv6 address is 594 stored in all characters (not binary). This can complicate the 595 processing since one IPv6 address, 2001:db8::1 can be written in 596 multiple ways such as: 598 o 2001:DB8::1 (in uppercase) 600 o 2001:0db8::0001 (with leading 0) 602 o and many other ways. 604 RFC 5952 [RFC5952] explains this problem in more details and 605 recommends the use of a single canonical format (in short use lower 606 case and suppress leading 0). This memo recommends the use of 607 canonical format [RFC5952] for IPv6 addresses in all possible cases. 608 If the existing application cannot log under the canonical format, 609 then this memo recommends the use an external program (or filter) in 610 order to canonicalize all IPv6 addresses. 612 For example, this perl script can be used: 613 #!/usr/bin/perl ?w 614 use strict ; 615 use Socket ; 616 use Socket6 ; 618 my (@words, $word, $binary_address) ; 620 ## go through the file one line at a time 621 while (my $line = ) { 622 @words = split /[ \n]/, $line ; 623 foreach $word (@words) { 624 $binary_address = inet_pton AF_INET6, $word ; 625 if ($binary_address) { 626 print inet_ntop AF_INET6, $binary_address ; 627 } else { 628 print $word ; 629 } 630 print " " ; 631 } 632 print "\n" ; 633 } 635 2.5.1.2. IP Flow Information Export by IPv6 Routers 637 IPfix [RFC5102] defines some data elements that are useful for 638 security: 640 o in section 5.4 (IP Header fields): nextHeaderIPv6 and 641 sourceIPv6Address; 643 o in section 5.6 (Sub-IP fields) sourceMacAddress. 645 Moreover, IPfix is very efficient in terms of data handling and 646 transport. It can also aggregate flows by a key such as 647 sourceMacAddress in order to have aggregated data associated with a 648 specific sourceMacAddress. This memo recommends the use of IPfix and 649 aggregation on nextHeaderIPv6, sourceIPv6Address and 650 sourceMacAddress. 652 2.5.1.3. SNMP MIB by IPv6 Routers 654 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 655 the two address families of IP. This memo recommends the use of: 657 o ipIfStatsTable table which collects traffic counters per 658 interface; 660 o ipNetToPhysicalTable table which is the content of the Neighbor 661 cache, i.e. the mapping between IPv6 and data-link layer 662 addresses. 664 2.5.1.4. Neighbor Cache of IPv6 Routers 666 The neighbor cache of routers contains all mappings between IPv4 667 addresses and data-link layer addresses. It is usually available by 668 two means: 670 o the SNMP MIB (Section 2.5.1.3) as explained above; 672 o also by connecting over a secure management channel (such as SSH 673 or HTTPS). 675 The neighbor cache is highly dynamic as mappings are added when a new 676 IPv6 address appears on the network (could be quite often with 677 privacy extension addresses [RFC4941] or when they are removed when 678 the state goes from UNREACH to removed (the default time for a 679 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 680 38 seconds for a typical host such as Windows 7). This means that 681 the content of the neighbor cache must periodically be fetched every 682 30 seconds (to be on the safe side) and stored for later use. 684 This is an important source of information because it is not trivial 685 on a switch using the SAVI [I-D.ietf-savi-framework] algorithm to 686 defeat the mapping between data-link layer address and IPv6 address. 688 2.5.1.5. Stateful DHCPv6 Lease 690 In some networks, IPv6 addresses are managed by stateful DHCPv6 691 server [RFC3315] that leases IPv6 addresses to clients. It is indeed 692 quite similar to DHCP for IPv4 so it can be tempting to use this DHCP 693 lease file to discover the mapping between IPv6 addresses and data- 694 link layer addresses as it was usually done in the IPv4 era. 696 It is not so easy in the IPv6 world because not all nodes will use 697 DHCPv6 (there are nodes which can only do stateless 698 autoconfiguration) but also because DHCPv6 clients are identified not 699 by their hardware-client address as in IPv4 but by a DHCP Unique ID 700 (DUID) which can have several formats: some being the data-link layer 701 address, some being data-link layer address prepended with time 702 information or even an opaque number which is useless for operation 703 security. Moreover, when the DUID is based on the data-link address, 704 this address can be of any interface of the client (such as the 705 wireless interface while the client actually uses its wired interface 706 to connect to the network). 708 In short, the DHCPv6 lease file is less interesting than in the IPv4 709 era. DHCPv6 servers that keeps the relayed data-link layer address 710 in addition to the DUID in the lease file do not suffer from this 711 limitation. Special care must be taken to prevent stateless 712 autoconfiguration anyway (and if applicable) by sending RA with all 713 announced prefixes without the A-bit set. 715 The mapping between data-link layer address and the IPv6 address can 716 be secured by using switches implementing the SAVI 717 [I-D.ietf-savi-dhcp] algorithms. 719 2.5.1.6. Other Data Sources 721 There are other data sources that must be kept exactly as in the IPv4 722 network: 724 o historical mapping of MAC address to RADIUS user authentication in 725 a wireless network or an IPsec-based remote access VPN; 727 o historical mapping of MAC address to switch interface in a wired 728 network. 730 2.5.2. Use of Collected Data 732 This section leverages the data collected as described before 733 (Section 2.5.1) in order to achieve several security benefits. 735 2.5.2.1. Forensic 737 The forensic use case is when the network operator must locate an 738 IPv6 address that was present in the network at a certain time or is 739 still currently in the network. 741 The source of information can be, in decreasing order, neighbor 742 cache, DHCP lease file. Then, the procedure is: 744 1. based on the IPv6 prefix of the IPv6 address find the router(s) 745 which are used to reach this prefix; 747 2. based on this limited set of routers, on the incident time and on 748 IPv6 address to retrieve the data-link address from live neighbor 749 cache, from the historical data of the neighbor cache, or from 750 the DHCP lease file; 752 3. based on the data-link layer address, look-up on which switch 753 interface was this data-link layer address. In the case of 754 wireless LAN, the RADIUS log should have the mapping between user 755 identification and the MAC address. 757 At the end of the process, the interface where the malicious user was 758 connected or the username that was used by the malicious user is 759 found. 761 2.5.2.2. Inventory 763 RFC 5157 [RFC5157] is about the difficulties to scan an IPv6 network 764 due to the vast number of IPv6 addresses per link. This has the side 765 effect of making the inventory task difficult in an IPv6 network 766 while it was trivial to do in an IPv4 network (a simple enumeration 767 of all IPv4 addresses, followed by a ping and a TCP/UDP port scan). 768 Getting an inventory of all connected devices is of prime importance 769 for a secure operation of a network. 771 There are two ways to do an inventory of an IPv6 network. 773 The first technique is to use the IPfix information and extract the 774 list of all IPv6 source addresses to find all IPv6 nodes that sent 775 packets through a router. This is very efficient but alas will not 776 discover silent node that never transmitted such packets... Also, it 777 must be noted that link-local addresses will never be discovered by 778 this means. 780 The second way is again to use the collected neighbor cache content 781 to find all IPv6 addresses in the cache. This process will also 782 discover all link-local addresses. 784 2.5.2.3. Correlation 786 In an IPv4 network, it is easy to correlate multiple logs, for 787 example to find events related to a specific IPv4 address. A simple 788 Unix grep command was enough to scan through multiple text-based 789 files and extract all lines relevant to a specific IPv4 address. 791 In an IPv6 network, this is slightly more difficult because different 792 character strings can express the same IPv6 address. Therefore, the 793 simple Unix grep command cannot be used. Moreover, an IPv6 node can 794 have multiple IPv6 addresses... 796 In order to do correlation in IPv6-related logs, it is advised to 797 have all logs with canonical IPv6 addresses. Then, the neighbor 798 cache current (or historical) data set must be searched to find the 799 data-link layer address of the IPv6 address. Then, the current and 800 historical neighbor cache data sets must be searched for all IPv6 801 addresses associated to this data-link layer address: this is the 802 search set. The last step is to search in all log files (containing 803 only IPv6 address in canonical format) for any IPv6 addresses in the 804 search set. 806 2.5.2.4. Abnormal Behavior Detection 808 Abnormal behaviors (such as network scanning, spamming, denial of 809 service) can be detected in the same way as in an IPv4 network 811 o sudden increase of traffic detected by interface counter (SNMP) or 812 by aggregated traffic from IPfix records [RFC5102]; 814 o change of traffic pattern (number of connection per second, number 815 of connection per host...) with the use of IPfix [RFC5102] 817 2.5.3. Summary 819 While some data sources (IPfix, MIB, switch CAM tables, logs, ...) 820 are also used in the secure operation of an IPv6 network, the DHCPv6 821 lease file is less reliable and the neighbor cache is of prime 822 importance. 824 The fact that there are multiple ways to express in a character 825 string the same IPv6 address renders the use of filters mandatory 826 when correlation must be done. 828 2.6. Transition/Coexistence Technologies 830 Some text 832 2.6.1. Dual Stack 834 Dual stack has established itself as the preferred deployment choice 835 for most network operators. Dual stacking the network offers many 836 advantages over other transition mechanisms. Firstly, it is easy to 837 turn on without impacting normal IPv4 operations. Secondly, perhaps 838 more importantly, it is easier to troubleshoot when things break. 839 Dual stack allows you to gradually turn IPv4 operations down when 840 your IPv6 network is ready for prime time. 842 From an operational security perspective, this now means that you 843 have twice the exposure. One needs to think about protecting both 844 protocols now. At a minimum, the IPv6 portion of a dual stacked 845 network should maintain parity with IPv4 from a security policy point 846 of view. Typically, the following methods are employed to protect 847 IPv4 networks at the edge: 849 o ACLs to permit or deny traffic 851 o Firewalls with stateful packet inspection 853 It is recommended that these ACLs and/or firewalls be additionally 854 configured to protect IPv6 communications. Also, given the end-to- 855 end connectivity that IPv6 provides, it is also recommended that 856 hosts be fortified against threats. General device hardening 857 guidelines are provided in Section 2.7 859 2.6.2. Tunneling Mechanisms 861 There are many tunnels used for specific use cases. Except when 862 protected by IPsec [RFC4301], all those tunnels have a couple of 863 security issues (most of them being described in RFC 6169 [RFC6169]); 865 o tunnel injection: a malevolent person knowing a few pieces of 866 information (for example the tunnel endpoints and the used 867 protocol) can forge a packet which looks like a legit and valid 868 encapsulated packet that will gladly be accepted by the 869 destination tunnel endpoint, this is a specific case of spoofing; 871 o traffic interception: no confidentiality is provided by the tunnel 872 protocols (without the use of IPsec), therefore anybody on the 873 tunnel path can intercept the traffic and have access to the 874 clear-text IPv6 packet; 876 o service theft: as there is no authorization, even a non authorized 877 user can use a tunnel relay for free (this is a specific case of 878 tunnel injection); 880 o reflection attack: another specific use case of tunnel injection 881 where the attacker injects packets with an IPv4 destination 882 address not matching the IPv6 address causing the first tunnel 883 endpoint to re-encapsulate the packet to the destination... 884 Hence, the final IPv4 destination will not see the original IPv4 885 address but only one IPv4 address of the relay router. 887 o bypassing security policy: if a firewall or an IPS is on the path 888 of the tunnel, then it will probably neither inspect not detect an 889 malevolent IPv6 traffic contained in the tunnel. 891 To mitigate the bypassing of security policies, it could be helpful 892 to block all default configuration tunnels by denying all IPv4 893 traffic matching: 895 o IP protocol 41: this will block ISATAP (Section 2.6.2.2), 6to4 896 (Section 2.6.2.4), 6rd (Section 2.6.2.5) as well as 6in4 897 (Section 2.6.2.1) tunnels; 899 o IP protocol 47: this will block GRE (Section 2.6.2.1) tunnels; 901 o UDP protocol 3544: this will block the default encapsulation of 902 Teredo (Section 2.6.2.3) tunnels. 904 Ingress filtering [RFC2827] should also be applied on all tunnel 905 endpoints if applicable to prevent IPv6 address spoofing. 907 As several of the tunnel techniques share the same encapsulation 908 (i.e. IPv4 protocol 41) and embeb the IPv4 address in the IPv6 909 address, there are a set of well-known looping attacks described in 910 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 912 2.6.2.1. Site-to-Site Static Tunnels 914 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 915 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 916 and are not dynamic they are slightly more secure (bi-directional 917 service theft is mostly impossible) but traffic interception ad 918 tunnel injection are still possible. Therefore, the use of IPsec 919 [RFC4301] in transport mode and protecting the encapsulated IPv4 920 packets is recommended for those tunnels. Alternatively, IPsec in 921 tunnel mode can be used to transport IPv6 traffic over a non-trusted 922 IPv4 network. 924 2.6.2.2. ISATAP 926 ISATAP tunnels [RFC5214] are mainly using within a single 927 administrative domain and to connect a single IPv6 host to the IPv6 928 network. This means that endpoints and and the tunnel endpoint are 929 usually managed by a single entity; therefore, audit trail and strict 930 anti-spoofing are usually possible and this raises the overall 931 security. 933 Special care must be taken to avoid looping attack by implementing 934 the measures of RFC 6324 [RFC6324] and of [I-D.templin-v6ops-isops]. 936 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 937 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 938 prevent service theft. 940 2.6.2.3. Teredo 942 Teredo tunnels [RFC4380] are mainly used in a residential environment 943 because that can easily traverse an IPv4 NAT-PT device thanks to its 944 UDP encapsulation and they connect a single host to the IPv6 945 Internet. Teredo shares the same issues as other tunnels: no 946 authentication, no confidentiality, possible spoofing and reflection 947 attacks. 949 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 951 The biggest threat to Teredo is probably for IPv4-only network as 952 Teredo has been designed to easily traverse IPV4 NAT-PT devices which 953 are quite often co-located with a stateful firewall. Therefore, if 954 the stateful IPv4 firewall allows unrestricted UDP outbound and 955 accept the return UDP traffic, then Teredo actually punches a hole in 956 this firewall for all IPv6 traffic to the Internet and from the 957 Internet. While host policies can be deployed to block Teredo in an 958 IPv4-only network in order to avoid this firewall bypass, it would be 959 more efficient to block all UDP outbound traffic at the IPv4 firewall 960 if deemed possible (of course, at least port 53 should be left open 961 for DNS traffic). 963 2.6.2.4. 6to4 965 6to4 tunnels [RFC3056] require a public routable IPv4 address in 966 order to work correctly. They can be used to provide either one IPv6 967 host connectivity to the IPv6 Internet or multiple IPv6 networks 968 connectivity to the IPV6 Internet. The 6to4 relay is usually the 969 anycast address defined in [RFC3068] 970 They suffer from several technical issues as well as security issues 971 [RFC3964]. Their use is no more recommended (see 972 [I-D.ietf-v6ops-6to4-to-historic]). 974 2.6.2.5. 6rd 976 While 6rd tunnels share the same encapsulation as 6to4 tunnels 977 (Section 2.6.2.4), they are designed to be used within a single SP 978 domain, in other words they are deployed in a more constrained 979 environment than 6to4 tunnels and have little security issues except 980 lack of confidentiality. The security considerations (Section 12) of 981 [RFC5969] describes how to secure the 6rd tunnels. 983 IPsec [RFC4301] for the transported IPv6 traffic can be used if 984 confidentiality is important. 986 2.6.2.6. DS-Lite 988 DS-lite is more a translation mechanism and is therefore analyzed 989 further (Section 2.6.3.3) in this document. 991 2.6.2.7. Mapping of Address and Port 993 With the tunnel and encapsulation versions of Mapping of Address and 994 Port (MAP [I-D.ietf-softwire-map]), the access network is purely an 995 IPv6 network and MAP protocols are used to give IPv4 hosts on the 996 subscriber network to IPv4 hosts on the Internet. The subscriber 997 router does stateful operations in order to map all internal IPv4 998 addresses and layer-4 ports to the IPv4 address and the set of 999 layer-4 ports received through MAP configuration process. The SP 1000 equipment always does stateless operations (either decapsulation or 1001 stateless translation). Therefore, as opposed to Section 2.6.3.3 1002 there is no DoS attack against the SP equipment because there is no 1003 state and there is no operation caused by a new layer-4 connection 1004 (no logging operation). 1006 The SP MAP equipment MUST implement all the security considerations 1007 of [I-D.ietf-softwire-map]; notably, ensuring that the mapping of the 1008 IPv4 address and port are consistent with the configuration. 1010 2.6.3. Translation Mechanisms 1012 Some text 1014 2.6.3.1. Carrier Grade Nat (CGN) 1016 Some text 1018 2.6.3.2. NAT64/DNS64 1020 Some text 1022 2.6.3.3. DS-lite 1024 Some text 1026 2.7. General Device Hardening 1028 There are many environments which rely too much on the network 1029 infrastructure to disallow malicious traffic to get access to 1030 critical hosts. In new IPv6 deployments it has been common to see 1031 IPv6 traffic enabled but none of the typical access control 1032 mechanisms enabled for IPv6 device access. With the possibility of 1033 network device configuration mistakes and the growth of IPv6 in the 1034 overall Internet it is important to ensure that all individual 1035 devices are hardened agains miscreant behavior. 1037 The following guidelines should be used to ensure appropriate 1038 hardening of the host, be it an individual computer or router, 1039 firewall, load-balancer,server, etc device. 1041 o Restrict access to the device to authenticated and authorized 1042 individuals 1044 o Monitor and audit access to the device 1046 o Turn off any unused services on the end node 1048 o Understand which IPv6 addresses are being used to source traffic 1049 and change defaults if necessary 1051 o Use cryptographically protected protocols for device management if 1052 possible (SCP, SNMPv3, SSH, TLS, etc) 1054 o Use host firewall capabilities to control traffic that gets 1055 processed by upper layer protocols 1057 o Use virus scanners to detect malicious programs 1059 3. Enterprises Specific Security Considerations 1061 Enterprises generally have robust network security policies in place 1062 to protect existing IPv4 networks. These policies have been 1063 distilled from years of experiential knowledge of securing IPv4 1064 networks. At the very least, it is recommended that enterprise 1065 networks have parity between their security policies for both 1066 protocol versions. 1068 Security considerations in the enterprise can be broadly categorized 1069 into two sections - External and Internal. 1071 3.1. External Security Considerations: 1073 The external aspect deals with providing security at the edge or 1074 perimeter of the enterprise network where it meets the service 1075 providers network. This is commonly achieved by filtering traffic 1076 either by implementing dedicated firewalls with stateful packet 1077 inspection or a router with ACLs. A common default IPv4 policy on 1078 firewalls that could easily be ported to IPv6 is to allow all traffic 1079 outbound while only allowing specific traffic, such as established 1080 sessions, inbound. Here are a few more things that could enhance the 1081 default policy: 1083 o Filter internal-use IPv6 addresses at the perimeter 1085 o Discard packets from and to bogon and reserved space 1087 o Accept certain ICMPv6 messages to allow proper operation of ND and 1088 PMTUD, see also [RFC4890] 1090 o Filter specific extension headers, where possible 1092 o Filter unneeded services at the perimeter 1094 o Implement Anti-Spoof filtering 1096 o Implement appropriate rate-limiters and control-plane policers 1098 3.2. Internal Security Considerations: 1100 The internal aspect deals with providing security inside the 1101 perimeter of the network, including the end host. The most 1102 significant concerns here are related to Neighbor Discovery. At the 1103 network level, it is recommended that all security considerations 1104 discussed in Section 2.2 be reviewed carefully and the 1105 recommendations be considered in-depth as well. 1107 Hosts need to be hardened directly through security policy to protect 1108 against security threats. The host firewall default capabilities 1109 have to be clearly understood, especially 3rd party ones which can 1110 have different settings for IPv4 or IPv6 default permit/deny 1111 behavior. In some cases, 3rd party firewalls have no IPv6 support 1112 whereas the native firewall installed by default has it. General 1113 device hardening guidelines are provided in Section 2.7 1115 It should also be noted that many hosts still use IPv4 for transport 1116 for things like RADIUS, TACACS+, SYSLOG, etc. This will require some 1117 extra level of due diligence on the part of the operator. 1119 4. Service Providers Security Considerations 1121 4.1. BGP 1123 tbd 1125 4.1.1. Remote Triggered Black Hole 1127 tbd 1129 4.2. Transition Mechanism 1131 tbd: will need to reference the security considerations of relevant 1132 RFC. 1134 4.2.1. 6PE and 6VPE 1136 tbd. 1138 4.2.2. 6rd 1140 tbd. refer to 6rd section (Section 2.6.2.5) 1142 4.2.3. DS-lite 1144 tbd. 1146 4.3. Lawful Intercept 1148 tbd. 1150 5. Residential Users Security Considerations 1152 The IETF Homenet working group is working on how IPv6 residential 1153 network should be done; this obviously includes operational security 1154 considerations; but, this is still work in progress. 1156 Residential networks have usually little clue about security or 1157 networking. As most of the recent hosts, smartphones, tablets have 1158 all IPv6 enabled by default, IPv6 security is important for those 1159 users. Even with an IPv4-only ISP, those users can get IPv6 Internet 1160 access with the help of Teredo tunnels. Several peer-to-peer 1161 programs (notably Bittorrent) support IPv6 and those programs can 1162 initiate a Teredo tunnel through the IPv4 residential gateway, with 1163 the consequence of making the internal host reachable from any IPv6 1164 host on the Internet. It is therefore recommended that all host 1165 security products (personal firewall, ...) are configured with a 1166 dual-stack security policy. 1168 If the Residential Gateway has IPv6 connectivity, [RFC6204] defines 1169 the requirements of an IPv6 CPE and does not take position on the 1170 debate of default IPv6 security policy: 1172 o outbound only: allowing all internally initiated connections and 1173 block all externally initiated ones, which is a common default 1174 security policy enforced by IPv4 Residential Gateway doing NAT-PT 1175 but it also breaks the end-to-end reachability promise of IPv6. 1176 [RFC6092] lists several recommendations to design such a CPE; 1178 o open: allowing all internally and externally initiated 1179 connections, therefore restauring the end-to-end nature of the 1180 Internet for the IPv6 traffic but having a different security 1181 policy for IPv6 than for IPv4. 1183 [RFC6204] states that a clear choice must be given to the user to 1184 select one of those two policies. 1186 6. Acknowledgements 1188 7. IANA Considerations 1190 This memo includes no request to IANA. 1192 8. Security Considerations 1194 This memo attempts to give an overview of security considerations of 1195 operating an IPv6 network both in an IPv6-only network but also in a 1196 dual-stack environment. 1198 9. References 1199 9.1. Normative References 1201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1202 Requirement Levels", BCP 14, RFC 2119, March 1997. 1204 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1205 Problem Statement", RFC 6104, February 2011. 1207 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1208 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1209 February 2011. 1211 9.2. Informative References 1213 [I-D.chakrabarti-nordmark-energy-aware-nd] 1214 Chakrabarti, S., Nordmark, E., and M. Wasserman, "Energy 1215 Aware IPv6 Neighbor Discovery Optimizations", 1216 draft-chakrabarti-nordmark-energy-aware-nd-02 (work in 1217 progress), March 2012. 1219 [I-D.gont-6man-nd-extension-headers] 1220 Gont, F., "Security Implications of the Use of IPv6 1221 Extension Headers with IPv6 Neighbor Discovery", 1222 draft-gont-6man-nd-extension-headers-03 (work in 1223 progress), June 2012. 1225 [I-D.ietf-savi-dhcp] 1226 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 1227 DHCP", draft-ietf-savi-dhcp-14 (work in progress), 1228 July 2012. 1230 [I-D.ietf-savi-framework] 1231 Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1232 "Source Address Validation Improvement Framework", 1233 draft-ietf-savi-framework-06 (work in progress), 1234 January 2012. 1236 [I-D.ietf-sidr-rpki-rtr] 1237 Bush, R. and R. Austein, "The RPKI/Router Protocol", 1238 draft-ietf-sidr-rpki-rtr-26 (work in progress), 1239 February 2012. 1241 [I-D.ietf-softwire-map] 1242 Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, 1243 S., and T. Murakami, "Mapping of Address and Port (MAP)", 1244 draft-ietf-softwire-map-01 (work in progress), June 2012. 1246 [I-D.ietf-v6ops-6to4-to-historic] 1247 Troan, O., "Request to move Connection of IPv6 Domains via 1248 IPv4 Clouds (6to4) to Historic status", 1249 draft-ietf-v6ops-6to4-to-historic-05 (work in progress), 1250 June 2011. 1252 [I-D.ietf-v6ops-ra-guard-implementation] 1253 Gont, F., "Implementation Advice for IPv6 Router 1254 Advertisement Guard (RA-Guard)", 1255 draft-ietf-v6ops-ra-guard-implementation-04 (work in 1256 progress), May 2012. 1258 [I-D.krishnan-ipv6-hopbyhop] 1259 Krishnan, S., "The case against Hop-by-Hop options", 1260 draft-krishnan-ipv6-hopbyhop-05 (work in progress), 1261 October 2010. 1263 [I-D.templin-v6ops-isops] 1264 Templin, F., "Operational Guidance for IPv6 Deployment in 1265 IPv4 Sites using ISATAP", draft-templin-v6ops-isops-17 1266 (work in progress), May 2012. 1268 [I-D.thubert-savi-ra-throttler] 1269 Thubert, P., "Throttling RAs on constrained interfaces", 1270 draft-thubert-savi-ra-throttler-01 (work in progress), 1271 June 2012. 1273 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1274 converting network protocol addresses to 48.bit Ethernet 1275 address for transmission on Ethernet hardware", STD 37, 1276 RFC 826, November 1982. 1278 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1279 RFC 2131, March 1997. 1281 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1282 Domains without Explicit Tunnels", RFC 2529, March 1999. 1284 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1285 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1286 March 2000. 1288 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1289 Defeating Denial of Service Attacks which employ IP Source 1290 Address Spoofing", BCP 38, RFC 2827, May 2000. 1292 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1293 Address Translator (Traditional NAT)", RFC 3022, 1294 January 2001. 1296 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1297 via IPv4 Clouds", RFC 3056, February 2001. 1299 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1300 RFC 3068, June 2001. 1302 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1303 and M. Carney, "Dynamic Host Configuration Protocol for 1304 IPv6 (DHCPv6)", RFC 3315, July 2003. 1306 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1307 Discovery (ND) Trust Models and Threats", RFC 3756, 1308 May 2004. 1310 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1311 6to4", RFC 3964, December 2004. 1313 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1314 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1316 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1317 RFC 3972, March 2005. 1319 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1320 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1322 [RFC4293] Routhier, S., "Management Information Base for the 1323 Internet Protocol (IP)", RFC 4293, April 2006. 1325 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1326 Internet Protocol", RFC 4301, December 2005. 1328 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1329 Network Address Translations (NATs)", RFC 4380, 1330 February 2006. 1332 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1333 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1334 September 2007. 1336 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1337 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1339 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1340 Extensions for Stateless Address Autoconfiguration in 1341 IPv6", RFC 4941, September 2007. 1343 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1344 Co-existence Security Considerations", RFC 4942, 1345 September 2007. 1347 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1348 Meyer, "Information Model for IP Flow Information Export", 1349 RFC 5102, January 2008. 1351 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1352 RFC 5157, March 2008. 1354 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1355 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1356 March 2008. 1358 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1359 Address Text Representation", RFC 5952, August 2010. 1361 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1362 Infrastructures (6rd) -- Protocol Specification", 1363 RFC 5969, August 2010. 1365 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1366 Customer Premises Equipment (CPE) for Providing 1367 Residential IPv6 Internet Service", RFC 6092, 1368 January 2011. 1370 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1371 Concerns with IP Tunneling", RFC 6169, April 2011. 1373 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1374 Router Control Plane", RFC 6192, March 2011. 1376 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1377 Troan, "Basic Requirements for IPv6 Customer Edge 1378 Routers", RFC 6204, April 2011. 1380 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1381 IPv6 Automatic Tunnels: Problem Statement and Proposed 1382 Mitigations", RFC 6324, August 2011. 1384 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1385 Authentication Trailer for OSPFv3", RFC 6506, 1386 February 2012. 1388 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1389 Neighbor Discovery Problems", RFC 6583, March 2012. 1391 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1392 SAVI: First-Come, First-Served Source Address Validation 1393 Improvement for Locally Assigned IPv6 Addresses", 1394 RFC 6620, May 2012. 1396 [evyncke_book] 1397 Hogg and Vyncke, "IPv6 Security", ISBN 1-58705-594-5, 1398 Publisher CiscoPress, December 2008. 1400 Authors' Addresses 1402 Kiran Kumar Chittimaneni 1403 Google 1404 1600 Amphitheater Pkwy 1405 Mountain View 94043 1406 USA 1408 Phone: +16502249772 1409 Email: kk@google.com 1411 Merike Kaeo 1412 ISC 1413 950 Charter Street 1414 Redwood City 94063 1415 USA 1417 Phone: +12066696394 1418 Email: merike@doubleshotsecurity.com 1420 Eric Vyncke 1421 Cisco Systems 1422 De Kleetlaan 6a 1423 Diegem 1831 1424 Belgium 1426 Phone: +32 2 778 4677 1427 Email: evyncke@cisco.com