< draft-ietf-opsec-v6-21.txt.orig   draft-ietf-opsec-v6-21.txt >
skipping to change at page 1, line 25 skipping to change at page 1, line 25
Abstract Abstract
Knowledge and experience on how to operate IPv4 securely is Knowledge and experience on how to operate IPv4 securely is
available: whether it is the Internet or an enterprise internal available: whether it is the Internet or an enterprise internal
network. However, IPv6 presents some new security challenges. RFC network. However, IPv6 presents some new security challenges. RFC
4942 describes the security issues in the protocol but network 4942 describes the security issues in the protocol but network
managers also need a more practical, operations-minded document to managers also need a more practical, operations-minded document to
enumerate advantages and/or disadvantages of certain choices. enumerate advantages and/or disadvantages of certain choices.
This document analyzes the operational security issues in several This document analyzes the operational security issues associated with
places of a network (enterprises, service providers and residential several type of networks (enterprises, service providers, and residential
users) and proposes technical and procedural mitigations techniques. users) and proposes technical and procedural mitigation techniques.
Some very specific places of a network such as the Internet of Things Some very specific types of networks, such as, Internet of Things (IoT)
are not discussed in this document. networks are not discussed in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 39 10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
Running an IPv6 network is new for most operators not only because 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 they are not yet used to large-scale IPv6 networks but also because
there are subtle differences between IPv4 and IPv6 especially with there are subtle differences between IPv4 and IPv6, especially with
respect to security. For example, all layer-2 interactions are now respect to security. For example, all layer-2 interactions are now
done using Neighbor Discovery Protocol [RFC4861] rather than using done using Neighbor Discovery Protocol [RFC4861] rather than using
Address Resolution Protocol [RFC0826]. Address Resolution Protocol [RFC0826].
IPv6 networks are deployed using a variety of techniques, each of IPv6 networks are deployed using a variety of techniques, each of
which have their own specific security concerns. which have their own specific security concerns.
This document complements [RFC4942] by listing all security issues This document complements [RFC4942] by listing all security issues
when operating a network utilizing varying transition technologies when operating a network utilizing varying transition technologies
and updating it with that have been standardized since 2007. It also and updating it with that have been standardized since 2007. It also
skipping to change at page 4, line 21 skipping to change at page 4, line 21
capitals, as shown here. capitals, as shown here.
2. Generic Security Considerations 2. Generic Security Considerations
2.1. Addressing Architecture 2.1. Addressing Architecture
IPv6 address allocations and overall architecture are an important IPv6 address allocations and overall architecture are an important
part of securing IPv6. Initial designs, even if intended to be part of securing IPv6. Initial designs, even if intended to be
temporary, tend to last much longer than expected. Although temporary, tend to last much longer than expected. Although
initially IPv6 was thought to make renumbering easy, in practice it initially IPv6 was thought to make renumbering easy, in practice it
may be extremely difficult to renumber without a proper IP Addresses may be extremely difficult to renumber without a proper IP Address
Management (IPAM) system. Management (IPAM) system.
A key task for a successful IPv6 deployment is to prepare an A key task for a successful IPv6 deployment is to prepare an
addressing plan. Because an abundance of address space available, addressing plan. Because of an abundance of available address space,
structuring an address plan around both services and geographic structuring an address plan around both services and geographic
locations allow address space to become a basis for more structured locations allows address space to become a basis for more structured
security policies to permit or deny services between geographic security policies to permit or deny services between geographic
regions. regions.
A common question is whether companies should use Provider A common question is whether companies should use Provider
Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from
a security perspective there is little difference. However, one a security perspective there is little difference. However, one
aspect to keep in mind is who has administrative ownership of the aspect to keep in mind is who has administrative ownership of the
address space and who is technically responsible if/when there is a address space and who is technically responsible if/when there is a
need to enforce restrictions on routability of the space e.g. due to need to enforce restrictions on routability of the space, e.g., due to
malicious criminal activity originating from it. malicious criminal activity originating from it.
In [RFC7934], it is recommended that IPv6 network deployments provide In [RFC7934], it is recommended that IPv6 network deployments provide
multiple IPv6 addresses from each prefix to general-purpose hosts and multiple IPv6 addresses from each prefix to general-purpose hosts and
it specifically does not recommend limiting a host to only one IPv6 it specifically does not recommend limiting a host to only one IPv6
address per prefix. It also recommends that the network give the address per prefix. It also recommends that the network give the
host the ability to use new addresses without requiring explicit host the ability to use new addresses without requiring explicit
requests (for example by using SLAAC). Having multiple IPv6 requests (for example by using SLAAC). Having multiple IPv6
addresses per interface is a major change compared to the unique IPv4 addresses per interface is a major change compared to the unique IPv4
address per interface; especially for audits (see section address per interface; especially for audits (see section
Section 2.6.2.3). Section 2.6.2.3).
2.1.1. Use of ULAs 2.1.1. Use of ULAs
Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
where interfaces are not globally reachable, despite being routed where interfaces are not globally reachable, despite being routed
within a domain. They formally have global scope, but [RFC4193] within a domain. They formally have global scope, but [RFC4193]
specifies that they must be filtered out at domain boundaries. ULAs specifies that they must be filtered at domain boundaries. ULAs
are different from [RFC1918] addresses and have different use cases. are different from [RFC1918] addresses and have different use cases.
One use of ULA is described in [RFC4864]. One use of ULA is described in [RFC4864].
2.1.2. Point-to-Point Links 2.1.2. Point-to-Point Links
[RFC6164] in section 5.1 specifies the rationale of using /127 for [RFC6164] in section 5.1 specifies the rationale of using /127 for
inter-router point-to-point links; a /127 prevents the ping-pong inter-router point-to-point links; a /127 prevents the ping-pong
attack between routers not implementing correctly [RFC4443] and also attack between routers not correctly implementing [RFC4443] and also
prevents a DoS attack on the neighbor cache. The previous prevents a DoS attack on the neighbor cache. The previous
recommendation of [RFC3627] has been obsoleted and marked Historic by recommendation of [RFC3627] has been obsoleted and marked Historic by
[RFC6547]). [RFC6547].
Some environments are also using link-local addressing for point-to- Some environments are also using link-local addressing for point-to-
point links. While this practice could further reduce the attack point links. While this practice could further reduce the attack
surface against infrastructure devices, the operational disadvantages surface of infrastructure devices, the operational disadvantages
need also to be carefully considered; see also [RFC7404]. also need to be carefully considered; see also [RFC7404].
2.1.3. Loopback Addresses 2.1.3. Loopback Addresses
Many operators reserve a /64 block for all loopback addresses in Many operators reserve a /64 block for all loopback addresses in
their infrastructure and allocate a /128 out of this reserved /64 their infrastructure and allocate a /128 out of this reserved /64
prefix for each loopback interface. This practice allows for an easy prefix for each loopback interface. This practice facilitates
to write Access Control List (ACL) to enforce a security policy about configuration of Access Control List (ACL) rules to enforce a security
those loopback addresses. policy for those loopback addresses.
2.1.4. Statically Configured Addresses 2.1.4. Statically Configured Addresses
When considering how to assign statically configured addresses, it is When considering how to assign statically configured addresses, it is
necessary to take into consideration the effectiveness of perimeter necessary to take into consideration the effectiveness of perimeter
security in a given environment. There is a trade-off between ease security in a given environment. There is a trade-off between ease
of operation (where some portions of the IPv6 address could be easily of operation (where some portions of the IPv6 address could be easily
recognizable for operational debugging and troubleshooting) versus recognizable for operational debugging and troubleshooting) versus
the risk of trivial scanning used for reconnaissance. [SCANNING] the risk of trivial scanning used for reconnaissance. [SCANNING]
shows that there are scientifically based mechanisms that make shows that there are scientifically based mechanisms that make
scanning for IPv6 reachable nodes more feasible than expected; see scanning for IPv6 reachable nodes more feasible than expected; see
also [RFC7707]. The use of well-known IPv6 addresses (such as also [RFC7707]. The use of well-known IPv6 addresses (such as
ff02::1 for all link-local nodes) or the use of commonly repeated ff02::1 for all link-local nodes) or the use of commonly repeated
addresses could make it easy to figure out which devices are name addresses could make it easy to figure out which devices are name
servers, routers or other critical devices; even a simple traceroute servers, routers, or other critical devices; even a simple traceroute
will expose most of the routers on a path. There are many scanning will expose most of the routers on a path. There are many scanning
techniques possible and operators should not rely on the 'impossible techniques possible and operators should not rely on the 'impossible
to find because my address is random' paradigm, even if it is common to find because my address is random' paradigm, even if it is common
practice to have the statically configured addresses randomly practice to have the statically configured addresses randomly
distributed across /64 subnets and to always use DNS. distributed across /64 subnets and to always use DNS.
While in some environments obfuscating addresses could be considered While in some environments obfuscating addresses could be considered
an added benefit, it does not preclude that perimeter rules are an added benefit, it does not preclude enforcement of perimeter rules
actively enforced and that statically configured addresses follow and that statically configured addresses follow
some logical allocation scheme for ease of operation (as simplicity some logical allocation scheme for ease of operation (as simplicity
always helps security). Typical deployments will have a mix of always helps security). Typical deployments will have a mix of
static and non-static addresses. static and non-static addresses.
2.1.5. Temporary Addresses - Privacy Extensions for SLAAC 2.1.5. Temporary Addresses - Privacy Extensions for SLAAC
Historically stateless address autoconfiguration (SLAAC) relied on an Historically, stateless address autoconfiguration (SLAAC) relied on an
automatically generated 64-bit interface identifier (IID) based on automatically generated 64-bit interface identifier (IID) based on
the EUI-64 MAC address, which together with the /64 prefix makes up the EUI-64 MAC address, which together with the /64 prefix makes up
the globally unique IPv6 address. The EUI-64 address is generated the globally unique IPv6 address. The EUI-64 address is generated
from the 48-bit stable MAC address. [RFC8064] recommends against the from a stable 48-bit MAC address. [RFC8064] recommends against the
use of EUI-64 addresses and it must be noted that most host operating use of EUI-64 addresses and it must be noted that most host operating
systems do not use EUI-64 addresses anymore and rely on either systems do not use EUI-64 addresses anymore and rely on either
[RFC4941] or [RFC8064]. [RFC4941] or [RFC8064].
Randomly generating an interface ID, as described in [RFC4941], is Randomly generating an interface ID, as described in [RFC4941], is
part of SLAAC with so-called privacy extension addresses and is used part of SLAAC with so-called privacy extension addresses and is used
to address some privacy concerns. Privacy extension addresses a.k.a. to address some privacy concerns. Privacy extension addresses, a.k.a.,
temporary addresses may help to mitigate the correlation of temporary addresses may help to mitigate the correlation of
activities of a node within the same network, and may also reduce the activities of a node within the same network, and may also reduce the
attack exposure window. attack exposure window.
Using [RFC4941] privacy extension addresses might prevent the Using [RFC4941] privacy extension addresses might prevent the
operator from building host specific access control lists (ACLs). operator from building host specific access control lists (ACLs).
The [RFC4941] privacy extension addresses could also be used to The [RFC4941] privacy extension addresses could also be used to
obfuscate some malevolent activities and specific user attribution/ obfuscate some malevolent activities and specific user attribution/
accountability procedures should be put in place as described in accountability procedures should be put in place as described in
Section 2.6. Section 2.6.
[RFC8064] specifies another way to generate an address while still [RFC8064] specifies another way to generate an address while still
keeping the same IID for each network prefix; this allows SLAAC nodes keeping the same IID for each network prefix; this allows SLAAC nodes
to always have the same stable IPv6 address on a specific network to always have the same stable IPv6 address on a specific network
while having different IPv6 address on different networks. while having different IPv6 addresses on different networks.
In some specific use cases where user accountability is more In some specific use cases where user accountability is more
important than user privacy, network operators may consider disabling important than user privacy, network operators may consider disabling
SLAAC and relying only on DHCPv6; but, not all operating systems SLAAC and relying only on DHCPv6; but, not all operating systems
support DHCPv6 so some hosts will not get any IPv6 connectivity. support DHCPv6 so some hosts will not get any IPv6 connectivity.
Disabling SLAAC and privacy extensions addresses can be done for most Disabling SLAAC and privacy extension addresses can be done for most
operating systems by sending RA messages with a hint to get addresses operating systems by sending RA messages with a hint to get addresses
via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting
all A-bits in all prefix information options. However, attackers all A-bits in all prefix information options. However, attackers
could still find ways to bypass this mechanism if not enforced at the could still find ways to bypass this mechanism if not enforced at the
switch/ router level. switch/router level.
However, in scenarios where anonymity is a strong desire (protecting However, in scenarios where anonymity is a strong desire (protecting
user privacy is more important than user attribution), privacy user privacy is more important than user attribution), privacy
extension addresses should be used. When [RFC8064] is available, the extension addresses should be used. When [RFC8064] is available, the
stable privacy address is probably a good balance between privacy stable privacy address is probably a good balance between privacy
(among different networks) and security/user attribution (within a (among different networks) and security/user attribution (within a
network). network).
2.1.6. DHCP/DNS Considerations 2.1.6. DHCP/DNS Considerations
Many environments use DHCPv6 to provision addresses and other Many environments use DHCPv6 to provision addresses and other
parameters in order to ensure audit-ability and traceability (see parameters in order to ensure audit-ability and traceability (see
Section 2.6.1.5). A main security concern is the ability to detect Section 2.6.1.5). A main security concern is the ability to detect
and counteract against rogue DHCP servers (Section 2.3.3). It must and counteract rogue DHCP servers (Section 2.3.3). It must
be noted that as opposed to DHCPv4, DHCPv6 can lease several IPv6 be noted that as opposed to DHCPv4, DHCPv6 can lease several IPv6
addresses per client and the lease is not bound to the link-layer addresses per client and the lease is not bound to the link-layer
address of the client but to the DHCP Unique ID (DUID) of the client address of the client but to the client's DHCP Unique ID (DUID) which
that is not always bound to the client link-layer address. is not always bound to the client link-layer address.
While there are no fundamental differences with IPv4 and IPv6 While there are no fundamental differences with IPv4 and IPv6
security concerns about DNS, there are specific consideration in DNS security concerns, there are specific considerations in
DNS64 [RFC6147] environments that need to be understood. DNS64 [RFC6147] environments that need to be understood.
Specifically, the interactions and the potential of interference with Specifically, the interactions and the potential of interference with
DNSSEC implementation need to be understood - these are pointed out DNSSEC implementation need to be understood - these are pointed out
in more detail in Section 2.7.3.2. in more detail in Section 2.7.3.2.
2.1.7. Using a /64 per host 2.1.7. Using a /64 per host
An interesting approach is using a /64 per host as proposed in An interesting approach is using a /64 per host as proposed in
[RFC8273]. This allows for easier user attribution (typically based [RFC8273]. This allows for easier user attribution (typically based
on the host MAC address) as its /64 prefix is stable even if on the host MAC address) as its /64 prefix is stable even if
applications within the host can change their IPv6 address within applications within the host can change their IPv6 address within
this /64. this /64 prefix.
2.1.8. Privacy consideration of Addresses 2.1.8. Privacy consideration of Addresses
Beside the security aspects of IPv6 addresses, there are also privacy Beside the security aspects of IPv6 addresses, there are also privacy
considerations: mainly because they are of global scope and visible considerations: mainly because they are of global scope and visible
globally. [RFC7721] goes in more details about the privacy globally. [RFC7721] goes into more detail on the privacy
considerations of IPv6 addresses by comparing the manually considerations for IPv6 addresses by comparing the manually
configured, DHCPv6 or SLAAC. configured IPv6 addresses, DHCPv6 or SLAAC.
2.2. Extension Headers 2.2. Extension Headers
The extension headers are an important difference between IPv4 and Extension headers are an important difference between IPv4 and
IPv6. In IPv4-based packets, it's trivial to find the upper layer IPv6. In IPv4-based packets, it's trivial to find the upper layer
protocol type and protocol header, while in IPv6 it is more complex protocol type and protocol header, while in IPv6 it is more complex
since the extension header chain must be parsed completely. The IANA since the extension header chain must be parsed completely. IANA
has closed the existing empty "Next Header Types" registry to new has closed the existing empty "Next Header Types" registry to new
entries and is redirecting its users to a new "IPv6 Extension Header entries and is redirecting its users to a new "IPv6 Extension Header
Types" registry per [RFC7045]. Types" registry per [RFC7045].
They have also become a very controversial topic since forwarding Extensions headers have also become a very controversial topic since forwarding
nodes that discard packets containing extension headers are known to nodes that discard packets containing extension headers are known to
cause connectivity failures and deployment problems [RFC7872]. cause connectivity failures and deployment problems [RFC7872].
Understanding the role of varying extension headers is important and Understanding the role of varying extension headers is important and
this section enumerates the ones that need careful consideration. this section enumerates the ones that need careful consideration.
A clarification on how intermediate nodes should handle packets with A clarification on how intermediate nodes should handle packets with
existing or future extension headers is found in [RFC7045]. The existing or future extension headers is found in [RFC7045]. The
uniform TLV format to be used for defining future extension headers uniform TLV format to be used for defining future extension headers
is described in [RFC6564]. is described in [RFC6564].
It must also be noted that there is no indication in the packet It must also be noted that there is no indication in IPv6 packets as to
whether the Next Protocol field points to an extension header or to a whether the Next Protocol field points to an extension header or to a
transport header. This may confuse some filtering rules. transport header. This may confuse some filtering rules.
There is work in progress at the IETF about filtering rules for those There is IETF work in progress regarding filtering rules for those
extension headers: [I-D.ietf-opsec-ipv6-eh-filtering] for transit extension headers: [I-D.ietf-opsec-ipv6-eh-filtering] for transit
routers. routers.
2.2.1. Order and Repetition of Extension Headers 2.2.1. Order and Repetition of Extension Headers
While [RFC8200] recommends the order and the maximum repetition of While [RFC8200] recommends the order and the maximum repetition of
extension headers, there are still IPv6 implementations at the time extension headers, there are still IPv6 implementations, at the time
of writing this document which support a non-recommended order of of writing, which support a non-recommended order of
headers (such as ESP before routing) or an illegal repetition of headers (such as ESP before routing) or an illegal repetition of
headers (such as multiple routing headers). The same applies for headers (such as multiple routing headers). The same applies for
options contained in the extension headers (see options contained in the extension headers (see
[I-D.kampanakis-6man-ipv6-eh-parsing]). In some cases, it has led to [I-D.kampanakis-6man-ipv6-eh-parsing]). In some cases, it has led to
nodes crashing when receiving or forwarding wrongly formatted nodes crashing when receiving or forwarding wrongly formatted
packets. packets.
A firewall or edge device should be used to enforce the recommended A firewall or edge device should be used to enforce the recommended
order and number of occurrences of extension headers. order and the maximum occurrences of extension headers.
2.2.2. Hop-by-Hop Options Header 2.2.2. Hop-by-Hop Options Header
The hop-by-hop options header, when present in an IPv6 packet, forces In the original IPv6 specification [RFC2460], the hop-by-hop options
all nodes in the path to inspect this header in the original IPv6 header, when present in an IPv6 packet, forced all nodes in the path
specification [RFC2460]. This enables denial of service attacks as to inspect this header. This enabled denial of service attacks as
most, if not all, routers cannot process this kind of packets in most, if not all, routers cannot process this kind of packet in
hardware but have to 'punt' this packet for software processing. hardware but have to 'punt' this packet for software processing.
Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has
taken this attack vector into account and made the processing of hop- taken this attack vector into account and made the processing of hop-
by-hop options header by intermediate routers optional. by-hop options header by intermediate routers optional.
2.2.3. Fragment Header 2.2.3. Fragment Header
The fragment header is used by the source (and only the source) when The fragment header is used by the source (and only the source) when
it has to fragment packets. [RFC7112] and section 4.5 of [RFC8200] it has to fragment packets. [RFC7112] and section 4.5 of [RFC8200]
explain why it is important that: explain why it is important that:
firewall and security devices should drop first fragments that do Firewall and security devices should drop first fragments that do
not contain the entire ipv6 header chain (including the transport- not contain the entire ipv6 header chain (including the transport-
layer header); layer header);
destination nodes should discard first fragments that do not Destination nodes should discard first fragments that do not
contain the entire ipv6 header chain (including the transport- contain the entire ipv6 header chain (including the transport-
layer header). layer header).
If those requirements are not met, stateless filtering could be If those requirements are not met, stateless filtering could be
bypassed by a hostile party. [RFC6980] applies a stricter rule to bypassed by a hostile party. [RFC6980] applies a stricter rule to
NDP by enforcing the drop of fragmented NDP packets. [RFC7113] NDP by enforcing the drop of fragmented NDP packets. [RFC7113]
describes how RA-guard function described in [RFC6105] should behave describes how the RA-guard function described in [RFC6105] should behave
in presence of fragmented RA packets. in the presence of fragmented RA packets.
2.2.4. IP Security Extension Header 2.2.4. IP Security Extension Header
The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP
[RFC4303]) are required if IPsec is to be utilized for network level [RFC4303]) are required if IPsec is to be utilized for network level
security functionality. security.
2.3. Link-Layer Security 2.3. Link-Layer Security
IPv6 relies heavily on the Neighbor Discovery protocol (NDP) IPv6 relies heavily on the Neighbor Discovery protocol (NDP)
[RFC4861] to perform a variety of link operations such as discovering [RFC4861] to perform a variety of link operations such as discovering
other nodes on the link, resolving their link-layer addresses, and other nodes on the link, resolving their link-layer addresses, and
finding routers on the link. If not secured, NDP is vulnerable to finding routers on the link. If not secured, NDP is vulnerable to
various attacks such as router/neighbor message spoofing, redirect various attacks such as router/neighbor message spoofing, redirect
attacks, Duplicate Address Detection (DAD) DoS attacks, etc. Many of attacks, Duplicate Address Detection (DAD) DoS attacks, etc. Many of
these security threats to NDP have been documented in IPv6 ND Trust these security threats to NDP have been documented in IPv6 ND Trust
skipping to change at page 11, line 21 skipping to change at page 11, line 21
designed around switching devices that are capable of identifying designed around switching devices that are capable of identifying
invalid RAs and blocking them before the attack packets actually invalid RAs and blocking them before the attack packets actually
reach the target nodes. reach the target nodes.
However, several evasion techniques that circumvent the protection However, several evasion techniques that circumvent the protection
provided by RA-Guard have surfaced. A key challenge to this provided by RA-Guard have surfaced. A key challenge to this
mitigation technique is introduced by IPv6 fragmentation. An mitigation technique is introduced by IPv6 fragmentation. An
attacker can conceal the attack by fragmenting his packets into attacker can conceal the attack by fragmenting his packets into
multiple fragments such that the switching device that is responsible multiple fragments such that the switching device that is responsible
for blocking invalid RAs cannot find all the necessary information to for blocking invalid RAs cannot find all the necessary information to
perform packet filtering in the same packet. [RFC7113] describes perform packet filtering of the same packet. [RFC7113] describes
such evasion techniques, and provides advice to RA-Guard implementers such evasion techniques, and provides advice to RA-Guard implementers
such that the aforementioned evasion vectors can be eliminated. such that the aforementioned evasion vectors can be eliminated.
Given that the IPv6 Fragmentation Header can be leveraged to Given that the IPv6 Fragmentation Header can be leveraged to
circumvent current implementations of RA-Guard, [RFC6980] updates circumvent current implementations of RA-Guard, [RFC6980] updates
[RFC4861] such that use of the IPv6 Fragmentation Header is forbidden [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden
in all Neighbor Discovery messages except "Certification Path in all Neighbor Discovery messages except "Certification Path
Advertisement", thus allowing for simple and effective measures to Advertisement", thus allowing for simple and effective measures to
counter Neighbor Discovery attacks. counter Neighbor Discovery attacks.
The Source Address Validation Improvements (SAVI) working group has The Source Address Validation Improvements (SAVI) working group has
worked on other ways to mitigate the effects of such attacks. worked on other ways to mitigate the effects of such attacks.
[RFC7513] helps in creating bindings between a DHCPv4 [RFC2131] [RFC7513] helps in creating bindings between a DHCPv4 [RFC2131]
/DHCPv6 [RFC8415] assigned source IP address and a binding anchor /DHCPv6 [RFC8415] assigned source IP address and a binding anchor
[RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean
similar bindings when DHCP is not used. The bindings can be used to similar bindings when DHCP is not used. The bindings can be used to
filter packets generated on the local link with forged source IP filter packets generated on the local link with forged source IP
address. addresses.
It is still recommended that RA-Guard and SAVI be employed as a first It is still recommended that RA-Guard and SAVI be employed as a first
line of defense against common attack vectors including misconfigured line of defense against common attack vectors including misconfigured
hosts. This line of defense is most effective when incomplete hosts. This line of defense is most effective when incomplete
fragments are dropped by routers and switches as described in fragments are dropped by routers and switches as described in
Section 2.2.3. The generated log should also be analyzed to act on Section 2.2.3. The generated log should also be analyzed to identify
violations. and act on violations.
A drastic technique to prevent all NDP attacks is based on isolation A drastic technique to prevent all NDP attacks is based on isolation
of all hosts with specific configurations. Hosts (i.e. all nodes of all hosts with specific configurations. Hosts (i.e., all nodes
that are not routers) are unable to send data-link layer frames to that are not routers) are unable to send data-link layer frames to
other hosts, therefore, no host to host attacks can happen. This other hosts, therefore, no host-to-host attacks can happen. This
specific set-up can be established on some switches or wireless specific setup can be established on some switches or wireless
access points. Of course, this is not always easily feasible when access points. Of course, this is not always feasible when
hosts need to communicate with other hosts. hosts need to communicate with other hosts.
2.3.3. Securing DHCP 2.3.3. Securing DHCP
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described in
[RFC8415], enables DHCP servers to pass configuration parameters such [RFC8415], enables DHCP servers to pass configuration parameters such
as IPv6 network addresses and other configuration information to IPv6 as IPv6 network addresses and other configuration information to IPv6
nodes. DHCP plays an important role in most large networks by nodes. DHCP plays an important role in most large networks by
providing robust stateful configuration and in the context of providing robust stateful configuration in the context of
automated system provisioning. automated system provisioning.
The two most common threats to DHCP clients come from malicious The two most common threats to DHCP clients come from malicious
(a.k.a. rogue) or unintentionally misconfigured DHCP servers. A (a.k.a., rogue) or unintentionally misconfigured DHCP servers. A
malicious DHCP server is established with the intent of providing malicious DHCP server is established with the intent of providing
incorrect configuration information to the client to cause a denial incorrect configuration information to the clients to cause a denial
of service attack or to mount a-man-in-the-middle attack. While of service attack or to mount a-man-in-the-middle attack. While
unintentional, a misconfigured DHCP server can have the same impact. unintentional, a misconfigured DHCP server can have the same impact.
Additional threats against DHCP are discussed in the security Additional threats against DHCP are discussed in the security
considerations section of [RFC8415]. considerations section of [RFC8415].
[RFC7610], DHCPv6-Shield, specifies a mechanism for protecting [RFC7610], DHCPv6-Shield, specifies a mechanism for protecting
connected DHCPv6 clients against rogue DHCPv6 servers. This connected DHCPv6 clients against rogue DHCPv6 servers. This
mechanism is based on DHCPv6 packet-filtering at the layer-2 device; mechanism is based on DHCPv6 packet-filtering at the layer-2 device;
the administrator specifies the interfaces connected to DHCPv6 i.e.,the administrator specifies the interfaces connected to DHCPv6
servers. Furthermore, extension headers could be leveraged to bypass servers. However, extension headers could be leveraged to bypass
DHCPv6-Shield unless [RFC7112] is enforced. DHCPv6-Shield unless [RFC7112] is enforced.
It is recommended to use DHCPv6-Shield and to analyze the It is recommended to use DHCPv6-Shield and to analyze the
corresponding log messages. corresponding log messages.
2.3.4. 3GPP Link-Layer Security 2.3.4. 3GPP Link-Layer Security
The 3GPP link is a point-to-point like link that has no link-layer 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 (the mobile address. This implies there can only be an end host (the mobile
hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node
(GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never
configures a non link-local address on the link using the advertised configures a non link-local address on the link using the advertised
/64 prefix on it. The advertised prefix must not be used for on-link /64 prefix on it. The advertised prefix must not be used for on-link
determination. There is no need for an address resolution on the determination. There is no need for address resolution on the
3GPP link, since there are no link-layer addresses. Furthermore, 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 GGSN/PGW assigns a prefix that is unique within each 3GPP link that
uses IPv6 stateless address autoconfiguration. This avoids the uses IPv6 stateless address autoconfiguration. This avoids the
necessity to perform DAD at the network level for every address built necessity to perform DAD at the network level for every address built
by the mobile host. The GGSN/PGW always provides an IID to the by the mobile host. The GGSN/PGW always provides an IID to the
cellular host for the purpose of configuring the link-local address cellular host for the purpose of configuring the link-local address
and ensures the uniqueness of the IID on the link (i.e., no and ensures the uniqueness of the IID on the link (i.e., no
collisions between its own link-local address and the mobile host's collisions between its own link-local address and the mobile host's
one). address).
The 3GPP link model itself mitigates most of the known NDP-related The 3GPP link model itself mitigates most of the known NDP-related
Denial-of-Service attacks. In practice, the GGSN/PGW only needs to Denial-of-Service attacks. In practice, the GGSN/PGW only needs to
route all traffic to the mobile host that falls under the prefix route all traffic to the mobile host that falls under the prefix
assigned to it. As there is also a single host on the 3GPP link, assigned to it. As there is also a single host on the 3GPP link,
there is no need to defend that IPv6 address. there is no need to defend that IPv6 address.
See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP
link model, NDP on it and the address configuration details. In some link model, NDP on it and the address configuration details. In some
mobile network, DHCPv6 and DHCP-PD are also used. mobile network, DHCPv6 and DHCP-PD are also used.
2.3.5. SeND and CGA 2.3.5. SeND and CGA
SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a SEcure Neighbor Discovery (SEND), as described in [RFC3971], is a
mechanism that was designed to secure ND messages. This approach mechanism that was designed to secure ND messages. This approach
involves the use of new NDP options to carry public key based involves the use of new NDP options to carry public key based
signatures. Cryptographically Generated Addresses (CGA), as signatures. Cryptographically Generated Addresses (CGA), as
described in [RFC3972], are used to ensure that the sender of a described in [RFC3972], are used to ensure that the sender of a
Neighbor Discovery message is the actual "owner" of the claimed IPv6 Neighbor Discovery message is the actual "owner" of the claimed IPv6
address. A new NDP option, the CGA option, was introduced and is address. A new NDP option, the CGA option, was introduced and is
used to carry the public key and associated parameters. Another NDP used to carry the public key and associated parameters. Another NDP
option, the RSA Signature option, is used to protect all messages option, the RSA Signature option, is used to protect all messages
relating to neighbor and Router discovery. relating to neighbor and router discovery.
SeND protects against: SeND protects against:
o Neighbor Solicitation/Advertisement Spoofing o Neighbor Solicitation/Advertisement Spoofing
o Neighbor Unreachability Detection Failure o Neighbor Unreachability Detection Failure
o Duplicate Address Detection DoS Attack o Duplicate Address Detection DoS Attack
o Router Solicitation and Advertisement Attacks o Router Solicitation and Advertisement Attacks
o Replay Attacks o Replay Attacks
o Neighbor Discovery DoS Attacks o Neighbor Discovery DoS Attacks
SeND does NOT: SeND does NOT:
o Protect statically configured addresses o Protect statically configured addresses
o Protect addresses configured using fixed identifiers (i.e. EUI- o Protect addresses configured using fixed identifiers (i.e., EUI-
64) 64)
o Provide confidentiality for NDP communications o Provide confidentiality for NDP communications
o Compensate for an unsecured link - SEND does not require that the o Compensate for an unsecured link - SEND does not require that the
addresses on the link and Neighbor Advertisements correspond addresses on the link and Neighbor Advertisements correspond.
However, at this time and over a decade since their original However, at this time and over a decade since their original
specifications, CGA and SeND do not have wide support from generic specifications, CGA and SEND do not have wide support from generic
operating systems; hence, their usefulness is limited and should not operating systems; hence, their usefulness is limited and should not
be relied upon. be relied upon.
2.4. Control Plane Security 2.4. Control Plane Security
[RFC6192] defines the router control plane. This definition is [RFC6192] defines the router control plane. This definition is
repeated here for the reader's convenience. Please note that the repeated here for the reader's convenience. Please note that the
definition is completely protocol-version agnostic (most of this definition is completely protocol-version agnostic (most of this
section applies to IPv6 in the same way as to IPv4). section applies to IPv6 in the same way as to IPv4).
Modern router architecture design maintains a strict separation of Modern router architecture design maintains a strict separation of
forwarding and router control plane hardware and software. The forwarding and router control plane hardware and software. The
router control plane supports routing and management functions. It router control plane supports routing and management functions. It
is generally described as the router architecture hardware and is generally described as the router architecture hardware and
software components for handling packets destined to the device software components for handling packets destined to the device
itself as well as building and sending packets originated locally on itself, as well as, building and sending packets originated locally on
the device. The forwarding plane is typically described as the the device. The forwarding plane is typically described as the
router architecture hardware and software components responsible for router architecture hardware and software components responsible for
receiving a packet on an incoming interface, performing a lookup to receiving a packet on an incoming interface, performing a lookup to
identify the packet's IP next hop and determine the best outgoing identify the packet's IP next hop and best outgoing
interface towards the destination, and forwarding the packet out interface towards the destination, and forwarding the packet
through the appropriate outgoing interface. through the appropriate outgoing interface.
While the forwarding plane is usually implemented in high-speed While the forwarding plane is usually implemented in high-speed
hardware, the control plane is implemented by a generic processor hardware, the control plane is implemented by a generic processor
(named router processor RP) and cannot process packets at a high (referred to as thed route processor (RP)) and cannot process packets at a high
rate. Hence, this processor can be attacked by flooding its input rate. Hence, this processor can be attacked by flooding its input
queue with more packets than it can process. The control plane queue with more packets than it can process. The control plane
processor is then unable to process valid control packets and the processor is then unable to process valid control packets and the
router can lose OSPF or BGP adjacencies which can cause a severe router can lose OSPF or BGP adjacencies which can cause a severe
network disruption. network disruption.
The mitigation techniques are: The mitigation techniques are:
o To drop non-legit control packet before they are queued to the RP o To drop non-legit control packet before they are queued to the RP
(this can be done by a forwarding plane ACL) and (this can be done by a forwarding plane ACL) and
o To rate limit the remaining packets to a rate that the RP can o To rate limit the remaining packets to a rate that the RP can
sustain. Protocol specific protection should also be done (for sustain. Protocol specific protection should also be done (for
example, a spoofed OSPFv3 packet could trigger the execution of example, a spoofed OSPFv3 packet could trigger the execution of
the Dijkstra algorithm, therefore, the number of Dijsktra the Dijkstra algorithm, therefore, the frequency of Dijsktra
execution should be also rate limited). calculations should be also rate limited).
This section will consider several classes of control packets: This section will consider several classes of control packets:
o Control protocols: routing protocols: such as OSPFv3, BGP and by o Control protocols: routing protocols: such as OSPFv3, BGP, and by
extension Neighbor Discovery and ICMP extension Neighbor Discovery and ICMP
o Management protocols: SSH, SNMP, IPfix, etc o Management protocols: SSH, SNMP, IPFIX, etc
o Packet exceptions: which are normal data packets which requires a o Packet exceptions: Normal data packets which require a
specific processing such as generating a packet-too-big ICMP specific processing such as generating a packet-too-big ICMP
message or having the hop-by-hop options header. message or processing the hop-by-hop options header.
2.4.1. Control Protocols 2.4.1. Control Protocols
This class includes OSPFv3, BGP, NDP, ICMP. This class includes OSPFv3, BGP, NDP, ICMP.
An ingress ACL to be applied on all the router interfaces should be An ingress ACL to be applied on all the router interfaces should be
configured such as: configured such as:
o drop OSPFv3 (identified by Next-Header being 89) and RIPng o drop OSPFv3 (identified by Next-Header being 89) and RIPng
(identified by UDP port 521) packets from a non link-local address (identified by UDP port 521) packets from a non link-local address
o allow BGP (identified by TCP port 179) packets from all BGP o allow BGP (identified by TCP port 179) packets from all BGP
neighbors and drop the others neighbors and drop the others
o allow all ICMP packets (transit and to the router interfaces) o allow all ICMP packets (transit and to the router interfaces)
Note: dropping OSPFv3 packets which are authenticated by IPsec could Note: dropping OSPFv3 packets which are authenticated by IPsec could
be impossible on some routers whose ACL are unable to parse the IPsec be impossible on some routers whose ACL are unable to parse the IPsec
ESP or AH extension headers. ESP or AH extension headers.
Rate limiting of the valid packets should be done. The exact rate limiting of the valid packets should be done. The exact
configuration will depend on the available resources of the router configuration will depend on the available resources of the router
(CPU, TCAM, ...). (CPU, TCAM, ...).
2.4.2. Management Protocols 2.4.2. Management Protocols
This class includes: SSH, SNMP, syslog, NTP, etc. This class includes: SSH, SNMP, syslog, NTP, etc.
An ingress ACL to be applied on all the router interfaces (or at An ingress ACL to be applied on all the router interfaces (or at
ingress interfaces of the security perimeter or by using specific ingress interfaces of the security perimeter or by using specific
features of the platform) should be configured such as: features of the platform) should be configured such as:
o Drop packets destined to the routers except those belonging to o Drop packets destined to the routers except those belonging to
protocols which are used (for example, permit TCP 22 and drop all protocols which are used (for example, permit TCP 22 and drop all
when only SSH is used); when only SSH is used);
o Drop packets where the source does not match the security policy, o Drop packets where the source does not match the security policy,
for example if SSH connections should only be originated from the 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, then the ACL should permit TCP port 22 packets only from the
NOC prefix. NOC prefix.
Rate limiting of the valid packets should be done. The exact rate limiting of the valid packets should be done. The exact
configuration will depend on the available resources of the router. configuration will depend on the available resources of the router.
2.4.3. Packet Exceptions 2.4.3. Packet Exceptions
This class covers multiple cases where a data plane packet is punted This class covers multiple cases where a data plane packet is punted
to the route processor because it requires specific processing: to the route processor because it requires specific processing:
o generation of an ICMP packet-too-big message when a data plane o generation of an ICMP packet-too-big message when a data plane
packet cannot be forwarded because it is too large; packet cannot be forwarded because it is too large;
skipping to change at page 16, line 30 skipping to change at page 16, line 30
0; 0;
o generation of an ICMP destination-unreachable message when a data o generation of an ICMP destination-unreachable message when a data
plane packet cannot be forwarded for any reason; plane packet cannot be forwarded for any reason;
o processing of the hop-by-hop options header, new implementations o processing of the hop-by-hop options header, new implementations
follow section 4.3 of [RFC8200] where this processing is optional; follow section 4.3 of [RFC8200] where this processing is optional;
o or more specific to some router implementation: an oversized o or more specific to some router implementation: an oversized
extension header chain which cannot be processed by the hardware extension header chain which cannot be processed by the hardware
and force the packet to be punted to the generic router CPU. and force the packet to be punted to the RP.
On some routers, not everything can be done by the specialized data On some routers, not everything can be done by the specialized data
plane hardware which requires some packets to be 'punted' to the plane hardware which requires some packets to be 'punted' to the
generic RP. This could include for example the processing of a long 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 extension header chain in order to apply an ACL based on layer-4
information. [RFC6980] and more generally [RFC7112] highlights the information. [RFC6980] and more generally [RFC7112] highlight the
security implications of oversized extension header chains on routers security implications of oversized extension header chains on routers
and updates the original IPv6 specifications, [RFC2460], such that and updates the original IPv6 specifications, [RFC2460], such that
the first fragment of a packet is required to contain the entire IPv6 the first fragment of a packet is required to contain the entire IPv6
header chain. Those changes are incorporated in the IPv6 standard header chain. Those changes are incorporated in the IPv6 standard
[RFC8200] [RFC8200]
An ingress ACL cannot mitigate a control plane attack using these An ingress ACL cannot mitigate a control plane attack using these
packet exceptions. The only protection for the RP is to limit the packet exceptions. The only protection for the RP is to limit the
rate of those packet exceptions forwarded to the RP, this means that rate of those packet exceptions forwarded to the RP, this means that
some data plane packets will be dropped without any ICMP messages some data plane packets will be dropped without an ICMP message
back to the source which may cause Path MTU holes. sent to the source which may delay Path MTU discovery and cause
drops.
In addition to limiting the rate of data plane packets queued to the 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 RP, it is also important to limit the generation rate of ICMP
messages. Both the save the RP and also to prevent an amplification messages. This is important both to preserve RP resources and also
to prevent an amplification
attack using the router as a reflector. It is worth noting that some attack using the router as a reflector. It is worth noting that some
platforms implement this rate-limiting in hardware. Of course, a platforms implement this rate limiting in hardware. Of course, a
consequence of not generating an ICMP message will break some IPv6 consequence of not generating an ICMP message will break some IPv6
mechanisms such as Path MTU discovery or a simple traceroute. mechanisms such as Path MTU discovery or a simple traceroute.
2.5. Routing Security 2.5. Routing Security
Routing security in general can be broadly divided into three Routing security in general can be broadly divided into three
sections: sections:
1. Authenticating neighbors/peers 1. Authenticating neighbors/peers
skipping to change at page 17, line 30 skipping to change at page 17, line 30
[RFC7454] covers these sections specifically for BGP in detail. [RFC7454] covers these sections specifically for BGP in detail.
[RFC5082] is also applicable to IPv6 and can ensure that routing [RFC5082] is also applicable to IPv6 and can ensure that routing
protocol packets are coming from the local network; it must also be protocol packets are coming from the local network; it must also be
noted that in IPv6 all interior gateway protocols use link-local noted that in IPv6 all interior gateway protocols use link-local
addresses. addresses.
2.5.1. Authenticating Neighbors 2.5.1. Authenticating Neighbors
A basic element of routing is the process of forming adjacencies, A basic element of routing is the process of forming adjacencies,
neighbor, or peering relationships with other routers. From a i.e., neighbor, or peering relationships with other routers. From a
security perspective, it is very important to establish such security perspective, it is very important to establish such
relationships only with routers and/or administrative domains that relationships only with routers and/or administrative domains that
one trusts. A traditional approach has been to use MD5 HMAC, which one trusts. A traditional approach has been to use MD5 HMAC, which
allows routers to authenticate each other prior to establishing a allows routers to authenticate each other prior to establishing a
routing relationship. routing relationship.
OSPFv3 can rely on IPsec to fulfill the authentication function. OSPFv3 can rely on IPsec to fulfill the authentication function.
However, it should be noted that IPsec support is not standard on all However, it should be noted that IPsec support is not standard on all
routing platforms. In some cases, this requires specialized hardware routing platforms. In some cases, this requires specialized hardware
that offloads crypto over to dedicated ASICs or enhanced software that offloads crypto over to dedicated ASICs or enhanced software
images (both of which often come with added financial cost) to images (both of which often come with added financial cost) to
provide such functionality. An added detail is to determine whether provide such functionality. An added detail is to determine whether
OSPFv3 IPsec implementations use AH or ESP-Null for integrity OSPFv3 IPsec implementations use AH or ESP-Null for integrity
protection. In early implementations all OSPFv3 IPsec configurations protection. In early implementations, all OSPFv3 IPsec configurations
relied on AH since the details weren't specified in [RFC5340]. relied on AH since the details weren't specified in [RFC5340].
However, the document which specifically describes how IPsec should However, the document which specifically describes how IPsec should
be implemented for OSPFv3 [RFC4552] specifically states that ESP-Null be implemented for OSPFv3 [RFC4552] specifically states that ESP-Null
MUST and AH MAY be implemented since it follows the overall IPsec MUST and AH MAY be implemented since it follows the overall IPsec
standards wordings. OSPFv3 can also use normal ESP to encrypt the standards wording. OSPFv3 can also use normal ESP to encrypt the
OSPFv3 payload to hide the routing information. OSPFv3 payload to privide confidentiality for the routing information.
[RFC7166] changes OSPFv3 reliance on IPsec by appending an [RFC7166] changes OSPFv3 reliance on IPsec by appending an
authentication trailer to the end of the OSPFv3 packets; it does not authentication trailer to the end of the OSPFv3 packets; it does not
specifically authenticate the specific originator of an OSPFv3 specifically authenticate the specific originator of an OSPFv3
packet; rather, it allows a router to confirm that the packet has packet; rather, it allows a router to confirm that the packet has
been issued by a router that had access to the shared authentication been issued by a router that had access to the shared authentication
key. key.
With all authentication mechanisms, operators should confirm that With all authentication mechanisms, operators should confirm that
implementations can support re-keying mechanisms that do not cause implementations can support re-keying mechanisms that do not cause
skipping to change at page 18, line 38 skipping to change at page 18, line 38
practice however, deploying IPsec is not always feasible given practice however, deploying IPsec is not always feasible given
hardware and software limitations of various platforms deployed, it hardware and software limitations of various platforms deployed, it
has also an operational cost as described in the earlier section. has also an operational cost as described in the earlier section.
2.5.3. Route Filtering 2.5.3. Route Filtering
Route filtering policies will be different depending on whether they Route filtering policies will be different depending on whether they
pertain to edge route filtering vs internal route filtering. At a pertain to edge route filtering vs internal route filtering. At a
minimum, IPv6 routing policy as it pertains to routing between minimum, IPv6 routing policy as it pertains to routing between
different administrative domains should aim to maintain parity with different administrative domains should aim to maintain parity with
IPv4 from a policy perspective e.g., IPv4 from a policy perspective, e.g.,
o Filter internal-use, non-globally routable IPv6 addresses at the o Filter internal-use, non-globally routable IPv6 addresses at the
perimeter; perimeter;
o Discard routes for bogon and reserved space (see [CYMRU] and o Discard routes for bogon and reserved space (see [CYMRU] and
[RFC8190]); [RFC8190]);
o Configure ingress route filters that validate route origin, prefix o Configure ingress route filters that validate route origin, prefix
ownership, etc. through the use of various routing databases, ownership, etc. through the use of various routing databases,
e.g., RADB. There is additional work being done in this area to e.g., RADB. There is additional work being done in this area to
formally validate the origin ASs of BGP announcements in [RFC8210] formally validate the origin ASs of BGP announcements in [RFC8210].
Some good recommendations for filtering can be found from Team CYMRU Some good recommendations for filtering can be found from Team CYMRU
at [CYMRU]. [RFC7454] is another valuable resource of guidance in at [CYMRU]. [RFC7454] is another valuable resource of guidance in
this space. this space.
A valid routing table can also be used apply network ingress A valid routing table can also be used apply network ingress
filtering (see [RFC2827]). filtering (see [RFC2827]).
2.6. Logging/Monitoring 2.6. Logging/Monitoring
In order to perform forensic research in case of a security incident In order to perform forensic research in the cases of security incidents
or to detect abnormal behaviors, network operators should log or detection of abnormal behavior, network operators should log
multiple pieces of information. multiple pieces of information.
This logging should include: This logging should include:
o logs of all applications using the network (including user space o logs of all applications using the network (including user space
and kernel space) when available (for example web servers); and kernel space) when available (for example web servers);
o data from IP Flow Information Export [RFC7011] also known as o data from IP Flow Information Export [RFC7011] also known as
IPfix; IPFIX;
o data from various SNMP MIB [RFC4293]; o data from various SNMP MIBs [RFC4293];
o historical data of Neighbour Cache entries; o historical data of Neighbor Cache entries;
o stateful DHCPv6 [RFC8415] lease cache, especially when a relay o stateful DHCPv6 [RFC8415] lease cache, especially when a relay
agent [RFC6221] is used; agent [RFC6221] is used;
o Source Address Validation Improvement (SAVI) [RFC7039] events, o Source Address Validation Improvement (SAVI) [RFC7039] events,
especially the binding of an IPv6 address to a MAC address and a especially the binding of an IPv6 address to a MAC address and a
specific switch or router interface; specific switch or router interface;
o RADIUS [RFC2866] accounting records. o RADIUS [RFC2866] accounting records.
Please note that there are privacy issues or regulations related to Please note that there are privacy issues or regulations related to
how those logs are collected, kept and safely discarded. Operators how these logs are collected, stored, and safely discarded. Operators
are urged to check their country legislation (e.g. GDPR in the are urged to check their country legislation (e.g., GDPR in the
European Union). European Union).
All those pieces of information can be used for: All those pieces of information can be used for:
o forensic (Section 2.6.2.1) investigations such as who did what and o forensic (Section 2.6.2.1) investigations such as who did what and
when? when?
o correlation (Section 2.6.2.3): which IP addresses were used by a o correlation (Section 2.6.2.3): which IP addresses were used by a
specific node (assuming the use of privacy extensions addresses specific node (assuming the use of privacy extensions addresses
[RFC4941]) [RFC4941])
o inventory (Section 2.6.2.2): which IPv6 nodes are on my network? o inventory (Section 2.6.2.2): which IPv6 nodes are on my network?
o abnormal behavior detection (Section 2.6.2.4): unusual traffic o abnormal behavior detection (Section 2.6.2.4): unusual traffic
patterns are often the symptoms of an abnormal behavior which is patterns are often the symptoms of an abnormal behavior which is
in turn a potential attack (denial of services, network scan, a in turn a potential attack (denial of service, network scan, a
node being part of a botnet, ...) node being part of a botnet, etc.)
2.6.1. Data Sources 2.6.1. Data Sources
This section lists the most important sources of data that are useful This section lists the most important sources of data that are useful
for operational security. for operational security.
2.6.1.1. Logs of Applications 2.6.1.1. Application Logs
Those logs are usually text files where the remote IPv6 address is Those logs are usually text files where the remote IPv6 address is
stored in all characters (not binary). This can complicate the stored in clear text (not binary). This can complicate the
processing since one IPv6 address, for example 2001:db8::1 can be processing since one IPv6 address, for example 2001:db8::1 can be
written in multiple ways such as: written in multiple ways, such as:
o 2001:DB8::1 (in uppercase) o 2001:DB8::1 (in uppercase)
o 2001:0db8::0001 (with leading 0) o 2001:0db8::0001 (with leading 0)
o and many other ways including the reverse DNS mapping into a FQDN o and many other ways including the reverse DNS mapping into a FQDN
(which should not be trusted). (which should not be trusted).
[RFC5952] explains this problem in detail and recommends the use of a [RFC5952] explains this problem in detail and recommends the use of a
single canonical format. This document recommends the use of single canonical format. This document recommends the use of
skipping to change at page 21, line 34 skipping to change at page 21, line 34
} }
print " " ; print " " ;
} }
print "\n" ; print "\n" ;
} }
<CODE ENDS> <CODE ENDS>
2.6.1.2. IP Flow Information Export by IPv6 Routers 2.6.1.2. IP Flow Information Export by IPv6 Routers
IPfix [RFC7012] defines some data elements that are useful for IPFIX [RFC7012] defines some data elements that are useful for
security: security:
o in section 5.4 (IP Header fields): nextHeaderIPv6 and o in section 5.4 (IP Header fields): nextHeaderIPv6 and
sourceIPv6Address; sourceIPv6Address;
o in section 5.6 (Sub-IP fields) sourceMacAddress. o in section 5.6 (Sub-IP fields) sourceMacAddress.
Moreover, IPfix is very efficient in terms of data handling and Moreover, IPFIX is very efficient in terms of data handling and
transport. It can also aggregate flows by a key such as transport. It can also aggregate flows by a key such as
sourceMacAddress in order to have aggregated data associated with a sourceMacAddress in order to have aggregated data associated with a
specific sourceMacAddress. This memo recommends the use of IPfix and specific sourceMacAddress. This memo recommends the use of IPFIX and
aggregation on nextHeaderIPv6, sourceIPv6Address and aggregation on nextHeaderIPv6, sourceIPv6Address,SW and
sourceMacAddress. sourceMacAddress.
2.6.1.3. SNMP MIB by IPv6 Routers 2.6.1.3. SNMP MIB by IPv6 Routers
RFC 4293 [RFC4293] defines a Management Information Base (MIB) for RFC 4293 [RFC4293] defines a Management Information Base (MIB) for
the two address families of IP. This memo recommends the use of: the two address families of IP. This memo recommends the use of:
o ipIfStatsTable table which collects traffic counters per o ipIfStatsTable table which collects traffic counters per
interface; interface;
o ipNetToPhysicalTable table which is the content of the Neighbor o ipNetToPhysicalTable table which is the content of the Neighbor
cache, i.e. the mapping between IPv6 and data-link layer cache, i.e., the mapping between IPv6 and data-link layer
addresses. addresses.
2.6.1.4. Neighbor Cache of IPv6 Routers 2.6.1.4. Neighbor Cache of IPv6 Routers
The neighbor cache of routers contains all mappings between IPv6 The neighbor cache of routers contains all mappings between IPv6
addresses and data-link layer addresses. There are multiple ways to addresses and data-link layer addresses. There are multiple ways to
collect the current entries in the Neighbor Cache, notably but not collect the current entries in the Neighbor Cache, notably but not
limited to: limited to:
o the SNMP MIB (Section 2.6.1.3) as explained above; o the SNMP MIB (Section 2.6.1.3) as explained above;
o using streaming telemetry or NETCONF [RFC6241] to collect the o using streaming telemetry or NETCONF [RFC6241] to collect the
operational state of the neighbor cache; operational state of the neighbor cache;
o also by connecting over a secure management channel (such as SSH) o also by connecting over a secure management channel (such as SSH)
and explicitly requesting a neighbor cache dump via the Command and explicitly requesting a neighbor cache dump via the Command
Line Interface or another monitoring mechanism. Line Interface or another monitoring mechanism.
The neighbor cache is highly dynamic as mappings are added when a new The neighbor cache is highly dynamic as mappings are added when a new
IPv6 address appears on the network (could be quite often with IPv6 address appears on the network. This could be quite often with
privacy extension addresses [RFC4941] or when they are removed when privacy extension addresses [RFC4941] or when they are removed when
the state goes from UNREACH to removed (the default time for a the state goes from UNREACH to removed (the default time for a
removal per Neighbor Unreachability Detection [RFC4861] algorithm is removal per Neighbor Unreachability Detection [RFC4861] algorithm is
38 seconds for a typical host such as Windows 7). This means that 38 seconds for a typical host such as Windows 7). This means that
the content of the neighbor cache must periodically be fetched at an the content of the neighbor cache must periodically be fetched at an
interval which does not exhaust the router resources and still interval which does not exhaust the router resources and still
provides valuable information (suggested value is 30 seconds but to provides valuable information (suggested value is 30 seconds but to
be checked in the actual set-up) and stored for later use. be checked in the actual setup) and stored for later use.
This is an important source of information because it is trivial (on This is an important source of information because it is trivial (on
a switch not using the SAVI [RFC7039] algorithm) to defeat the a switch not using the SAVI [RFC7039] algorithm) to defeat the
mapping between data-link layer address and IPv6 address. Let us mapping between data-link layer address and IPv6 address. Let us
rephrase the previous statement: having access to the current and rephrase the previous statement: having access to the current and
past content of the neighbor cache has a paramount value for forensic past content of the neighbor cache has a paramount value for forensic
and audit trail. and audit trail.
When using one /64 per host (Section 2.1.7) or DHCP-PD, it is When using one /64 per host (Section 2.1.7) or DHCP-PD, it is
sufficient to keep the history of the allocated prefixes when sufficient to keep the history of the allocated prefixes when
combined with strict source address prefix enforcement on the routers combined with strict source address prefix enforcement on the routers
and layer-2 switches to prevent IPv6 spoofing. and layer-2 switches to prevent IPv6 spoofing.
2.6.1.5. Stateful DHCPv6 Lease 2.6.1.5. Stateful DHCPv6 Lease
In some networks, IPv6 addresses/prefixes are managed by a stateful In some networks, IPv6 addresses/prefixes are managed by a stateful
DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to
clients. It is indeed quite similar to DHCP for IPv4 so it can be 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 tempting to use this DHCP lease file to discover the mapping between
IPv6 addresses/prefixes and data-link layer addresses as it was IPv6 addresses/prefixes and data-link layer addresses as it was
usually done in the IPv4 era. usually done in IPv4 networks.
It is not so easy in the IPv6 era because not all nodes will use It is not so easy in IPv6 networks because not all nodes will use
DHCPv6 (there are nodes which can only do stateless DHCPv6 (there are nodes which can only do stateless
autoconfiguration) but also because DHCPv6 clients are identified not autoconfiguration) but also because DHCPv6 clients are identified not
by their hardware-client address as in IPv4 but by a DHCP Unique ID 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 (DUID) which can have several formats: some being the data-link layer
address, some being data-link layer address prepended with time address, some being data-link layer address prepended with time
information or even an opaque number which is useless for operation information, or even an opaque number which is useless for operational
security. Moreover, when the DUID is based on the data-link address, 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 this address can be of any client interface (such as the
wireless interface while the client actually uses its wired interface wireless interface while the client actually uses its wired interface
to connect to the network). to connect to the network).
If a lightweight DHCP relay agent [RFC6221] is used in the layer-2 If a lightweight DHCP relay agent [RFC6221] is used in a layer-2
switches, then the DHCP server also receives the Interface-ID switch, then the DHCP server also receive the Interface-ID
information which could be saved in order to identify the interface information which could be saved in order to identify the interface
of the switches which received a specific leased IPv6 address. Also, on which the switch received a specific leased IPv6 address. Also,
if a 'normal' (not lightweight) relay agent adds the data-link layer if a 'normal' (not lightweight) relay agent adds the data-link layer
address in the option for Relay Agent Remote-ID [RFC4649] or address in the option for Relay Agent Remote-ID [RFC4649] or
[RFC6939], then the DHCPv6 server can keep track of the data-link and [RFC6939], then the DHCPv6 server can keep track of the data-link and
leased IPv6 addresses. leased IPv6 addresses.
In short, the DHCPv6 lease file is less interesting than in the IPv4 In short, the DHCPv6 lease file is less interesting than for IPv4
era. If possible, it is recommended to use DHCPv6 servers that keep networks. If possible, it is recommended to use DHCPv6 servers that keep
the relayed data-link layer address in addition to the DUID in the the relayed data-link layer address in addition to the DUID in the
lease file as those servers have the equivalent information to IPv4 lease file as those servers have the equivalent information to IPv4
DHCP servers. DHCP servers.
The mapping between data-link layer address and the IPv6 address can The mapping between data-link layer address and the IPv6 address can
be secured by using switches implementing the SAVI [RFC7513] be secured by deploying switches implementing the SAVI [RFC7513]
algorithms. Of course, this also requires that data-link layer mechanisms. Of course, this also requires that the data-link layer
address is protected by using layer-2 mechanism such as address is protected by using a layer-2 mechanism such as
[IEEE-802.1X]. [IEEE-802.1X].
2.6.1.6. RADIUS Accounting Log 2.6.1.6. RADIUS Accounting Log
For interfaces where the user is authenticated via a RADIUS [RFC2866] For interfaces where the user is authenticated via a RADIUS [RFC2866]
server, and if RADIUS accounting is enabled, then the RADIUS server server, and if RADIUS accounting is enabled, then the RADIUS server
receives accounting Acct-Status-Type records at the start and at the receives accounting Acct-Status-Type records at the start and at the
end of the connection which include all IPv6 (and IPv4) addresses end of the connection which include all IPv6 (and IPv4) addresses
used by the user. This technique can be used notably for Wi-Fi used by the user. This technique can be used notably for Wi-Fi
networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X
[IEEE-802.1X] wired interface on an Ethernet switch. [IEEE-802.1X] wired interface on an ethernet switch.
2.6.1.7. Other Data Sources 2.6.1.7. Other Data Sources
There are other data sources that must be kept as in the IPv4 There are other data sources for log information that must be collected
network: (as currently collected in the IPv4 networks):
o historical mapping of IPv6 addresses to users of remote access o historical mappings of IPv6 addresses to users of remote access
VPN; VPN;
o historical mapping of MAC address to switch interface in a wired o historical mappings of MAC addresses to switch interfaces in a wired
network. network.
2.6.2. Use of Collected Data 2.6.2. Use of Collected Data
This section leverages the data collected as described before This section leverages the data collected as described before
(Section 2.6.1) in order to achieve several security benefits. (Section 2.6.1) in order to achieve several security benefits.
Section 9.1 of [RFC7934] contains more details about host tracking. Section 9.1 of [RFC7934] contains more details about host tracking.
2.6.2.1. Forensic and User Accountability 2.6.2.1. Forensic and User Accountability
The forensic use case is when the network operator must locate an 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 IPv6 address that was present in the network at a certain time or is
still currently in the network. still currently in the network.
To locate an IPv6 address in an enterprise network where the operator To locate an IPv6 address in an enterprise network where the operator
has control over all resources, the source of information can be, in has control over all resources, the source of information can be the
decreasing order, neighbor cache, DHCP lease file. Then, the neighbor cache, or if not found, the DHCP lease file. Then, the
procedure is: procedure is:
1. based on the IPv6 prefix of the IPv6 address, find the router(s) 1. Based on the IPv6 prefix of the IPv6 address, find the router(s)
which is(are) used to reach this prefix (assuming that anti- which is(are) used to reach this prefix (assuming that anti-
spoofing mechanisms are used); spoofing mechanisms are used).
2. based on this limited set of routers, on the incident time and on 2. Based on this limited set of routers, on the incident time and on
the IPv6 address, retrieve the data-link address from live the IPv6 address, retrieve the data-link address from the live
neighbor cache, from the historical data of the neighbor cache or neighbor cache, the historical neighbor cache data, or
from SAVI events, or retrieve the data-link address from the DHCP from SAVI events, or retrieve the data-link address from the DHCP
lease file (Section 2.6.1.5); lease file (Section 2.6.1.5).
SW
3. based on the data-link layer address, look-up on which switch 3. Based on the data-link layer address, look-up the switch
interface was this data-link layer address. In the case of interface associated with the data-link layer address. In the case of
wireless LAN with RADIUS accounting (see Section 2.6.1.6), the wireless LAN with RADIUS accounting (see Section 2.6.1.6), the
RADIUS log has the mapping between the user identification and RADIUS log has the mapping between the user identification and
the MAC address. If a Configuration Management Data Base (CMDB) the MAC address. If a Configuration Management Data Base (CMDB)
is used, then it can be used to map the data-link layer address is used, then it can be used to map the data-link layer address
to a switch port. to a switch port.
At the end of the process, the interface the host originating At the end of the process, the interface of the host originating
malicious activity or the username which was abused for malicious malicious activity or the username perpetrating the malicious
activity has been determined. activity has been determined.
To identify the subscriber of an IPv6 address in a residential To identify the subscriber of an IPv6 address in a residential
Internet Service Provider, the starting point is the DHCP-PD leased Internet Service Provider, the starting point is the DHCP-PD leased
prefix covering the IPv6 address; this prefix can often be linked to prefix covering the IPv6 address; this prefix can often be linked to
a subscriber via the RADIUS log. Alternatively, the Forwarding a subscriber via the RADIUS log. Alternatively, the Forwarding
Information Base of the CMTS or BNG indicates the CPE of the Information Base of the CMTS or BNG indicates the CPE of the
subscriber and the RADIUS log can be used to retrieve the actual subscriber and the RADIUS log can be used to retrieve the actual
subscriber. subscriber.
More generally, a mix of the above techniques can be used in most if More generally, a mix of the above techniques can be used in most, if
not all networks. not all, networks.
2.6.2.2. Inventory 2.6.2.2. Inventory
RFC 7707 [RFC7707] is about the difficulties for an attacker to scan RFC 7707 [RFC7707] describes the difficulties for an attacker to scan
an IPv6 network due to the vast number of IPv6 addresses per link an IPv6 network due to the vast number of IPv6 addresses per link
(and why in some case it can still be done). While the huge (and why in some case it can still be done). While the huge
addressing space can sometime be perceived as a 'protection', it also addressing space can sometime be perceived as a 'protection', it also
make the inventory task difficult in an IPv6 network while it was makes the inventory task difficult in an IPv6 network while it was
trivial to do in an IPv4 network (a simple enumeration of all IPv4 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 addresses, followed by a ping and a TCP/UDP port scan). Getting an
inventory of all connected devices is of prime importance for a inventory of all connected devices is of prime importance for
secure operation of a network. secure network operation.
There are many ways to do an inventory of an IPv6 network. There are many ways to do an inventory of an IPv6 network.
The first technique is to use the IPfix information and extract the 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 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 packets through a router. This is very efficient but, alas, will not
discover silent node that never transmitted such packets. Also, it discover silent nodes that never transmitted packets traversing the
the IPFIX target router. Also, it
must be noted that link-local addresses will never be discovered by must be noted that link-local addresses will never be discovered by
this means. this means.
The second way is again to use the collected neighbor cache content The second way is again to use the collected neighbor cache content
to find all IPv6 addresses in the cache. This process will also to find all IPv6 addresses in the cache. This process will also
discover all link-local addresses. See Section 2.6.1.4. discover all link-local addresses. See Section 2.6.1.4.
Another way works only for local network, it consists in sending a Another way that works only for local network, consists in sending a
ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 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 addresses all IPv6 nodes on the network. All nodes should reply to this
ECHO_REQUEST per [RFC4443]. ECHO_REQUEST per [RFC4443].
Other techniques involve obtaining data from DNS, parsing log files, Other techniques involve obtaining data from DNS, parsing log files,
leveraging service discovery such as mDNS [RFC6762] and [RFC6763]. leveraging service discovery such as mDNS [RFC6762] and [RFC6763].
Enumerating DNS zones, especially looking at reverse DNS records and Enumerating DNS zones, especially looking at reverse DNS records and
CNAMES, is another common method employed by various tools. As CNAMES, is another common method employed by various tools. As
already mentioned in [RFC7707], this allows an attacker to prune the already mentioned in [RFC7707], this allows an attacker to prune the
IPv6 reverse DNS tree, and hence enumerate it in a feasible time. IPv6 reverse DNS tree, and hence identify it in a feasible time.
Furthermore, authoritative servers that allow zone transfers (AXFR) Furthermore, authoritative servers that allow zone transfers (AXFR)
may be a further information source. may be a further information source.
2.6.2.3. Correlation 2.6.2.3. Correlation
In an IPv4 network, it is easy to correlate multiple logs, for In an IPv4 network, it is easy to correlate multiple logs, for
example to find events related to a specific IPv4 address. A simple example to find events related to a specific IPv4 address. A simple
Unix grep command was enough to scan through multiple text-based Unix grep command is enough to scan through multiple text-based
files and extract all lines relevant to a specific IPv4 address. files and extract all lines relevant to a specific IPv4 address.
In an IPv6 network, this is slightly more difficult because different In an IPv6 network, this is slightly more difficult because different
character strings can express the same IPv6 address. Therefore, the character strings can express the same IPv6 address. Therefore, the
simple Unix grep command cannot be used. Moreover, an IPv6 node can simple Unix grep command cannot be used. Moreover, an IPv6 node can
have multiple IPv6 addresses. have multiple IPv6 addresses.
In order to do correlation in IPv6-related logs, it is advised to In order to do correlation in IPv6-related logs, it is advised to
have all logs in a format with only canonical IPv6 addresses. Then, have all logs in a format with only canonical IPv6 addresses. Then,
the neighbor cache current (or historical) data set must be searched the neighbor cache current (or historical) data set must be searched
to find the data-link layer address of the IPv6 address. Then, the to find the data-link layer address of the IPv6 address. Then, the
current and historical neighbor cache data sets must be searched for current and historical neighbor cache data sets must be searched for
all IPv6 addresses associated to this data-link layer address: this all IPv6 addresses associated to this data-link layer address to
is the search set. The last step is to search in all log files derive the search set. The last step is to search in all log files
(containing only IPv6 address in canonical format) for any IPv6 (containing only IPv6 address in canonical format) for any IPv6
addresses in the search set. addresses in the search set.
Moreover, [RFC7934] recommends using multiple IPv6 addresses per Moreover, [RFC7934] recommends using multiple IPv6 addresses per
prefix, so, the correlation must also be done among those multiple prefix, so, the correlation must also be done among those multiple
IPv6 addresses, for example by discovering in the NDP cache IPv6 addresses, for example by discovering in the NDP cache
(Section 2.6.1.4) all IPv6 addresses associated with the same MAC (Section 2.6.1.4) all IPv6 addresses associated with the same MAC
address and interface. address and interface.
2.6.2.4. Abnormal Behavior Detection 2.6.2.4. Abnormal Behavior Detection
Abnormal behaviors (such as network scanning, spamming, denial of Abnormal behavior (such as network scanning, spamming, denial of
service) can be detected in the same way as in an IPv4 network 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 o Sudden increase in traffic detected by interface counter (SNMP) or
of connection per host...) with the use of IPfix [RFC7012] by aggregated traffic from IPFIX records [RFC7012]
o Change in traffic pattern (number of connection per second, number
of connection per host...) with the use of IPFIX [RFC7012]
2.6.3. Summary 2.6.3. Summary
While some data sources (IPfix, MIB, switch CAM tables, logs, ...) While some data sources (IPFIX, MIB, switch CAM tables, logs, ...)
used in IPv4 are also used in the secure operation of an IPv6 used in IPv4 are also used in the secure operation of an IPv6
network, the DHCPv6 lease file is less reliable and the neighbor network, the DHCPv6 lease file is less reliable and the neighbor
cache is of prime importance. cache is of prime importance.
The fact that there are multiple ways to express in a character The fact that there are multiple ways to express the same IPv6
string the same IPv6 address renders the use of filters mandatory address as a character string renders the use of filters mandatory
when correlation must be done. when correlation must be done.
2.7. Transition/Coexistence Technologies 2.7. Transition/Coexistence Technologies
As it is expected that some networks will not run in a pure IPv6-only As it is expected that some networks will not run in a pure IPv6-only
way, the different transition mechanisms must be deployed and mode, the different transition mechanisms must be deployed and
operated in a secure way. This section proposes operational operated in a secure way. This section proposes operational
guidelines for the most known and deployed transition techniques. guidelines for the most known and deployed transition techniques.
2.7.1. Dual Stack 2.7.1. Dual Stack
Dual stack is often the first deployment choice for network Dual stack is often the first deployment choice for network
operators. Dual stacking the network offers some advantages over operators. Dual stacking the network offers some advantages over
other transition mechanisms. Firstly, the impact on existing IPv4 other transition mechanisms. Firstly, the impact on existing IPv4
operations is reduced. Secondly, in the absence of tunnels or operations is reduced. Secondly, in the absence of tunnels or
address translation, the IPv4 and IPv6 traffics are native (easier to address translation, the IPv4 and IPv6 traffic are native (easier to
observe and secure) and should have the same network processing observe and secure) and should have the same network processing
(network path, quality of service, ...). Dual stack enables a (network path, quality of service, ...). Dual stack enables a
gradual turn off of the IPv4 operations when the IPv6 network is gradual termination of the IPv4 operations when the IPv6 network is
ready for prime time. On the other hand, the operators have to ready for prime time. On the other hand, the operators have to
manage two network stacks with the added complexities. manage two network stacks with the added complexities.
From an operational security perspective, this now means that you From an operational security perspective, this now means that you
have twice the exposure. One needs to think about protecting both have twice the exposure. One needs to think about protecting both
protocols now. At a minimum, the IPv6 portion of a dual stacked protocols now. At a minimum, the IPv6 portion of a dual stack
network should maintain parity with IPv4 from a security policy point network should maintain parity with IPv4 from a security policy point
of view. Typically, the following methods are employed to protect of view. Typically, the following methods are employed to protect
IPv4 networks at the edge or security perimeter: IPv4 networks at the edge or security perimeter:
o ACLs to permit or deny traffic; o ACLs to permit or deny traffic;
o Firewalls with stateful packet inspection. o Firewalls with stateful packet inspection.
It is recommended that these ACLs and/or firewalls be additionally It is recommended that these ACLs and/or firewalls be additionally
configured to protect IPv6 communications. The enforced IPv6 configured to protect IPv6 communications. The enforced IPv6
security must be congruent with the IPv4 security policy, else the security must be congruent with the IPv4 security policy, otherwise the
attacker will use the protocol version having the more relax security attacker will use the protocol version having the more relaxed security
policy. Maintaining the congruence between security policies can be policy. Maintaining the congruence between security policies can be
challenging (especially over time); it is recommended to use a challenging (especially over time); it is recommended to use a
firewall or an ACL manager that is dual-stack, i.e., a system that firewall or an ACL manager that is dual-stack, i.e., a system that
can apply a single ACL entry to a mixed group of IPv4 and IPv6 can apply a single ACL entry to a mixed group of IPv4 and IPv6
addresses. addresses.
Also, given the end-to-end connectivity that IPv6 provides, it is Also, given the end-to-end connectivity that IPv6 provides, it is
recommended that hosts be fortified against threats. General device recommended that hosts be fortified against threats. General device
hardening guidelines are provided in Section 2.8. hardening guidelines are provided in Section 2.8.
For many years, all host operating systems have IPv6 enabled by For many years, all host operating systems have IPv6 enabled by
default, so, it is possible even in an 'IPv4-only' network to attack default, so, it is possible even in an 'IPv4-only' network to attack
layer-2 adjacent victims over their IPv6 link-local address or over a layer-2 adjacent victims via their IPv6 link-local address or via a
global IPv6 address when the attacker provides rogue RAs or a rogue global IPv6 address when the attacker provides rogue RAs or a rogue
DHCPv6 service. DHCPv6 service.
2.7.2. Encapsulation Mechanisms 2.7.2. Encapsulation Mechanisms
There are many tunnels used for specific use cases. Except when There are many tunnels used for specific use cases. Except when
protected by IPsec [RFC4301], all those tunnels have a couple of protected by IPsec [RFC4301], all those tunnels have a couple of
security issues as described in RFC 6169 [RFC6169]; security issues as described in RFC 6169 [RFC6169];
o tunnel injection: a malevolent person knowing a few pieces of o tunnel injection: a malevolent person knowing a few pieces of
information (for example the tunnel endpoints and the used information (for example the tunnel endpoints and the encapsulation
protocol) can forge a packet which looks like a legit and valid protocol) can forge a packet which looks like a legit and valid
encapsulated packet that will gladly be accepted by the encapsulated packet that will gladly be accepted by the
destination tunnel endpoint, this is a specific case of spoofing; destination tunnel endpoint, this is a specific case of spoofing;
o traffic interception: no confidentiality is provided by the tunnel o traffic interception: no confidentiality is provided by the tunnel
protocols (without the use of IPsec or alternative encryption protocols (without the use of IPsec or alternative encryption
methods), therefore anybody on the tunnel path can intercept the methods), therefore anybody on the tunnel path can intercept the
traffic and have access to the clear-text IPv6 packet; combined traffic and have access to the clear-text IPv6 packet; combined
with the absence of authentication, a man in the middle attack can with the absence of authentication, a man-in-the-middle attack can
also be mounted; also be mounted;
o service theft: as there is no authorization, even a non-authorized 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 user can use a tunnel relay for free (this is a specific case of
tunnel injection); tunnel injection);
o reflection attack: another specific use case of tunnel injection o reflection attack: another specific use case of tunnel injection
where the attacker injects packets with an IPv4 destination where the attacker injects packets with an IPv4 destination
address not matching the IPv6 address causing the first tunnel address not matching the IPv6 address causing the first tunnel
endpoint to re-encapsulate the packet to the destination... Hence, endpoint to re-encapsulate the packet to the destination... Hence,
the final IPv4 destination will not see the original IPv4 address the final IPv4 destination will not see the original IPv4 address
but only one IPv4 address of the relay router. but only the IPv4 address of the relay router.
o bypassing security policy: if a firewall or an IPS is on the path o bypassing security policy: if a firewall or an IPS is on the path
of the tunnel, then it may neither inspect nor detect an of the tunnel, then it may neither inspect nor detect a
malevolent IPv6 traffic contained in the tunnel. malevolent IPv6 packet transmitted over the tunnel.
To mitigate the bypassing of security policies, it is recommended to To mitigate the bypassing of security policies, it is recommended to
block all default configuration tunnels by denying IPv4 packets block all default configuration tunnels by denying IPv4 packets
matching: matching:
o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4
(Section 2.7.2.7), 6rd (Section 2.7.2.3) as well as 6in4 (Section 2.7.2.7), 6rd (Section 2.7.2.3) as well as 6in4
(Section 2.7.2.1) tunnels; (Section 2.7.2.1) tunnels;
o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels;
o UDP protocol 3544: this will block the default encapsulation of o UDP protocol 3544: this will block the default encapsulation of
Teredo (Section 2.7.2.8) tunnels. Teredo is now mostly never used Teredo (Section 2.7.2.8) tunnels. Teredo is now hardly ever used
and it is no more automated in most environment, so, it is less of and it is no longer automated in most environments, so, it is less of
a threat, however, special consideration must be taken in case of a threat, however, special consideration must be taken in case of
devices with older or non-updated operating systems may be devices with older or non-updated operating systems that may be
present, which by default were running Teredo. present and by default are running Teredo.
Ingress filtering [RFC2827] should also be applied on all tunnel Ingress filtering [RFC2827] should also be applied on all tunnel
endpoints if applicable to prevent IPv6 address spoofing. endpoints if applicable to prevent IPv6 address spoofing.
As several of the tunnel techniques share the same encapsulation As several of the tunnel techniques share the same encapsulation
(i.e. IPv4 protocol 41) and embed the IPv4 address in the IPv6 (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6
address, there are a set of well-known looping attacks described in address, there are a set of well-known looping attacks described in
RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. RFC 6324 [RFC6324], this RFC also proposes mitigation techniques.
2.7.2.1. Site-to-Site Static Tunnels 2.7.2.1. Site-to-Site Static Tunnels
Site-to-site static tunnels are described in RFC 2529 [RFC2529] and Site-to-site static tunnels are described in RFC 2529 [RFC2529] and
in GRE [RFC2784]. As the IPv4 endpoints are statically configured in GRE [RFC2784]. As the IPv4 endpoints are statically configured
and are not dynamic they are slightly more secure (bi-directional and are not dynamic they are slightly more secure (bi-directional
service theft is mostly impossible) but traffic interception and service theft is mostly impossible) but traffic interception and
tunnel injection are still possible. Therefore, the use of IPsec tunnel injection are still possible. Therefore, the use of IPsec
skipping to change at page 30, line 13 skipping to change at page 30, line 13
IPv4 network. IPv4 network.
2.7.2.2. ISATAP 2.7.2.2. ISATAP
ISATAP tunnels [RFC5214] are mainly used within a single ISATAP tunnels [RFC5214] are mainly used within a single
administrative domain and to connect a single IPv6 host to the IPv6 administrative domain and to connect a single IPv6 host to the IPv6
network. This often implies that those systems are usually managed network. This often implies that those systems are usually managed
by a single entity; therefore, audit trail and strict anti-spoofing by a single entity; therefore, audit trail and strict anti-spoofing
are usually possible and this raises the overall security. are usually possible and this raises the overall security.
Special care must be taken to avoid looping attack by implementing Special care must be taken to avoid a looping attack by implementing
the measures of RFC 6324 [RFC6324] and of [RFC6964]. the measures of RFC 6324 [RFC6324] and of [RFC6964].
IPsec [RFC4301] in transport or tunnel mode can be used to secure the IPsec [RFC4301] in transport or tunnel mode can be used to secure the
IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and
prevent service theft. prevent service theft.
2.7.2.3. 6rd 2.7.2.3. 6rd
While 6rd tunnels share the same encapsulation as 6to4 tunnels While 6rd tunnels share the same encapsulation as 6to4 tunnels
(Section 2.7.2.7), they are designed to be used within a single SP (Section 2.7.2.7), they are designed to be used within a single SP
domain, in other words they are deployed in a more constrained domain, in other words they are deployed in a more constrained
environment than 6to4 tunnels and have little security issues except environment than 6to4 tunnels and have few security issues other than
lack of confidentiality. The security considerations (Section 12) of lack of confidentiality. The security considerations (Section 12) of
[RFC5969] describes how to secure the 6rd tunnels. [RFC5969] describes how to secure 6rd tunnels.
IPsec [RFC4301] for the transported IPv6 traffic can be used if IPsec [RFC4301] for the transported IPv6 traffic can be used if
confidentiality is important. confidentiality is important.
2.7.2.4. 6PE, 6VPE, and LDPv6 2.7.2.4. 6PE, 6VPE, and LDPv6
Organizations using MPLS in their core can also use 6PE [RFC4798] and 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 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are
really similar to BGP/MPLS IP VPN described in [RFC4364], the really similar to BGP/MPLS IP VPN described in [RFC4364], the
security of these networks is also similar to the one described in security properties of these networks is also similar to those described in
[RFC4381]. It relies on: [RFC4381]. It relies on:
o Address space, routing and traffic separation with the help of o Address space, routing and traffic separation with the help of
VRFs (only applicable to 6VPE); VRFs (only applicable to 6VPE);
o Hiding the IPv4 core, hence removing all attacks against o Hiding the IPv4 core, hence removing all attacks against
P-routers; P-routers;
o Securing the routing protocol between CE and PE; in the case of o Securing the routing protocol between CE and PE; in the case of
6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and
skipping to change at page 31, line 14 skipping to change at page 31, line 14
2.7.2.5. DS-Lite 2.7.2.5. DS-Lite
DS-lite is also a translation mechanism and is therefore analyzed DS-lite is also a translation mechanism and is therefore analyzed
further (Section 2.7.3.3) in this document. further (Section 2.7.3.3) in this document.
2.7.2.6. Mapping of Address and Port 2.7.2.6. Mapping of Address and Port
With the encapsulation and translation versions of mapping of Address With the encapsulation and translation versions of mapping of Address
and Port (MAP-E [RFC7597] and MAP-T [RFC7599]), the access network is and Port (MAP-E [RFC7597] and MAP-T [RFC7599]), the access network is
purely an IPv6 network and MAP protocols are used to give IPv4 hosts purely an IPv6 network and MAP protocols are used to connect IPv4 hosts
on the subscriber network access to IPv4 hosts on the Internet. The on the subscriber network access to IPv4 hosts on the Internet. The
subscriber router does stateful operations in order to map all subscriber router does stateful operations in order to map all
internal IPv4 addresses and layer-4 ports to the IPv4 address and the internal IPv4 addresses and layer-4 ports to the IPv4 address and the
set of layer-4 ports received through MAP configuration process. The set of layer-4 ports received through MAP configuration process. The
SP equipment always does stateless operations (either decapsulation SP equipment always does stateless operations (either decapsulation
or stateless translation). Therefore, as opposed to Section 2.7.3.3 or stateless translation). Therefore, as opposed to Section 2.7.3.3
there is no state-exhaustion DoS attack against the SP equipment 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 because there is no state and there is no operation caused by a new
layer-4 connection (no logging operation). layer-4 connection (no logging operation).
The SP MAP equipment should implement all the security considerations The SP MAP equipment should implement all the security considerations
of [RFC7597]; notably, ensuring that the mapping of the IPv4 address of [RFC7597]; notably, ensuring that the mapping of the IPv4 address
and port are consistent with the configuration. As MAP has a and port are consistent with the configuration. As MAP has a
predictable IPv4 address and port mapping, the audit logs are easier predictable IPv4 address and port mapping, the audit logs are easier
to manage. to manage.
2.7.2.7. 6to4 2.7.2.7. 6to4
6to4 tunnels [RFC3056] require a public routable IPv4 address in 6to4 tunnels [RFC3056] require a public routable IPv4 address in
order to work correctly. They can be used to provide either one IPv6 order to work correctly. They can be used to provide either singleIPv6
host connectivity to the IPv6 Internet or multiple IPv6 networks host connectivity to the IPv6 Internet or multiple IPv6 networks
connectivity to the IPv6 Internet. The 6to4 relay was historically connectivity to the IPv6 Internet. The 6to4 relay was historically
the anycast address defined in [RFC3068] which has been deprecated by the anycast address defined in [RFC3068] which has been deprecated by
[RFC7526] and is no more used by recent Operating Systems. Some [RFC7526] and is no longer used by recent Operating Systems. Some
security considerations are explained in [RFC3964]. security considerations are explained in [RFC3964].
[RFC6343] points out that if an operator provides well-managed [RFC6343] points out that if an operator provides well-managed
servers and relays for 6to4, non-encapsulated IPv6 packets will pass servers and relays for 6to4, non-encapsulated IPv6 packets will pass
through well- defined points (the native IPv6 interfaces of those through well-defined points (the native IPv6 interfaces of those
servers and relays) at which security mechanisms may be applied. servers and relays) at which security mechanisms may be applied.
Client usage of 6to4 by default is now discouraged, and significant Client usage of 6to4 by default is now discouraged, and significant
precautions are needed to avoid operational problems. precautions are needed to avoid operational problems.
2.7.2.8. Teredo 2.7.2.8. Teredo
Teredo tunnels [RFC4380] are mainly used in a residential environment Teredo tunnels [RFC4380] are mainly used in a residential environment
because Teredo easily traverses an IPv4 NAPT device thanks to its UDP because Teredo easily traverses an IPv4 NAPT device thanks to its UDP
encapsulation. Teredo tunnels connect a single host to the IPv6 encapsulation. Teredo tunnels connect a single host to the IPv6
Internet. Teredo shares the same issues as other tunnels: no Internet. Teredo shares the same issues as other tunnels: no
authentication, no confidentiality, possible spoofing and reflection authentication, no confidentiality, possible spoofing and reflection
attacks. attacks.
IPsec [RFC4301] for the transported IPv6 traffic is recommended. IPsec [RFC4301] for the transported IPv6 traffic is recommended.
The biggest threat to Teredo is probably for IPv4-only network as The biggest threat to Teredo is probably for an IPv4-only network as
Teredo has been designed to easily traverse IPV4 NAT-PT devices which Teredo has been designed to easily traverse IPV4 NAT-PT devices which
are quite often co-located with a stateful firewall. Therefore, if are quite often co-located with a stateful firewall. Therefore, if
the stateful IPv4 firewall allows unrestricted UDP outbound and the stateful IPv4 firewall allows unrestricted UDP outbound and
accept the return UDP traffic, then Teredo actually punches a hole in accepts the return UDP traffic, then Teredo actually punches a hole in
this firewall for all IPv6 traffic to the Internet and from the this firewall for all IPv6 traffic to the Internet and from the
Internet. While host policies can be deployed to block Teredo in an 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 IPv4-only network in order to avoid this firewall bypass, it would be
enough to block all UDP outbound traffic at the IPv4 firewall if enough to block all UDP outbound traffic at the IPv4 firewall if
deemed possible (of course, at least port 53 should be left open for deemed possible (of course, at least port 53 should be left open for
DNS traffic). DNS traffic).
Teredo is now mostly never used and no more enabled by default in Teredo is now hardly ever used and no longer enabled by default in
most environment, so, it is less of a threat, however, special most environments, so, it is less of a threat, however, special
consideration must be taken in case of devices with older or non- consideration must be taken in case of devices with older or non-
updated operating systems may be present, which by default were updated operating systems may be present and by default are
running Teredo. running Teredo.
2.7.3. Translation Mechanisms 2.7.3. Translation Mechanisms
Translation mechanisms between IPv4 and IPv6 networks are alternate Translation mechanisms between IPv4 and IPv6 networks are alternate
coexistence strategies while networks transition to IPv6. While a coexistence strategies while networks transition to IPv6. While a
framework is described in [RFC6144] the specific security framework is described in [RFC6144], the specific security
considerations are documented in each individual mechanism. For the considerations are documented in each individual mechanism. For the
most part they specifically mention interference with IPsec or DNSSEC most part, they specifically mention interference with IPsec or DNSSEC
deployments, how to mitigate spoofed traffic and what some effective deployments, how to mitigate spoofed traffic, and what some effective
filtering strategies may be. filtering strategies may be.
While not really a transition mechanism to IPv6, this section also While not really a transition mechanism to IPv6, this section also
includes the discussion about the use of heavy IPv4 to IPv4 network includes the discussion about the use of heavy IPv4-to-IPv4 network
address and port translation to prolong the life of IPv4-only address and port translation to prolong the life of IPv4-only
network. networks.
2.7.3.1. Carrier-Grade NAT (CGN) 2.7.3.1. Carrier-Grade NAT (CGN)
Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 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 (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 interim measure to extend the use of IPv4 in a large service
provider network until the provider can deploy and effective IPv6 provider network until the provider can deploy an effective IPv6
solution. [RFC6598] requested a specific IANA allocated /10 IPv4 solution. [RFC6598] requested a specific IANA allocated /10 IPv4
address block to be used as address space shared by all access 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. networks using CGN. This has been allocated as 100.64.0.0/10.
Section 13 of [RFC6269] lists some specific security-related issues Section 13 of [RFC6269] lists some specific security-related issues
caused by large scale address sharing. The Security Considerations caused by large scale address sharing. The Security Considerations
section of [RFC6598] also lists some specific mitigation techniques section of [RFC6598] also lists some specific mitigation techniques
for potential misuse of shared address space. Some Law Enforcement for potential misuse of shared address space. Some Law Enforcement
Agencies have identified CGN as impeding their cyber-crime Agencies have identified CGN as impeding their cyber-crime
investigations (for example Europol press release on CGN investigations (for example Europol press release on CGN
[europol-cgn]). Many translation techniques (NAT64, DS-lite, ...) [europol-cgn]). Many translation techniques (NAT64, DS-lite, ...)
have the same security issues as CGN when one part of the connection have the same security issues as CGN when one part of the connection
is IPv4-only. is IPv4-only.
[RFC6302] has recommendations for Internet-facing servers to also log [RFC6302] has recommendations for Internet-facing servers to also log
the source TCP or UDP ports of incoming connections in an attempt to the source TCP or UDP ports of incoming connections in an attempt to
help identify the users behind such a CGN. help identify the users behind such a CGN.
[RFC7422] suggests the use of deterministic address mapping in order [RFC7422] suggests the use of deterministic address mapping in order
to reduce logging requirements for CGN. The idea is to have an to reduce logging requirements for CGN. The idea is to have a
algorithm mapping back and forth the internal subscriber to public known algorithm for mapping internal subscriber to/from public ports.
ports.
2.7.3.2. NAT64/DNS64 and 464XLAT 2.7.3.2. NAT64/DNS64 and 464XLAT
Stateful NAT64 translation [RFC6146] allows IPv6-only clients to Stateful NAT64 translation [RFC6146] allows IPv6-only clients to
contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used
in conjunction with DNS64 [RFC6147], a mechanism which synthesizes in conjunction with DNS64 [RFC6147], a mechanism which synthesizes
AAAA records from existing A records. There is also a stateless AAAA records from existing A records. There is also a stateless
NAT64 [RFC7915] which is similar for the security aspects with the NAT64 [RFC7915] which is similar for the security aspects with the
added benefit of being stateless, so, less prone to a state added benefit of being stateless, so, less prone to a state
exhaustion attack. exhaustion attack.
skipping to change at page 33, line 44 skipping to change at page 33, line 43
The Security Consideration sections of [RFC6146] and [RFC6147] list The Security Consideration sections of [RFC6146] and [RFC6147] list
the comprehensive issues. A specific issue with the use of NAT64 is the comprehensive issues. A specific issue with the use of NAT64 is
that it will interfere with most IPsec deployments unless UDP that it will interfere with most IPsec deployments unless UDP
encapsulation is used. DNSSEC has an impact on DNS64 see section 3.1 encapsulation is used. DNSSEC has an impact on DNS64 see section 3.1
of [RFC7050]. of [RFC7050].
Another translation mechanism relying on a combination of stateful Another translation mechanism relying on a combination of stateful
and stateless translation, 464XLAT [RFC6877], can be used to do host and stateless translation, 464XLAT [RFC6877], can be used to do host
local translation from IPv4 to IPv6 and a network provider local translation from IPv4 to IPv6 and a network provider
translation from IPv6 to IPv4, i.e., giving IPv4-only application translation from IPv6 to IPv4, i.e., giving IPv4-only application
access to IPv4-only server over an IPv6-only network. 464XLAT shares access to an IPv4-only server over an IPv6-only network. 464XLAT shares
the same security considerations as NAT64 and DNS64, however it can the same security considerations as NAT64 and DNS64, however it can
be used without DNS64, avoiding the DNSSEC implications. be used without DNS64, avoiding the DNSSEC implications.
2.7.3.3. DS-Lite 2.7.3.3. DS-Lite
Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that
enables a service provider to share IPv4 addresses among customers by enables a service provider to share IPv4 addresses among customers by
combining two well-known technologies: IP in IP (IPv4-in-IPv6) and combining two well-known technologies: IP in IP (IPv4-in-IPv6) and
Network Address and Port Translation (NAPT). Network Address and Port Translation (NAPT).
Security considerations with respect to DS-Lite mainly revolve around Security considerations with respect to DS-Lite mainly revolve around
logging data, preventing DoS attacks from rogue devices (as the logging data, preventing DoS attacks from rogue devices (as the
Address Family Translation Router, AFTR [RFC6333] function is Address Family Translation Router (AFTR) [RFC6333] function is
stateful) and restricting service offered by the AFTR only to stateful), and restricting service offered by the AFTR only to
registered customers. registered customers.
Section 11 of [RFC6333] describes important security issues Section 11 of [RFC6333] describes important security issues
associated with this technology. associated with this technology.
2.8. General Device Hardening 2.8. General Device Hardening
There are many environments which rely on the network infrastructure There are many environments which rely on the network infrastructure
to disallow malicious traffic to get access to critical hosts. In to disallow malicious traffic from accessing critical hosts. In
new IPv6 deployments it has been common to see IPv6 traffic enabled new IPv6 deployments, it has been common to see IPv6 traffic enabled
but none of the typical access control mechanisms enabled for IPv6 but none of the typical access control mechanisms enabled for IPv6
device access. With the possibility of network device configuration device access. With the possibility of network device configuration
mistakes and the growth of IPv6 in the overall Internet it is mistakes and the growth of IPv6 in the overall Internet, it is
important to ensure that all individual devices are hardened against important to ensure that all individual devices are hardened against
miscreant behavior. miscreant behavior.
The following guidelines should be used to ensure appropriate The following guidelines should be used to ensure appropriate
hardening of the host, be it an individual computer or router, hardening of the host, be it an individual computer or router,
firewall, load-balancer, server, etc. device. firewall, load-balancer, server, etc.
o Restrict access to the device to authorized individuals o Restrict device access to authorized individuals
o Monitor and audit access to the device o Monitor and audit access to the device
o Turn off any unused services on the end node o Turn off any unused services on the end node
o Understand which IPv6 addresses are being used to source traffic o Understand which IPv6 addresses are being used to source traffic
and change defaults if necessary and change defaults if necessary
o Use cryptographically protected protocols for device management if o Use cryptographically protected protocols for device management if
possible (SCP, SNMPv3, SSH, TLS, etc.) possible (SCP, SNMPv3, SSH, TLS, etc.)
skipping to change at page 35, line 13 skipping to change at page 35, line 13
o Use virus scanners to detect malicious programs o Use virus scanners to detect malicious programs
3. Enterprises Specific Security Considerations 3. Enterprises Specific Security Considerations
Enterprises generally have robust network security policies in place Enterprises generally have robust network security policies in place
to protect existing IPv4 networks. These policies have been to protect existing IPv4 networks. These policies have been
distilled from years of experiential knowledge of securing IPv4 distilled from years of experiential knowledge of securing IPv4
networks. At the very least, it is recommended that enterprise networks. At the very least, it is recommended that enterprise
networks have parity between their security policies for both networks have parity between their security policies for both
protocol versions. This section also applies to the enterprise part protocol versions. This section also applies to the enterprise part
of all ISP, i.e., the part of the network where the ISP employees are of all SP networks, i.e., the part of the network where the SP employees are
connected. connected.
Security considerations in the enterprise can be broadly categorized Security considerations in the enterprise can be broadly categorized
into two sections - External and Internal. into two sections - External and Internal.
3.1. External Security Considerations: 3.1. External Security Considerations
The external aspect deals with providing security at the edge or The external aspect deals with providing security at the edge or
perimeter of the enterprise network where it meets the service perimeter of the enterprise network where it meets the service
providers network. This is commonly achieved by enforcing a security providers network. This is commonly achieved by enforcing a security
policy either by implementing dedicated firewalls with stateful policy either by implementing dedicated firewalls with stateful
packet inspection or a router with ACLs. A common default IPv4 packet inspection or a router with ACLs. A common default IPv4
policy on firewalls that could easily be ported to IPv6 is to allow policy on firewalls that could easily be ported to IPv6 is to allow
all traffic outbound while only allowing specific traffic, such as all traffic outbound while only allowing specific traffic, such as
established sessions, inbound (see also [RFC6092]). Here are a few established sessions, inbound (see also [RFC6092]). Here are a few
more things that could enhance the default policy: more things that could enhance the default policy:
skipping to change at page 36, line 5 skipping to change at page 36, line 5
o Filter packets having an illegal IPv6 headers chain at the o Filter packets having an illegal IPv6 headers chain at the
perimeter (and if possible, inside the network as well), see perimeter (and if possible, inside the network as well), see
Section 2.2 Section 2.2
o Filter unneeded services at the perimeter o Filter unneeded services at the perimeter
o Implement ingress and egress anti-spoofing in the forwarding and o Implement ingress and egress anti-spoofing in the forwarding and
control planes control planes
o Implement appropriate rate-limiters and control-plane policers o Implement appropriate rate limiters and control-plane policers
3.2. Internal Security Considerations: 3.2. Internal Security Considerations:
The internal aspect deals with providing security inside the The internal aspect deals with providing security inside the
perimeter of the network, including the end host. The most perimeter of the network, including end hosts. The most
significant concerns here are related to Neighbor Discovery. At the significant concerns here are related to Neighbor Discovery. At the
network level, it is recommended that all security considerations network level, it is recommended that all security considerations
discussed in Section 2.3 be reviewed carefully and the discussed in Section 2.3 be reviewed carefully and the
recommendations be considered in-depth as well. recommendations be considered in-depth as well.
As mentioned in Section 2.6.2, care must be taken when running As mentioned in Section 2.6.2, care must be taken when running
automated IPv6-in-IP4 tunnels. automated IPv6-in-IP4 tunnels.
When site-to-site VPNs are used it should be kept in mind that, given When site-to-site VPNs are used it should be kept in mind that, given
the global scope of IPv6 global addresses as opposed to the common the global scope of IPv6 global addresses as opposed to the common
skipping to change at page 37, line 50 skipping to change at page 37, line 50
In contrast, in mobile environments, since the 3GPP specifications In contrast, in mobile environments, since the 3GPP specifications
allocate a /64 per device, it may be sufficient to intercept traffic 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 from the /64 rather than specific /128's (since each time the device
powers up it gets a new IID). powers up it gets a new IID).
A sample architecture which was written for informational purposes is A sample architecture which was written for informational purposes is
found in [RFC3924]. found in [RFC3924].
5. Residential Users Security Considerations 5. Residential Users Security Considerations
The IETF Homenet working group is working on how IPv6 residential The IETF Homenet working group is working on standards and guidelines for
network should be done; this obviously includes operational security IPv6 residential networks; this obviously includes operational security
considerations; but this is still work in progress. considerations; but this is still work in progress.
Some residential users have less experience and knowledge about Some residential users have less experience and knowledge about
security or networking. As most of the recent hosts, smartphones, security or networking. As most of the recent hosts (e.g., smartphones,
tablets have all IPv6 enabled by default, IPv6 security is important and tablets) all have IPv6 enabled by default, IPv6 security is important
for those users. Even with an IPv4-only ISP, those users can get for those users. Even with an IPv4-only ISP, those users can get
IPv6 Internet access with the help of Teredo tunnels. Several peer- IPv6 Internet access with the help of Teredo tunnels. Several peer-
to-peer programs support IPv6 and those programs can initiate a to-peer programs support IPv6 and those programs can initiate a
Teredo tunnel through the IPv4 residential gateway, with the Teredo tunnel through an IPv4 residential gateway, with the
consequence of making the internal host reachable from any IPv6 host consequence of making the internal host reachable from any IPv6 host
on the Internet. It is therefore recommended that all host security on the Internet. It is therefore recommended that all host security
products (including personal firewalls) are configured with a dual- products (including personal firewalls) are configured with a dual-
stack security policy. stack security policy.
If the residential CPE has IPv6 connectivity, [RFC7084] defines the If the residential CPE has IPv6 connectivity, [RFC7084] defines the
requirements of an IPv6 CPE and does not take position on the debate requirements of an IPv6 CPE and does not take position on the debate
of default IPv6 security policy as defined in [RFC6092]: of default IPv6 security policy as defined in [RFC6092]:
o outbound only: allowing all internally initiated connections and o outbound only: allowing all internally initiated connections and
skipping to change at page 38, line 36 skipping to change at page 38, line 36
o open/transparent: allowing all internally and externally initiated o open/transparent: allowing all internally and externally initiated
connections, therefore restoring the end-to-end nature of the connections, therefore restoring the end-to-end nature of the
Internet for the IPv6 traffic but having a different security Internet for the IPv6 traffic but having a different security
policy for IPv6 than for IPv4. policy for IPv6 than for IPv4.
[RFC6092] REC-49 states that a choice must be given to the user to [RFC6092] REC-49 states that a choice must be given to the user to
select one of those two policies. select one of those two policies.
There is also an alternate solution which has been deployed notably There is also an alternate solution which has been deployed notably
by Swisscom: open to all outbound and inbound connections at the by Swisscom: open to all outbound and inbound connections with the
exception of a handful of TCP and UDP ports known as vulnerable. exception of a handful of TCP and UDP ports that are known to be vulnerable.
6. Further Reading 6. Further Reading
There are several documents that describe in more details the There are several documents that describe in more details the
security of an IPv6 network; these documents are not written by the security of an IPv6 network; these documents are not written by the
IETF and some of them are dated but are listed here for your IETF and some of them are dated but are listed here for your
convenience: convenience:
1. Guidelines for the Secure Deployment of IPv6 [NIST] 1. Guidelines for the Secure Deployment of IPv6 [NIST]
skipping to change at page 39, line 23 skipping to change at page 39, line 23
Sleigh, Donal Smith, Tarko Tikan, Ole Troan, Bernie Volz (by Sleigh, Donal Smith, Tarko Tikan, Ole Troan, Bernie Volz (by
alphabetical order). alphabetical order).
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
This memo attempts to give an overview of security considerations of This memo attempts to give an overview of security considerations of
operating an IPv6 network both in an IPv6-only network and in operating an IPv6 network both for an IPv6-only networks and for networks
utilizing the most widely deployed IPv4/IPv6 coexistence strategies. utilizing the most widely deployed IPv4/IPv6 coexistence strategies.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 168 change blocks. 
233 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/