idnits 2.17.1 draft-ietf-opsec-v6-11.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 (April 11, 2017) is 2571 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: October 13, 2017 Double Shot Security 6 E. Vyncke, Ed. 7 Cisco 8 April 11, 2017 10 Operational Security Considerations for IPv6 Networks 11 draft-ietf-opsec-v6-11 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 October 13, 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.2.4. IP Security Extension Header . . . . . . . . . . . . 9 75 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9 76 2.3.1. SeND and CGA . . . . . . . . . . . . . . . . . . . . 9 77 2.3.2. Securing DHCP . . . . . . . . . . . . . . . . . . . . 10 78 2.3.3. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 10 79 2.3.4. ND/RA Filtering . . . . . . . . . . . . . . . . . . . 11 80 2.3.5. 3GPP Link-Layer Security . . . . . . . . . . . . . . 12 81 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 13 82 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 14 83 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 14 84 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 15 85 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 16 86 2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 16 87 2.5.2. Securing Routing Updates Between Peers . . . . . . . 17 88 2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 17 89 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 17 90 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 18 91 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 22 92 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 24 93 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 24 94 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 24 95 2.7.2. Transition Mechanisms . . . . . . . . . . . . . . . . 25 96 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 29 97 2.8. General Device Hardening . . . . . . . . . . . . . . . . 30 98 3. Enterprises Specific Security Considerations . . . . . . . . 31 99 3.1. External Security Considerations: . . . . . . . . . . . . 31 100 3.2. Internal Security Considerations: . . . . . . . . . . . . 32 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 . . . . . . . . . . . . . . . . . . 33 105 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 33 106 5. Residential Users Security Considerations . . . . . . . . . . 33 107 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 34 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 112 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 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. They have also become a very controversial 327 topic since forwarding nodes that discard packets containing 328 extension headers are known to cause connectivity failures and 329 deployment problems. Understanding the role of varying extension 330 headers is important and this section enumerates the ones that need 331 careful consideration. The IANA has closed the the existing empty 332 "Next Header Types" registry to new entries and is redirecting its 333 users to a new "IPv6 Extension Header Types" registry. 335 A clarification on how intermediate nodes should handle existing 336 packets with extension headers and any extension headers that are 337 defined in the future is found in RFC7045 [RFC7045]. The uniform TLV 338 format to be used for defining future extension headers is described 339 in RFC6564 [RFC6564]. Some observations listed in RFC7872 [RFC7872] 340 seems to indicate that packets with certain extension headers may not 341 traverse the Internet to its intended destination based on operator 342 policies. 344 It must also be noted that there is no indication in the packet 345 whether the Next Protocol field points to an extension header or to a 346 transport header. This may confuse some filtering rules. 348 2.2.1. Order and Repetition of Extension Headers 350 While RFC2460 [RFC2460]RFC2460 defines the order and the maximum 351 repetition of extension headers, there are still IPv6 implementations 352 at the time of writing this document which support a wrong order of 353 headers (such as ESP before routing) or an illegal repetition of 354 headers (such as multiple routing headers). The same applies for 355 options contained in the extension headers (see 356 [I-D.kampanakis-6man-ipv6-eh-parsing]). In some cases, it has lead 357 to nodes crashing when receiving or forwarding wrongly formated 358 packets. 360 2.2.2. Hop-by-Hop Extension Header 362 The hop-by-hop extension header, when present in an IPv6 packet, 363 forces all nodes in the path to inspect this header. This is of 364 course a large avenue for a denial of service as most if not all 365 routers cannot process this kind of packets in hardware but have to 366 'punt' this packet for software processing. See also 367 [I-D.ietf-6man-hbh-header-handling]. 369 2.2.3. Fragmentation Extension Header 371 The fragmentation extension header is used by the source when it has 372 to fragment packets. RFC7112 [RFC7112] explains why it is important 373 to: 375 firewall and security devices should drop first fragment not 376 containing enough of the layer-4 header; 378 destination node should ignore first fragment not containing the 379 entire IPv6 header chain. 381 Else, stateless filtering could be bypassed by an hostile party. 382 RFC6980 [RFC6980] applies the same rule to NDP and the RA-guard 383 function. 385 2.2.4. IP Security Extension Header 387 The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP 388 [RFC4303]) are required if IPsec is to be utilized for network level 389 security functionality. 391 2.3. Link-Layer Security 393 IPv6 relies heavily on the Neighbor Discovery protocol (NDP) RFC4861 394 [RFC4861] to perform a variety of link operations such as discovering 395 other nodes on the link, resolving their link-layer addresses, and 396 finding routers on the link. If not secured, NDP is vulnerable to 397 various attacks such as router/neighbor message spoofing, redirect 398 attacks, Duplicate Address Detection (DAD) DoS attacks, etc. many of 399 these security threats to NDP have been documented in IPv6 ND Trust 400 Models and Threats RFC3756 [RFC3756] and in RFC6583 [RFC6583]. 402 2.3.1. SeND and CGA 404 SEcure Neighbor Discovery (SeND), as described in RFC3971 [RFC3971], 405 is a mechanism that was designed to secure ND messages. This 406 approach involves the use of new NDP options to carry public key 407 based signatures. Cryptographically Generated Addresses (CGA), as 408 described in RFC3972 [RFC3972], are used to ensure that the sender of 409 a Neighbor Discovery message is the actual "owner" of the claimed 410 IPv6 address. A new NDP option, the CGA option, was introduced and 411 is used to carry the public key and associated parameters. Another 412 NDP option, the RSA Signature option, is used to protect all messages 413 relating to neighbor and Router discovery. 415 SeND protects against: 417 o Neighbor Solicitation/Advertisement Spoofing 419 o Neighbor Unreachability Detection Failure 421 o Duplicate Address Detection DoS Attack 423 o Router Solicitation and Advertisement Attacks 425 o Replay Attacks 427 o Neighbor Discovery DoS Attacks 428 SeND does NOT: 430 o Protect statically configured addresses 432 o Protect addresses configured using fixed identifiers (i.e. EUI- 433 64) 435 o Provide confidentiality for NDP communications 437 o Compensate for an unsecured link - SEND does not require that the 438 addresses on the link and Neighbor Advertisements correspond 440 However, at this time and after many years after their 441 specifications, CGA and SeND do not have wide support from generic 442 operating systems; hence, their usefulness is limited. 444 2.3.2. Securing DHCP 446 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in 447 RFC3315 [RFC3315], enables DHCP servers to pass configuration 448 parameters such as IPv6 network addresses and other configuration 449 information to IPv6 nodes. DHCP plays an important role in any large 450 network by providing robust stateful configuration and 451 autoregistration of DNS Host Names. 453 The two most common threats to DHCP clients come from malicious 454 (a.k.a. rogue) or unintentionally misconfigured DHCP servers. A 455 malicious DHCP server is established with the intent of providing 456 incorrect configuration information to the client to cause a denial 457 of service attack or mount a man in the middle attack. While 458 unintentionall, a misconfigured DHCP server can have the same impact. 459 Additional threats against DHCP are discussed in the security 460 considerations section of RFC3315 [RFC3315]DHCP-shield 462 RFC7610 [RFC7610] specifies a mechanism for protecting connected 463 DHCPv6 clients against rogue DHCPv6 servers. This mechanism is based 464 on DHCPv6 packet-filtering at the layer-2 device; the administrator 465 specifies the interfaces connected to DHCPv6 servers. 467 It is recommended to use DHCP-shield. 469 2.3.3. ND/RA Rate Limiting 471 Neighbor Discovery (ND) can be vulnerable to denial of service (DoS) 472 attacks in which a router is forced to perform address resolution for 473 a large number of unassigned addresses. Possible side effects of 474 this attack preclude new devices from joining the network or even 475 worse rendering the last hop router ineffective due to high CPU 476 usage. Easy mitigative steps include rate limiting Neighbor 477 Solicitations, restricting the amount of state reserved for 478 unresolved solicitations, and clever cache/timer management. 480 RFC6583 [RFC6583] discusses the potential for DoS in detail and 481 suggests implementation improvements and operational mitigation 482 techniques that may be used to mitigate or alleviate the impact of 483 such attacks. Here are some feasible mitigation options that can be 484 employed by network operators today: 486 o Ingress filtering of unused addresses by ACL, route filtering, 487 longer than /64 prefix; These require static configuration of the 488 addresses. 490 o Tuning of NDP process (where supported). 492 Additionally, IPv6 ND uses multicast extensively for signaling 493 messages on the local link to avoid broadcast messages for on-the- 494 wire efficiency. However, this has some side effects on wifi 495 networks, especially a negative impact on battery life of smartphones 496 and other battery operated devices that are connected to such 497 networks. The following drafts are actively discussing methods to 498 rate limit RAs and other ND messages on wifi networks in order to 499 address this issue: 501 o [I-D.thubert-savi-ra-throttler] 503 o [I-D.chakrabarti-nordmark-6man-efficient-nd] 505 2.3.4. ND/RA Filtering 507 Router Advertisement spoofing is a well-known attack vector and has 508 been extensively documented. The presence of rogue RAs, either 509 intentional or malicious, can cause partial or complete failure of 510 operation of hosts on an IPv6 link. For example, a host can select 511 an incorrect router address which can be used as a man-in-the-middle 512 (MITM) attack or can assume wrong prefixes to be used for stateless 513 address configuration (SLAAC). RFC6104 [RFC6104] summarizes the 514 scenarios in which rogue RAs may be observed and presents a list of 515 possible solutions to the problem. RFC6105 [RFC6105] (RA-Guard) 516 describes a solution framework for the rogue RA problem where network 517 segments are designed around switching devices that are capable of 518 identifying invalid RAs and blocking them before the attack packets 519 actually reach the target nodes. 521 However, several evasion techniques that circumvent the protection 522 provided by RA-Guard have surfaced. A key challenge to this 523 mitigation technique is introduced by IPv6 fragmentation. An 524 attacker can conceal the attack by fragmenting his packets into 525 multiple fragments such that the switching device that is responsible 526 for blocking invalid RAs cannot find all the necessary information to 527 perform packet filtering in the same packet. RFC7113 [RFC7113] 528 describes such evasion techniques, and provides advice to RA-Guard 529 implementers such that the aforementioned evasion vectors can be 530 eliminated. 532 Given that the IPv6 Fragmentation Header can be leveraged to 533 circumvent current implementations of RA-Guard, RFC6980 [RFC6980] 534 updates RFC4861 [RFC4861] such that use of the IPv6 Fragmentation 535 Header is forbidden in all Neighbor Discovery messages except 536 "Certification Path Advertisement", thus allowing for simple and 537 effective measures to counter Neighbor Discovery attacks. 539 The Source Address Validation Improvements (SAVI) working group has 540 worked on other ways to mitigate the effects of such attacks. 541 RFC7513 [RFC7513] would help in creating bindings between a DHCPv4 542 RFC2131 [RFC2131] /DHCPv6 RFC3315 [RFC3315] assigned source IP 543 address and a binding anchor RFC7039 [RFC7039] on a SAVI device. 544 Also, RFC6620 [RFC6620] describes how to glean similar bindings when 545 DHCP is not used. The bindings can be used to filter packets 546 generated on the local link with forged source IP address. 548 It is still recommended that RA-Guard be be employed as a first line 549 of defense against common attack vectors including misconfigured 550 hosts. 552 2.3.5. 3GPP Link-Layer Security 554 The 3GPP link is a point-to-point like link that has no link-layer 555 address. This implies there can only be an end host (the mobile 556 hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node 557 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never 558 configures a non link-local address on the link using the advertised 559 /64 prefix on it. The advertised prefix must not be used for on-link 560 determination. There is no need for an address resolution on the 561 3GPP link, since there are no link-layer addresses. Furthermore, the 562 GGSN/PGW assigns a prefix that is unique within each 3GPP link that 563 uses IPv6 stateless address autoconfiguration. This avoids the 564 necessity to perform DAD at the network level for every address built 565 by the mobile host. The GGSN/PGW always provides an IID to the 566 cellular host for the purpose of configuring the link-local address 567 and ensures the uniqueness of the IID on the link (i.e., no 568 collisions between its own link-local address and the mobile host's 569 one). 571 The 3GPP link model itself mitigates most of the known NDP-related 572 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to 573 route all traffic to the mobile host that falls under the prefix 574 assigned to it. As there is also a single host on the 3GPP link, 575 there is no need to defend that IPv6 address. 577 See Section 5 of RFC6459 [RFC6459] for a more detailed discussion on 578 the 3GPP link model, NDP on it and the address configuration detail. 580 2.4. Control Plane Security 582 RFC6192 [RFC6192] defines the router control plane. This definition 583 is repeated here for the reader's convenience. 585 Modern router architecture design maintains a strict separation of 586 forwarding and router control plane hardware and software. The 587 router control plane supports routing and management functions. It 588 is generally described as the router architecture hardware and 589 software components for handling packets destined to the device 590 itself as well as building and sending packets originated locally on 591 the device. The forwarding plane is typically described as the 592 router architecture hardware and software components responsible for 593 receiving a packet on an incoming interface, performing a lookup to 594 identify the packet's IP next hop and determine the best outgoing 595 interface towards the destination, and forwarding the packet out 596 through the appropriate outgoing interface. 598 While the forwarding plane is usually implemented in high-speed 599 hardware, the control plane is implemented by a generic processor 600 (named router processor RP) and cannot process packets at a high 601 rate. Hence, this processor can be attacked by flooding its input 602 queue with more packets than it can process. The control plane 603 processor is then unable to process valid control packets and the 604 router can lose OSPF or BGP adjacencies which can cause a severe 605 network disruption. 607 The mitigation technique is: 609 o To drop non-legit control packet before they are queued to the RP 610 (this can be done by a forwarding plane ACL) and 612 o To rate limit the remaining packets to a rate that the RP can 613 sustain. Protocol specific protection should also be done (for 614 example, a spoofed OSPFv3 packet could trigger the execution of 615 the Dijkstra algorithm, therefore the number of Dijsktra execution 616 should be also rate limited). 618 This section will consider several classes of control packets: 620 o Control protocols: routing protocols: such as OSPFv3, BGP and by 621 extension Neighbor Discovery and ICMP 623 o Management protocols: SSH, SNMP, IPfix, etc 625 o Packet exceptions: which are normal data packets which requires a 626 specific processing such as generating a packet-too-big ICMP 627 message or having the hop-by-hop extension header. 629 2.4.1. Control Protocols 631 This class includes OSPFv3, BGP, NDP, ICMP. 633 An ingress ACL to be applied on all the router interfaces SHOULD be 634 configured such as: 636 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 637 (identified by UDP port 521) packets from a non link-local address 639 o allow BGP (identified by TCP port 179) packets from all BGP 640 neighbors and drop the others 642 o allow all ICMP packets (transit and to the router interfaces) 644 Note: dropping OSPFv3 packets which are authenticated by IPsec could 645 be impossible on some routers whose ACL are unable to parse the IPsec 646 ESP or AH extension headers. 648 Rate limiting of the valid packets SHOULD be done. The exact 649 configuration obviously depends on the power of the Route Processor. 651 2.4.2. Management Protocols 653 This class includes: SSH, SNMP, syslog, NTP, etc 655 An ingress ACL to be applied on all the router interfaces SHOULD be 656 configured such as: 658 o Drop packets destined to the routers except those belonging to 659 protocols which are used (for example, permit TCP 22 and drop all 660 when only SSH is used); 662 o Drop packets where the source does not match the security policy, 663 for example if SSH connections should only be originated from the 664 NOC, then the ACL should permit TCP port 22 packets only from the 665 NOC prefix. 667 Rate limiting of the valid packets SHOULD be done. The exact 668 configuration obviously depends on the power of the Route Processor. 670 2.4.3. Packet Exceptions 672 This class covers multiple cases where a data plane packet is punted 673 to the route processor because it requires specific processing: 675 o generation of an ICMP packet-too-big message when a data plane 676 packet cannot be forwarded because it is too large; 678 o generation of an ICMP hop-limit-expired message when a data plane 679 packet cannot be forwarded because its hop-limit field has reached 680 0; 682 o generation of an ICMP destination-unreachable message when a data 683 plane packet cannot be forwarded for any reason; 685 o processing of the hop-by-hop extension header (see also 686 [I-D.ietf-6man-hbh-header-handling]); 688 o or more specific to some router implementation: an oversized 689 extension header chain which cannot be processed by the hardware 690 and force the packet to be punted to the generic router CPU. 692 On some routers, not everything can be done by the specialized data 693 plane hardware which requires some packets to be 'punted' to the 694 generic RP. This could include for example the processing of a long 695 extension header chain in order to apply an ACL based on layer 4 696 information. RFC6980 [RFC6980] and more generally RFC7112 [RFC7112] 697 highlights the security implications of oversized extension header 698 chains on routers and updates RFC2460 [RFC2460] such that the first 699 fragment of a packet is required to contain the entire IPv6 header 700 chain. 702 An ingress ACL cannot help to mitigate a control plane attack using 703 those packet exceptions. The only protection for the RP is to limit 704 the rate of those packet exceptions forwarded to the RP, this means 705 that some data plane packets will be dropped without any ICMP 706 messages back to the source which will cause Path MTU holes. But, 707 there is no other solution. 709 In addition to limiting the rate of data plane packets queued to the 710 RP, it is also important to limit the generation rate of ICMP 711 messages both the save the RP but also to prevent an amplification 712 attack using the router as a reflector. 714 2.5. Routing Security 716 Routing security in general can be broadly divided into three 717 sections: 719 1. Authenticating neighbors/peers 721 2. Securing routing updates between peers 723 3. Route filtering 725 [RFC7454] covers these sections specifically for BGP in detail. 727 2.5.1. Authenticating Neighbors/Peers 729 A basic element of routing is the process of forming adjacencies, 730 neighbor, or peering relationships with other routers. From a 731 security perspective, it is very important to establish such 732 relationships only with routers and/or administrative domains that 733 one trusts. A traditional approach has been to use MD5 HMAC, which 734 allows routers to authenticate each other prior to establishing a 735 routing relationship. 737 OSPFv3 can rely on IPsec to fulfill the authentication function. 738 However, it should be noted that IPsec support is not standard on all 739 routing platforms. In some cases, this requires specialized hardware 740 that offloads crypto over to dedicated ASICs or enhanced software 741 images (both of which often come with added financial cost) to 742 provide such functionality. An added detail is to determine whether 743 OSPFv3 IPsec implementations use AH or ESP-Null for integrity 744 protection. In early implementations all OSPFv3 IPsec configurations 745 relied on AH since the details weren't specified in RFC5340 [RFC5340] 746 or RFC2740 [RFC2740] that was obsoleted by the former. However, the 747 document which specifically describes how IPsec should be implemented 748 for OSPFv3 RFC4552 [RFC4552] specifically states that ESP-Null MUST 749 and AH MAY be implemented since it follows the overall IPsec 750 standards wordings. OSPFv3 can also use normal ESP to encrypt the 751 OSPFv3 payload to hide the routing information. 753 RFC7166 [RFC7166] (which obsoletes RFC6506 [RFC6506] changes OSPFv3's 754 reliance on IPsec by appending an authentication trailer to the end 755 of the OSPFv3 packets. This document does not specifically provide 756 for a mechanism that will authenticate the specific originator of a 757 packet. Rather, it will allow a router to confirm that the packet 758 has indeed been issued by a router that had access to the shared 759 authentication key. 761 With all authentication mechanisms, operators should confirm that 762 implementations can support re-keying mechanisms that do not cause 763 outages. There have been instances where any re-keying cause outages 764 and therefore the tradeoff between utilizing this functionality needs 765 to be weighed against the protection it provides. 767 2.5.2. Securing Routing Updates Between Peers 769 IPv6 initially mandated the provisioning of IPsec capability in all 770 nodes. However, in the updated IPv6 Nodes Requirement standard 771 RFC6434 [RFC6434] is now a SHOULD and not MUST implement. 772 Theoretically it is possible, and recommended, that communication 773 between two IPv6 nodes, including routers exchanging routing 774 information be encrypted using IPsec. In practice however, deploying 775 IPsec is not always feasible given hardware and software limitations 776 of various platforms deployed, as described in the earlier section. 777 Additionally, in a protocol such as OSPFv3 where adjacencies are 778 formed on a one-to-many basis, IPsec key management becomes difficult 779 to maintain and is not often utilized. 781 2.5.3. Route Filtering 783 Route filtering policies will be different depending on whether they 784 pertain to edge route filtering vs internal route filtering. At a 785 minimum, IPv6 routing policy as it pertains to routing between 786 different administrative domains should aim to maintain parity with 787 IPv4 from a policy perspective e.g., 789 o Filter internal-use, non-globally routable IPv6 addresses at the 790 perimeter 792 o Discard packets from and to bogon and reserved space 794 o Configure ingress route filters that validate route origin, prefix 795 ownership, etc. through the use of various routing databases, 796 e.g., RADB. There is additional work being done in this area to 797 formally validate the origin ASs of BGP announcements in RFC6810 798 [RFC6810] 800 Some good recommendations for filtering can be found from Team CYMRU 801 at [CYMRU]. 803 2.6. Logging/Monitoring 805 In order to perform forensic research in case of any security 806 incident or to detect abnormal behaviors, network operator should log 807 multiple pieces of information. 809 This includes: 811 o logs of all applications when available (for example web servers); 813 o use of IP Flow Information Export [RFC7011] also known as IPfix; 815 o use of SNMP MIB [RFC4293]; 817 o use of the Neighbor cache; 819 o use of stateful DHCPv6 [RFC3315] lease cache, especially when a 820 relay agent [RFC6221] in layer-2 switches is used; 822 o use of RADIUS [RFC2866] for accounting records. 824 Please note that there are privacy issues related to how those logs 825 are collected, kept and safely discarded. Operators are urged to 826 check their country legislation. 828 All those pieces of information will be used for: 830 o forensic (Section 2.6.2.1) research to answer questions such as 831 who did what and when? 833 o correlation (Section 2.6.2.3): which IP addresses were used by a 834 specific node (assuming the use of privacy extensions addresses 835 [RFC4941]) 837 o inventory (Section 2.6.2.2): which IPv6 nodes are on my network? 839 o abnormal behavior detection (Section 2.6.2.4): unusual traffic 840 patterns are often the symptoms of a abnormal behavior which is in 841 turn a potential attack (denial of services, network scan, a node 842 being part of a botnet, ...) 844 2.6.1. Data Sources 846 This section lists the most important sources of data that are useful 847 for operational security. 849 2.6.1.1. Logs of Applications 851 Those logs are usually text files where the remote IPv6 address is 852 stored in all characters (not binary). This can complicate the 853 processing since one IPv6 address, 2001:db8::1 can be written in 854 multiple ways such as: 856 o 2001:DB8::1 (in uppercase) 857 o 2001:0db8::0001 (with leading 0) 859 o and many other ways. 861 RFC 5952 [RFC5952] explains this problem in detail and recommends the 862 use of a single canonical format (in short use lower case and 863 suppress leading 0). This memo recommends the use of canonical 864 format [RFC5952] for IPv6 addresses in all possible cases. If the 865 existing application cannot log under the canonical format, then this 866 memo recommends the use an external program in order to canonicalize 867 all IPv6 addresses. 869 For example, this perl script can be used: 871 #!/usr/bin/perl -w 872 use strict ; 873 use warnings ; 874 use Socket ; 875 use Socket6 ; 877 my (@words, $word, $binary_address) ; 879 ## go through the file one line at a time 880 while (my $line = ) { 881 chomp $line; 882 foreach my $word (split /[\s+]/, $line) { 883 $binary_address = inet_pton AF_INET6, $word ; 884 if ($binary_address) { 885 print inet_ntop AF_INET6, $binary_address ; 886 } else { 887 print $word ; 888 } 889 print " " ; 890 } 891 print "\n" ; 892 } 894 2.6.1.2. IP Flow Information Export by IPv6 Routers 896 IPfix [RFC7012] defines some data elements that are useful for 897 security: 899 o in section 5.4 (IP Header fields): nextHeaderIPv6 and 900 sourceIPv6Address; 902 o in section 5.6 (Sub-IP fields) sourceMacAddress. 904 Moreover, IPfix is very efficient in terms of data handling and 905 transport. It can also aggregate flows by a key such as 906 sourceMacAddress in order to have aggregated data associated with a 907 specific sourceMacAddress. This memo recommends the use of IPfix and 908 aggregation on nextHeaderIPv6, sourceIPv6Address and 909 sourceMacAddress. 911 2.6.1.3. SNMP MIB by IPv6 Routers 913 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 914 the two address families of IP. This memo recommends the use of: 916 o ipIfStatsTable table which collects traffic counters per 917 interface; 919 o ipNetToPhysicalTable table which is the content of the Neighbor 920 cache, i.e. the mapping between IPv6 and data-link layer 921 addresses. 923 2.6.1.4. Neighbor Cache of IPv6 Routers 925 The neighbor cache of routers contains all mappings between IPv6 926 addresses and data-link layer addresses. It is usually available by 927 two means: 929 o the SNMP MIB (Section 2.6.1.3) as explained above; 931 o also by connecting over a secure management channel (such as SSH 932 or HTTPS) and explicitely requesting a neighbor cache dump. 934 The neighbor cache is highly dynamic as mappings are added when a new 935 IPv6 address appears on the network (could be quite often with 936 privacy extension addresses [RFC4941] or when they are removed when 937 the state goes from UNREACH to removed (the default time for a 938 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 939 38 seconds for a typical host such as Windows 7). This means that 940 the content of the neighbor cache must periodically be fetched every 941 30 seconds (to be on the safe side) and stored for later use. 943 This is an important source of information because it is trivial (on 944 a switch not using the SAVI [RFC7039] algorithm) to defeat the 945 mapping between data-link layer address and IPv6 address. Let us 946 rephrase the previous statement: having access to the current and 947 past content of the neighbor cache has a paramount value for forensic 948 and audit trail. 950 2.6.1.5. Stateful DHCPv6 Lease 952 In some networks, IPv6 addresses are managed by stateful DHCPv6 953 server [RFC3315] that leases IPv6 addresses to clients. It is indeed 954 quite similar to DHCP for IPv4 so it can be tempting to use this DHCP 955 lease file to discover the mapping between IPv6 addresses and data- 956 link layer addresses as it was usually done in the IPv4 era. 958 It is not so easy in the IPv6 era because not all nodes will use 959 DHCPv6 (there are nodes which can only do stateless 960 autoconfiguration) but also because DHCPv6 clients are identified not 961 by their hardware-client address as in IPv4 but by a DHCP Unique ID 962 (DUID) which can have several formats: some being the data-link layer 963 address, some being data-link layer address prepended with time 964 information or even an opaque number which is useless for operation 965 security. Moreover, when the DUID is based on the data-link address, 966 this address can be of any interface of the client (such as the 967 wireless interface while the client actually uses its wired interface 968 to connect to the network). 970 If a lightweight DHCP relay agent [RFC6221] is used in the layer-2 971 switches, then the DHCP server also receives the Interface-ID 972 information which could be save in order to identifity the interface 973 of the switches which received a specific leased IPv6 address. 975 In short, the DHCPv6 lease file is less interesting than in the IPv4 976 era. DHCPv6 servers that keeps the relayed data-link layer address 977 in addition to the DUID in the lease file do not suffer from this 978 limitation. On a managed network where all hosts support DHCPv6, 979 special care must be taken to prevent stateless autoconfiguration 980 anyway (and if applicable) by sending RA with all announced prefixes 981 without the A-bit set. 983 The mapping between data-link layer address and the IPv6 address can 984 be secured by using switches implementing the SAVI [RFC7513] 985 algorithms. Of course, this also requires that data-link layer 986 address is protected by using layer-2 mechanism such as 987 [IEEE-802.1X]. 989 2.6.1.6. RADIUS Accounting Log 991 For interfaces where the user is authenticated via a RADIUS [RFC2866] 992 server, and if RADIUS accounting is enabled, then the RADIUS server 993 receives accounting Acct-Status-Type records at the start and at the 994 end of the connection which include all IPv6 (and IPv4) addresses 995 used by the user. This technique can be used notably for Wi-Fi 996 networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X 997 [IEEE-802.1X]wired interface on an Ethernet switch. 999 2.6.1.7. Other Data Sources 1001 There are other data sources that must be kept exactly as in the IPv4 1002 network: 1004 o historical mapping of IPv6 addresses to users of remote access 1005 VPN; 1007 o historical mapping of MAC address to switch interface in a wired 1008 network. 1010 2.6.2. Use of Collected Data 1012 This section leverages the data collected as described before 1013 (Section 2.6.1) in order to achieve several security benefits. 1015 2.6.2.1. Forensic 1017 The forensic use case is when the network operator must locate an 1018 IPv6 address that was present in the network at a certain time or is 1019 still currently in the network. 1021 The source of information can be, in decreasing order, neighbor 1022 cache, DHCP lease file. Then, the procedure is: 1024 1. based on the IPv6 prefix of the IPv6 address find the router(s) 1025 which are used to reach this prefix; 1027 2. based on this limited set of routers, on the incident time and on 1028 IPv6 address to retrieve the data-link address from live neighbor 1029 cache, from the historical data of the neighbor cache, or from 1030 the DHCP lease file; 1032 3. based on the data-link layer address, look-up on which switch 1033 interface was this data-link layer address. In the case of 1034 wireless LAN, the RADIUS log should have the mapping between user 1035 identification and the MAC address. 1037 At the end of the process, the interface where the malicious user was 1038 connected or the username that was used by the malicious user is 1039 found. 1041 2.6.2.2. Inventory 1043 RFC 7707 [RFC7707] (which obsoletes RFC 5157 [RFC5157]) is about the 1044 difficulties to scan an IPv6 network due to the vast number of IPv6 1045 addresses per link. This has the side effect of making the inventory 1046 task difficult in an IPv6 network while it was trivial to do in an 1047 IPv4 network (a simple enumeration of all IPv4 addresses, followed by 1048 a ping and a TCP/UDP port scan). Getting an inventory of all 1049 connected devices is of prime importance for a secure operation of a 1050 network. 1052 There are many ways to do an inventory of an IPv6 network. 1054 The first technique is to use the IPfix information and extract the 1055 list of all IPv6 source addresses to find all IPv6 nodes that sent 1056 packets through a router. This is very efficient but alas will not 1057 discover silent node that never transmitted such packets... Also, it 1058 must be noted that link-local addresses will never be discovered by 1059 this means. 1061 The second way is again to use the collected neighbor cache content 1062 to find all IPv6 addresses in the cache. This process will also 1063 discover all link-local addresses. See Section 2.6.1.4. 1065 Another way works only for local network, it consists in sending a 1066 ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 1067 is all IPv6 nodes on the network. All nodes should reply to this 1068 ECHO_REQUEST per [RFC4443]. 1070 Other techniques involve enumerating the DNS zones, parsing log 1071 files, leveraging service discovery such as mDNS RFC6762 [RFC6762] 1072 and RFC6763 [RFC6763]. 1074 Other techniques involve enumerating the DNS zones, especially 1075 looking at reverse DNS records and CNAMES. Or scanning for DNS 1076 misconfigurations to find DNS servers that send NXDOMAIN instead of 1077 NOERROR for non-existing nodes with children, which violates RFC8020 1078 [RFC8020]. Parsing log files and leveraging service discovery such 1079 as mDNS RFC6762 [RFC6762] and RFC6763 [RFC6763] are also added 1080 techniques. 1082 2.6.2.3. Correlation 1084 In an IPv4 network, it is easy to correlate multiple logs, for 1085 example to find events related to a specific IPv4 address. A simple 1086 Unix grep command was enough to scan through multiple text-based 1087 files and extract all lines relevant to a specific IPv4 address. 1089 In an IPv6 network, this is slightly more difficult because different 1090 character strings can express the same IPv6 address. Therefore, the 1091 simple Unix grep command cannot be used. Moreover, an IPv6 node can 1092 have multiple IPv6 addresses... 1094 In order to do correlation in IPv6-related logs, it is advised to 1095 have all logs with canonical IPv6 addresses. Then, the neighbor 1096 cache current (or historical) data set must be searched to find the 1097 data-link layer address of the IPv6 address. Then, the current and 1098 historical neighbor cache data sets must be searched for all IPv6 1099 addresses associated to this data-link layer address: this is the 1100 search set. The last step is to search in all log files (containing 1101 only IPv6 address in canonical format) for any IPv6 addresses in the 1102 search set. 1104 2.6.2.4. Abnormal Behavior Detection 1106 Abnormal behaviors (such as network scanning, spamming, denial of 1107 service) can be detected in the same way as in an IPv4 network 1109 o sudden increase of traffic detected by interface counter (SNMP) or 1110 by aggregated traffic from IPfix records [RFC7012]; 1112 o change of traffic pattern (number of connection per second, number 1113 of connection per host...) with the use of IPfix [RFC7012] 1115 2.6.3. Summary 1117 While some data sources (IPfix, MIB, switch CAM tables, logs, ...) 1118 used in IPv4 are also used in the secure operation of an IPv6 1119 network, the DHCPv6 lease file is less reliable and the neighbor 1120 cache is of prime importance. 1122 The fact that there are multiple ways to express in a character 1123 string the same IPv6 address renders the use of filters mandatory 1124 when correlation must be done. 1126 2.7. Transition/Coexistence Technologies 1128 Some text 1130 2.7.1. Dual Stack 1132 Dual stack has established itself as the preferred deployment choice 1133 for most network operators without an MPLS core where 6PE RFC4798 1134 [RFC4798] is quite common. Dual stacking the network offers many 1135 advantages over other transition mechanisms. Firstly, it is easy to 1136 turn on without impacting normal IPv4 operations. Secondly, perhaps 1137 more importantly, it is easier to troubleshoot when things break. 1138 Dual stack allows you to gradually turn IPv4 operations down when 1139 your IPv6 network is ready for prime time. 1141 From an operational security perspective, this now means that you 1142 have twice the exposure. One needs to think about protecting both 1143 protocols now. At a minimum, the IPv6 portion of a dual stacked 1144 network should maintain parity with IPv4 from a security policy point 1145 of view. Typically, the following methods are employed to protect 1146 IPv4 networks at the edge: 1148 o ACLs to permit or deny traffic 1150 o Firewalls with stateful packet inspection 1152 It is recommended that these ACLs and/or firewalls be additionally 1153 configured to protect IPv6 communications. Also, given the end-to- 1154 end connectivity that IPv6 provides, it is also recommended that 1155 hosts be fortified against threats. General device hardening 1156 guidelines are provided in Section 2.8 1158 2.7.2. Transition Mechanisms 1160 There are many tunnels used for specific use cases. Except when 1161 protected by IPsec [RFC4301], all those tunnels have a couple of 1162 security issues (most of them being described in RFC 6169 [RFC6169]); 1164 o tunnel injection: a malevolent person knowing a few pieces of 1165 information (for example the tunnel endpoints and the used 1166 protocol) can forge a packet which looks like a legit and valid 1167 encapsulated packet that will gladly be accepted by the 1168 destination tunnel endpoint, this is a specific case of spoofing; 1170 o traffic interception: no confidentiality is provided by the tunnel 1171 protocols (without the use of IPsec), therefore anybody on the 1172 tunnel path can intercept the traffic and have access to the 1173 clear-text IPv6 packet; 1175 o service theft: as there is no authorization, even a non authorized 1176 user can use a tunnel relay for free (this is a specific case of 1177 tunnel injection); 1179 o reflection attack: another specific use case of tunnel injection 1180 where the attacker injects packets with an IPv4 destination 1181 address not matching the IPv6 address causing the first tunnel 1182 endpoint to re-encapsulate the packet to the destination... Hence, 1183 the final IPv4 destination will not see the original IPv4 address 1184 but only one IPv4 address of the relay router. 1186 o bypassing security policy: if a firewall or an IPS is on the path 1187 of the tunnel, then it will probably neither inspect not detect an 1188 malevolent IPv6 traffic contained in the tunnel. 1190 To mitigate the bypassing of security policies, it could be helpful 1191 to block all default configuration tunnels by denying all IPv4 1192 traffic matching: 1194 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 1195 (Section 2.7.2.4), 6rd (Section 2.7.2.5) as well as 6in4 1196 (Section 2.7.2.1) tunnels; 1198 o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; 1200 o UDP protocol 3544: this will block the default encapsulation of 1201 Teredo (Section 2.7.2.3) tunnels. 1203 Ingress filtering [RFC2827] should also be applied on all tunnel 1204 endpoints if applicable to prevent IPv6 address spoofing. 1206 As several of the tunnel techniques share the same encapsulation 1207 (i.e. IPv4 protocol 41) and embed the IPv4 address in the IPv6 1208 address, there are a set of well-known looping attacks described in 1209 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 1211 2.7.2.1. Site-to-Site Static Tunnels 1213 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 1214 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 1215 and are not dynamic they are slightly more secure (bi-directional 1216 service theft is mostly impossible) but traffic interception ad 1217 tunnel injection are still possible. Therefore, the use of IPsec 1218 [RFC4301] in transport mode and protecting the encapsulated IPv4 1219 packets is recommended for those tunnels. Alternatively, IPsec in 1220 tunnel mode can be used to transport IPv6 traffic over a non-trusted 1221 IPv4 network. 1223 2.7.2.2. ISATAP 1225 ISATAP tunnels [RFC5214] are mainly used within a single 1226 administrative domain and to connect a single IPv6 host to the IPv6 1227 network. This means that endpoints and and the tunnel endpoint are 1228 usually managed by a single entity; therefore, audit trail and strict 1229 anti-spoofing are usually possible and this raises the overall 1230 security. 1232 Special care must be taken to avoid looping attack by implementing 1233 the measures of RFC 6324 [RFC6324] and of RFC6964 [RFC6964]. 1235 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 1236 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 1237 prevent service theft. 1239 2.7.2.3. Teredo 1241 Teredo tunnels [RFC4380] are mainly used in a residential environment 1242 because that can easily traverse an IPv4 NAT-PT device thanks to its 1243 UDP encapsulation and they connect a single host to the IPv6 1244 Internet. Teredo shares the same issues as other tunnels: no 1245 authentication, no confidentiality, possible spoofing and reflection 1246 attacks. 1248 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 1250 The biggest threat to Teredo is probably for IPv4-only network as 1251 Teredo has been designed to easily traverse IPV4 NAT-PT devices which 1252 are quite often co-located with a stateful firewall. Therefore, if 1253 the stateful IPv4 firewall allows unrestricted UDP outbound and 1254 accept the return UDP traffic, then Teredo actually punches a hole in 1255 this firewall for all IPv6 traffic to the Internet and from the 1256 Internet. While host policies can be deployed to block Teredo in an 1257 IPv4-only network in order to avoid this firewall bypass, it would be 1258 more efficient to block all UDP outbound traffic at the IPv4 firewall 1259 if deemed possible (of course, at least port 53 should be left open 1260 for DNS traffic). 1262 2.7.2.4. 6to4 1264 6to4 tunnels [RFC3056] require a public routable IPv4 address in 1265 order to work correctly. They can be used to provide either one IPv6 1266 host connectivity to the IPv6 Internet or multiple IPv6 networks 1267 connectivity to the IPv6 Internet. The 6to4 relay is usually the 1268 anycast address defined in RFC3068 [RFC3068] which has been 1269 deprecated by RFC7526 [RFC7526], and is no more used by recent 1270 Operating Systems. Some security considerations are explained in 1271 RFC3694 [RFC3964]. 1273 RFC6343 [RFC6343] points out that if an operator provides well- 1274 managed servers and relays for 6to4, non-encapsulated IPv6 packets 1275 will pass through well- defined points (the native IPv6 interfaces of 1276 those servers and relays) at which security mechanisms may be 1277 applied. Client usage of 6to4 by default is now discouraged, and 1278 significant precautions are needed to avoid operational problems. 1280 2.7.2.5. 6rd 1282 While 6rd tunnels share the same encapsulation as 6to4 tunnels 1283 (Section 2.7.2.4), they are designed to be used within a single SP 1284 domain, in other words they are deployed in a more constrained 1285 environment than 6to4 tunnels and have little security issues except 1286 lack of confidentiality. The security considerations (Section 12) of 1287 RFC5969 [RFC5969] describes how to secure the 6rd tunnels. 1289 IPsec [RFC4301] for the transported IPv6 traffic can be used if 1290 confidentiality is important. 1292 2.7.2.6. 6PE and 6VPE 1294 Organizations using MPLS in their core can also use 6PE [RFC4798] and 1295 6VPE RFC4659 [RFC4659] to enable IPv6 access over MPLS. As 6PE and 1296 6VPE are really similar to BGP/MPLS IP VPN described in RFC4364 1297 [RFC4364], the security of these networks is also similar to the one 1298 described in RFC4381 [RFC4381]. It relies on: 1300 o Address space, routing and traffic seperation with the help of VRF 1301 (only applicable to 6VPE); 1303 o Hiding the IPv4 core, hence removing all attacks against 1304 P-routers; 1306 o Securing the routing protocol between CE and PE, in the case of 1307 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 1308 as these addresses cannot be reached from outside of the link, the 1309 security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP 1310 VPN. 1312 2.7.2.7. DS-Lite 1314 DS-lite is more a translation mechanism and is therefore analyzed 1315 further (Section 2.7.3.3) in this document. 1317 2.7.2.8. Mapping of Address and Port 1319 With the tunnel and encapsulation versions of mapping of Address and 1320 Port (MAP-E [RFC7597] and MAP-T [RFC7599]), the access network is 1321 purely an IPv6 network and MAP protocols are used to give IPv4 hosts 1322 on the subscriber network, access to IPv4 hosts on the Internet. The 1323 subscriber router does stateful operations in order to map all 1324 internal IPv4 addresses and layer-4 ports to the IPv4 address and the 1325 set of layer-4 ports received through MAP configuration process. The 1326 SP equipment always does stateless operations (either decapsulation 1327 or stateless translation). Therefore, as opposed to Section 2.7.3.3 1328 there is no state-exhaustion DoS attack against the SP equipment 1329 because there is no state and there is no operation caused by a new 1330 layer-4 connection (no logging operation). 1332 The SP MAP equipment MUST implement all the security considerations 1333 of [RFC7597]; notably, ensuring that the mapping of the IPv4 address 1334 and port are consistent with the configuration. As MAP has a 1335 predictable IPv4 address and port mapping, the audit logs are easier 1336 to manager. 1338 2.7.3. Translation Mechanisms 1340 Translation mechanisms between IPv4 and IPv6 networks are alternative 1341 coexistence strategies while networks transition to IPv6. While a 1342 framework is described in [RFC6144] the specific security 1343 considerations are documented in each individual mechanism. For the 1344 most part they specifically mention interference with IPsec or DNSSEC 1345 deployments, how to mitigate spoofed traffic and what some effective 1346 filtering strategies may be. 1348 2.7.3.1. Carrier-Grade Nat (CGN) 1350 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 1351 (LSN) or SP NAT is described in [RFC6264] and is utilized as an 1352 interim measure to prolong the use of IPv4 in a large service 1353 provider network until the provider can deploy and effective IPv6 1354 solution. [RFC6598] requested a specific IANA allocated /10 IPv4 1355 address block to be used as address space shared by all access 1356 networks using CGN. This has been allocated as 100.64.0.0/10. 1358 Section 13 of [RFC6269] lists some specific security-related issues 1359 caused by large scale address sharing. The Security Considerations 1360 section of [RFC6598] also lists some specific mitigation techniques 1361 for potential misuse of shared address space. 1363 RFC7422 [RFC7422] suggests the use of deterministic address mapping 1364 in order to reduce logging requirements for CGN. The idea is to have 1365 an algorithm mapping back and forth the internal subscriber to public 1366 ports. 1368 2.7.3.2. NAT64/DNS64 1370 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to 1371 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used 1372 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes 1373 AAAA records from existing A records. There is also a stateless 1374 NAT64 [RFC6145] which is similar for the security aspects with the 1375 added benefit of being stateless, so, less prone to a state 1376 exhaustion attack. 1378 The Security Consideration sections of [RFC6146] and [RFC6147] list 1379 the comprehensive issues. A specific issue with the use of NAT64 is 1380 that it will interfere with most IPsec deployments unless UDP 1381 encapsulation is used. DNS64 has an incidence on DNSSEC see section 1382 3.1 of [RFC7050]. 1384 2.7.3.3. DS-Lite 1386 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that 1387 enables a service provider to share IPv4 addresses among customers by 1388 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 1389 Network Address and Port Translation (NAPT). 1391 Security considerations with respect to DS-Lite mainly revolve around 1392 logging data, preventing DoS attacks from rogue devices (as the AFTR 1393 function is stateful) and restricting service offered by the AFTR 1394 only to registered customers. 1396 Section 11 of [RFC6333] describes important security issues 1397 associated with this technology. 1399 2.8. General Device Hardening 1401 There are many environments which rely too much on the network 1402 infrastructure to disallow malicious traffic to get access to 1403 critical hosts. In new IPv6 deployments it has been common to see 1404 IPv6 traffic enabled but none of the typical access control 1405 mechanisms enabled for IPv6 device access. With the possibility of 1406 network device configuration mistakes and the growth of IPv6 in the 1407 overall Internet it is important to ensure that all individual 1408 devices are hardened agains miscreant behavior. 1410 The following guidelines should be used to ensure appropriate 1411 hardening of the host, be it an individual computer or router, 1412 firewall, load-balancer,server, etc device. 1414 o Restrict access to the device to authorized individuals 1416 o Monitor and audit access to the device 1418 o Turn off any unused services on the end node 1420 o Understand which IPv6 addresses are being used to source traffic 1421 and change defaults if necessary 1423 o Use cryptographically protected protocols for device management if 1424 possible (SCP, SNMPv3, SSH, TLS, etc) 1426 o Use host firewall capabilities to control traffic that gets 1427 processed by upper layer protocols 1429 o Use virus scanners to detect malicious programs 1431 3. Enterprises Specific Security Considerations 1433 Enterprises generally have robust network security policies in place 1434 to protect existing IPv4 networks. These policies have been 1435 distilled from years of experiential knowledge of securing IPv4 1436 networks. At the very least, it is recommended that enterprise 1437 networks have parity between their security policies for both 1438 protocol versions. 1440 Security considerations in the enterprise can be broadly categorized 1441 into two sections - External and Internal. 1443 3.1. External Security Considerations: 1445 The external aspect deals with providing security at the edge or 1446 perimeter of the enterprise network where it meets the service 1447 providers network. This is commonly achieved by enforcing a security 1448 policy either by implementing dedicated firewalls with stateful 1449 packet inspection or a router with ACLs. A common default IPv4 1450 policy on firewalls that could easily be ported to IPv6 is to allow 1451 all traffic outbound while only allowing specific traffic, such as 1452 established sessions, inbound (see also [RFC6092]). Here are a few 1453 more things that could enhance the default policy: 1455 o Filter internal-use IPv6 addresses at the perimeter 1457 o Discard packets from and to bogon and reserved space, see also 1458 [CYMRU] 1460 o Accept certain ICMPv6 messages to allow proper operation of ND and 1461 PMTUD, see also [RFC4890] 1463 o Filter specific extension headers by accepting only the required 1464 ones (white list approach) such as ESP, AH (not forgetting the 1465 required transport layers: ICMP, TCP, UDP, ...) , where possible 1466 at the edge and possibly inside the perimeter; see also 1467 [I-D.gont-opsec-ipv6-eh-filtering] 1469 o Filter packets having an illegal IPv6 headers chain at the 1470 perimeter (and possible inside as well), see Section 2.2 1472 o Filter unneeded services at the perimeter 1474 o Implement anti-spoofing 1476 o Implement appropriate rate-limiters and control-plane policers 1478 3.2. Internal Security Considerations: 1480 The internal aspect deals with providing security inside the 1481 perimeter of the network, including the end host. The most 1482 significant concerns here are related to Neighbor Discovery. At the 1483 network level, it is recommended that all security considerations 1484 discussed in Section 2.3 be reviewed carefully and the 1485 recommendations be considered in-depth as well. 1487 As mentioned in Section 2.6.2, care must be taken when running 1488 automated IPv6-in-IP4 tunnels. 1490 Hosts need to be hardened directly through security policy to protect 1491 against security threats. The host firewall default capabilities 1492 have to be clearly understood, especially 3rd party ones which can 1493 have different settings for IPv4 or IPv6 default permit/deny 1494 behavior. In some cases, 3rd party firewalls have no IPv6 support 1495 whereas the native firewall installed by default has it. General 1496 device hardening guidelines are provided in Section 2.8 1498 It should also be noted that many hosts still use IPv4 for transport 1499 for things like RADIUS, TACACS+, SYSLOG, etc. This will require some 1500 extra level of due diligence on the part of the operator. 1502 4. Service Providers Security Considerations 1504 4.1. BGP 1506 The threats and mitigation techniques are identical between IPv4 and 1507 IPv6. Broadly speaking they are: 1509 o Authenticating the TCP session; 1511 o TTL security (which becomes hop-limit security in IPv6); 1513 o Prefix Filtering. 1515 These are explained in more detail in section Section 2.5. 1517 4.1.1. Remote Triggered Black Hole Filtering 1519 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has 1520 allocated 100::/64 as discard prefix RFC6666 [RFC6666]. 1522 4.2. Transition Mechanism 1524 SP will typically use transition mechanisms such as 6rd, 6PE, MAP, 1525 DS-Lite which have been analyzed in the transition Section 2.7.2 1526 section. 1528 4.3. Lawful Intercept 1530 The Lawful Intercept requirements are similar for IPv6 and IPv4 1531 architectures and will be subject to the laws enforced in varying 1532 geographic regions. The local issues with each jurisdiction can make 1533 this challenging and both corporate legal and privacy personnel 1534 should be involved in discussions pertaining to what information gets 1535 logged and what the logging retention policies will be. 1537 The target of interception will usually be a residential subscriber 1538 (e.g. his/her PPP session or physical line or CPE MAC address). With 1539 the absence of NAT on the CPE, IPv6 has the provision to allow for 1540 intercepting the traffic from a single host (a /128 target) rather 1541 than the whole set of hosts of a subscriber (which could be a /48, a 1542 /60 or /64). 1544 In contrast, in mobile environments, since the 3GPP specifications 1545 allocate a /64 per device, it may be sufficient to intercept traffic 1546 from the /64 rather than specific /128's (since each time the device 1547 powers up it gets a new IID). 1549 A sample architecture which was written for informational purposes is 1550 found in [RFC3924]. 1552 5. Residential Users Security Considerations 1554 The IETF Homenet working group is working on how IPv6 residential 1555 network should be done; this obviously includes operational security 1556 considerations; but, this is still work in progress. 1558 Residential users have usually less experience and knowledge about 1559 security or networking. As most of the recent hosts, smartphones, 1560 tablets have all IPv6 enabled by default, IPv6 security is important 1561 for those users. Even with an IPv4-only ISP, those users can get 1562 IPv6 Internet access with the help of Teredo tunnels. Several peer- 1563 to-peer programs (notably Bittorrent) support IPv6 and those programs 1564 can initiate a Teredo tunnel through the IPv4 residential gateway, 1565 with the consequence of making the internal host reachable from any 1566 IPv6 host on the Internet. It is therefore recommended that all host 1567 security products (personal firewall, ...) are configured with a 1568 dual-stack security policy. 1570 If the Residential Gateway has IPv6 connectivity, [RFC7084] (which 1571 obsoletes [RFC6204]) defines the requirements of an IPv6 CPE and does 1572 not take position on the debate of default IPv6 security policy as 1573 defined in [RFC6092]: 1575 o outbound only: allowing all internally initiated connections and 1576 block all externally initiated ones, which is a common default 1577 security policy enforced by IPv4 Residential Gateway doing NAT-PT 1578 but it also breaks the end-to-end reachability promise of IPv6. 1579 [RFC6092] lists several recommendations to design such a CPE; 1581 o open/transparent: allowing all internally and externally initiated 1582 connections, therefore restoring the end-to-end nature of the 1583 Internet for the IPv6 traffic but having a different security 1584 policy for IPv6 than for IPv4. 1586 [RFC6092] REC-49 states that a choice must be given to the user to 1587 select one of those two policies. 1589 There is also an alternate solution which has been deployed notably 1590 by Swisscom ([I-D.ietf-v6ops-balanced-ipv6-security]: open to all 1591 outbound and inbound connections at the exception of an handful of 1592 TCP and UDP ports known as vulnerable. 1594 6. Further Reading 1596 There are several documents that describe in more details the 1597 security of an IPv6 network; these documents are not written by the 1598 IETF but are listed here for your convenience: 1600 1. Guidelines for the Secure Deployment of IPv6 [NIST] 1602 2. North American IPv6 Task Force Technology Report - IPv6 Security 1603 Technology Paper [NAv6TF_Security] 1605 3. IPv6 Security [IPv6_Security_Book] 1607 7. Acknowledgements 1609 The authors would like to thank the following people for their useful 1610 comments: Mikael Abrahamsson, Fred Baker, Brian Carpenter, Tim Chown, 1611 Markus deBruen, Fernando Gont, Jeffry Handal, Panos Kampanakis, Erik 1612 Kline, Jouni Korhonen, Mark Lentczner, Bob Sleigh,Tarko Tikan (by 1613 alphabetical order). 1615 8. IANA Considerations 1617 This memo includes no request to IANA. 1619 9. Security Considerations 1621 This memo attempts to give an overview of security considerations of 1622 operating an IPv6 network both in an IPv6-only network and in 1623 utilizing the most widely deployed IPv4/IPv6 coexistence strategies. 1625 10. References 1627 10.1. Normative References 1629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1630 Requirement Levels", BCP 14, RFC 2119, 1631 DOI 10.17487/RFC2119, March 1997, 1632 . 1634 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1635 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1636 December 1998, . 1638 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1639 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 1640 February 2011, . 1642 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1643 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1644 DOI 10.17487/RFC6105, February 2011, 1645 . 1647 10.2. Informative References 1649 [CYMRU] "Packet Filter and Route Filter Recommendation for IPv6 at 1650 xSP routers", . 1654 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1655 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 1656 Wasserman, "IPv6 Neighbor Discovery Optimizations for 1657 Wired and Wireless Networks", draft-chakrabarti-nordmark- 1658 6man-efficient-nd-07 (work in progress), February 2015. 1660 [I-D.gont-opsec-ipv6-eh-filtering] 1661 Gont, F., Will, W., and R. Bonica, "Recommendations on 1662 Filtering of IPv6 Packets Containing IPv6 Extension 1663 Headers", draft-gont-opsec-ipv6-eh-filtering-02 (work in 1664 progress), August 2014. 1666 [I-D.ietf-6man-hbh-header-handling] 1667 Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options 1668 Extension Header", draft-ietf-6man-hbh-header-handling-03 1669 (work in progress), March 2016. 1671 [I-D.ietf-v6ops-balanced-ipv6-security] 1672 Gysi, M., Leclanche, G., Vyncke, E., and R. Anfinsen, 1673 "Balanced Security for IPv6 Residential CPE", draft-ietf- 1674 v6ops-balanced-ipv6-security-01 (work in progress), 1675 December 2013. 1677 [I-D.kampanakis-6man-ipv6-eh-parsing] 1678 Kampanakis, P., "Implementation Guidelines for parsing 1679 IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh- 1680 parsing-01 (work in progress), August 2014. 1682 [I-D.thubert-savi-ra-throttler] 1683 Thubert, P., "Throttling RAs on constrained interfaces", 1684 draft-thubert-savi-ra-throttler-01 (work in progress), 1685 June 2012. 1687 [IEEE-802.1X] 1688 IEEE, , "IEEE Standard for Local and metropolitan area 1689 networks - Port-Based Network Access Control", IEEE Std 1690 802.1X-2010, February 2010. 1692 [IPv6_Security_Book] 1693 Hogg, and Vyncke, "IPv6 Security", ISBN 1-58705-594-5, 1694 Publisher CiscoPress, December 2008. 1696 [NAv6TF_Security] 1697 Kaeo, , Green, , Bound, , and Pouffary, "North American 1698 IPv6 Task Force Technology Report - IPv6 Security 1699 Technology Paper", 2006, 1700 . 1703 [NIST] Frankel, , Graveman, , Pearce, , and Rooks, "Guidelines 1704 for the Secure Deployment of IPv6", 2010, 1705 . 1708 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1709 Converting Network Protocol Addresses to 48.bit Ethernet 1710 Address for Transmission on Ethernet Hardware", STD 37, 1711 RFC 826, DOI 10.17487/RFC0826, November 1982, 1712 . 1714 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1715 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1716 . 1718 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1719 Domains without Explicit Tunnels", RFC 2529, 1720 DOI 10.17487/RFC2529, March 1999, 1721 . 1723 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1724 RFC 2740, DOI 10.17487/RFC2740, December 1999, 1725 . 1727 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1728 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1729 DOI 10.17487/RFC2784, March 2000, 1730 . 1732 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1733 Defeating Denial of Service Attacks which employ IP Source 1734 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1735 May 2000, . 1737 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 1738 DOI 10.17487/RFC2866, June 2000, 1739 . 1741 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1742 DOI 10.17487/RFC2993, November 2000, 1743 . 1745 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1746 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1747 2001, . 1749 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1750 RFC 3068, DOI 10.17487/RFC3068, June 2001, 1751 . 1753 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1754 C., and M. Carney, "Dynamic Host Configuration Protocol 1755 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1756 2003, . 1758 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1759 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1760 September 2003, . 1762 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1763 Neighbor Discovery (ND) Trust Models and Threats", 1764 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1765 . 1767 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 1768 for Lawful Intercept in IP Networks", RFC 3924, 1769 DOI 10.17487/RFC3924, October 2004, 1770 . 1772 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1773 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, 1774 . 1776 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1777 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1778 DOI 10.17487/RFC3971, March 2005, 1779 . 1781 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1782 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1783 . 1785 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1786 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1787 . 1789 [RFC4293] Routhier, S., Ed., "Management Information Base for the 1790 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 1791 April 2006, . 1793 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1794 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1795 December 2005, . 1797 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1798 DOI 10.17487/RFC4302, December 2005, 1799 . 1801 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1802 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1803 . 1805 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1806 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1807 2006, . 1809 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1810 Network Address Translations (NATs)", RFC 4380, 1811 DOI 10.17487/RFC4380, February 2006, 1812 . 1814 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1815 Virtual Private Networks (VPNs)", RFC 4381, 1816 DOI 10.17487/RFC4381, February 2006, 1817 . 1819 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1820 Control Message Protocol (ICMPv6) for the Internet 1821 Protocol Version 6 (IPv6) Specification", RFC 4443, 1822 DOI 10.17487/RFC4443, March 2006, 1823 . 1825 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1826 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1827 . 1829 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1830 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1831 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1832 . 1834 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1835 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1836 Provider Edge Routers (6PE)", RFC 4798, 1837 DOI 10.17487/RFC4798, February 2007, 1838 . 1840 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1841 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1842 DOI 10.17487/RFC4861, September 2007, 1843 . 1845 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1846 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1847 DOI 10.17487/RFC4864, May 2007, 1848 . 1850 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1851 ICMPv6 Messages in Firewalls", RFC 4890, 1852 DOI 10.17487/RFC4890, May 2007, 1853 . 1855 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1856 Extensions for Stateless Address Autoconfiguration in 1857 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1858 . 1860 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1861 Co-existence Security Considerations", RFC 4942, 1862 DOI 10.17487/RFC4942, September 2007, 1863 . 1865 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1866 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1867 . 1869 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1870 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1871 DOI 10.17487/RFC5214, March 2008, 1872 . 1874 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1875 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1876 . 1878 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 1879 Filtering with Unicast Reverse Path Forwarding (uRPF)", 1880 RFC 5635, DOI 10.17487/RFC5635, August 2009, 1881 . 1883 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1884 Address Text Representation", RFC 5952, 1885 DOI 10.17487/RFC5952, August 2010, 1886 . 1888 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1889 Infrastructures (6rd) -- Protocol Specification", 1890 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1891 . 1893 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1894 Capabilities in Customer Premises Equipment (CPE) for 1895 Providing Residential IPv6 Internet Service", RFC 6092, 1896 DOI 10.17487/RFC6092, January 2011, 1897 . 1899 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1900 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1901 April 2011, . 1903 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1904 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 1905 . 1907 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1908 NAT64: Network Address and Protocol Translation from IPv6 1909 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1910 April 2011, . 1912 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1913 Beijnum, "DNS64: DNS Extensions for Network Address 1914 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1915 DOI 10.17487/RFC6147, April 2011, 1916 . 1918 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1919 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1920 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1921 . 1923 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1924 Concerns with IP Tunneling", RFC 6169, 1925 DOI 10.17487/RFC6169, April 2011, 1926 . 1928 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1929 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1930 March 2011, . 1932 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1933 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 1934 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 1935 . 1937 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 1938 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 1939 DOI 10.17487/RFC6221, May 2011, 1940 . 1942 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 1943 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 1944 DOI 10.17487/RFC6264, June 2011, 1945 . 1947 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1948 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1949 DOI 10.17487/RFC6269, June 2011, 1950 . 1952 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1953 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1954 . 1956 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1957 "Logging Recommendations for Internet-Facing Servers", 1958 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 1959 . 1961 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1962 IPv6 Automatic Tunnels: Problem Statement and Proposed 1963 Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, 1964 . 1966 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1967 Stack Lite Broadband Deployments Following IPv4 1968 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1969 . 1971 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1972 RFC 6343, DOI 10.17487/RFC6343, August 2011, 1973 . 1975 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1976 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1977 2011, . 1979 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1980 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1981 Partnership Project (3GPP) Evolved Packet System (EPS)", 1982 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1983 . 1985 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1986 Authentication Trailer for OSPFv3", RFC 6506, 1987 DOI 10.17487/RFC6506, February 2012, 1988 . 1990 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 1991 DOI 10.17487/RFC6547, February 2012, 1992 . 1994 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 1995 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 1996 RFC 6564, DOI 10.17487/RFC6564, April 2012, 1997 . 1999 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 2000 Neighbor Discovery Problems", RFC 6583, 2001 DOI 10.17487/RFC6583, March 2012, 2002 . 2004 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 2005 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 2006 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2007 2012, . 2009 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2010 SAVI: First-Come, First-Served Source Address Validation 2011 Improvement for Locally Assigned IPv6 Addresses", 2012 RFC 6620, DOI 10.17487/RFC6620, May 2012, 2013 . 2015 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 2016 RFC 6666, DOI 10.17487/RFC6666, August 2012, 2017 . 2019 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2020 DOI 10.17487/RFC6762, February 2013, 2021 . 2023 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2024 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2025 . 2027 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 2028 Infrastructure (RPKI) to Router Protocol", RFC 6810, 2029 DOI 10.17487/RFC6810, January 2013, 2030 . 2032 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 2033 IPv4 Sites Using the Intra-Site Automatic Tunnel 2034 Addressing Protocol (ISATAP)", RFC 6964, 2035 DOI 10.17487/RFC6964, May 2013, 2036 . 2038 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2039 with IPv6 Neighbor Discovery", RFC 6980, 2040 DOI 10.17487/RFC6980, August 2013, 2041 . 2043 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2044 "Specification of the IP Flow Information Export (IPFIX) 2045 Protocol for the Exchange of Flow Information", STD 77, 2046 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2047 . 2049 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 2050 for IP Flow Information Export (IPFIX)", RFC 7012, 2051 DOI 10.17487/RFC7012, September 2013, 2052 . 2054 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 2055 "Source Address Validation Improvement (SAVI) Framework", 2056 RFC 7039, DOI 10.17487/RFC7039, October 2013, 2057 . 2059 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2060 of IPv6 Extension Headers", RFC 7045, 2061 DOI 10.17487/RFC7045, December 2013, 2062 . 2064 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2065 the IPv6 Prefix Used for IPv6 Address Synthesis", 2066 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2067 . 2069 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 2070 Requirements for IPv6 Customer Edge Routers", RFC 7084, 2071 DOI 10.17487/RFC7084, November 2013, 2072 . 2074 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 2075 Oversized IPv6 Header Chains", RFC 7112, 2076 DOI 10.17487/RFC7112, January 2014, 2077 . 2079 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 2080 Advertisement Guard (RA-Guard)", RFC 7113, 2081 DOI 10.17487/RFC7113, February 2014, 2082 . 2084 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 2085 Authentication Trailer for OSPFv3", RFC 7166, 2086 DOI 10.17487/RFC7166, March 2014, 2087 . 2089 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2090 Interface Identifiers with IPv6 Stateless Address 2091 Autoconfiguration (SLAAC)", RFC 7217, 2092 DOI 10.17487/RFC7217, April 2014, 2093 . 2095 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 2096 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 2097 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 2098 . 2100 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 2101 Addressing inside an IPv6 Network", RFC 7404, 2102 DOI 10.17487/RFC7404, November 2014, 2103 . 2105 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 2106 and O. Vautrin, "Deterministic Address Mapping to Reduce 2107 Logging in Carrier-Grade NAT Deployments", RFC 7422, 2108 DOI 10.17487/RFC7422, December 2014, 2109 . 2111 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 2112 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 2113 February 2015, . 2115 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 2116 Validation Improvement (SAVI) Solution for DHCP", 2117 RFC 7513, DOI 10.17487/RFC7513, May 2015, 2118 . 2120 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 2121 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 2122 DOI 10.17487/RFC7526, May 2015, 2123 . 2125 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 2126 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 2127 Port with Encapsulation (MAP-E)", RFC 7597, 2128 DOI 10.17487/RFC7597, July 2015, 2129 . 2131 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 2132 and T. Murakami, "Mapping of Address and Port using 2133 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2134 2015, . 2136 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 2137 Protecting against Rogue DHCPv6 Servers", BCP 199, 2138 RFC 7610, DOI 10.17487/RFC7610, August 2015, 2139 . 2141 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 2142 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 2143 . 2145 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2146 Considerations for IPv6 Address Generation Mechanisms", 2147 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2148 . 2150 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 2151 "Observations on the Dropping of Packets with IPv6 2152 Extension Headers in the Real World", RFC 7872, 2153 DOI 10.17487/RFC7872, June 2016, 2154 . 2156 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 2157 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 2158 November 2016, . 2160 [SCANNING] 2161 "Mapping the Great Void - Smarter scanning for IPv6", 2162 . 2165 Authors' Addresses 2167 Kiran K. Chittimaneni 2168 Dropbox Inc. 2169 185 Berry Street, Suite 400 2170 San Francisco, CA 94107 2171 USA 2173 Email: kk@dropbox.com 2175 Merike Kaeo 2176 Double Shot Security 2177 3518 Fremont Ave N 363 2178 Seattle 98103 2179 USA 2181 Phone: +12066696394 2182 Email: merike@doubleshotsecurity.com 2183 Eric Vyncke (editor) 2184 Cisco 2185 De Kleetlaan 6a 2186 Diegem 1831 2187 Belgium 2189 Phone: +32 2 778 4677 2190 Email: evyncke@cisco.com