idnits 2.17.1 draft-ietf-opsec-v6-10.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 : ---------------------------------------------------------------------------- == 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2600 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 ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) -- 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 3627 (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 6506 (Obsoleted by RFC 7166) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC K. Chittimaneni 3 Internet-Draft Dropbox Inc. 4 Intended status: Informational M. Kaeo 5 Expires: September 14, 2017 Double Shot Security 6 E. Vyncke, Ed. 7 Cisco 8 March 13, 2017 10 Operational Security Considerations for IPv6 Networks 11 draft-ietf-opsec-v6-10 13 Abstract 15 Knowledge and experience on how to operate IPv4 securely is 16 available: whether it is the Internet or an enterprise internal 17 network. However, IPv6 presents some new security challenges. RFC 18 4942 describes the security issues in the protocol but network 19 managers also need a more practical, operations-minded document to 20 enumerate advantages and/or disadvantages of certain choices. 22 This document analyzes the operational security issues in all places 23 of a network (enterprises, service providers and residential users) 24 and proposes technical and procedural mitigations techniques. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 14, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Generic Security Considerations . . . . . . . . . . . . . . . 4 63 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 64 2.1.1. Statically Configured Addresses . . . . . . . . . . . 4 65 2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5 66 2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . 6 67 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC . 6 68 2.1.5. Privacy consideration of Addresses . . . . . . . . . 7 69 2.1.6. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7 70 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 7 71 2.2.1. Order and Repetition of Extension Headers . . . . . . 8 72 2.2.2. Hop-by-Hop Extension Header . . . . . . . . . . . . . 8 73 2.2.3. Fragmentation Extension Header . . . . . . . . . . . 8 74 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 8 75 2.3.1. SeND and CGA . . . . . . . . . . . . . . . . . . . . 9 76 2.3.2. Securing DHCP . . . . . . . . . . . . . . . . . . . . 10 77 2.3.3. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 10 78 2.3.4. ND/RA Filtering . . . . . . . . . . . . . . . . . . . 11 79 2.3.5. 3GPP Link-Layer Security . . . . . . . . . . . . . . 12 80 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 12 81 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 13 82 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 14 83 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 14 84 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 15 85 2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 15 86 2.5.2. Securing Routing Updates Between Peers . . . . . . . 16 87 2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 17 88 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 17 89 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 18 90 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 21 91 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 24 92 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 24 93 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 24 94 2.7.2. Transition Mechanisms . . . . . . . . . . . . . . . . 24 95 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 28 97 2.8. General Device Hardening . . . . . . . . . . . . . . . . 30 98 3. Enterprises Specific Security Considerations . . . . . . . . 30 99 3.1. External Security Considerations: . . . . . . . . . . . . 31 100 3.2. Internal Security Considerations: . . . . . . . . . . . . 31 101 4. Service Providers Security Considerations . . . . . . . . . . 32 102 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 32 104 4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . 32 105 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 32 106 5. Residential Users Security Considerations . . . . . . . . . . 33 107 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 34 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 113 10.2. Informative References . . . . . . . . . . . . . . . . . 35 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 116 1. Introduction 118 Running an IPv6 network is new for most operators not only because 119 they are not yet used to large scale IPv6 networks but also because 120 there are subtle differences between IPv4 and IPv6 especially with 121 respect to security. For example, all layer-2 interactions are now 122 done using Neighbor Discovery Protocol [RFC4861] rather than using 123 Address Resolution Protocol [RFC0826]. Also, there are subtle 124 differences between NAT44 [RFC2993] and NPTv6 [RFC6296] which are 125 explicitly pointed out in the latter's security considerations 126 section. 128 IPv6 networks are deployed using a variety of techniques, each of 129 which have their own specific security concerns. 131 This document complements [RFC4942] by listing all security issues 132 when operating a network utilizing varying transition technologies 133 and updating with ones that have been standardized since 2007. It 134 also provides more recent operational deployment experiences where 135 warranted. 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119] when they 142 appear in ALL CAPS. These words may also appear in this document in 143 lower case as plain English words, absent their normative meanings. 145 2. Generic Security Considerations 147 2.1. Addressing Architecture 149 IPv6 address allocations and overall architecture are an important 150 part of securing IPv6. Initial designs, even if intended to be 151 temporary, tend to last much longer than expected. Although 152 initially IPv6 was thought to make renumbering easy, in practice, it 153 may be extremely difficult to renumber without a good IP Addresses 154 Management (IPAM) system. 156 Once an address allocation has been assigned, there should be some 157 thought given to an overall address allocation plan. With the 158 abundance of address space available, an address allocation may be 159 structured around services along with geographic locations, which 160 then can be a basis for more structured security policies to permit 161 or deny services between geographic regions. 163 A common question is whether companies should use PI vs PA space 164 [RFC7381], but from a security perspective there is little 165 difference. However, one aspect to keep in mind is who has 166 administrative ownership of the address space and who is technically 167 responsible if/when there is a need to enforce restrictions on 168 routability of the space due to malicious criminal activity. 170 2.1.1. Statically Configured Addresses 172 When considering how to assign statically configured addresses it is 173 necessary to take into consideration the effectiveness of perimeter 174 security in a given environment. There is a trade-off between ease 175 of operational deployment where some portions of the IPv6 address 176 could be easily recognizable for operational debugging and 177 troubleshooting versus the risk of scanning; [SCANNING] shows that 178 there are scientifically based mechanisms that make scanning for IPv6 179 reachable nodes more realizable than expected; see also [RFC7707]. 180 The use of common multicast groups which are defined for important 181 networked devices and the use of commonly repeated addresses could 182 make it easy to figure out which devices are name servers, routers or 183 other critical devices. 185 While in some environments the security is so poor that obfuscating 186 addresses is considered a benefit; it is a better practice to ensure 187 that perimeter rules are actively checked and enforced and that 188 statically configured addresses follow some logical allocation scheme 189 for ease of operation. 191 2.1.2. Use of ULAs 193 ULAs are intended for scenarios where IP addresses will not have 194 global scope so they should not appear in the global BGP routing 195 table. The implicit expectation from the RFC is that all ULAs will 196 be randomly created as /48s. Any use of ULAs that are not created as 197 a /48 violates RFC4193 [RFC4193]. 199 ULAs could be useful for infrastructure hiding as described in 200 RFC4864 [RFC4864]. Alternatively Link-Local addresses RFC7404 201 [RFC7404] could also be used. Although ULAs are supposed to be used 202 in conjunction with global addresses for hosts that desire external 203 connectivity, a few operators chose to use ULAs in conjunction with 204 some sort of address translation at the border in order to maintain a 205 perception of parity between their IPv4 and IPv6 setup. Some 206 operators believe that stateful IPv6 Network Address and Port 207 Translation (NAPT) provides some security not provided by NPTv6 (the 208 authors of this document do not share this point of view). The use 209 of stateful IPv6 NAPT would be problematic in trying to track 210 specific machines that may source malware although this is less of an 211 issue if appropriate logging is done which includes utilizing 212 accurate timestamps and logging a node's source ports RFC6302 213 [RFC6302]. Another typical argument in favor of ULA is that there 214 are too many mistakes made with ACL filters at the edge and the use 215 of ULAs could make things easier to set filters. 217 The use of ULA does not isolate 'by magic' the part of the network 218 using ULA from other parts of the network (including the Internet). 219 Although section 4.1 of RFC4193 [RFC4193] explicitly states "If BGP 220 is being used at the site border with an ISP, the default BGP 221 configuration must filter out any Local IPv6 address prefixes, both 222 incoming and outgoing.", the operational reality is that this 223 guideline is not always followed. As written, RFC4193 makes no 224 changes to default routing behavior of exterior protocols. 225 Therefore, routers will happily forward packets whose source or 226 destination address is ULA as long as they have a route to the 227 destination and there is no ACL blocking those packets. This means 228 that using ULA does not prevent route and packet filters having to be 229 implemented and monitored. This also means that all Internet transit 230 networks should consider ULA as source or destination as bogons 231 packets and drop them. 233 It is important to carefully weigh the benefits of using ULAs versus 234 utilizing a section of the global allocation and creating a more 235 effective filtering strategy. It is also important to note that the 236 IETF does not recommend the use of ULA and NPTv6. 238 2.1.3. Point-to-Point Links 240 RFC6164 [RFC6164] recommends the use of /127 for inter-router point- 241 to-point links. A /127 prevents the ping-pong attack between 242 routers. However, it should be noted that at the time of this 243 writing, there are still many networks out there that follow the 244 advice provided by RFC3627 [RFC3627] (obsoleted and marked Historic 245 by RFC6547 [RFC6547]) and therefore continue to use /64's and/or 246 /112's. We recommend that the guidance provided by RFC6164 be 247 followed. 249 Some environments are also using link-local addressing for point-to- 250 point links. While this practice could further reduce the attack 251 surface against infrastructure devices, the operational disadvantages 252 need also to be carefully considered RFC7404 [RFC7404]. 254 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC 256 Normal stateless address autoconfiguration (SLAAC) relies on the 257 automatically generated EUI-64 address, which together with the /64 258 prefix makes up the global unique IPv6 address. The EUI-64 address 259 is generated from the MAC address. Randomly generating an interface 260 ID, as described in [RFC4941], is part of SLAAC with so-called 261 privacy extension addresses and used to address some privacy 262 concerns. Privacy extension addresses a.k.a. temporary addresses may 263 help to mitigate the correlation of activities of a node within the 264 same network, and may also reduce the attack exposure window. 266 As privacy extension addresses could also be used to obfuscate some 267 malevolent activities (whether on purpose or not), it is advised in 268 scenarios where user attribution is important to rely on a layer-2 269 authentication mechanism such as IEEE 802.1X [IEEE-802.1X] with the 270 appropriate RADIUS accounting (Section 2.6.1.6) or to disable SLAAC 271 and rely only on DHCPv6. However, in scenarios where anonymity is a 272 strong desire (protecting user privacy is more important than user 273 attribution), privacy extension addresses should be used. 275 Using privacy extension addresses prevents the operator from building 276 a priori host specific access control lists (ACLs). It must be noted 277 that recent versions of Windows do not use the MAC address anymore to 278 build the stable address but use a mechanism similar to the one 279 described in [RFC7217], this also means that such an ACL cannot be 280 configured based solely on the MAC address of the nodes, diminishing 281 the value of such ACL. On the other hand, different VLANs are often 282 used to segregate users, in this case ACL can rely on a /64 prefix 283 per VLAN rather than a per host ACL entry. 285 The decision to utilize privacy extension addresses can come down to 286 whether the network is managed versus unmanaged. In some 287 environments full visibility into the network is required at all 288 times which requires that all traffic be attributable to where it is 289 sourced or where it is destined to within a specific network. This 290 situation is dependent on what level of logging is performed. If 291 logging considerations include utilizing accurate timestamps and 292 logging a node's source ports [RFC6302] then there should always 293 exist appropriate user attribution needed to get to the source of any 294 malware originator or source of criminal activity. 296 Disabling SLAAC and privacy extensions addresses can be done by 297 sending Router Advertisement with a hint to get addresses via DHCPv6 298 by setting the M-bit but also disabling SLAAC by resetting all A-bits 299 in all prefix information options sent in the Router Advertisement 300 message. 302 2.1.5. Privacy consideration of Addresses 304 However, there are several privacy issues still present with 305 [RFC4941] such as host tracking, and address scanning attacks are 306 still possible. More details are provided in Appendix A. of 307 [RFC7217] and in [RFC7721]. 309 2.1.6. DHCP/DNS Considerations 311 Many environments use DHCPv6 to allocate addresses to ensure audit- 312 ability and traceability (but see Section 2.6.1.5). A main security 313 concern is the ability to detect and counteract against rogue DHCP 314 servers (Section 2.3.2). 316 DNS is often used for malware activities and while there are no 317 fundamental differences with IPv4 and IPv6 security concerns, there 318 are specific consideration in DNS64 RFC6147 [RFC6147] environments 319 that need to be understood. Specifically the interactions and 320 potential to interference with DNSsec implementation need to be 321 understood - these are pointed out in detail in Section 2.7.3.2. 323 2.2. Extension Headers 325 The extension headers are one of the most critical differentiator 326 between IPv4 and IPv6. Obvioulsy, the IPSec [RFC4301]IPsec extension 327 headers (AH [RFC4302] and ESP [RFC4303]) are the most used IPv6 328 extension headers as they were back-ported to IPv4. But, they are 329 other ones and there are even sub-type within each defined extension 330 headers. The IANA has closed the the existing empty "Next Header 331 Types" registry to new entries and is redirecting its users to a new 332 "IPv6 Extension Header Types" registry. 334 A good read about extension headers is RFC7045 [RFC7045]. RFC7872 335 [RFC7872] seems to indicate that packets with some extension headers 336 may not traverse safely the Internet. 338 2.2.1. Order and Repetition of Extension Headers 340 While RFC2460 defines the order and the maximum repetition of 341 extension headers, there are still IPv6 implementations at the time 342 of writing this document which do not support a wrong order of 343 headers (such as ESP before routing) or an illegal repetition of 344 headers (such as twice routing header). The same applies for options 345 contained in the extension headers (see 346 [I-D.kampanakis-6man-ipv6-eh-parsing]). In some case, it has lead to 347 node crash when receiving or forwarding wrongly formated packets. 349 2.2.2. Hop-by-Hop Extension Header 351 The hop-by-hop extension header when present in an IPv6 packet forces 352 all nodes in the path to inspect this header. This is of course a 353 large avenue for a denial of service as most if not all routers 354 cannot process this kind of packets in hardware but have to 'punt' 355 this packet for software processing. See also 356 [I-D.ietf-6man-hbh-header-handling]. 358 2.2.3. Fragmentation Extension Header 360 The fragmentation extension header is used by the source when it has 361 to fragment packets. RFC7112 [RFC7112] explains why it is important 362 to: 364 firewall and security devices should drop first fragment not 365 containing enough of the layer-4 header; 367 destiantion node should ignore first fragment not containing the 368 entire IPv6 header chain. 370 Else, stateless access control list could be bypassed by an hostile 371 party. RFC6980 [RFC6980] applies the same rule to NDP and the RA- 372 guard function. 374 2.3. Link-Layer Security 376 IPv6 relies heavily on the Neighbor Discovery protocol (NDP) RFC4861 377 [RFC4861] to perform a variety of link operations such as discovering 378 other nodes on the link, resolving their link-layer addresses, and 379 finding routers on the link. If not secured, NDP is vulnerable to 380 various attacks such as router/neighbor message spoofing, redirect 381 attacks, Duplicate Address Detection (DAD) DoS attacks, etc. many of 382 these security threats to NDP have been documented in IPv6 ND Trust 383 Models and Threats RFC3756 [RFC3756] and in RFC6583 [RFC6583]. 385 2.3.1. SeND and CGA 387 SEcure Neighbor Discovery (SeND), as described in RFC3971 [RFC3971], 388 is a mechanism that was designed to secure ND messages. This 389 approach involves the use of new NDP options to carry public key 390 based signatures. Cryptographically Generated Addresses (CGA), as 391 described in RFC3972 [RFC3972], are used to ensure that the sender of 392 a Neighbor Discovery message is the actual "owner" of the claimed 393 IPv6 address. A new NDP option, the CGA option, was introduced and 394 is used to carry the public key and associated parameters. Another 395 NDP option, the RSA Signature option, is used to protect all messages 396 relating to neighbor and Router discovery. 398 SeND protects against: 400 o Neighbor Solicitation/Advertisement Spoofing 402 o Neighbor Unreachability Detection Failure 404 o Duplicate Address Detection DoS Attack 406 o Router Solicitation and Advertisement Attacks 408 o Replay Attacks 410 o Neighbor Discovery DoS Attacks 412 SeND does NOT: 414 o Protect statically configured addresses 416 o Protect addresses configured using fixed identifiers (i.e. EUI- 417 64) 419 o Provide confidentiality for NDP communications 421 o Compensate for an unsecured link - SEND does not require that the 422 addresses on the link and Neighbor Advertisements correspond 424 However, at this time and after many years after their 425 specifications, CGA and SeND do not have wide support from generic 426 operating systems; hence, their usefulness is limited. 428 2.3.2. Securing DHCP 430 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in 431 RFC3315 [RFC3315], enables DHCP servers to pass configuration 432 parameters such as IPv6 network addresses and other configuration 433 information to IPv6 nodes. DHCP plays an important role in any large 434 network by providing robust stateful configuration and 435 autoregistration of DNS Host Names. 437 The two most common threats to DHCP clients come from malicious 438 (a.k.a. rogue) or unintentionally misconfigured DHCP servers. A 439 malicious DHCP server is established with the intent of providing 440 incorrect configuration information to the client to cause a denial 441 of service attack or mount a man in the middle attack. While 442 unintentionall, a misconfigured DHCP server can have the same impact. 443 Additional threats against DHCP are discussed in the security 444 considerations section of RFC3315 [RFC3315]DHCP-shield 446 RFC7610 [RFC7610] specifies a mechanism for protecting connected 447 DHCPv6 clients against rogue DHCPv6 servers. This mechanism is based 448 on DHCPv6 packet-filtering at the layer-2 device; the administrator 449 specifies the interfaces connected to DHCPv6 servers. 451 It is recommended to use DHCP-shield. 453 2.3.3. ND/RA Rate Limiting 455 Neighbor Discovery (ND) can be vulnerable to denial of service (DoS) 456 attacks in which a router is forced to perform address resolution for 457 a large number of unassigned addresses. Possible side effects of 458 this attack preclude new devices from joining the network or even 459 worse rendering the last hop router ineffective due to high CPU 460 usage. Easy mitigative steps include rate limiting Neighbor 461 Solicitations, restricting the amount of state reserved for 462 unresolved solicitations, and clever cache/timer management. 464 RFC6583 [RFC6583] discusses the potential for DoS in detail and 465 suggests implementation improvements and operational mitigation 466 techniques that may be used to mitigate or alleviate the impact of 467 such attacks. Here are some feasible mitigation options that can be 468 employed by network operators today: 470 o Ingress filtering of unused addresses by ACL, route filtering, 471 longer than /64 prefix; These require static configuration of the 472 addresses. 474 o Tuning of NDP process (where supported). 476 Additionally, IPv6 ND uses multicast extensively for signaling 477 messages on the local link to avoid broadcast messages for on-the- 478 wire efficiency. However, this has some side effects on wifi 479 networks, especially a negative impact on battery life of smartphones 480 and other battery operated devices that are connected to such 481 networks. The following drafts are actively discussing methods to 482 rate limit RAs and other ND messages on wifi networks in order to 483 address this issue: 485 o [I-D.thubert-savi-ra-throttler] 487 o [I-D.chakrabarti-nordmark-6man-efficient-nd] 489 2.3.4. ND/RA Filtering 491 Router Advertisement spoofing is a well-known attack vector and has 492 been extensively documented. The presence of rogue RAs, either 493 intentional or malicious, can cause partial or complete failure of 494 operation of hosts on an IPv6 link. For example, a host can select 495 an incorrect router address which can be used as a man-in-the-middle 496 (MITM) attack or can assume wrong prefixes to be used for stateless 497 address configuration (SLAAC). RFC6104 [RFC6104] summarizes the 498 scenarios in which rogue RAs may be observed and presents a list of 499 possible solutions to the problem. RFC6105 [RFC6105] (RA-Guard) 500 describes a solution framework for the rogue RA problem where network 501 segments are designed around switching devices that are capable of 502 identifying invalid RAs and blocking them before the attack packets 503 actually reach the target nodes. 505 However, several evasion techniques that circumvent the protection 506 provided by RA-Guard have surfaced. A key challenge to this 507 mitigation technique is introduced by IPv6 fragmentation. An 508 attacker can conceal the attack by fragmenting his packets into 509 multiple fragments such that the switching device that is responsible 510 for blocking invalid RAs cannot find all the necessary information to 511 perform packet filtering in the same packet. RFC7113 [RFC7113] 512 describes such evasion techniques, and provides advice to RA-Guard 513 implementers such that the aforementioned evasion vectors can be 514 eliminated. 516 Given that the IPv6 Fragmentation Header can be leveraged to 517 circumvent current implementations of RA-Guard, RFC6980 [RFC6980] 518 updates RFC4861 [RFC4861] such that use of the IPv6 Fragmentation 519 Header is forbidden in all Neighbor Discovery messages except 520 "Certification Path Advertisement", thus allowing for simple and 521 effective measures to counter Neighbor Discovery attacks. 523 The Source Address Validation Improvements (SAVI) working group has 524 worked on other ways to mitigate the effects of such attacks. 525 RFC7513 [RFC7513] would help in creating bindings between a DHCPv4 526 RFC2131 [RFC2131] /DHCPv6 RFC3315 [RFC3315] assigned source IP 527 address and a binding anchor RFC7039 [RFC7039] on a SAVI device. 528 Also, RFC6620 [RFC6620] describes how to glean similar bindings when 529 DHCP is not used. The bindings can be used to filter packets 530 generated on the local link with forged source IP address. 532 It is still recommended that RA-Guard be be employed as a first line 533 of defense against common attack vectors including misconfigured 534 hosts. 536 2.3.5. 3GPP Link-Layer Security 538 The 3GPP link is a point-to-point like link that has no link-layer 539 address. This implies there can only be an end host (the mobile 540 hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node 541 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never 542 configures a non link-local address on the link using the advertised 543 /64 prefix on it. The advertised prefix must not be used for on-link 544 determination. There is no need for an address resolution on the 545 3GPP link, since there are no link-layer addresses. Furthermore, the 546 GGSN/PGW assigns a prefix that is unique within each 3GPP link that 547 uses IPv6 stateless address autoconfiguration. This avoids the 548 necessity to perform DAD at the network level for every address built 549 by the mobile host. The GGSN/PGW always provides an IID to the 550 cellular host for the purpose of configuring the link-local address 551 and ensures the uniqueness of the IID on the link (i.e., no 552 collisions between its own link-local address and the mobile host's 553 one). 555 The 3GPP link model itself mitigates most of the known NDP-related 556 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to 557 route all traffic to the mobile host that falls under the prefix 558 assigned to it. As there is also a single host on the 3GPP link, 559 there is no need to defend that IPv6 address. 561 See Section 5 of RFC6459 [RFC6459] for a more detailed discussion on 562 the 3GPP link model, NDP on it and the address configuration detail. 564 2.4. Control Plane Security 566 RFC6192 [RFC6192] defines the router control plane. This definition 567 is repeated here for the reader's convenience. 569 Modern router architecture design maintains a strict separation of 570 forwarding and router control plane hardware and software. The 571 router control plane supports routing and management functions. It 572 is generally described as the router architecture hardware and 573 software components for handling packets destined to the device 574 itself as well as building and sending packets originated locally on 575 the device. The forwarding plane is typically described as the 576 router architecture hardware and software components responsible for 577 receiving a packet on an incoming interface, performing a lookup to 578 identify the packet's IP next hop and determine the best outgoing 579 interface towards the destination, and forwarding the packet out 580 through the appropriate outgoing interface. 582 While the forwarding plane is usually implemented in high-speed 583 hardware, the control plane is implemented by a generic processor 584 (named router processor RP) and cannot process packets at a high 585 rate. Hence, this processor can be attacked by flooding its input 586 queue with more packets than it can process. The control plane 587 processor is then unable to process valid control packets and the 588 router can lose OSPF or BGP adjacencies which can cause a severe 589 network disruption. 591 The mitigation technique is: 593 o To drop non-legit control packet before they are queued to the RP 594 (this can be done by a forwarding plane ACL) and 596 o To rate limit the remaining packets to a rate that the RP can 597 sustain. Protocol specific protection should also be done (for 598 example, a spoofed OSPFv3 packet could trigger the execution of 599 the Dijkstra algorithm, therefore the number of Dijsktra execution 600 should be also rate limited). 602 This section will consider several classes of control packets: 604 o Control protocols: routing protocols: such as OSPFv3, BGP and by 605 extension Neighbor Discovery and ICMP 607 o Management protocols: SSH, SNMP, IPfix, etc 609 o Packet exceptions: which are normal data packets which requires a 610 specific processing such as generating a packet-too-big ICMP 611 message or having the hop-by-hop extension header. 613 2.4.1. Control Protocols 615 This class includes OSPFv3, BGP, NDP, ICMP. 617 An ingress ACL to be applied on all the router interfaces SHOULD be 618 configured such as: 620 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 621 (identified by UDP port 521) packets from a non link-local address 623 o allow BGP (identified by TCP port 179) packets from all BGP 624 neighbors and drop the others 626 o allow all ICMP packets (transit and to the router interfaces) 628 Note: dropping OSPFv3 packets which are authenticated by IPsec could 629 be impossible on some routers whose ACL are unable to parse the IPsec 630 ESP or AH extension headers. 632 Rate limiting of the valid packets SHOULD be done. The exact 633 configuration obviously depends on the power of the Route Processor. 635 2.4.2. Management Protocols 637 This class includes: SSH, SNMP, syslog, NTP, etc 639 An ingress ACL to be applied on all the router interfaces SHOULD be 640 configured such as: 642 o Drop packets destined to the routers except those belonging to 643 protocols which are used (for example, permit TCP 22 and drop all 644 when only SSH is used); 646 o Drop packets where the source does not match the security policy, 647 for example if SSH connections should only be originated from the 648 NOC, then the ACL should permit TCP port 22 packets only from the 649 NOC prefix. 651 Rate limiting of the valid packets SHOULD be done. The exact 652 configuration obviously depends on the power of the Route Processor. 654 2.4.3. Packet Exceptions 656 This class covers multiple cases where a data plane packet is punted 657 to the route processor because it requires specific processing: 659 o generation of an ICMP packet-too-big message when a data plane 660 packet cannot be forwarded because it is too large; 662 o generation of an ICMP hop-limit-expired message when a data plane 663 packet cannot be forwarded because its hop-limit field has reached 664 0; 666 o generation of an ICMP destination-unreachable message when a data 667 plane packet cannot be forwarded for any reason; 669 o processing of the hop-by-hop extension header (see also 670 [I-D.ietf-6man-hbh-header-handling]); 672 o or more specific to some router implementation: an oversized 673 extension header chain which cannot be processed by the hardware 674 and force the packet to be punted to the generic router CPU. 676 On some routers, not everything can be done by the specialized data 677 plane hardware which requires some packets to be 'punted' to the 678 generic RP. This could include for example the processing of a long 679 extension header chain in order to apply an ACL based on layer 4 680 information. RFC6980 [RFC6980] and more generally RFC7112 [RFC7112] 681 highlights the security implications of oversized extension header 682 chains on routers and updates RFC2460 [RFC2460] such that the first 683 fragment of a packet is required to contain the entire IPv6 header 684 chain. 686 An ingress ACL cannot help to mitigate a control plane attack using 687 those packet exceptions. The only protection for the RP is to limit 688 the rate of those packet exceptions forwarded to the RP, this means 689 that some data plane packets will be dropped without any ICMP 690 messages back to the source which will cause Path MTU holes. But, 691 there is no other solution. 693 In addition to limiting the rate of data plane packets queued to the 694 RP, it is also important to limit the generation rate of ICMP 695 messages both the save the RP but also to prevent an amplification 696 attack using the router as a reflector. 698 2.5. Routing Security 700 Routing security in general can be broadly divided into three 701 sections: 703 1. Authenticating neighbors/peers 705 2. Securing routing updates between peers 707 3. Route filtering 709 [RFC7454] covers these sections specifically for BGP in detail. 711 2.5.1. Authenticating Neighbors/Peers 713 A basic element of routing is the process of forming adjacencies, 714 neighbor, or peering relationships with other routers. From a 715 security perspective, it is very important to establish such 716 relationships only with routers and/or administrative domains that 717 one trusts. A traditional approach has been to use MD5 HMAC, which 718 allows routers to authenticate each other prior to establishing a 719 routing relationship. 721 OSPFv3 can rely on IPsec to fulfill the authentication function. 722 However, it should be noted that IPsec support is not standard on all 723 routing platforms. In some cases, this requires specialized hardware 724 that offloads crypto over to dedicated ASICs or enhanced software 725 images (both of which often come with added financial cost) to 726 provide such functionality. An added detail is to determine whether 727 OSPFv3 IPsec implementations use AH or ESP-Null for integrity 728 protection. In early implementations all OSPFv3 IPsec configurations 729 relied on AH since the details weren't specified in RFC5340 [RFC5340] 730 or RFC2740 [RFC2740] that was obsoleted by the former. However, the 731 document which specifically describes how IPsec should be implemented 732 for OSPFv3 RFC4552 [RFC4552] specifically states that ESP-Null MUST 733 and AH MAY be implemented since it follows the overall IPsec 734 standards wordings. OSPFv3 can also use normal ESP to encrypt the 735 OSPFv3 payload to hide the routing information. 737 RFC7166 [RFC7166] (which obsoletes RFC6506 [RFC6506] changes OSPFv3's 738 reliance on IPsec by appending an authentication trailer to the end 739 of the OSPFv3 packets. This document does not specifically provide 740 for a mechanism that will authenticate the specific originator of a 741 packet. Rather, it will allow a router to confirm that the packet 742 has indeed been issued by a router that had access to the shared 743 authentication key. 745 With all authentication mechanisms, operators should confirm that 746 implementations can support re-keying mechanisms that do not cause 747 outages. There have been instances where any re-keying cause outages 748 and therefore the tradeoff between utilizing this functionality needs 749 to be weighed against the protection it provides. 751 2.5.2. Securing Routing Updates Between Peers 753 IPv6 initially mandated the provisioning of IPsec capability in all 754 nodes. However, in the updated IPv6 Nodes Requirement standard 755 RFC6434 [RFC6434] is now a SHOULD and not MUST implement. 756 Theoretically it is possible, and recommended, that communication 757 between two IPv6 nodes, including routers exchanging routing 758 information be encrypted using IPsec. In practice however, deploying 759 IPsec is not always feasible given hardware and software limitations 760 of various platforms deployed, as described in the earlier section. 761 Additionally, in a protocol such as OSPFv3 where adjacencies are 762 formed on a one-to-many basis, IPsec key management becomes difficult 763 to maintain and is not often utilized. 765 2.5.3. Route Filtering 767 Route filtering policies will be different depending on whether they 768 pertain to edge route filtering vs internal route filtering. At a 769 minimum, IPv6 routing policy as it pertains to routing between 770 different administrative domains should aim to maintain parity with 771 IPv4 from a policy perspective e.g., 773 o Filter internal-use, non-globally routable IPv6 addresses at the 774 perimeter 776 o Discard packets from and to bogon and reserved space 778 o Configure ingress route filters that validate route origin, prefix 779 ownership, etc. through the use of various routing databases, 780 e.g., RADB. There is additional work being done in this area to 781 formally validate the origin ASs of BGP announcements in RFC6810 782 [RFC6810] 784 Some good recommendations for filtering can be found from Team CYMRU 785 at [CYMRU]. 787 2.6. Logging/Monitoring 789 In order to perform forensic research in case of any security 790 incident or to detect abnormal behaviors, network operator should log 791 multiple pieces of information. 793 This includes: 795 o logs of all applications when available (for example web servers); 797 o use of IP Flow Information Export [RFC7011] also known as IPfix; 799 o use of SNMP MIB [RFC4293]; 801 o use of the Neighbor cache; 803 o use of stateful DHCPv6 [RFC3315] lease cache, especially when a 804 relay agent [RFC6221] in layer-2 switches is used; 806 o use of RADIUS [RFC2866] for accounting records. 808 Please note that there are privacy issues related to how those logs 809 are collected, kept and safely discarded. Operators are urged to 810 check their country legislation. 812 All those pieces of information will be used for: 814 o forensic (Section 2.6.2.1) research to answer questions such as 815 who did what and when? 817 o correlation (Section 2.6.2.3): which IP addresses were used by a 818 specific node (assuming the use of privacy extensions addresses 819 [RFC4941]) 821 o inventory (Section 2.6.2.2): which IPv6 nodes are on my network? 823 o abnormal behavior detection (Section 2.6.2.4): unusual traffic 824 patterns are often the symptoms of a abnormal behavior which is in 825 turn a potential attack (denial of services, network scan, a node 826 being part of a botnet, ...) 828 2.6.1. Data Sources 830 This section lists the most important sources of data that are useful 831 for operational security. 833 2.6.1.1. Logs of Applications 835 Those logs are usually text files where the remote IPv6 address is 836 stored in all characters (not binary). This can complicate the 837 processing since one IPv6 address, 2001:db8::1 can be written in 838 multiple ways such as: 840 o 2001:DB8::1 (in uppercase) 842 o 2001:0db8::0001 (with leading 0) 844 o and many other ways. 846 RFC 5952 [RFC5952] explains this problem in detail and recommends the 847 use of a single canonical format (in short use lower case and 848 suppress leading 0). This memo recommends the use of canonical 849 format [RFC5952] for IPv6 addresses in all possible cases. If the 850 existing application cannot log under the canonical format, then this 851 memo recommends the use an external program in order to canonicalize 852 all IPv6 addresses. 854 For example, this perl script can be used: 856 #!/usr/bin/perl -w 857 use strict ; 858 use warnings ; 859 use Socket ; 860 use Socket6 ; 862 my (@words, $word, $binary_address) ; 864 ## go through the file one line at a time 865 while (my $line = ) { 866 chomp $line; 867 foreach my $word (split /[\s+]/, $line) { 868 $binary_address = inet_pton AF_INET6, $word ; 869 if ($binary_address) { 870 print inet_ntop AF_INET6, $binary_address ; 871 } else { 872 print $word ; 873 } 874 print " " ; 875 } 876 print "\n" ; 877 } 879 2.6.1.2. IP Flow Information Export by IPv6 Routers 881 IPfix [RFC7012] defines some data elements that are useful for 882 security: 884 o in section 5.4 (IP Header fields): nextHeaderIPv6 and 885 sourceIPv6Address; 887 o in section 5.6 (Sub-IP fields) sourceMacAddress. 889 Moreover, IPfix is very efficient in terms of data handling and 890 transport. It can also aggregate flows by a key such as 891 sourceMacAddress in order to have aggregated data associated with a 892 specific sourceMacAddress. This memo recommends the use of IPfix and 893 aggregation on nextHeaderIPv6, sourceIPv6Address and 894 sourceMacAddress. 896 2.6.1.3. SNMP MIB by IPv6 Routers 898 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 899 the two address families of IP. This memo recommends the use of: 901 o ipIfStatsTable table which collects traffic counters per 902 interface; 904 o ipNetToPhysicalTable table which is the content of the Neighbor 905 cache, i.e. the mapping between IPv6 and data-link layer 906 addresses. 908 2.6.1.4. Neighbor Cache of IPv6 Routers 910 The neighbor cache of routers contains all mappings between IPv6 911 addresses and data-link layer addresses. It is usually available by 912 two means: 914 o the SNMP MIB (Section 2.6.1.3) as explained above; 916 o also by connecting over a secure management channel (such as SSH 917 or HTTPS) and explicitely requesting a neighbor cache dump. 919 The neighbor cache is highly dynamic as mappings are added when a new 920 IPv6 address appears on the network (could be quite often with 921 privacy extension addresses [RFC4941] or when they are removed when 922 the state goes from UNREACH to removed (the default time for a 923 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 924 38 seconds for a typical host such as Windows 7). This means that 925 the content of the neighbor cache must periodically be fetched every 926 30 seconds (to be on the safe side) and stored for later use. 928 This is an important source of information because it is trivial (on 929 a switch not using the SAVI [RFC7039] algorithm) to defeat the 930 mapping between data-link layer address and IPv6 address. Let us 931 rephrase the previous statement: having access to the current and 932 past content of the neighbor cache has a paramount value for forensic 933 and audit trail. 935 2.6.1.5. Stateful DHCPv6 Lease 937 In some networks, IPv6 addresses are managed by stateful DHCPv6 938 server [RFC3315] that leases IPv6 addresses to clients. It is indeed 939 quite similar to DHCP for IPv4 so it can be tempting to use this DHCP 940 lease file to discover the mapping between IPv6 addresses and data- 941 link layer addresses as it was usually done in the IPv4 era. 943 It is not so easy in the IPv6 era because not all nodes will use 944 DHCPv6 (there are nodes which can only do stateless 945 autoconfiguration) but also because DHCPv6 clients are identified not 946 by their hardware-client address as in IPv4 but by a DHCP Unique ID 947 (DUID) which can have several formats: some being the data-link layer 948 address, some being data-link layer address prepended with time 949 information or even an opaque number which is useless for operation 950 security. Moreover, when the DUID is based on the data-link address, 951 this address can be of any interface of the client (such as the 952 wireless interface while the client actually uses its wired interface 953 to connect to the network). 955 If a lightweight DHCP relay agent [RFC6221] is used in the layer-2 956 switches, then the DHCP server also receives the Interface-ID 957 information which could be save in order to identifity the interface 958 of the switches which received a specific leased IPv6 address. 960 In short, the DHCPv6 lease file is less interesting than in the IPv4 961 era. DHCPv6 servers that keeps the relayed data-link layer address 962 in addition to the DUID in the lease file do not suffer from this 963 limitation. On a managed network where all hosts support DHCPv6, 964 special care must be taken to prevent stateless autoconfiguration 965 anyway (and if applicable) by sending RA with all announced prefixes 966 without the A-bit set. 968 The mapping between data-link layer address and the IPv6 address can 969 be secured by using switches implementing the SAVI [RFC7513] 970 algorithms. Of course, this also requires that data-link layer 971 address is protected by using layer-2 mechanism such as 972 [IEEE-802.1X]. 974 2.6.1.6. RADIUS Accounting Log 976 For interfaces where the user is authenticated via a RADIUS [RFC2866] 977 server, and if RADIUS accounting is enabled, then the RADIUS server 978 receives accounting Acct-Status-Type records at the start and at the 979 end of the connection which include all IPv6 (and IPv4) addresses 980 used by the user. This technique can be used notably for Wi-Fi 981 networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X 982 [IEEE-802.1X]wired interface on an Ethernet switch. 984 2.6.1.7. Other Data Sources 986 There are other data sources that must be kept exactly as in the IPv4 987 network: 989 o historical mapping of IPv6 addresses to users of remote access 990 VPN; 992 o historical mapping of MAC address to switch interface in a wired 993 network. 995 2.6.2. Use of Collected Data 997 This section leverages the data collected as described before 998 (Section 2.6.1) in order to achieve several security benefits. 1000 2.6.2.1. Forensic 1002 The forensic use case is when the network operator must locate an 1003 IPv6 address that was present in the network at a certain time or is 1004 still currently in the network. 1006 The source of information can be, in decreasing order, neighbor 1007 cache, DHCP lease file. Then, the procedure is: 1009 1. based on the IPv6 prefix of the IPv6 address find the router(s) 1010 which are used to reach this prefix; 1012 2. based on this limited set of routers, on the incident time and on 1013 IPv6 address to retrieve the data-link address from live neighbor 1014 cache, from the historical data of the neighbor cache, or from 1015 the DHCP lease file; 1017 3. based on the data-link layer address, look-up on which switch 1018 interface was this data-link layer address. In the case of 1019 wireless LAN, the RADIUS log should have the mapping between user 1020 identification and the MAC address. 1022 At the end of the process, the interface where the malicious user was 1023 connected or the username that was used by the malicious user is 1024 found. 1026 2.6.2.2. Inventory 1028 RFC 7707 [RFC7707] (which obsoletes RFC 5157 [RFC5157]) is about the 1029 difficulties to scan an IPv6 network due to the vast number of IPv6 1030 addresses per link. This has the side effect of making the inventory 1031 task difficult in an IPv6 network while it was trivial to do in an 1032 IPv4 network (a simple enumeration of all IPv4 addresses, followed by 1033 a ping and a TCP/UDP port scan). Getting an inventory of all 1034 connected devices is of prime importance for a secure operation of a 1035 network. 1037 There are many ways to do an inventory of an IPv6 network. 1039 The first technique is to use the IPfix information and extract the 1040 list of all IPv6 source addresses to find all IPv6 nodes that sent 1041 packets through a router. This is very efficient but alas will not 1042 discover silent node that never transmitted such packets... Also, it 1043 must be noted that link-local addresses will never be discovered by 1044 this means. 1046 The second way is again to use the collected neighbor cache content 1047 to find all IPv6 addresses in the cache. This process will also 1048 discover all link-local addresses. See Section 2.6.1.4. 1050 Another way works only for local network, it consists in sending a 1051 ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 1052 is all IPv6 nodes on the network. All nodes should reply to this 1053 ECHO_REQUEST per [RFC4443]. 1055 Other techniques involve enumerating the DNS zones, parsing log 1056 files, leveraging service discovery such as mDNS RFC6762 [RFC6762] 1057 and RFC6763 [RFC6763]. 1059 2.6.2.3. Correlation 1061 In an IPv4 network, it is easy to correlate multiple logs, for 1062 example to find events related to a specific IPv4 address. A simple 1063 Unix grep command was enough to scan through multiple text-based 1064 files and extract all lines relevant to a specific IPv4 address. 1066 In an IPv6 network, this is slightly more difficult because different 1067 character strings can express the same IPv6 address. Therefore, the 1068 simple Unix grep command cannot be used. Moreover, an IPv6 node can 1069 have multiple IPv6 addresses... 1071 In order to do correlation in IPv6-related logs, it is advised to 1072 have all logs with canonical IPv6 addresses. Then, the neighbor 1073 cache current (or historical) data set must be searched to find the 1074 data-link layer address of the IPv6 address. Then, the current and 1075 historical neighbor cache data sets must be searched for all IPv6 1076 addresses associated to this data-link layer address: this is the 1077 search set. The last step is to search in all log files (containing 1078 only IPv6 address in canonical format) for any IPv6 addresses in the 1079 search set. 1081 2.6.2.4. Abnormal Behavior Detection 1083 Abnormal behaviors (such as network scanning, spamming, denial of 1084 service) can be detected in the same way as in an IPv4 network 1086 o sudden increase of traffic detected by interface counter (SNMP) or 1087 by aggregated traffic from IPfix records [RFC7012]; 1089 o change of traffic pattern (number of connection per second, number 1090 of connection per host...) with the use of IPfix [RFC7012] 1092 2.6.3. Summary 1094 While some data sources (IPfix, MIB, switch CAM tables, logs, ...) 1095 used in IPv4 are also used in the secure operation of an IPv6 1096 network, the DHCPv6 lease file is less reliable and the neighbor 1097 cache is of prime importance. 1099 The fact that there are multiple ways to express in a character 1100 string the same IPv6 address renders the use of filters mandatory 1101 when correlation must be done. 1103 2.7. Transition/Coexistence Technologies 1105 Some text 1107 2.7.1. Dual Stack 1109 Dual stack has established itself as the preferred deployment choice 1110 for most network operators without an MPLS core where 6PE RFC4798 1111 [RFC4798] is quite common. Dual stacking the network offers many 1112 advantages over other transition mechanisms. Firstly, it is easy to 1113 turn on without impacting normal IPv4 operations. Secondly, perhaps 1114 more importantly, it is easier to troubleshoot when things break. 1115 Dual stack allows you to gradually turn IPv4 operations down when 1116 your IPv6 network is ready for prime time. 1118 From an operational security perspective, this now means that you 1119 have twice the exposure. One needs to think about protecting both 1120 protocols now. At a minimum, the IPv6 portion of a dual stacked 1121 network should maintain parity with IPv4 from a security policy point 1122 of view. Typically, the following methods are employed to protect 1123 IPv4 networks at the edge: 1125 o ACLs to permit or deny traffic 1127 o Firewalls with stateful packet inspection 1129 It is recommended that these ACLs and/or firewalls be additionally 1130 configured to protect IPv6 communications. Also, given the end-to- 1131 end connectivity that IPv6 provides, it is also recommended that 1132 hosts be fortified against threats. General device hardening 1133 guidelines are provided in Section 2.8 1135 2.7.2. Transition Mechanisms 1137 There are many tunnels used for specific use cases. Except when 1138 protected by IPsec [RFC4301], all those tunnels have a couple of 1139 security issues (most of them being described in RFC 6169 [RFC6169]); 1140 o tunnel injection: a malevolent person knowing a few pieces of 1141 information (for example the tunnel endpoints and the used 1142 protocol) can forge a packet which looks like a legit and valid 1143 encapsulated packet that will gladly be accepted by the 1144 destination tunnel endpoint, this is a specific case of spoofing; 1146 o traffic interception: no confidentiality is provided by the tunnel 1147 protocols (without the use of IPsec), therefore anybody on the 1148 tunnel path can intercept the traffic and have access to the 1149 clear-text IPv6 packet; 1151 o service theft: as there is no authorization, even a non authorized 1152 user can use a tunnel relay for free (this is a specific case of 1153 tunnel injection); 1155 o reflection attack: another specific use case of tunnel injection 1156 where the attacker injects packets with an IPv4 destination 1157 address not matching the IPv6 address causing the first tunnel 1158 endpoint to re-encapsulate the packet to the destination... Hence, 1159 the final IPv4 destination will not see the original IPv4 address 1160 but only one IPv4 address of the relay router. 1162 o bypassing security policy: if a firewall or an IPS is on the path 1163 of the tunnel, then it will probably neither inspect not detect an 1164 malevolent IPv6 traffic contained in the tunnel. 1166 To mitigate the bypassing of security policies, it could be helpful 1167 to block all default configuration tunnels by denying all IPv4 1168 traffic matching: 1170 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 1171 (Section 2.7.2.4), 6rd (Section 2.7.2.5) as well as 6in4 1172 (Section 2.7.2.1) tunnels; 1174 o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; 1176 o UDP protocol 3544: this will block the default encapsulation of 1177 Teredo (Section 2.7.2.3) tunnels. 1179 Ingress filtering [RFC2827] should also be applied on all tunnel 1180 endpoints if applicable to prevent IPv6 address spoofing. 1182 As several of the tunnel techniques share the same encapsulation 1183 (i.e. IPv4 protocol 41) and embed the IPv4 address in the IPv6 1184 address, there are a set of well-known looping attacks described in 1185 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 1187 2.7.2.1. Site-to-Site Static Tunnels 1189 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 1190 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 1191 and are not dynamic they are slightly more secure (bi-directional 1192 service theft is mostly impossible) but traffic interception ad 1193 tunnel injection are still possible. Therefore, the use of IPsec 1194 [RFC4301] in transport mode and protecting the encapsulated IPv4 1195 packets is recommended for those tunnels. Alternatively, IPsec in 1196 tunnel mode can be used to transport IPv6 traffic over a non-trusted 1197 IPv4 network. 1199 2.7.2.2. ISATAP 1201 ISATAP tunnels [RFC5214] are mainly used within a single 1202 administrative domain and to connect a single IPv6 host to the IPv6 1203 network. This means that endpoints and and the tunnel endpoint are 1204 usually managed by a single entity; therefore, audit trail and strict 1205 anti-spoofing are usually possible and this raises the overall 1206 security. 1208 Special care must be taken to avoid looping attack by implementing 1209 the measures of RFC 6324 [RFC6324] and of RFC6964 [RFC6964]. 1211 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 1212 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 1213 prevent service theft. 1215 2.7.2.3. Teredo 1217 Teredo tunnels [RFC4380] are mainly used in a residential environment 1218 because that can easily traverse an IPv4 NAT-PT device thanks to its 1219 UDP encapsulation and they connect a single host to the IPv6 1220 Internet. Teredo shares the same issues as other tunnels: no 1221 authentication, no confidentiality, possible spoofing and reflection 1222 attacks. 1224 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 1226 The biggest threat to Teredo is probably for IPv4-only network as 1227 Teredo has been designed to easily traverse IPV4 NAT-PT devices which 1228 are quite often co-located with a stateful firewall. Therefore, if 1229 the stateful IPv4 firewall allows unrestricted UDP outbound and 1230 accept the return UDP traffic, then Teredo actually punches a hole in 1231 this firewall for all IPv6 traffic to the Internet and from the 1232 Internet. While host policies can be deployed to block Teredo in an 1233 IPv4-only network in order to avoid this firewall bypass, it would be 1234 more efficient to block all UDP outbound traffic at the IPv4 firewall 1235 if deemed possible (of course, at least port 53 should be left open 1236 for DNS traffic). 1238 2.7.2.4. 6to4 1240 6to4 tunnels [RFC3056] require a public routable IPv4 address in 1241 order to work correctly. They can be used to provide either one IPv6 1242 host connectivity to the IPv6 Internet or multiple IPv6 networks 1243 connectivity to the IPv6 Internet. The 6to4 relay is usually the 1244 anycast address defined in RFC3068 [RFC3068] which has been 1245 deprecated by RFC7526 [RFC7526], and is no more used by recent 1246 Operating Systems. Some security considerations are explained in 1247 RFC3694 [RFC3964]. 1249 RFC6343 [RFC6343] points out that if an operator provides well- 1250 managed servers and relays for 6to4, non-encapsulated IPv6 packets 1251 will pass through well- defined points (the native IPv6 interfaces of 1252 those servers and relays) at which security mechanisms may be 1253 applied. Client usage of 6to4 by default is now discouraged, and 1254 significant precautions are needed to avoid operational problems. 1256 2.7.2.5. 6rd 1258 While 6rd tunnels share the same encapsulation as 6to4 tunnels 1259 (Section 2.7.2.4), they are designed to be used within a single SP 1260 domain, in other words they are deployed in a more constrained 1261 environment than 6to4 tunnels and have little security issues except 1262 lack of confidentiality. The security considerations (Section 12) of 1263 RFC5969 [RFC5969] describes how to secure the 6rd tunnels. 1265 IPsec [RFC4301] for the transported IPv6 traffic can be used if 1266 confidentiality is important. 1268 2.7.2.6. 6PE and 6VPE 1270 Organizations using MPLS in their core can also use 6PE [RFC4798] and 1271 6VPE RFC4659 [RFC4659] to enable IPv6 access over MPLS. As 6PE and 1272 6VPE are really similar to BGP/MPLS IP VPN described in RFC4364 1273 [RFC4364], the security of these networks is also similar to the one 1274 described in RFC4381 [RFC4381]. It relies on: 1276 o Address space, routing and traffic seperation with the help of VRF 1277 (only applicable to 6VPE); 1279 o Hiding the IPv4 core, hence removing all attacks against 1280 P-routers; 1282 o Securing the routing protocol between CE and PE, in the case of 1283 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 1284 as these addresses cannot be reached from outside of the link, the 1285 security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP 1286 VPN. 1288 2.7.2.7. DS-Lite 1290 DS-lite is more a translation mechanism and is therefore analyzed 1291 further (Section 2.7.3.3) in this document. 1293 2.7.2.8. Mapping of Address and Port 1295 With the tunnel and encapsulation versions of mapping of Address and 1296 Port (MAP-E [RFC7597] and MAP-T [RFC7599]), the access network is 1297 purely an IPv6 network and MAP protocols are used to give IPv4 hosts 1298 on the subscriber network, access to IPv4 hosts on the Internet. The 1299 subscriber router does stateful operations in order to map all 1300 internal IPv4 addresses and layer-4 ports to the IPv4 address and the 1301 set of layer-4 ports received through MAP configuration process. The 1302 SP equipment always does stateless operations (either decapsulation 1303 or stateless translation). Therefore, as opposed to Section 2.7.3.3 1304 there is no state-exhaustion DoS attack against the SP equipment 1305 because there is no state and there is no operation caused by a new 1306 layer-4 connection (no logging operation). 1308 The SP MAP equipment MUST implement all the security considerations 1309 of [RFC7597]; notably, ensuring that the mapping of the IPv4 address 1310 and port are consistent with the configuration. As MAP has a 1311 predictable IPv4 address and port mapping, the audit logs are easier 1312 to manager. 1314 2.7.3. Translation Mechanisms 1316 Translation mechanisms between IPv4 and IPv6 networks are alternative 1317 coexistence strategies while networks transition to IPv6. While a 1318 framework is described in [RFC6144] the specific security 1319 considerations are documented in each individual mechanism. For the 1320 most part they specifically mention interference with IPsec or DNSSEC 1321 deployments, how to mitigate spoofed traffic and what some effective 1322 filtering strategies may be. 1324 2.7.3.1. Carrier-Grade Nat (CGN) 1326 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 1327 (LSN) or SP NAT is described in [RFC6264] and is utilized as an 1328 interim measure to prolong the use of IPv4 in a large service 1329 provider network until the provider can deploy and effective IPv6 1330 solution. [RFC6598] requested a specific IANA allocated /10 IPv4 1331 address block to be used as address space shared by all access 1332 networks using CGN. This has been allocated as 100.64.0.0/10. 1334 Section 13 of [RFC6269] lists some specific security-related issues 1335 caused by large scale address sharing. The Security Considerations 1336 section of [RFC6598] also lists some specific mitigation techniques 1337 for potential misuse of shared address space. 1339 RFC7422 [RFC7422] suggests the use of deterministic address mapping 1340 in order to reduce logging requirements for CGN. The idea is to have 1341 an algorithm mapping back and forth the internal subscriber to public 1342 ports. 1344 2.7.3.2. NAT64/DNS64 1346 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to 1347 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used 1348 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes 1349 AAAA records from existing A records. There is also a stateless 1350 NAT64 [RFC6145] which is similar for the security aspects with the 1351 added benefit of being stateless, so, less prone to a state 1352 exhaustion attack. 1354 The Security Consideration sections of [RFC6146] and [RFC6147] list 1355 the comprehensive issues. A specific issue with the use of NAT64 is 1356 that it will interfere with most IPsec deployments unless UDP 1357 encapsulation is used. DNS64 has an incidence on DNSSEC see section 1358 3.1 of [RFC7050]. 1360 2.7.3.3. DS-Lite 1362 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that 1363 enables a service provider to share IPv4 addresses among customers by 1364 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 1365 Network Address and Port Translation (NAPT). 1367 Security considerations with respect to DS-Lite mainly revolve around 1368 logging data, preventing DoS attacks from rogue devices (as the AFTR 1369 function is stateful) and restricting service offered by the AFTR 1370 only to registered customers. 1372 Section 11 of [RFC6333] describes important security issues 1373 associated with this technology. 1375 2.8. General Device Hardening 1377 There are many environments which rely too much on the network 1378 infrastructure to disallow malicious traffic to get access to 1379 critical hosts. In new IPv6 deployments it has been common to see 1380 IPv6 traffic enabled but none of the typical access control 1381 mechanisms enabled for IPv6 device access. With the possibility of 1382 network device configuration mistakes and the growth of IPv6 in the 1383 overall Internet it is important to ensure that all individual 1384 devices are hardened agains miscreant behavior. 1386 The following guidelines should be used to ensure appropriate 1387 hardening of the host, be it an individual computer or router, 1388 firewall, load-balancer,server, etc device. 1390 o Restrict access to the device to authorized individuals 1392 o Monitor and audit access to the device 1394 o Turn off any unused services on the end node 1396 o Understand which IPv6 addresses are being used to source traffic 1397 and change defaults if necessary 1399 o Use cryptographically protected protocols for device management if 1400 possible (SCP, SNMPv3, SSH, TLS, etc) 1402 o Use host firewall capabilities to control traffic that gets 1403 processed by upper layer protocols 1405 o Use virus scanners to detect malicious programs 1407 3. Enterprises Specific Security Considerations 1409 Enterprises generally have robust network security policies in place 1410 to protect existing IPv4 networks. These policies have been 1411 distilled from years of experiential knowledge of securing IPv4 1412 networks. At the very least, it is recommended that enterprise 1413 networks have parity between their security policies for both 1414 protocol versions. 1416 Security considerations in the enterprise can be broadly categorized 1417 into two sections - External and Internal. 1419 3.1. External Security Considerations: 1421 The external aspect deals with providing security at the edge or 1422 perimeter of the enterprise network where it meets the service 1423 providers network. This is commonly achieved by enforcing a security 1424 policy either by implementing dedicated firewalls with stateful 1425 packet inspection or a router with ACLs. A common default IPv4 1426 policy on firewalls that could easily be ported to IPv6 is to allow 1427 all traffic outbound while only allowing specific traffic, such as 1428 established sessions, inbound (see also [RFC6092]). Here are a few 1429 more things that could enhance the default policy: 1431 o Filter internal-use IPv6 addresses at the perimeter 1433 o Discard packets from and to bogon and reserved space, see also 1434 [CYMRU] 1436 o Accept certain ICMPv6 messages to allow proper operation of ND and 1437 PMTUD, see also [RFC4890] 1439 o Filter specific extension headers by accepting only the required 1440 ones (white list approach) such as ESP, AH (not forgetting the 1441 required transport layers: ICMP, TCP, UDP, ...) , where possible 1442 at the edge and possibly inside the perimeter; see also 1443 [I-D.gont-opsec-ipv6-eh-filtering] 1445 o Filter packets having an illegal IPv6 headers chain at the 1446 perimeter (and possible inside as well), see Section 2.2 1448 o Filter unneeded services at the perimeter 1450 o Implement anti-spoofing 1452 o Implement appropriate rate-limiters and control-plane policers 1454 3.2. Internal Security Considerations: 1456 The internal aspect deals with providing security inside the 1457 perimeter of the network, including the end host. The most 1458 significant concerns here are related to Neighbor Discovery. At the 1459 network level, it is recommended that all security considerations 1460 discussed in Section 2.3 be reviewed carefully and the 1461 recommendations be considered in-depth as well. 1463 As mentioned in Section 2.6.2, care must be taken when running 1464 automated IPv6-in-IP4 tunnels. 1466 Hosts need to be hardened directly through security policy to protect 1467 against security threats. The host firewall default capabilities 1468 have to be clearly understood, especially 3rd party ones which can 1469 have different settings for IPv4 or IPv6 default permit/deny 1470 behavior. In some cases, 3rd party firewalls have no IPv6 support 1471 whereas the native firewall installed by default has it. General 1472 device hardening guidelines are provided in Section 2.8 1474 It should also be noted that many hosts still use IPv4 for transport 1475 for things like RADIUS, TACACS+, SYSLOG, etc. This will require some 1476 extra level of due diligence on the part of the operator. 1478 4. Service Providers Security Considerations 1480 4.1. BGP 1482 The threats and mitigation techniques are identical between IPv4 and 1483 IPv6. Broadly speaking they are: 1485 o Authenticating the TCP session; 1487 o TTL security (which becomes hop-limit security in IPv6); 1489 o Prefix Filtering. 1491 These are explained in more detail in section Section 2.5. 1493 4.1.1. Remote Triggered Black Hole Filtering 1495 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has 1496 allocated 100::/64 as discard prefix RFC6666 [RFC6666]. 1498 4.2. Transition Mechanism 1500 SP will typically use transition mechanisms such as 6rd, 6PE, MAP, 1501 DS-Lite which have been analyzed in the transition Section 2.7.2 1502 section. 1504 4.3. Lawful Intercept 1506 The Lawful Intercept requirements are similar for IPv6 and IPv4 1507 architectures and will be subject to the laws enforced in varying 1508 geographic regions. The local issues with each jurisdiction can make 1509 this challenging and both corporate legal and privacy personnel 1510 should be involved in discussions pertaining to what information gets 1511 logged and what the logging retention policies will be. 1513 The target of interception will usually be a residential subscriber 1514 (e.g. his/her PPP session or physical line or CPE MAC address). With 1515 the absence of NAT on the CPE, IPv6 has the provision to allow for 1516 intercepting the traffic from a single host (a /128 target) rather 1517 than the whole set of hosts of a subscriber (which could be a /48, a 1518 /60 or /64). 1520 In contrast, in mobile environments, since the 3GPP specifications 1521 allocate a /64 per device, it may be sufficient to intercept traffic 1522 from the /64 rather than specific /128's (since each time the device 1523 powers up it gets a new IID). 1525 A sample architecture which was written for informational purposes is 1526 found in [RFC3924]. 1528 5. Residential Users Security Considerations 1530 The IETF Homenet working group is working on how IPv6 residential 1531 network should be done; this obviously includes operational security 1532 considerations; but, this is still work in progress. 1534 Residential users have usually less experience and knowledge about 1535 security or networking. As most of the recent hosts, smartphones, 1536 tablets have all IPv6 enabled by default, IPv6 security is important 1537 for those users. Even with an IPv4-only ISP, those users can get 1538 IPv6 Internet access with the help of Teredo tunnels. Several peer- 1539 to-peer programs (notably Bittorrent) support IPv6 and those programs 1540 can initiate a Teredo tunnel through the IPv4 residential gateway, 1541 with the consequence of making the internal host reachable from any 1542 IPv6 host on the Internet. It is therefore recommended that all host 1543 security products (personal firewall, ...) are configured with a 1544 dual-stack security policy. 1546 If the Residential Gateway has IPv6 connectivity, [RFC7084] (which 1547 obsoletes [RFC6204]) defines the requirements of an IPv6 CPE and does 1548 not take position on the debate of default IPv6 security policy as 1549 defined in [RFC6092]: 1551 o outbound only: allowing all internally initiated connections and 1552 block all externally initiated ones, which is a common default 1553 security policy enforced by IPv4 Residential Gateway doing NAT-PT 1554 but it also breaks the end-to-end reachability promise of IPv6. 1555 [RFC6092] lists several recommendations to design such a CPE; 1557 o open/transparent: allowing all internally and externally initiated 1558 connections, therefore restoring the end-to-end nature of the 1559 Internet for the IPv6 traffic but having a different security 1560 policy for IPv6 than for IPv4. 1562 [RFC6092] REC-49 states that a choice must be given to the user to 1563 select one of those two policies. 1565 There is also an alternate solution which has been deployed notably 1566 by Swisscom ([I-D.ietf-v6ops-balanced-ipv6-security]: open to all 1567 outbound and inbound connections at the exception of an handful of 1568 TCP and UDP ports known as vulnerable. 1570 6. Further Reading 1572 There are several documents that describe in more details the 1573 security of an IPv6 network; these documents are not written by the 1574 IETF but are listed here for your convenience: 1576 1. Guidelines for the Secure Deployment of IPv6 [NIST] 1578 2. North American IPv6 Task Force Technology Report - IPv6 Security 1579 Technology Paper [NAv6TF_Security] 1581 3. IPv6 Security [IPv6_Security_Book] 1583 7. Acknowledgements 1585 The authors would like to thank the following people for their useful 1586 comments: Mikael Abrahamsson, Fred Baker, Brian Carpenter, Tim Chown, 1587 Markus deBruen, Fernando Gont, Jeffry Handal, Panos Kampanakis, Erik 1588 Kline, Jouni Korhonen, Mark Lentczner, Bob Sleigh,Tarko Tikan (by 1589 alphabetical order). 1591 8. IANA Considerations 1593 This memo includes no request to IANA. 1595 9. Security Considerations 1597 This memo attempts to give an overview of security considerations of 1598 operating an IPv6 network both in an IPv6-only network and in 1599 utilizing the most widely deployed IPv4/IPv6 coexistence strategies. 1601 10. References 1603 10.1. Normative References 1605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1606 Requirement Levels", BCP 14, RFC 2119, 1607 DOI 10.17487/RFC2119, March 1997, 1608 . 1610 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1611 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1612 December 1998, . 1614 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1615 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 1616 February 2011, . 1618 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1619 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1620 DOI 10.17487/RFC6105, February 2011, 1621 . 1623 10.2. Informative References 1625 [CYMRU] "Packet Filter and Route Filter Recommendation for IPv6 at 1626 xSP routers", . 1630 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1631 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 1632 Wasserman, "IPv6 Neighbor Discovery Optimizations for 1633 Wired and Wireless Networks", draft-chakrabarti-nordmark- 1634 6man-efficient-nd-07 (work in progress), February 2015. 1636 [I-D.gont-opsec-ipv6-eh-filtering] 1637 Gont, F., Will, W., and R. Bonica, "Recommendations on 1638 Filtering of IPv6 Packets Containing IPv6 Extension 1639 Headers", draft-gont-opsec-ipv6-eh-filtering-02 (work in 1640 progress), August 2014. 1642 [I-D.ietf-6man-hbh-header-handling] 1643 Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options 1644 Extension Header", draft-ietf-6man-hbh-header-handling-03 1645 (work in progress), March 2016. 1647 [I-D.ietf-v6ops-balanced-ipv6-security] 1648 Gysi, M., Leclanche, G., Vyncke, E., and R. Anfinsen, 1649 "Balanced Security for IPv6 Residential CPE", draft-ietf- 1650 v6ops-balanced-ipv6-security-01 (work in progress), 1651 December 2013. 1653 [I-D.kampanakis-6man-ipv6-eh-parsing] 1654 Kampanakis, P., "Implementation Guidelines for parsing 1655 IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh- 1656 parsing-01 (work in progress), August 2014. 1658 [I-D.thubert-savi-ra-throttler] 1659 Thubert, P., "Throttling RAs on constrained interfaces", 1660 draft-thubert-savi-ra-throttler-01 (work in progress), 1661 June 2012. 1663 [IEEE-802.1X] 1664 IEEE, , "IEEE Standard for Local and metropolitan area 1665 networks - Port-Based Network Access Control", IEEE Std 1666 802.1X-2010, February 2010. 1668 [IPv6_Security_Book] 1669 Hogg, and Vyncke, "IPv6 Security", ISBN 1-58705-594-5, 1670 Publisher CiscoPress, December 2008. 1672 [NAv6TF_Security] 1673 Kaeo, , Green, , Bound, , and Pouffary, "North American 1674 IPv6 Task Force Technology Report - IPv6 Security 1675 Technology Paper", 2006, 1676 . 1679 [NIST] Frankel, , Graveman, , Pearce, , and Rooks, "Guidelines 1680 for the Secure Deployment of IPv6", 2010, 1681 . 1684 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1685 Converting Network Protocol Addresses to 48.bit Ethernet 1686 Address for Transmission on Ethernet Hardware", STD 37, 1687 RFC 826, DOI 10.17487/RFC0826, November 1982, 1688 . 1690 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1691 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1692 . 1694 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1695 Domains without Explicit Tunnels", RFC 2529, 1696 DOI 10.17487/RFC2529, March 1999, 1697 . 1699 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1700 RFC 2740, DOI 10.17487/RFC2740, December 1999, 1701 . 1703 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1704 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1705 DOI 10.17487/RFC2784, March 2000, 1706 . 1708 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1709 Defeating Denial of Service Attacks which employ IP Source 1710 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1711 May 2000, . 1713 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 1714 DOI 10.17487/RFC2866, June 2000, 1715 . 1717 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1718 DOI 10.17487/RFC2993, November 2000, 1719 . 1721 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1722 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1723 2001, . 1725 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1726 RFC 3068, DOI 10.17487/RFC3068, June 2001, 1727 . 1729 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1730 C., and M. Carney, "Dynamic Host Configuration Protocol 1731 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1732 2003, . 1734 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1735 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1736 September 2003, . 1738 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1739 Neighbor Discovery (ND) Trust Models and Threats", 1740 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1741 . 1743 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 1744 for Lawful Intercept in IP Networks", RFC 3924, 1745 DOI 10.17487/RFC3924, October 2004, 1746 . 1748 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1749 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, 1750 . 1752 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1753 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1754 DOI 10.17487/RFC3971, March 2005, 1755 . 1757 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1758 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1759 . 1761 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1762 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1763 . 1765 [RFC4293] Routhier, S., Ed., "Management Information Base for the 1766 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 1767 April 2006, . 1769 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1770 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1771 December 2005, . 1773 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1774 DOI 10.17487/RFC4302, December 2005, 1775 . 1777 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1778 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1779 . 1781 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1782 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1783 2006, . 1785 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1786 Network Address Translations (NATs)", RFC 4380, 1787 DOI 10.17487/RFC4380, February 2006, 1788 . 1790 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1791 Virtual Private Networks (VPNs)", RFC 4381, 1792 DOI 10.17487/RFC4381, February 2006, 1793 . 1795 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1796 Control Message Protocol (ICMPv6) for the Internet 1797 Protocol Version 6 (IPv6) Specification", RFC 4443, 1798 DOI 10.17487/RFC4443, March 2006, 1799 . 1801 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1802 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1803 . 1805 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1806 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1807 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1808 . 1810 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1811 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1812 Provider Edge Routers (6PE)", RFC 4798, 1813 DOI 10.17487/RFC4798, February 2007, 1814 . 1816 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1817 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1818 DOI 10.17487/RFC4861, September 2007, 1819 . 1821 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1822 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1823 DOI 10.17487/RFC4864, May 2007, 1824 . 1826 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1827 ICMPv6 Messages in Firewalls", RFC 4890, 1828 DOI 10.17487/RFC4890, May 2007, 1829 . 1831 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1832 Extensions for Stateless Address Autoconfiguration in 1833 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1834 . 1836 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1837 Co-existence Security Considerations", RFC 4942, 1838 DOI 10.17487/RFC4942, September 2007, 1839 . 1841 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1842 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1843 . 1845 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1846 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1847 DOI 10.17487/RFC5214, March 2008, 1848 . 1850 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1851 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1852 . 1854 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 1855 Filtering with Unicast Reverse Path Forwarding (uRPF)", 1856 RFC 5635, DOI 10.17487/RFC5635, August 2009, 1857 . 1859 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1860 Address Text Representation", RFC 5952, 1861 DOI 10.17487/RFC5952, August 2010, 1862 . 1864 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1865 Infrastructures (6rd) -- Protocol Specification", 1866 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1867 . 1869 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1870 Capabilities in Customer Premises Equipment (CPE) for 1871 Providing Residential IPv6 Internet Service", RFC 6092, 1872 DOI 10.17487/RFC6092, January 2011, 1873 . 1875 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1876 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1877 April 2011, . 1879 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1880 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 1881 . 1883 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1884 NAT64: Network Address and Protocol Translation from IPv6 1885 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1886 April 2011, . 1888 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1889 Beijnum, "DNS64: DNS Extensions for Network Address 1890 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1891 DOI 10.17487/RFC6147, April 2011, 1892 . 1894 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1895 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1896 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1897 . 1899 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1900 Concerns with IP Tunneling", RFC 6169, 1901 DOI 10.17487/RFC6169, April 2011, 1902 . 1904 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1905 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1906 March 2011, . 1908 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1909 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 1910 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 1911 . 1913 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 1914 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 1915 DOI 10.17487/RFC6221, May 2011, 1916 . 1918 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 1919 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 1920 DOI 10.17487/RFC6264, June 2011, 1921 . 1923 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1924 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1925 DOI 10.17487/RFC6269, June 2011, 1926 . 1928 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1929 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1930 . 1932 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1933 "Logging Recommendations for Internet-Facing Servers", 1934 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 1935 . 1937 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1938 IPv6 Automatic Tunnels: Problem Statement and Proposed 1939 Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, 1940 . 1942 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1943 Stack Lite Broadband Deployments Following IPv4 1944 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1945 . 1947 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1948 RFC 6343, DOI 10.17487/RFC6343, August 2011, 1949 . 1951 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1952 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1953 2011, . 1955 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1956 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1957 Partnership Project (3GPP) Evolved Packet System (EPS)", 1958 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1959 . 1961 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1962 Authentication Trailer for OSPFv3", RFC 6506, 1963 DOI 10.17487/RFC6506, February 2012, 1964 . 1966 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 1967 DOI 10.17487/RFC6547, February 2012, 1968 . 1970 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1971 Neighbor Discovery Problems", RFC 6583, 1972 DOI 10.17487/RFC6583, March 2012, 1973 . 1975 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1976 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1977 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 1978 2012, . 1980 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1981 SAVI: First-Come, First-Served Source Address Validation 1982 Improvement for Locally Assigned IPv6 Addresses", 1983 RFC 6620, DOI 10.17487/RFC6620, May 2012, 1984 . 1986 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 1987 RFC 6666, DOI 10.17487/RFC6666, August 2012, 1988 . 1990 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1991 DOI 10.17487/RFC6762, February 2013, 1992 . 1994 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1995 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1996 . 1998 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1999 Infrastructure (RPKI) to Router Protocol", RFC 6810, 2000 DOI 10.17487/RFC6810, January 2013, 2001 . 2003 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 2004 IPv4 Sites Using the Intra-Site Automatic Tunnel 2005 Addressing Protocol (ISATAP)", RFC 6964, 2006 DOI 10.17487/RFC6964, May 2013, 2007 . 2009 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2010 with IPv6 Neighbor Discovery", RFC 6980, 2011 DOI 10.17487/RFC6980, August 2013, 2012 . 2014 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2015 "Specification of the IP Flow Information Export (IPFIX) 2016 Protocol for the Exchange of Flow Information", STD 77, 2017 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2018 . 2020 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 2021 for IP Flow Information Export (IPFIX)", RFC 7012, 2022 DOI 10.17487/RFC7012, September 2013, 2023 . 2025 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 2026 "Source Address Validation Improvement (SAVI) Framework", 2027 RFC 7039, DOI 10.17487/RFC7039, October 2013, 2028 . 2030 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2031 of IPv6 Extension Headers", RFC 7045, 2032 DOI 10.17487/RFC7045, December 2013, 2033 . 2035 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2036 the IPv6 Prefix Used for IPv6 Address Synthesis", 2037 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2038 . 2040 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 2041 Requirements for IPv6 Customer Edge Routers", RFC 7084, 2042 DOI 10.17487/RFC7084, November 2013, 2043 . 2045 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 2046 Oversized IPv6 Header Chains", RFC 7112, 2047 DOI 10.17487/RFC7112, January 2014, 2048 . 2050 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 2051 Advertisement Guard (RA-Guard)", RFC 7113, 2052 DOI 10.17487/RFC7113, February 2014, 2053 . 2055 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 2056 Authentication Trailer for OSPFv3", RFC 7166, 2057 DOI 10.17487/RFC7166, March 2014, 2058 . 2060 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2061 Interface Identifiers with IPv6 Stateless Address 2062 Autoconfiguration (SLAAC)", RFC 7217, 2063 DOI 10.17487/RFC7217, April 2014, 2064 . 2066 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 2067 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 2068 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 2069 . 2071 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 2072 Addressing inside an IPv6 Network", RFC 7404, 2073 DOI 10.17487/RFC7404, November 2014, 2074 . 2076 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 2077 and O. Vautrin, "Deterministic Address Mapping to Reduce 2078 Logging in Carrier-Grade NAT Deployments", RFC 7422, 2079 DOI 10.17487/RFC7422, December 2014, 2080 . 2082 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 2083 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 2084 February 2015, . 2086 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 2087 Validation Improvement (SAVI) Solution for DHCP", 2088 RFC 7513, DOI 10.17487/RFC7513, May 2015, 2089 . 2091 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 2092 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 2093 DOI 10.17487/RFC7526, May 2015, 2094 . 2096 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 2097 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 2098 Port with Encapsulation (MAP-E)", RFC 7597, 2099 DOI 10.17487/RFC7597, July 2015, 2100 . 2102 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 2103 and T. Murakami, "Mapping of Address and Port using 2104 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2105 2015, . 2107 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 2108 Protecting against Rogue DHCPv6 Servers", BCP 199, 2109 RFC 7610, DOI 10.17487/RFC7610, August 2015, 2110 . 2112 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 2113 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 2114 . 2116 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2117 Considerations for IPv6 Address Generation Mechanisms", 2118 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2119 . 2121 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 2122 "Observations on the Dropping of Packets with IPv6 2123 Extension Headers in the Real World", RFC 7872, 2124 DOI 10.17487/RFC7872, June 2016, 2125 . 2127 [SCANNING] 2128 "Mapping the Great Void - Smarter scanning for IPv6", 2129 . 2132 Authors' Addresses 2134 Kiran K. Chittimaneni 2135 Dropbox Inc. 2136 185 Berry Street, Suite 400 2137 San Francisco, CA 94107 2138 USA 2140 Email: kk@dropbox.com 2142 Merike Kaeo 2143 Double Shot Security 2144 3518 Fremont Ave N 363 2145 Seattle 98103 2146 USA 2148 Phone: +12066696394 2149 Email: merike@doubleshotsecurity.com 2151 Eric Vyncke (editor) 2152 Cisco 2153 De Kleetlaan 6a 2154 Diegem 1831 2155 Belgium 2157 Phone: +32 2 778 4677 2158 Email: evyncke@cisco.com