| Operational Security Capabilities for IPv6 Network Infrastructure | K. Chittimaneni |
| Internet-Draft | |
| Intended status: Informational | M. Kaeo |
| Expires: January 15, 2013 | ISC |
| E. Vyncke | |
| Cisco Systems | |
| July 16, 2012 |
Operational Security Considerations for IPv6 Networks
draft-vyncke-opsec-v6-01
Network managers know how to operate securely IPv4 network: whether it is the Internet or an enterprise internal network. IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers need also a more practical, operation-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.
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 January 15, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
Running an IPv6 network is new for most operators not only because they are not yet used to large scale IPv6 network 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]. Moreover, for end-users that usually combination in a single box Customer Premice Equipment (CPE) of firewall and Network Address and Port Translation [RFC3022] has lead to the common feeling that NATPT equals security and with IPv6 NATPT is no more needed.
The deployment of IPv6 network is commonly done with the dual-stack technique [RFC4213] which also leads to specific security issues.
This document complements [RFC4942] by listing all security issues when operating a network.
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.
IPv6 address allocations and overall architecture are an import part of securing IPv6.
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.
An important consideration for manually configured addressing is to make them hard to guess whenever possible. When manually configuring interface ID's, the more common forms of starting at the beginning or end of a subnet boundary (i.e using a 1 or FF for routers) should be avoided. This will make any potential reconnaissance attack attempt much more difficult. Although some common multicast groups are defined for important networked devices and use of commonly repeated addresses make it easy figure out what the name servers, routers or other critical devices are, a non-random manual address scheme also makes it easy for a potential attacker using a "dictionary attack" of commonly used interface IDs to find your critical infrastructure.
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. While ULAs can be useful for infrastructure hiding, it may create an issue in future if the decision at some point is to make the machines using ULAs globally reachable. This would require renumbering or perhaps even stateful IPv6 Network Address Translation (NAT). The latter would again be problematic in trying to track specific machines that may source malware. 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.
RFC3627 indicates that the use of a /64 is the best solution for point-to-point links while a /112 can be used if that's not possible. However, in current deployments where it is felt that using a /64 is wasteful for point-to-point links, many opt to use a /127 or /126 subnet boundary and create manually defined IPv6 addresses for the point-to-point or tunnel endpoints.
Randomly generating an interface ID, as described in RFC 3041, is part of stateless autoconfiguration and used to address some security concerns. Stateless autoconfiguration relies on the automatically generated EUI-64 node address, which together with the /64 prefix make up the global unique IPv6 address. The EUI-64 address is generated from the MAC address. Since MAC addresses for specific vendor equipment can be know, it may be easy for a potential attacker to perform a more directed intelligent scan to try and ascertain specific vendor device reachability for exploitation. Privacy addressing attempts to mitigate this threat.
As privacy addressing could also be used to hide illegal and unsavory activities, privacy addressing can be assigned, audited, and controlled in managed enterprise networks via DHCPv6.
Some people also feel that stateless addressing means that we may not know addresses operating in our networks ahead of time in order to to build 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.
Some text
Link layer security is quite possibly the most important and visible security consideration for most operators. IPv6 relied heavily on the Neighbor Discovery protocol (NDP) [RFC4861] to perform a variety of link operations such as discovering other nodes not he 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]
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. SEcure Neighbor Discovery (SEND), as described in [RFC3971], is a mechanism designed to secure ND messages without having to rely on manual IPsec configuration. 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 address. A new NDP option, the CGA option, 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:
SEND does NOT:
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. Misconfigured (rogue) or malicious DHCP servers can be leveraged to attack IPv6 nodes either by denying nodes from getting a valid address/prefix or by disseminating incorrect information to end nodes for malicious purposes. Some of these scenarios are discussed in [RFC3315]
The Source Address Validation Improvements (SAVI) group is currently working on 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 SAVI (Source Address Validation Improvements) device. [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.
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 mplementation improvements and operational mitigation techniques that may be used to mitigate or alleviate the impact of such attacks.
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:
Router Advertising 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] 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. This mechanism is commonly employed as a first line of defense against common attack vectors.
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.
[I-D.gont-6man-nd-extension-headers] attempts to analyze the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. The ultimate goal of this doc is to update RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective measures to counter Neighbor Discovery attacks.
[RFC6192] defines the router control plane and this definition is repeated here for the reader's convenience.
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:
This section will consider several classes of control packets:
This class includes OSPFv3, BGP, NDP, ICMP.
An ingress ACL to be applied on all the router interfaces SHOULD be configured such as:
Note: dropping OSPFv3 packets which are authenticated by IPsec could be impossible on some routers which 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.
This class includes: SSH, SNMP, syslog, IPfix, NTP, etc
An ingress ACL to be applied on all the router interfaces SHOULD be configured such as:
Rate limiting of the valid packets SHOULD be done. The exact configuration obviously depends on the power of the Route Processor.
This class covers multiple cases where a data plane packet is punted to the route processor because it requires specific processing:
On some routers, not everything can be done by the specialized data plane hardware.. then some packets are '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.
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 with 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.
Routing security in general can be broadly divided into three sections:
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 passwords, which allows routers to authenticate each other prior to establishing a routing relationship. Most open standard protocols, with the notable exception of OSPFv3, are able to provide this type of authentication mechanism.
OSPFv3 relies 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. [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 authentication key.
IPv6 mandates the provisioning of IPSEC capability in all nodes. 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, most key management mechanisms are designed for a one-to-one communication model. However, in a protocol such as OSPFv3 where adjacencies are formed on a one-to-many basis, IPSEC key management becomes difficult to maintain.
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.,
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:
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 to do:
This section lists the most important sources of data that are useful for operational security.
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:
RFC 5952 [RFC5952] explains this problem in more details 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 Socket ;
use Socket6 ;
my (@words, $word, $binary_address) ;
## go through the file one line at a time
while (my $line = <STDIN>) {
@words = split /[ \n]/, $line ;
foreach $word (@words) {
$binary_address = inet_pton AF_INET6, $word ;
if ($binary_address) {
print inet_ntop AF_INET6, $binary_address ;
} else {
print $word ;
}
print " " ;
}
print "\n" ;
}
IPfix [RFC5102] defines some data elements that are useful for security:
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.
RFC 4293 [RFC4293] defines a Management Information Base (MIB) for the two address families of IP. This memo recommends the use of:
The neighbor cache of routers contains all mappings between IPv4 addresses and data-link layer addresses. It is usually available by two means:
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 not trivial on a switch using the SAVI [I-D.ietf-savi-framework] algorithm to defeat the mapping between data-link layer address and IPv6 address.
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 world 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).
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. 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.
There are other data sources that must be kept exactly as in the IPv4 network:
This section leverages the data collected as described before [data_sources] in order to achieve several security benefits.
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:
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.
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.
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...
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.
Abnormal behaviors (such as network scanning, spamming, denial of service) can be detected in the same way as in an IPv4 network
While some data sources (IPfix, MIB, switch CAM tables, logs, ...) 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.
Some text
Dual stack has established itself as the preferred deployment choice for most network operators. 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.
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:
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
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]);
To mitigate the bypassing of security policies, it could be helpful to block all default configuration tunnels by denying all IPv4 traffic matching:
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.
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.
ISATAP tunnels [RFC5214] are mainly using 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 [I-D.templin-v6ops-isops].
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.
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).
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]
They suffer from several technical issues as well as security issues [RFC3964]. Their use is no more recommended (see [I-D.ietf-v6ops-6to4-to-historic]).
While 6rd tunnels share the same encapsulation as 6to4 tunnels [sixtofour], 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.
IPsec [RFC4301] for the transported IPv6 traffic can be used if confidentiality is important.
DS-lite is more a translation mechanism and is therefore analyzed further [dslite] in this document.
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 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 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.
Some text
Some text
Some text
Some text
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.
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.
Security considerations in the enterprise can be broadly categorized into two sections - External and Internal.
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:
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.
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.
tbd
tbd
tbd: will need to reference the security considerations of relevant RFC.
tbd.
tbd. refer to 6rd section [sixrd]
tbd.
tbd.
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 networks have usually little clue 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:
[RFC6204] states that a clear choice must be given to the user to select one of those two policies.
This memo includes no request to IANA.
This memo attempts to give an overview of security considerations of operating an IPv6 network both in an IPv6-only network but also in a dual-stack environment.
| [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. |
| [RFC6105] | Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C. and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011. |