OPSEC K. Chittimaneni Internet-Draft Google Intended status: Informational M. Kaeo Expires: April 25, 2014 Double Shot Security E. Vyncke Cisco Systems October 22, 2013 Operational Security Considerations for IPv6 Networks draft-ietf-opsec-v6-04 Abstract Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers also need a more practical, operations-minded best common practices. This document analyzes the operational security issues in all places of a network (service providers, enterprises and residential users) and proposes technical and procedural mitigations techniques. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 25, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Chittimaneni, et al. Expires April 25, 2014 [Page 1] Internet-Draft OPsec IPV6 October 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Generic Security Considerations . . . . . . . . . . . . . . . 3 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 3 2.1.1. Overall Structure . . . . . . . . . . . . . . . . . . 4 2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 4 2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . 5 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC . 6 2.1.5. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7 2.2. Link-Layer Security . . . . . . . . . . . . . . . . . . . 7 2.2.1. SeND and CGA . . . . . . . . . . . . . . . . . . . . 7 2.2.2. DHCP Snooping . . . . . . . . . . . . . . . . . . . . 8 2.2.3. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 9 2.2.4. ND/RA Filtering . . . . . . . . . . . . . . . . . . . 10 2.2.5. 3GPP Link-Layer Security . . . . . . . . . . . . . . 11 2.3. Control Plane Security . . . . . . . . . . . . . . . . . 11 2.3.1. Control Protocols . . . . . . . . . . . . . . . . . . 12 2.3.2. Management Protocols . . . . . . . . . . . . . . . . 13 2.3.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 13 2.4. Routing Security . . . . . . . . . . . . . . . . . . . . 14 2.4.1. Authenticating Neighbors/Peers . . . . . . . . . . . 14 2.4.2. Securing Routing Updates Between Peers . . . . . . . 15 2.4.3. Route Filtering . . . . . . . . . . . . . . . . . . . 16 2.5. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 16 2.5.1. Data Sources . . . . . . . . . . . . . . . . . . . . 17 2.5.2. Use of Collected Data . . . . . . . . . . . . . . . . 20 2.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 22 2.6. Transition/Coexistence Technologies . . . . . . . . . . . 22 2.6.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 22 2.6.2. Transition Mechanisms . . . . . . . . . . . . . . . . 23 2.6.3. Translation Mechanisms . . . . . . . . . . . . . . . 27 2.7. General Device Hardening . . . . . . . . . . . . . . . . 28 3. Enterprises Specific Security Considerations . . . . . . . . 28 3.1. External Security Considerations: . . . . . . . . . . . . 29 3.2. Internal Security Considerations: . . . . . . . . . . . . 29 4. Service Providers Security Considerations . . . . . . . . . . 30 Chittimaneni, et al. Expires April 25, 2014 [Page 2] Internet-Draft OPsec IPV6 October 2013 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 30 4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . 30 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 30 5. Residential Users Security Considerations . . . . . . . . . . 31 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 32 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction Running an IPv6 network is new for most operators not only because they are not yet used to large scale IPv6 networks but also because there are subtle differences between IPv4 and IPv6 especially with respect to security. For example, all layer-2 interactions are now done by Neighbor Discovery Protocol [RFC4861] rather than by Address Resolution Protocol [RFC0826]. Also, there are subtle differences between NAT44 and NPTv6 [RFC6296] which are explicitly pointed out in the latter's security considerations section. IPv6 networks are deployed using a variety of techniques, each of which have their own specific security concerns. This document complements [RFC4942] by listing all security issues when operating a network utilizing varying transition technologies and updating with ones that have been standardized since 2007. It also provides more recent operational deployment experiences where warranted. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. 2. Generic Security Considerations 2.1. Addressing Architecture IPv6 address allocations and overall architecture are an important part of securing IPv6. Chittimaneni, et al. Expires April 25, 2014 [Page 3] Internet-Draft OPsec IPV6 October 2013 2.1.1. Overall Structure Once an address allocation has been assigned, there should be some thought given to an overall address allocation plan. A structured address allocation plan can lead to more concise and simpler firewall filtering rules. With the abundance of address space available, an address allocation may be structured around services along with geographic locations, which then can be a basis for more structured network filters to permit or deny services between geographic regions. There still exists a debate whether companies should use PI vs PA space [I-D.ietf-v6ops-enterprise-incremental-ipv6] but from a security perspective there is little difference. However, one aspect to keep in mind is who has ownership of the address space and who is responsible if/when Law Enforcement may need to enforce restrictions on routability of the space due to malicious criminal activity. When considering how to assign manually configured addresses it is necessary to take into consideration the effectiveness of perimeter security in a given environment. There is a trade-off between ease of operational deployment where some portions of the IPv6 address could be easily recognizable for operational debugging and troubleshooting versus the risk of scanning; [SCANNING] shows that there are scientifically based mechanisms that make scanning for IPv6 reachable nodes more realizable than expected. The use of common multicast groups which are defined for important networked devices and the use of commonly repeated addresses could make it easy to figure out which devices are name servers, routers or other critical devices. While in some environments the perimeter security is so poor that obfuscating addresses is considered a benefit; it is a much better practice to ensure that perimeter rules are actively checked and enforced and that manually configured addresses follow some logical allocation scheme for ease of operation. 2.1.2. Use of ULAs ULAs are intended for scenarios where IP addresses will not have global scope. The implicit expectation from the RFC is that all ULAs will be randomly created as /48s. However, in practice some environments have chosen to create ULAs as a /32 by removing the random part of the address. The use of a /32 violates [RFC4193] and greatly reduces the probability of non-collision. ULAs are also useful for infrastructure hiding as described in [RFC4864]. Although ULAs are supposed to be used in conjunction with global addresses for hosts that desire external connectivity, a few operators chose to use ULAs in conjunction with some sort of address translation at the border in order to maintain a perception of parity between their IPv4 Chittimaneni, et al. Expires April 25, 2014 [Page 4] Internet-Draft OPsec IPV6 October 2013 and IPv6 setup. Additionally, there have been some issues with source address selection, although these should be considered bugs to be fixed rather than worked around using NAT. Some operators believe that stateful IPv6 Network Address and Port Translation (NAPT) provides some security not provided by NPTv6 (the authors of this document do not share this point of view). The latter would be problematic in trying to track specific machines that may source malware although this is less of an issue if appropriate logging is done which includes utilizing accurate timestamps and logging a node's source ports [RFC6302]. The use of ULA does not isolate 'by magic' the part of the network using ULA from other parts of the network (including the Internet). Although section 4.1 of [RFC4193] explicitly states "If BGP is being used at the site border with an ISP, the default BGP configuration must filter out any Local IPv6 address prefixes, both incoming and outgoing.", the operational reality is that this guideline is not always followed. As written, RFC4193 makes no changes to default routing behavior of exterior protocols. Therefore, routers will happily forward packets whose source or destination address is ULA as long as they have a route to the destination and there is no ACL blocking those packets. This means that using ULA does not prevent route and packet filters to be implemented and monitored. This also means that all transit networks should consider ULA as source or destination as bogons packets and drop them. It is important to carefully weigh the benefits of using ULAs versus utilizing a section of the global allocation and creating a more effective filtering strategy. A typical argument is that there are too many mistakes made with filters and ULAs make things easier to hide machines. 2.1.3. Point-to-Point Links [RFC6164] recommends the use of /127 for inter-router point-to-point links. /127 prevents the ping-pong attack between routers non enforced RFC4443. However, it should be noted that at the time of this writing, there are still many networks out there that follow the advice provided by [RFC3627] (Obsoleted and marked Historic by [RFC6547]) and therefore continue to use /64's and/or /112's. We recommend that the guidance provided by RFC6164 be followed. Some environments are also using link-local addressing for point-to- point links. While this practice could further reduce the attack surface against infrastructure devices, the operational disadvantages need also to be carefully considered [I-D.ietf-opsec-lla-only]. Chittimaneni, et al. Expires April 25, 2014 [Page 5] Internet-Draft OPsec IPV6 October 2013 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC Normal stateless address autoconfiguration (SLAAC) relies on the automatically generated EUI-64 address, which together with the /64 prefix makes up the global unique IPv6 address. The EUI-64 address is generated from the MAC address. Randomly generating an interface ID, as described in [RFC4941], is part of SLAAC with so-called temporary addresses and used to address some privacy concerns. Temporary addresses a.k.a. privacy extensions may help to mitigate the correlation of activities of a node within the same network, and may also reduce the attack exposure window. As temporary address could also be used to obfuscate some illegal activities (whether on purpose or not), it is advised in scenarios where attribution is important to disable SLAAC and rely only on DHCPv6. However, in scenarios where anonymity is a strong desire since protecting user privacy is more important than attribution, temporary addresses should be used Some people also feel that SLAAC means that the operator may not know addresses operating in the networks ahead of time in order to to build host specific access control lists (ACLs) of authorized users. While privacy addresses are truly generated randomly to protect against user tracking, but assuming that nodes use the EUI-64 format for global addressing, a list of expected pre-authorized host addresses can be generated. It must be noted that recent versions of Windows do not use the MAC address anymore to build the stable address but use a mechanism similar to the one described in [I-D.ietf-6man-stable-privacy-addresses], this also means that such an ACL cannot be configured based solely on the MAC address of the nodes, diminushing the value of such ACL. On the other hand, different VLANs are often used to seggregate users, then ACL can rely on a /64 prefix per VLAN rather than a per host ACL entry. The decision to utilize temporary addresses can come down to whether the network is managed versus unmanaged. In some environments full visibility into the network is required at all times which requires that all traffic be attributable to where it is sourced or where it is destined to within a specific network. This situation is dependent on what level of logging is performed. If logging considerations include utilizing accurate timestamps and logging a node's source ports [RFC6302] then there should always exist appropriate attribution needed to get to the source of any malware originator or source of criminal activity. Chittimaneni, et al. Expires April 25, 2014 [Page 6] Internet-Draft OPsec IPV6 October 2013 However, there are several privacy issues still present with [RFC4941] such as host tracking, and address scanning attacks are still possible. More details are provided in Appendix A. of [I-D.ietf-6man-stable-privacy-addresses]. Disabling SLAAC and temporary addresses can be done by sending Router Advertisement with a hint to use DHCPv6 by setting the M-bit but also disabling SLAAC by resetting all A-bits in all prefixes sent in the Router Advertisement message. 2.1.5. DHCP/DNS Considerations Many environments use DHCPv6 in their environments to ensure audibility and traceability (but see Section 2.5.1.5). A main security concern is the ability to detect and mitigate against rogue DHCP servers (Section 2.2.2). DNS is often used for malware activities and while there are no fundamental differences with IPv4 and IPv6 security concerns, there are specific consideration in DNS64 [RFC6147] environments that need to be understood. Specifically the interactions and potential to interference with DNSsec implementation need to be understood - these are pointed out in detail in Section 2.6.3.2. 2.2. Link-Layer Security IPv6 relies heavily on the Neighbor Discovery protocol (NDP) [RFC4861] to perform a variety of link operations such as discovering other nodes on the link, resolving their link-layer addresses, and finding routers on the link. If not secured, NDP is vulnerable to various attacks such as router/neighbor message spoofing, redirect attacks, Duplicate Address Detection (DAD) DoS attacks, etc. many of these security threats to NDP have been documented in IPv6 ND Trust Models and Threats [RFC3756] and in [RFC6583]. 2.2.1. SeND and CGA The original NDP specification called for using IPsec to protect Neighbor Discovery messages. However, manually configuring security associations among multiple hosts on a large network can be very challenging. In many environments the tradeoff between using technologies that require an effective key management lifecycle process creates more of an operational burden than the protection offered by a given technology. IPsec protection for NDP typically falls under this category. SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a mechanism that was designed to secure ND messages without having to Chittimaneni, et al. Expires April 25, 2014 [Page 7] Internet-Draft OPsec IPV6 October 2013 rely on manual IPsec configuration. This approach involves the use of new NDP options to carry public key based signatures. Cryptographically Generated Addresses (CGA), as described in [RFC3972], are used to ensure that the sender of a Neighbor Discovery message is the actual "owner" of the claimed IPv6 address. A new NDP option, the CGA option, was introduced and is used to carry the public key and associated parameters. Another NDP option, the RSA Signature option, is used to protect all messages relating to neighbor and Router discovery. SeND protects against: o Neighbor Solicitation/Advertisement Spoofing o Neighbor Unreachability Detection Failure o Duplicate Address Detection DoS Attack o Router Solicitation and Advertisement Attacks o Replay Attacks o Neighbor Discovery DoS Attacks SeND does NOT: o Protect statically configured addresses o Protect addresses configured using fixed identifiers (i.e. EUI-64) o Provide confidentiality for NDP communications o Compensate for an unsecured link - SEND does not require that the addresses on the link and Neighbor Advertisements correspond However, at this time, CGA and SeND do not have wide support from generic operating systems; hence, their usefulness is limited. 2.2.2. DHCP Snooping Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in [RFC3315], enables DHCP servers to pass configuration parameters such as IPv6 network addresses and other configuration information to IPv6 nodes. DHCP plays an important role in any large network by providing robust stateful autoconfiguration and autoregistration of DNS Host Names. Chittimaneni, et al. Expires April 25, 2014 [Page 8] Internet-Draft OPsec IPV6 October 2013 The two most common threats to DHCP clients come from malicious or misconfigured DHCP servers. A malicious DHCP server is one that is established with the intent of providing incorrect configuration information to the client. The motivation for doing so may be to mount a "man in the middle" attack instead of a valid server for services such as DNS or to cause a denial of service attack through misconfiguration of the client that causes all network communication from the client to fail. A misconfigured, or sometimes referred to as rogue, DHCP server is one that has unintentionally been configured to answer DHCP client requests with incorrect configuration parameters. Some additional threats against DHCP are discussed in the security considerations section of [RFC3315] [I-D.ietf-opsec-dhcpv6-shield] specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. This mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. Before the DCHPv6-Shield device is deployed, the administrator specifies the layer-2 port(s) on which DHCPv6 packets meant for DHCPv6 clients are allowed. Only those ports to which a DHCPv6 server is to be connected should be specified as such. Once deployed, the DHCPv6-Shield device inspects received packets, and allows DHCPv6 messages meant for DHCPv6 clients only if they are received on layer-2 ports that have been explicitly configured for such purpose. Additionally, the Source Address Validation Improvements (SAVI) working group is currently working on other ways to mitigate the effects of such attacks. [I-D.ietf-savi-dhcp] would help in creating bindings between a DHCPv4 [RFC2131] /DHCPv6 [RFC3315] assigned source IP address and a binding anchor [I-D.ietf-savi-framework] on a SAVI device. Also, [RFC6620] describes how to glean similar bindings when DHCP is not used. The bindings can be used to filter packets generated on the local link with forged source IP address. 2.2.3. ND/RA Rate Limiting Neighbor Discovery (ND) can be vulnerable to denial of service (DoS) attacks in which a router is forced to perform address resolution for a large number of unassigned addresses. Possible side effects of this attack preclude new devices from joining the network or even worse rendering the last hop router ineffective due to high CPU usage. Easy mitigative steps include rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache/timer management. [RFC6583] discusses the potential for DOS in detail and suggests implementation improvements and operational mitigation techniques that may be used to mitigate or alleviate the impact of such attacks. Chittimaneni, et al. Expires April 25, 2014 [Page 9] Internet-Draft OPsec IPV6 October 2013 Here are some feasible mitigation options that can be employed by network operators today: o Ingress filtering of unused addresses by ACL, route filtering, longer than /64 prefix; These require static configuration of the addresses. o Tuning of NDP process (where supported). Additionally, IPv6 ND uses multicast extensively for signaling messages on the local link to avoid broadcast messages for on-the- wire efficiency. However, this has some side effects on wifi networks, especially a negative impact on battery life of smartphones and other battery operated devices that are connected to such networks. The following drafts are actively discussing methods to rate limit RAs and other ND messages on wifi networks in order to address this issue: o [I-D.thubert-savi-ra-throttler] o [I-D.chakrabarti-nordmark-6man-efficient-nd] 2.2.4. ND/RA Filtering Router Advertisement spoofing is a well-known attack vector and has been extensively documented. The presence of rogue RAs, either intentional or malicious, can cause partial or complete failure of operation of hosts on an IPv6 link. For example, a host can select an incorrect router address which can be used as a man-in-the-middle (MITM) attack or can assume wrong prefixes to be used for stateless address configuration (SLAAC). [RFC6104] summarizes the scenarios in which rogue RAs may be observed and presents a list of possible solutions to the problem. [RFC6105] (RA-Guard) describes a solution framework for the rogue RA problem where network segments are designed around switching devices that are capable of identifying invalid RAs and blocking them before the attack packets actually reach the target nodes. However, several evasion techniques that circumvent the protection provided by RA-Guard have surfaced. A key challenge to this mitigation technique is introduced by IPv6 fragmentation. An attacker can conceal the attack by fragmenting his packets into multiple fragments such that the switching device that is responsible for blocking invalid RAs cannot find all the necessary information to perform packet filtering in the same packet. [I-D.ietf-v6ops-ra-guard-implementation] describes such evasion techniques, and provides advice to RA-Guard implementers such that the aforementioned evasion vectors can be eliminated. Chittimaneni, et al. Expires April 25, 2014 [Page 10] Internet-Draft OPsec IPV6 October 2013 Given that the IPv6 Fragmentation Header can be leveraged to circumvent current implementations of RA-Guard, [RFC6980] aims to update [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages except "Certification Path Advertisement", thus allowing for simple and effective measures to counter Neighbor Discovery attacks. It is still recommended that RA-Guard be be employed as a first line of defense against common attack vectors including misconfigured hosts. 2.2.5. 3GPP Link-Layer Security The 3GPP link is a point-to-point like link that has no link-layer address. This implies there can only be an end host and the first- hop router i.e., a GGSN or a PGW on that link. The GGSN/PGW never configures a non link-local address on the link using the prefix advertised on it and the advertised prefix must not be used for on- link determination. There is no need for an address resolution on the 3GPP link, since there are no link-layer addresses. Furthermore, the GGSN/PGW assigns a prefix that is unique within each 3GPP link that uses IPv6 stateless address autoconfiguration. This avoids the necessity to perform DAD at the network level for every address built by the cellular host. The GGSN/PGW always provides an IID to the cellular host for the purpose of configuring the link-local address and ensures the uniqueness of the IID on the link (i.e., no collisions between its own link-local address and the cellular host's). The 3GPP link model itself mitigates most of the known NDP-related Denial-of-Service attacks. In practice, the GGSN/PGW only needs to route all traffic to the cellular host that fall under the prefix assigned to it. This implies the GGSN/PGW may implement a minimal neighbor discovery protocol subset; since, due the point-to-point link model and the absence of link-layer addressing the address resolution can be entirely statically configured per each 3GPP link, and there is no need to defend any other address than the link-local address for very unlikely duplicates. See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP link model, NDP on it and the address configuration detail. 2.3. Control Plane Security [RFC6192] defines the router control plane and this definition is repeated here for the reader's convenience. Chittimaneni, et al. Expires April 25, 2014 [Page 11] Internet-Draft OPsec IPV6 October 2013 Modern router architecture design maintains a strict separation of forwarding and router control plane hardware and software. The router control plane supports routing and management functions. It is generally described as the router architecture hardware and software components for handling packets destined to the device itself as well as building and sending packets originated locally on the device. The forwarding plane is typically described as the router architecture hardware and software components responsible for receiving a packet on an incoming interface, performing a lookup to identify the packet's IP next hop and determine the best outgoing interface towards the destination, and forwarding the packet out through the appropriate outgoing interface. While the forwarding plane is usually implemented in high-speed hardware, the control plane is implemented by a generic processor (named router processor RP) and cannot process packets at a high rate. Hence, this processor can be attacked by flooding its input queue with more packets than it can process. The control plane processor is then unable to process valid control packets and the router can lose OSPF or BGP adjacencies which can cause a severe network disruption. The mitigation technique is: o To drop non-legit control packet before they are queued to the RP (this can be done by a forwarding plane ACL) and o To rate limit the remaining packets to a rate that the RP can sustain. Protocol specific protection should also be done (for example, a spoofed OSPFv3 packet could trigger the execution of the Dijkstra algorithm, therefore the number of Dijsktra execution should be also rate limited). This section will consider several classes of control packets: o Control protocols: routing protocols: such as OSPFv3, BGP and by extension Neighbor Discovery and ICMP o Management protocols: SSH, SNMP, IPfix, etc o Packet exceptions: which are normal data packets which requires a specific processing such as generating a packet-too-big ICMP message or having the hop-by-hop extension header. 2.3.1. Control Protocols This class includes OSPFv3, BGP, NDP, ICMP. Chittimaneni, et al. Expires April 25, 2014 [Page 12] Internet-Draft OPsec IPV6 October 2013 An ingress ACL to be applied on all the router interfaces SHOULD be configured such as: o drop OSPFv3 (identified by Next-Header being 89) and RIPng (identified by UDP port 521) packets from a non link-local address o allow BGP (identified by TCP port 179) packets from all BGP neighbors and drop the others o allow all ICMP packets (transit and to the router interfaces) Note: dropping OSPFv3 packets which are authenticated by IPsec could be impossible on some routers whose ACL are unable to parse the IPsec ESP or AH extension headers. Rate limiting of the valid packets SHOULD be done. The exact configuration obviously depends on the power of the Route Processor. 2.3.2. Management Protocols This class includes: SSH, SNMP, syslog, NTP, etc An ingress ACL to be applied on all the router interfaces SHOULD be configured such as: o Drop packets destined to the routers except those belonging to protocols which are used (for example, permit TCP 22 and drop all when only SSH is used); o Drop packets where the source does not match the security policy, for example if SSH connections should only be originated from the NOC, then the ACL should permit TCP port 22 packets only from the NOC prefix. Rate limiting of the valid packets SHOULD be done. The exact configuration obviously depends on the power of the Route Processor. 2.3.3. Packet Exceptions This class covers multiple cases where a data plane packet is punted to the route processor because it requires specific processing: o generation of an ICMP packet-too-big message when a data plane packet cannot be forwarded because it is too large; o generation of an ICMP hop-limit-expired message when a data plane packet cannot be forwarded because its hop-limit field has reached 0; Chittimaneni, et al. Expires April 25, 2014 [Page 13] Internet-Draft OPsec IPV6 October 2013 o generation of an ICMP destination-unreachable message when a data plane packet cannot be forwarded for any reason; o processing of the hop-by-hop extension header. On some routers, not everything can be done by the specialized data plane hardware which requires some packets to be 'punted' to the generic RP. This could include for example the processing of a long extension header chain in order to apply an ACL based on layer 4 information. [RFC6980] highlights the security implications of oversized header chains on routers and aims to update RFC2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain. An ingress ACL cannot help to mitigate a control plane attack using those packet exceptions. The only protection for the RP is to limit the rate of those packet exceptions forwarded to the RP, this means that some data plane packets will be dropped without any ICMP messages back to the source which will cause Path MTU holes. But, there is no other solution. In addition to limiting the rate of data plane packets queued to the RP, it is also important to limit the generation rate of ICMP messages both the save the RP but also to prevent an amplification attack using the router as a reflector. 2.4. Routing Security Routing security in general can be broadly divided into three sections: 1. Authenticating neighbors/peers 2. Securing routing updates between peers 3. Route filtering [I-D.ietf-opsec-bgp-security] covers these sections specifically for BGP in detail. 2.4.1. Authenticating Neighbors/Peers Chittimaneni, et al. Expires April 25, 2014 [Page 14] Internet-Draft OPsec IPV6 October 2013 A basic element of routing is the process of forming adjacencies, neighbor, or peering relationships with other routers. From a security perspective, it is very important to establish such relationships only with routers and/or administrative domains that one trusts. A traditional approach has been to use MD5 HMAC, which allows routers to authenticate each other prior to establishing a routing relationship. OSPFv3 can rely on IPsec to fulfill the authentication function. However, it should be noted that IPsec support is not standard on all routing platforms. In some cases, this requires specialized hardware that offloads crypto over to dedicated ASICs or enhanced software images (both of which often come with added financial cost) to provide such functionality. An added detail is to determine whether OSPFv3 IPsec implementations use AH or ESP-Null for integrity protection. In early implementations all OSPFv3 IPsec configurations relied on AH since the details weren't specified in [RFC5340] or [RFC2740] that was obsoleted by the former. However, the document which specifically describes how IPsec should be implemented for OSPFv3 [RFC4552] specifically states that ESP-Null MUST and AH MAY be implemented since it follows the overall IPsec standards wordings. OSPFv3 can also use normal ESP to encrypt the OSPFv3 payload to hide the routing information. [RFC6506] changes OSPFv3's reliance on IPsec by appending an authentication trailer to the end of the OSPFv3 packets. This document does not specifically provide for a mechanism that will authenticate the specific originator of a packet. Rather, it will allow a router to confirm that the packet has indeed been issued by a router that had access to the shared authentication key. With all authentication mechanisms, operators should confirm that implementations can support re-keying mechanisms that do not cause outages. There have been instances where any re-keying cause outages and therefore the tradeoff between utilizing this functionality needs to be weighed against the protection it provides. 2.4.2. Securing Routing Updates Between Peers IPv6 initially mandated the provisioning of IPsec capability in all nodes. However, in the updated IPv6 Nodes Requirement standard [RFC6434] is now a SHOULD and not MUST implement. Theoretically it is possible, and recommended, that communication between two IPv6 nodes, including routers exchanging routing information be encrypted using IPsec. In practice however, deploying IPsec is not always feasible given hardware and software limitations of various platforms deployed, as described in the earlier section. Additionally, in a protocol such as OSPFv3 where adjacencies are formed on a one-to-many Chittimaneni, et al. Expires April 25, 2014 [Page 15] Internet-Draft OPsec IPV6 October 2013 basis, IPsec key management becomes difficult to maintain and is not often utilized. 2.4.3. Route Filtering Route filtering policies will be different depending on whether they pertain to edge route filtering vs internal route filtering. At a minimum, IPv6 routing policy as it pertains to routing between different administrative domains should aim to maintain parity with IPv4 from a policy perspective e.g., o Filter internal-use, non-globally routable IPv6 addresses at the perimeter o Discard packets from and to bogon and reserved space o Configure ingress route filters that validate route origin, prefix ownership, etc. through the use of various routing databases, e.g., RADB. There is additional work being done in this area to formally validate the origin ASs of BGP announcements in [RFC6810] Some good recommendations for filtering can be found from Team CYMRU at [CYMRU]. 2.5. Logging/Monitoring In order to perform forensic research in case of any security incident or to detect abnormal behaviors, network operator should log multiple pieces of information. This includes: o logs of all applications when available (for example web servers); o use of IP Flow Information Export [RFC7011] also known as IPfix; o use of SNMP MIB [RFC4293]; o use of the Neighbor cache; o use of stateful DHCPv6 [RFC3315] lease cache. Please note that there are privacy issues related to how those logs are collected, kept and safely discarded. Operators are urged to check their country legislation. All those pieces of information will be used for: Chittimaneni, et al. Expires April 25, 2014 [Page 16] Internet-Draft OPsec IPV6 October 2013 o forensic (Section 2.5.2.1) research to answer questions such as who did what and when? o correlation (Section 2.5.2.3): which IP addresses were used by a specific node (assuming the use of privacy extensions addresses [RFC4941]) o inventory (Section 2.5.2.2): which IPv6 nodes are on my network? o abnormal behavior detection (Section 2.5.2.4): unusual traffic patterns are often the symptoms of a abnormal behavior which is in turn a potential attack (denial of services, network scan, a node being part of a botnet, ...) 2.5.1. Data Sources This section lists the most important sources of data that are useful for operational security. 2.5.1.1. Logs of Applications Those logs are usually text files where the remote IPv6 address is stored in all characters (not binary). This can complicate the processing since one IPv6 address, 2001:db8::1 can be written in multiple ways such as: o 2001:DB8::1 (in uppercase) o 2001:0db8::0001 (with leading 0) o and many other ways. RFC 5952 [RFC5952] explains this problem in detail and recommends the use of a single canonical format (in short use lower case and suppress leading 0). This memo recommends the use of canonical format [RFC5952] for IPv6 addresses in all possible cases. If the existing application cannot log under the canonical format, then this memo recommends the use an external program (or filter) in order to canonicalize all IPv6 addresses. For example, this perl script can be used: #!/usr/bin/perl ?w use strict ; use warnings ; use Socket ; use Socket6 ; Chittimaneni, et al. Expires April 25, 2014 [Page 17] Internet-Draft OPsec IPV6 October 2013 my (@words, $word, $binary_address) ; ## go through the file one line at a time while (my $line = ) { chomp $line; foreach my $word (split /[ \n]/, $line) { $binary_address = inet_pton AF_INET6, $word ; if ($binary_address) { print inet_ntop AF_INET6, $binary_address ; } else { print $word ; } print " " ; } print "\n" ; } 2.5.1.2. IP Flow Information Export by IPv6 Routers IPfix [RFC7012] defines some data elements that are useful for security: o in section 5.4 (IP Header fields): nextHeaderIPv6 and sourceIPv6Address; o in section 5.6 (Sub-IP fields) sourceMacAddress. Moreover, IPfix is very efficient in terms of data handling and transport. It can also aggregate flows by a key such as sourceMacAddress in order to have aggregated data associated with a specific sourceMacAddress. This memo recommends the use of IPfix and aggregation on nextHeaderIPv6, sourceIPv6Address and sourceMacAddress. 2.5.1.3. SNMP MIB by IPv6 Routers RFC 4293 [RFC4293] defines a Management Information Base (MIB) for the two address families of IP. This memo recommends the use of: o ipIfStatsTable table which collects traffic counters per interface; o ipNetToPhysicalTable table which is the content of the Neighbor cache, i.e. the mapping between IPv6 and data-link layer addresses. Chittimaneni, et al. Expires April 25, 2014 [Page 18] Internet-Draft OPsec IPV6 October 2013 2.5.1.4. Neighbor Cache of IPv6 Routers The neighbor cache of routers contains all mappings between IPv6 addresses and data-link layer addresses. It is usually available by two means: o the SNMP MIB (Section 2.5.1.3) as explained above; o also by connecting over a secure management channel (such as SSH or HTTPS) and explicitely requesting a neighbor cache dump. The neighbor cache is highly dynamic as mappings are added when a new IPv6 address appears on the network (could be quite often with privacy extension addresses [RFC4941] or when they are removed when the state goes from UNREACH to removed (the default time for a removal per Neighbor Unreachability Detection [RFC4861] algorithm is 38 seconds for a typical host such as Windows 7). This means that the content of the neighbor cache must periodically be fetched every 30 seconds (to be on the safe side) and stored for later use. This is an important source of information because it is trivial (on a switch not using the SAVI [I-D.ietf-savi-framework] algorithm) to defeat the mapping between data-link layer address and IPv6 address. Let us rephrase the previous statement: having access to the current and past content of the neighbor cache has a paramount value for forensic and audit trail. 2.5.1.5. Stateful DHCPv6 Lease In some networks, IPv6 addresses are managed by stateful DHCPv6 server [RFC3315] that leases IPv6 addresses to clients. It is indeed quite similar to DHCP for IPv4 so it can be tempting to use this DHCP lease file to discover the mapping between IPv6 addresses and data- link layer addresses as it was usually done in the IPv4 era. It is not so easy in the IPv6 era because not all nodes will use DHCPv6 (there are nodes which can only do stateless autoconfiguration) but also because DHCPv6 clients are identified not by their hardware-client address as in IPv4 but by a DHCP Unique ID (DUID) which can have several formats: some being the data-link layer address, some being data-link layer address prepended with time information or even an opaque number which is useless for operation security. Moreover, when the DUID is based on the data-link address, this address can be of any interface of the client (such as the wireless interface while the client actually uses its wired interface to connect to the network). Chittimaneni, et al. Expires April 25, 2014 [Page 19] Internet-Draft OPsec IPV6 October 2013 In short, the DHCPv6 lease file is less interesting than in the IPv4 era. DHCPv6 servers that keeps the relayed data-link layer address in addition to the DUID in the lease file do not suffer from this limitation. On a managed network where all hosts support DHCPv6, special care must be taken to prevent stateless autoconfiguration anyway (and if applicable) by sending RA with all announced prefixes without the A-bit set. The mapping between data-link layer address and the IPv6 address can be secured by using switches implementing the SAVI [I-D.ietf-savi-dhcp] algorithms. 2.5.1.6. Other Data Sources There are other data sources that must be kept exactly as in the IPv4 network: o historical mapping of MAC address to RADIUS user authentication in a IEEE 802.1X network or an IPsec-based remote access VPN; o historical mapping of MAC address to switch interface in a wired network. 2.5.2. Use of Collected Data This section leverages the data collected as described before (Section 2.5.1) in order to achieve several security benefits. 2.5.2.1. Forensic The forensic use case is when the network operator must locate an IPv6 address that was present in the network at a certain time or is still currently in the network. The source of information can be, in decreasing order, neighbor cache, DHCP lease file. Then, the procedure is: 1. based on the IPv6 prefix of the IPv6 address find the router(s) which are used to reach this prefix; 2. based on this limited set of routers, on the incident time and on IPv6 address to retrieve the data-link address from live neighbor cache, from the historical data of the neighbor cache, or from the DHCP lease file; Chittimaneni, et al. Expires April 25, 2014 [Page 20] Internet-Draft OPsec IPV6 October 2013 3. based on the data-link layer address, look-up on which switch interface was this data-link layer address. In the case of wireless LAN, the RADIUS log should have the mapping between user identification and the MAC address. At the end of the process, the interface where the malicious user was connected or the username that was used by the malicious user is found. 2.5.2.2. Inventory RFC 5157 [RFC5157] is about the difficulties to scan an IPv6 network due to the vast number of IPv6 addresses per link. This has the side effect of making the inventory task difficult in an IPv6 network while it was trivial to do in an IPv4 network (a simple enumeration of all IPv4 addresses, followed by a ping and a TCP/UDP port scan). Getting an inventory of all connected devices is of prime importance for a secure operation of a network. There are two ways to do an inventory of an IPv6 network. The first technique is to use the IPfix information and extract the list of all IPv6 source addresses to find all IPv6 nodes that sent packets through a router. This is very efficient but alas will not discover silent node that never transmitted such packets... Also, it must be noted that link-local addresses will never be discovered by this means. The second way is again to use the collected neighbor cache content to find all IPv6 addresses in the cache. This process will also discover all link-local addresses. See Section 2.5.1.4. Another way works only for local network, it consists in sending a ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which is all IPv6 nodes on the network. All nodes should reply to this ECHO_REQUEST per [RFC4443]. 2.5.2.3. Correlation In an IPv4 network, it is easy to correlate multiple logs, for example to find events related to a specific IPv4 address. A simple Unix grep command was enough to scan through multiple text-based files and extract all lines relevant to a specific IPv4 address. In an IPv6 network, this is slightly more difficult because different character strings can express the same IPv6 address. Therefore, the simple Unix grep command cannot be used. Moreover, an IPv6 node can have multiple IPv6 addresses... Chittimaneni, et al. Expires April 25, 2014 [Page 21] Internet-Draft OPsec IPV6 October 2013 In order to do correlation in IPv6-related logs, it is advised to have all logs with canonical IPv6 addresses. Then, the neighbor cache current (or historical) data set must be searched to find the data-link layer address of the IPv6 address. Then, the current and historical neighbor cache data sets must be searched for all IPv6 addresses associated to this data-link layer address: this is the search set. The last step is to search in all log files (containing only IPv6 address in canonical format) for any IPv6 addresses in the search set. 2.5.2.4. Abnormal Behavior Detection Abnormal behaviors (such as network scanning, spamming, denial of service) can be detected in the same way as in an IPv4 network o sudden increase of traffic detected by interface counter (SNMP) or by aggregated traffic from IPfix records [RFC7012]; o change of traffic pattern (number of connection per second, number of connection per host...) with the use of IPfix [RFC7012] 2.5.3. Summary While some data sources (IPfix, MIB, switch CAM tables, logs, ...) used in IPv4 are also used in the secure operation of an IPv6 network, the DHCPv6 lease file is less reliable and the neighbor cache is of prime importance. The fact that there are multiple ways to express in a character string the same IPv6 address renders the use of filters mandatory when correlation must be done. 2.6. Transition/Coexistence Technologies Some text 2.6.1. Dual Stack Dual stack has established itself as the preferred deployment choice for most network operators without a MPLS core where 6PE [RFC4798] is quite common. Dual stacking the network offers many advantages over other transition mechanisms. Firstly, it is easy to turn on without impacting normal IPv4 operations. Secondly, perhaps more importantly, it is easier to troubleshoot when things break. Dual stack allows you to gradually turn IPv4 operations down when your IPv6 network is ready for prime time. Chittimaneni, et al. Expires April 25, 2014 [Page 22] Internet-Draft OPsec IPV6 October 2013 From an operational security perspective, this now means that you have twice the exposure. One needs to think about protecting both protocols now. At a minimum, the IPv6 portion of a dual stacked network should maintain parity with IPv4 from a security policy point of view. Typically, the following methods are employed to protect IPv4 networks at the edge: o ACLs to permit or deny traffic o Firewalls with stateful packet inspection It is recommended that these ACLs and/or firewalls be additionally configured to protect IPv6 communications. Also, given the end-to- end connectivity that IPv6 provides, it is also recommended that hosts be fortified against threats. General device hardening guidelines are provided in Section 2.7 2.6.2. Transition Mechanisms There are many tunnels used for specific use cases. Except when protected by IPsec [RFC4301], all those tunnels have a couple of security issues (most of them being described in RFC 6169 [RFC6169]); o tunnel injection: a malevolent person knowing a few pieces of information (for example the tunnel endpoints and the used protocol) can forge a packet which looks like a legit and valid encapsulated packet that will gladly be accepted by the destination tunnel endpoint, this is a specific case of spoofing; o traffic interception: no confidentiality is provided by the tunnel protocols (without the use of IPsec), therefore anybody on the tunnel path can intercept the traffic and have access to the clear-text IPv6 packet; o service theft: as there is no authorization, even a non authorized user can use a tunnel relay for free (this is a specific case of tunnel injection); o reflection attack: another specific use case of tunnel injection where the attacker injects packets with an IPv4 destination address not matching the IPv6 address causing the first tunnel endpoint to re-encapsulate the packet to the destination... Hence, the final IPv4 destination will not see the original IPv4 address but only one IPv4 address of the relay router. o bypassing security policy: if a firewall or an IPS is on the path of the tunnel, then it will probably neither inspect not detect an malevolent IPv6 traffic contained in the tunnel. Chittimaneni, et al. Expires April 25, 2014 [Page 23] Internet-Draft OPsec IPV6 October 2013 To mitigate the bypassing of security policies, it could be helpful to block all default configuration tunnels by denying all IPv4 traffic matching: o IP protocol 41: this will block ISATAP (Section 2.6.2.2), 6to4 (Section 2.6.2.4), 6rd (Section 2.6.2.5) as well as 6in4 (Section 2.6.2.1) tunnels; o IP protocol 47: this will block GRE (Section 2.6.2.1) tunnels; o UDP protocol 3544: this will block the default encapsulation of Teredo (Section 2.6.2.3) tunnels. Ingress filtering [RFC2827] should also be applied on all tunnel endpoints if applicable to prevent IPv6 address spoofing. As several of the tunnel techniques share the same encapsulation (i.e. IPv4 protocol 41) and embeb the IPv4 address in the IPv6 address, there are a set of well-known looping attacks described in RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 2.6.2.1. Site-to-Site Static Tunnels Site-to-site static tunnels are described in RFC 2529 [RFC2529] and in GRE [RFC2784]. As the IPv4 endpoints are statically configured and are not dynamic they are slightly more secure (bi-directional service theft is mostly impossible) but traffic interception ad tunnel injection are still possible. Therefore, the use of IPsec [RFC4301] in transport mode and protecting the encapsulated IPv4 packets is recommended for those tunnels. Alternatively, IPsec in tunnel mode can be used to transport IPv6 traffic over a non-trusted IPv4 network. 2.6.2.2. ISATAP ISATAP tunnels [RFC5214] are mainly used within a single administrative domain and to connect a single IPv6 host to the IPv6 network. This means that endpoints and and the tunnel endpoint are usually managed by a single entity; therefore, audit trail and strict anti-spoofing are usually possible and this raises the overall security. Special care must be taken to avoid looping attack by implementing the measures of RFC 6324 [RFC6324] and of [RFC6964]. IPsec [RFC4301] in transport or tunnel mode can be used to secure the IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and prevent service theft. Chittimaneni, et al. Expires April 25, 2014 [Page 24] Internet-Draft OPsec IPV6 October 2013 2.6.2.3. Teredo Teredo tunnels [RFC4380] are mainly used in a residential environment because that can easily traverse an IPv4 NAT-PT device thanks to its UDP encapsulation and they connect a single host to the IPv6 Internet. Teredo shares the same issues as other tunnels: no authentication, no confidentiality, possible spoofing and reflection attacks. IPsec [RFC4301] for the transported IPv6 traffic is recommended. The biggest threat to Teredo is probably for IPv4-only network as Teredo has been designed to easily traverse IPV4 NAT-PT devices which are quite often co-located with a stateful firewall. Therefore, if the stateful IPv4 firewall allows unrestricted UDP outbound and accept the return UDP traffic, then Teredo actually punches a hole in this firewall for all IPv6 traffic to the Internet and from the Internet. While host policies can be deployed to block Teredo in an IPv4-only network in order to avoid this firewall bypass, it would be more efficient to block all UDP outbound traffic at the IPv4 firewall if deemed possible (of course, at least port 53 should be left open for DNS traffic). 2.6.2.4. 6to4 6to4 tunnels [RFC3056] require a public routable IPv4 address in order to work correctly. They can be used to provide either one IPv6 host connectivity to the IPv6 Internet or multiple IPv6 networks connectivity to the IPV6 Internet. The 6to4 relay is usually the anycast address defined in [RFC3068]. Some security considerations are explained in [RFC3964]. [RFC6343] points out that if an operator provides well-managed servers and relays for 6to4, non-encapsulated IPv6 packets will pass through well- defined points (the native IPv6 interfaces of those servers and relays) at which security mechanisms may be applied. Client usage of 6to4 by default is now discouraged, and significant precautions are needed to avoid operational problems 2.6.2.5. 6rd While 6rd tunnels share the same encapsulation as 6to4 tunnels (Section 2.6.2.4), they are designed to be used within a single SP domain, in other words they are deployed in a more constrained environment than 6to4 tunnels and have little security issues except lack of confidentiality. The security considerations (Section 12) of [RFC5969] describes how to secure the 6rd tunnels. Chittimaneni, et al. Expires April 25, 2014 [Page 25] Internet-Draft OPsec IPV6 October 2013 IPsec [RFC4301] for the transported IPv6 traffic can be used if confidentiality is important. 2.6.2.6. 6PE and 6VPE Organizations using MPLS in their core can also use 6PE [RFC4798] and 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are really similar to BGP/MPLS IP VPN described in [RFC4364], the security of these networks is also similar to the one described in [RFC4381]. It relies on: o Address space, routing and traffic seperation with the help of VRF (only applicable to 6VPE); o Hiding the IPv4 core, hence removing all attacks against P-routers; o Securing the routing protocol between CE and PE, in the case of 6PE and 6VPE, link-local addresses (see [I-D.ietf-opsec-lla-only]) can be used and as these addresses cannot be reached from outside of the link, the security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP VPN. 2.6.2.7. DS-Lite DS-lite is more a translation mechanism and is therefore analyzed further (Section 2.6.3.3) in this document. 2.6.2.8. Mapping of Address and Port With the tunnel and encapsulation versions of Mapping of Address and Port (MAP [I-D.ietf-softwire-map]), the access network is purely an IPv6 network and MAP protocols are used to give IPv4 hosts on the subscriber network, access to IPv4 hosts on the Internet. The subscriber router does stateful operations in order to map all internal IPv4 addresses and layer-4 ports to the IPv4 address and the set of layer-4 ports received through MAP configuration process. The SP equipment always does stateless operations (either decapsulation or stateless translation). Therefore, as opposed to Section 2.6.3.3 there is no state-exhaustion DoS attack against the SP equipment because there is no state and there is no operation caused by a new layer-4 connection (no logging operation). The SP MAP equipment MUST implement all the security considerations of [I-D.ietf-softwire-map]; notably, ensuring that the mapping of the IPv4 address and port are consistent with the configuration. Chittimaneni, et al. Expires April 25, 2014 [Page 26] Internet-Draft OPsec IPV6 October 2013 2.6.3. Translation Mechanisms Translation mechanisms between IPv4 and IPv6 networks are alternative coexistence strategies while networks transition to IPv6. While a framework is described in [RFC6144] the specific security considerations are documented in each individual mechanism. For the most part they specifically mention interference with IPsec or DNSSEC deployments, how to mitigate spoofed traffic and what some effective filtering strategies may be. 2.6.3.1. Carrier-Grade Nat (CGN) Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT (LSN) or SP NAT is described in [RFC6264] and is utilized as an interim measure to prolong the use of IPv4 in a large service provider network until the provider can deploy and effective IPv6 solution. [RFC6598] requested a specific IANA allocated /10 IPv4 address block to be used as address space shared by all access networks using CGN. This has been allocated as 100.64.0.0/10. Section 13 of [RFC6269] lists some specific security-related issues caused by large scale address sharing. The Security Considerations section of [RFC6598] also lists some specific mitigation techniques for potential misuse of shared address space. [From Panos K: could mention the log size concern and draft-donley- behave-deterministic-cgn that alleviates it] 2.6.3.2. NAT64/DNS64 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used in conjunction with DNS64 [RFC6147], a mechanism which synthesizes AAAA records from existing A records. The Security Consideration sections of [RFC6146] and [RFC6147] list the comprehensive issues. A specific issue with the use of NAT64 is that it will interfere with most IPsec deployments unless UDP encapsulation is used. DNS64 has an incidence on DNSSEC see section 3.1 of [I-D.ietf-behave-nat64-discovery-heuristic]. 2.6.3.3. DS-lite Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that enables a service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address and Port Translation (NAPT) Chittimaneni, et al. Expires April 25, 2014 [Page 27] Internet-Draft OPsec IPV6 October 2013 Security considerations with respect to DS-Lite mainly revolve around logging data, preventing DoS attacks from rogue devices and restricting service offered by the AFTR only to registered customers. Section 11 of [RFC6333] describes important security issues associated with this technology. 2.7. General Device Hardening There are many environments which rely too much on the network infrastructure to disallow malicious traffic to get access to critical hosts. In new IPv6 deployments it has been common to see IPv6 traffic enabled but none of the typical access control mechanisms enabled for IPv6 device access. With the possibility of network device configuration mistakes and the growth of IPv6 in the overall Internet it is important to ensure that all individual devices are hardened agains miscreant behavior. The following guidelines should be used to ensure appropriate hardening of the host, be it an individual computer or router, firewall, load-balancer,server, etc device. o Restrict access to the device to authenticated and authorized individuals o Monitor and audit access to the device o Turn off any unused services on the end node o Understand which IPv6 addresses are being used to source traffic and change defaults if necessary o Use cryptographically protected protocols for device management if possible (SCP, SNMPv3, SSH, TLS, etc) o Use host firewall capabilities to control traffic that gets processed by upper layer protocols o Use virus scanners to detect malicious programs 3. Enterprises Specific Security Considerations Enterprises generally have robust network security policies in place to protect existing IPv4 networks. These policies have been distilled from years of experiential knowledge of securing IPv4 networks. At the very least, it is recommended that enterprise networks have parity between their security policies for both protocol versions. Chittimaneni, et al. Expires April 25, 2014 [Page 28] Internet-Draft OPsec IPV6 October 2013 Security considerations in the enterprise can be broadly categorized into two sections - External and Internal. 3.1. External Security Considerations: The external aspect deals with providing security at the edge or perimeter of the enterprise network where it meets the service providers network. This is commonly achieved by filtering traffic either by implementing dedicated firewalls with stateful packet inspection or a router with ACLs. A common default IPv4 policy on firewalls that could easily be ported to IPv6 is to allow all traffic outbound while only allowing specific traffic, such as established sessions, inbound. Here are a few more things that could enhance the default policy: o Filter internal-use IPv6 addresses at the perimeter o Discard packets from and to bogon and reserved space o Accept certain ICMPv6 messages to allow proper operation of ND and PMTUD, see also [RFC4890] o Filter specific extension headers, where possible o Filter unneeded services at the perimeter o Implement anti-spoofing filtering or other anti-spoof protections o Implement appropriate rate-limiters and control-plane policers 3.2. Internal Security Considerations: The internal aspect deals with providing security inside the perimeter of the network, including the end host. The most significant concerns here are related to Neighbor Discovery. At the network level, it is recommended that all security considerations discussed in Section 2.2 be reviewed carefully and the recommendations be considered in-depth as well. As mentioned in Section 2.6.2, care must be taken when running automated IPv6-in-IP4 tunnels. Chittimaneni, et al. Expires April 25, 2014 [Page 29] Internet-Draft OPsec IPV6 October 2013 Hosts need to be hardened directly through security policy to protect against security threats. The host firewall default capabilities have to be clearly understood, especially 3rd party ones which can have different settings for IPv4 or IPv6 default permit/deny behavior. In some cases, 3rd party firewalls have no IPv6 support whereas the native firewall installed by default has it. General device hardening guidelines are provided in Section 2.7 It should also be noted that many hosts still use IPv4 for transport for things like RADIUS, TACACS+, SYSLOG, etc. This will require some extra level of due diligence on the part of the operator. 4. Service Providers Security Considerations 4.1. BGP The threats and mitigation techniques are identical between IPv4 and IPv6. Broadly speaking they are: o Authenticating the TCP session; o TTL security (which becomes hop-limit security in IPv6); o Prefix Filtering. These are explained in more detail in section Section 2.4. 4.1.1. Remote Triggered Black Hole Filtering RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has allocated 100::/64 as discard prefix [RFC6666]. 4.2. Transition Mechanism SP will typically use transition mechanisms such as 6rd, 6PE, MAP, DS-LITE which have been analyzed in the transition Section 2.6.2 section. 4.3. Lawful Intercept The Lawful Intercept requirements are similar for IPv6 and IPv4 architectures and will be subject to the laws enforced in varying geographic regions. The local issues with each jurisdiction can make this challenging and both corporate legal and privacy personnel should be involved in discussions pertaining to what information gets logged and what the logging retention policies will be. Chittimaneni, et al. Expires April 25, 2014 [Page 30] Internet-Draft OPsec IPV6 October 2013 The target of interception will usually be a residential subscriber (e.g. his/her PPP session or physical line or CPE MAC address). With the absence of NAT on the CPE, IPv6 has the provision to allow for intercepting the traffic from a single host (a /128 target) rather than the whole set of hosts of a subscriber (which could be a /48, a /60 or /64). In contrast, in mobile environments, since the 3GPP specifications allocate a /64 per device, it may be sufficient to intercept traffic from the /64 rather than specific /128's (since each time the device powers up it gets a new IID). A sample architecture which was written for informational purposes is found in [RFC3924]. 5. Residential Users Security Considerations The IETF Homenet working group is working on how IPv6 residential network should be done; this obviously includes operational security considerations; but, this is still work in progress. Residential users have usually less experience and knowledge about security or networking. As most of the recent hosts, smartphones, tablets have all IPv6 enabled by default, IPv6 security is important for those users. Even with an IPv4-only ISP, those users can get IPv6 Internet access with the help of Teredo tunnels. Several peer- to-peer programs (notably Bittorrent) support IPv6 and those programs can initiate a Teredo tunnel through the IPv4 residential gateway, with the consequence of making the internal host reachable from any IPv6 host on the Internet. It is therefore recommended that all host security products (personal firewall, ...) are configured with a dual-stack security policy. If the Residential Gateway has IPv6 connectivity, [RFC6204] defines the requirements of an IPv6 CPE and does not take position on the debate of default IPv6 security policy: o outbound only: allowing all internally initiated connections and block all externally initiated ones, which is a common default security policy enforced by IPv4 Residential Gateway doing NAT-PT but it also breaks the end-to-end reachability promise of IPv6. [RFC6092] lists several recommendations to design such a CPE; o open: allowing all internally and externally initiated connections, therefore restoring the end-to-end nature of the Internet for the IPv6 traffic but having a different security policy for IPv6 than for IPv4. Chittimaneni, et al. Expires April 25, 2014 [Page 31] Internet-Draft OPsec IPV6 October 2013 [RFC6204] states that a clear choice must be given to the user to select one of those two policies. There is also an alternate solution which has been deployed notably by Swisscom ([I-D.v6ops-vyncke-balanced-ipv6-security]: open to all outbound and inbound connections at the exception of an handful of TCP and UDP ports known as vulnerable. 6. Further Reading There are several documents that describe in more details the security of an IPv6 network; these documents are not written by the IETF but are listed here for your convenience: 1. Guidelines for the Secure Deployment of IPv6 [NIST] 2. North American IPv6 Task Force Technology Report - IPv6 Security Technology Paper [NAv6TF_Security] 3. IPv6 Security [IPv6_Security_Book] 7. Acknowledgements The authors would like to thank the following people for their useful comments: Mikael Abrahamsson, Brian Carpenter, Tim Chown, Fernando Gont, Panos Kampanakis, Jouni Korhonen, Mark Lentczner, Tarko Tikan (by alphabetical order). 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations This memo attempts to give an overview of security considerations of operating an IPv6 network both in an IPv6-only network and in utilizing the most widely deployed IPv4/IPv6 coexistence strategies. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011. Chittimaneni, et al. Expires April 25, 2014 [Page 32] Internet-Draft OPsec IPV6 October 2013 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011. 10.2. Informative References [CYMRU] , "Packet Filter and Route Filter Recommendation for IPv6 at xSP routers", , . [I-D.chakrabarti-nordmark-6man-efficient-nd] Chakrabarti, S., Nordmark, E., Thubert, P., and M. Wasserman, "Wired and Wireless IPv6 Neighbor Discovery Optimizations", draft-chakrabarti-nordmark-6man-efficient- nd-03 (work in progress), October 2013. [I-D.ietf-6man-oversized-header-chain] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", draft-ietf-6man-oversized- header-chain-08 (work in progress), October 2013. [I-D.ietf-6man-stable-privacy-addresses] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", draft-ietf-6man-stable- privacy-addresses-14 (work in progress), October 2013. [I-D.ietf-behave-nat64-discovery-heuristic] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", draft- ietf-behave-nat64-discovery-heuristic-17 (work in progress), April 2013. [I-D.ietf-opsec-bgp-security] Durand, J., Pepelnjak, I., and G. Doering, "BGP operations and security", draft-ietf-opsec-bgp-security-01 (work in progress), July 2013. [I-D.ietf-opsec-dhcpv6-shield] Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", draft-ietf- opsec-dhcpv6-shield-00 (work in progress), December 2012. [I-D.ietf-opsec-lla-only] Behringer, M. and E. Vyncke, "Using Only Link-Local Addressing Inside an IPv6 Network", draft-ietf-opsec-lla- only-04 (work in progress), October 2013. Chittimaneni, et al. Expires April 25, 2014 [Page 33] Internet-Draft OPsec IPV6 October 2013 [I-D.ietf-savi-dhcp] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for DHCP", draft-ietf-savi-dhcp-18 (work in progress), June 2013. [I-D.ietf-savi-framework] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, "Source Address Validation Improvement Framework", draft- ietf-savi-framework-06 (work in progress), January 2012. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", draft-ietf-softwire-map-08 (work in progress), August 2013. [I-D.ietf-v6ops-enterprise-incremental-ipv6] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Guidelines", draft-ietf-v6ops-enterprise-incremental- ipv6-04 (work in progress), October 2013. [I-D.ietf-v6ops-ra-guard-implementation] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra- guard-implementation-07 (work in progress), November 2012. [I-D.thubert-savi-ra-throttler] Thubert, P., "Throttling RAs on constrained interfaces", draft-thubert-savi-ra-throttler-01 (work in progress), June 2012. [I-D.v6ops-vyncke-balanced-ipv6-security] Gysi, M., Leclanche, G., Vyncke, E., and R. Anfinsen, "Balanced Security for IPv6 CPE", draft-v6ops-vyncke- balanced-ipv6-security-01 (work in progress), July 2013. [IPv6_Security_Book] Hogg, . and . Vyncke, "IPv6 Security", ISBN 1-58705-594-5, Publisher CiscoPress, December 2008. [NAv6TF_Security] Kaeo, ., Green, ., Bound, ., and . Pouffary, "North American IPv6 Task Force Technology Report - IPv6 Security Technology Paper", 2006, . Chittimaneni, et al. Expires April 25, 2014 [Page 34] Internet-Draft OPsec IPV6 October 2013 [NIST] Frankel, ., Graveman, ., Pearce, ., and . Rooks, "Guidelines for the Secure Deployment of IPv6", 2010, . [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture for Lawful Intercept in IP Networks", RFC 3924, October 2004. Chittimaneni, et al. Expires April 25, 2014 [Page 35] Internet-Draft OPsec IPV6 October 2013 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, February 2006. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006. [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006. [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Chittimaneni, et al. Expires April 25, 2014 [Page 36] Internet-Draft OPsec IPV6 October 2013 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007. [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, August 2009. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011. [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. Chittimaneni, et al. Expires April 25, 2014 [Page 37] Internet-Draft OPsec IPV6 October 2013 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- Router Links", RFC 6164, April 2011. [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011. [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011. [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011. [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011. [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, August 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011. [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011. Chittimaneni, et al. Expires April 25, 2014 [Page 38] Internet-Draft OPsec IPV6 October 2013 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012. [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, February 2012. [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012. [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012. [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012. [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", RFC 6666, August 2012. [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, January 2013. [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 6964, May 2013. [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, August 2013. [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013. [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013. [SCANNING] Chittimaneni, et al. Expires April 25, 2014 [Page 39] Internet-Draft OPsec IPV6 October 2013 , "Mapping the Great Void - Smarter scanning for IPv6", , . Authors' Addresses Kiran Kumar Chittimaneni Google 1600 Amphitheater Pkwy Mountain View 94043 USA Phone: +16502249772 Email: kk@google.com Merike Kaeo Double Shot Security 3518 Fremont Ave N 363 Seattle 98103 USA Phone: +12066696394 Email: merike@doubleshotsecurity.com Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2 778 4677 Email: evyncke@cisco.com Chittimaneni, et al. Expires April 25, 2014 [Page 40]