< draft-ietf-opsec-v6-24.txt.orig   draft-ietf-opsec-v6-24.txt >
skipping to change at page 1, line 28 skipping to change at page 1, line 28
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 associated This document analyzes the operational security issues associated
with several types of network and proposes technical and procedural with several types of network and proposes technical and procedural
mitigation techniques. This document is only applicable to managed mitigation techniques. This document is only applicable to managed
networks, such as enterprise building networks. The recommendations networks, such as enterprise networks. The recommendations
in this document are not applicable to residential user cases, even in this document are not applicable to residential user cases, even
in cases where a Service Provider may be managing the home gateway. in cases where a Service Provider may be managing the home gateway.
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
skipping to change at page 4, line 9 skipping to change at page 4, line 9
This document complements [RFC4942] by listing all security issues This document complements [RFC4942] by listing all security issues
when operating a network (including various transition technologies). when operating a network (including various transition technologies).
It also provides more recent operational deployment experiences where It also provides more recent operational deployment experiences where
warranted. warranted.
1.1. Applicability Statement 1.1. Applicability Statement
This document is applicable to managed networks, i.e., when the This document is applicable to managed networks, i.e., when the
network is operated by the user organization itself. Indeed, many of network is operated by the user organization itself. Indeed, many of
the recommended mitigation techniques must be configured with the the recommended mitigation techniques must be configured with
detailed knowledge of the network (which are the default router, detailed knowledge of the network (which are the default routers,
which are the switch trunk ports, etc.). This covers Service which are the switch trunk ports, etc.). This covers Service
Provider (SP), enterprise networks and some knowledgeable-home-user- Provider (SP), enterprise networksl and some knowledgeable-home-user-
managed residential network. This applicability statement especially managed residential network. This applicability statement especially
applies to Section 2.3 and Section 2.5.4. applies to Section 2.3 and Section 2.5.4.
For example, an exception to the generic recommendations of this For example, an exception to the generic recommendations of this
document is when a residential or enterprise network is multi-homed. document is when a residential or enterprise network is multi-homed.
2. Generic Security Considerations 2. Generic Security Considerations
2.1. Addressing Architecture 2.1. Addressing Architecture
skipping to change at page 4, line 39 skipping to change at page 4, line 39
could be utilized for IPv6 site renumbering and tries to cover most could be utilized for IPv6 site renumbering and tries to cover most
of the explicit issues and requirements associated with IPv6 of the explicit issues and requirements associated with IPv6
renumbering. renumbering.
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 is available, addressing plan. Because an abundance of address space is available,
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 allow 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. [RFC6177] documents some operational considerations of regions. [RFC6177] documents some operational considerations of
using different prefix size for address assignments to end sites. using different prefix sizes for address assignments at end sites.
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 need to enforce restrictions on routability of the space, e.g., due
to malicious criminal activity originating from it. Relying on PA to malicious criminal activity originating from it. Relying on PA
address may also force the use of NPTv6 and therefore augmenting the address may also force the use of NPTv6 and therefore augmenting the
complexity of the operations including the security operations. complexity of the operations including the security operations.
skipping to change at page 5, line 44 skipping to change at page 5, line 44
point links. While this practice could further reduce the attack point links. While this practice could further reduce the attack
surface of infrastructure devices, the operational disadvantages also surface of infrastructure devices, the operational disadvantages also
need to be carefully considered; see also [RFC7404]. 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 facilitates prefix for each loopback interface. This practice facilitates
configuration of Access Control List (ACL) rules to enforce a configuration of Access Control List (ACL) rules to enforce a
security policy for those loopback addresses security policy for those loopback addresses.
2.1.4. Stable Addresses 2.1.4. Stable Addresses
When considering how to assign stable addresses (either by static When considering how to assign stable addresses (either by static
configuration or by pre-provisioned DHCPv6 lease Section 2.1.6), it configuration or by pre-provisioned DHCPv6 lease Section 2.1.6), it
is necessary to take into consideration the effectiveness of is necessary to take into consideration the effectiveness of
perimeter security in a given environment. perimeter security in a given environment.
There is a trade-off between ease of operation (where some portions There is a trade-off between ease of operation (where some portions
of the IPv6 address could be easily recognizable for operational of the IPv6 address could be easily recognizable for operational
skipping to change at page 6, line 26 skipping to change at page 6, line 26
The use of well-known IPv6 addresses (such as ff02::1 for all link- The use of well-known IPv6 addresses (such as ff02::1 for all link-
local nodes) or the use of commonly repeated addresses could make it local nodes) or the use of commonly repeated addresses could make it
easy to figure out which devices are name servers, routers, or other easy to figure out which devices are name servers, routers, or other
critical devices; even a simple traceroute will expose most of the critical devices; even a simple traceroute will expose most of the
routers on a path. There are many scanning techniques possible and routers on a path. There are many scanning techniques possible and
operators should not rely on the 'impossible to find because my operators should not rely on the 'impossible to find because my
address is random' paradigm (a.k.a. "security by obscurity"), even if address is random' paradigm (a.k.a. "security by obscurity"), even if
it is common practice to have the stable addresses randomly it is common practice to have the stable addresses randomly
distributed across /64 subnets and to always use DNS (as IPv6 distributed across /64 subnets and to always use DNS (as IPv6
addresses are hard to remember for the human brains). addresses are hard for human brains to remember).
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 enforcement of perimeter rules an added benefit, it does not preclude enforcement of perimeter rules
and that stable addresses follow some logical allocation scheme for and that stable addresses follow some logical allocation scheme for
ease of operation (as simplicity always helps security). ease of operation (as simplicity always helps security).
Typical deployments will have a mix of stable and non-stable Typical deployments will have a mix of stable and non-stable
addresses; the stable addresses being either predicatable (e.g., ::25 addresses; the stable addresses being either predicatable (e.g., ::25
for a mail server) or obfuscated (i.e., appearing as a random 64-bit for a mail server) or obfuscated (i.e., appearing as a random 64-bit
number). number).
skipping to change at page 7, line 51 skipping to change at page 7, line 51
2.1.6. DHCP and DNS Considerations 2.1.6. DHCP and DNS Considerations
Even if the use of DHCP is not mandated by [RFC8504], some Even if the use of DHCP is not mandated by [RFC8504], some
environments use DHCPv6 to provision addresses and other parameters environments use DHCPv6 to provision addresses and other parameters
in order to ensure auditability and traceability (see in order to ensure auditability and traceability (see
Section 2.6.1.5) for the limitations of DHCPv6 for auditability. Section 2.6.1.5) for the limitations of DHCPv6 for auditability.
A main security concern is the ability to detect and counteract rogue A main security concern is the ability to detect and counteract rogue
DHCP servers (Section 2.3.3). It must be noted that as opposed to DHCP servers (Section 2.3.3). It must be noted that as opposed to
DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For
DHCPv4, the lease is bond to the 'client identifier', which may DHCPv4, the lease is bound to the 'client identifier', which may
contain a hardware address, or it may contain another type of contain a hardware address, or it may contain another type of
identifier, such as a DNS name. For DHCPv6, the lease is bound to identifier, such as a DNS name. For DHCPv6, the lease is bound to
the client DHCP Unique ID (DUID) which is also not always bound to the client DHCP Unique ID (DUID) which is also not always bound to
the client link-layer address. [RFC7824] describes the privacy the client link-layer address. [RFC7824] describes the privacy
issues associated with the use of DHCPv6 by Internet users. The issues associated with the use of DHCPv6 by Internet users. The
anonymity profiles [RFC7844] are designed for clients that wish to anonymity profiles [RFC7844] are designed for clients that wish to
remain anonymous to the visited network. [RFC7707] recommends that remain anonymous to the visited network. [RFC7707] recommends that
DHCPv6 servers issue addresses randomly from a large pool. DHCPv6 servers issue addresses randomly from a large pool.
While there are no fundamental differences with IPv4 and IPv6 DNS While there are no fundamental differences with IPv4 and IPv6 DNS
skipping to change at page 8, line 32 skipping to change at page 8, line 32
[RFC8273] especially in a shared environment. This allows for easier [RFC8273] especially in a shared environment. This allows for easier
user attribution (typically based on the host MAC address) as its /64 user attribution (typically based on the host MAC address) as its /64
prefix is stable even if applications within the host can change prefix is stable even if applications within the host can change
their IPv6 address within this /64 prefix. their IPv6 address within 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 into more detail on the privacy globally. [RFC7721] goes into more detail on the privacy
considerations for IPv6 addresses by comparing the manually considerations for IPv6 addresses by comparing manually
configured IPv6 address, DHCPv6 or SLAAC. configured IPv6 addresses, DHCPv6, and SLAAC.
2.2. Extension Headers 2.2. Extension Headers
Extension headers are an important difference between IPv4 and IPv6. Extension headers are an important difference between IPv4 and IPv6.
In IPv4-based packets, it's trivial to find the upper layer protocol In IPv4-based packets, it's trivial to find the upper-layer protocol
type and protocol header, while in IPv6 it is more complex since the type and protocol header, while in IPv6 it is more complex since the
extension header chain must be parsed completely (even if not extension header chain must be parsed completely (even if not
processed) in order to find the upper layer protocol header. IANA processed) in order to find the upper-layer protocol header. 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].
Extension headers have also become a very controversial topic since Extension headers have also become a very controversial topic since
forwarding nodes that discard packets containing extension headers forwarding nodes that discard packets containing extension headers
are known to cause connectivity failures and deployment problems are known to cause connectivity failures and deployment problems
[RFC7872]. Understanding the role of varying extension headers is [RFC7872]. Understanding the role of varying extension headers is
important and this section enumerates the ones that need careful important and this section enumerates the ones that need careful
consideration. consideration.
skipping to change at page 9, line 32 skipping to change at page 9, line 32
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, which support a non-recommended order of headers (such as 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 options contained in multiple routing headers). The same applies for options contained in
the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]). the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]).
In some cases, it has led to nodes crashing when receiving or In some cases, it has led to nodes crashing when receiving or
forwarding wrongly formatted packets. forwarding wrongly formatted 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 the maximum 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
In the previous IPv6 specification [RFC2460], the hop-by-hop options In the previous IPv6 specification [RFC2460], the hop-by-hop options
header, when present in an IPv6 packet, forced all nodes to inspect header, when present in an IPv6 packet, forced all nodes to inspect
and possibly process this header. This enabled denial-of-service and possibly process this header. This enabled denial-of-service
attacks as most, if not all, routers can not process this kind of attacks as most, if not all, routers cannot process this type of
packet in hardware but have to process this packet in software hence packet in hardware but have to process these packets in software and
competing with other software tasks such as handling the control and hence compete with other software tasks, such as, control and management
management planes. plane 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 explicitly by-hop options headers by intermediate routers explicitly
configurable. configurable.
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-
skipping to change at page 10, line 29 skipping to change at page 10, line 29
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
Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented
NDP packets. [RFC7113] describes how the RA-guard function described NDP packets. [RFC7113] describes how the RA-guard function described
in [RFC6105] should behave in the presence of fragmented RA packets. in [RFC6105] should behave 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. But IPsec is no more required for normal IPv6 nodes: in security. But IPsec is no longer required for normal IPv6 nodes: in
the updated IPv6 Nodes Requirement standard <xref target="RFC8504"/> the updated IPv6 Nodes Requirement standard [RFC8504],
IPsec is a 'SHOULD' and not a 'MUST' implement. IPsec is a 'SHOULD' and not a 'MUST' implement.
2.3. Link-Layer Security 2.3. Link-Layer Security
IPv6 relies heavily on NDP [RFC4861] to perform a variety of link IPv6 relies heavily on NDP [RFC4861] to perform a variety of link
operations such as discovering other nodes on the link, resolving operations such as discovering other nodes on the link, resolving
their link-layer addresses, and finding routers on the link. If not their link-layer addresses, and finding routers on the link. If not
secured, NDP is vulnerable to various attacks such as router/neighbor secured, NDP is vulnerable to various attacks such as router/neighbor
message spoofing, redirect attacks, Duplicate Address Detection (DAD) message spoofing, redirect attacks, Duplicate Address Detection (DAD)
DoS attacks, etc. Many of these security threats to NDP have been DoS attacks, etc. Many of these security threats to NDP have been
documented in IPv6 ND Trust Models and Threats [RFC3756] and in documented in IPv6 ND Trust Models and Threats [RFC3756] and in
[RFC6583]. [RFC6583].
NDP has even issues when the attacker is off-link see the section NDP even has issues when the attacker is off-link, see the section
below Section 2.3.1; but, most of the issues are only when the below Section 2.3.1; but, most of the issues are only when the
attacker is on the same link. attacker is on the same link.
2.3.1. Neighbor Solicitation Rate Limiting 2.3.1. Neighbor Solicitation Rate-Limiting
Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial-
of service (DoS) attacks; for example, when a router is forced to of-service (DoS) attacks; for example, when a router is forced to
perform address resolution for a large number of unassigned perform address resolution for a large number of unassigned
addresses, i.e., a neighbor cache exhaustion attack. This can keep addresses, i.e., a neighbor cache exhaustion attack. This can keep
new devices from joining the network or render the last hop router new devices from joining the network or render the last-hop router
ineffective due to high CPU usage. Easy mitigative steps include ineffective due to high CPU usage. Easy mitigative steps include
rate limiting Neighbor Solicitations, restricting the amount of state rate-limiting Neighbor Solicitations, restricting the amount of state
reserved for unresolved solicitations, and clever cache/timer reserved for unresolved solicitations, and clever cache/timer
management. management.
[RFC6583] discusses the potential for off-link DoS in detail and [RFC6583] discusses the potential for off-link DoS in detail and
suggests implementation improvements and operational mitigation suggests implementation improvements and operational mitigation
techniques that may be used to mitigate or alleviate the impact of techniques that may be used to mitigate or alleviate the impact of
such attacks. Here are some feasible mitigation options that can be such attacks. Here are some feasible mitigation options that can be
employed by network operators today: employed by network operators today:
o Ingress filtering of unused addresses by ACL. These require o Ingress filtering of unused addresses by ACL. These require
stable configuration of the addresses; for example, allocating the stable configuration of the addresses; for example, allocating the
addresses out of a /120 and using a specific ACL to only allow addresses out of a /120 and using a specific ACL to only allow
traffic to this /120 (of course, the actual hosts are configured traffic to this /120 (of course, the actual hosts are configured
with a /64 prefix for the link). with a /64 prefix for the link).
o Tuning of NDP process (where supported). o Tuning of NDP process (where supported).
o Using /127 on point-to-point link per [RFC6164]. o Using /127 on point-to-point link per [RFC6164].
o Using link-local addresses only on links where there are only o Using link-local addresses only on links where there are only
routers see [RFC7404] routers, see [RFC7404]
2.3.2. Router and Neighbor Advertisements Filtering 2.3.2. Router and Neighbor Advertisements Filtering
2.3.2.1. Router Advertisement Filtering 2.3.2.1. Router Advertisement Filtering
Router Advertisement spoofing is a well-known on-link attack vector Router Advertisement spoofing is a well-known on-link attack vector
and has been extensively documented. The presence of rogue RAs, and has been extensively documented. The presence of rogue RAs,
either unintentional or malicious, can cause partial or complete either unintentional or malicious, can cause partial or complete
failure of operation of hosts on an IPv6 link. For example, a host failure of operation of hosts on an IPv6 link. For example, a host
can select an incorrect router address which can be used as on-path can select an incorrect router address which can be used as on-path
attack or can assume wrong prefixes to be used for SLAAC. [RFC6104] attack or can assume wrong prefixes to be used for SLAAC. [RFC6104]
summarizes the scenarios in which rogue RAs may be observed and summarizes the scenarios in which rogue RAs may be observed and
presents a list of possible solutions to the problem. [RFC6105] (RA- presents a list of possible solutions to the problem. [RFC6105] (RA-
Guard) describes a solution framework for the rogue RA problem where Guard) describes a solution framework for the rogue RA problem where
network segments are designed around switching devices that are network segments are designed around switching devices that are
capable of identifying invalid RAs and blocking them before the capable of identifying invalid RAs and blocking them before the
attack packets actually reach the target nodes. attack packets actually 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. Attacker mitigation technique is introduced by IPv6 fragmentation. Attackers
can conceal their attack by fragmenting their packets into multiple can conceal their attack by fragmenting their packets into multiple
fragments such that the switching device that is responsible for fragments such that the switching device that is responsible for
blocking invalid RAs cannot find all the necessary information to blocking invalid RAs cannot find all the necessary information to
perform packet filtering of 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
skipping to change at page 12, line 29 skipping to change at page 12, line 29
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
addresses. addresses.
2.3.2.3. Host Isolation 2.3.2.3. Host Isolation
Isolating hosts for the NDP traffic canbe done by using a /64 per Isolating hosts for the NDP traffic can be done by using a /64 per
host Section 2.1.7 as NDP is only relevant within a /64 on-link host as NDP is only relevant within a /64 on-link prefix, refer to
prefix; 3GPP Section 2.3.4 uses a similar mechanism. Section 2.7.1. 3GPP Section 2.3.4 uses a similar mechanism.
A more drastic technique to prevent all NDP attacks is based on A more drastic technique to prevent all NDP attacks is based on
isolation of all hosts with specific configurations. Hosts (i.e., isolation of all hosts with specific configurations. Hosts (i.e.,
all nodes that are not routers) are unable to send data-link layer all nodes that are not routers) are unable to send data-link layer
frames to other hosts, therefore, no host-to-host attacks can happen. frames to other hosts, therefore, no host-to-host attacks can happen.
This specific setup can be established on some switches or Wi-Fi This specific setup can be established on some switches or Wi-Fi
access points. Of course, this is not always feasible when hosts access points. Of course, this is not always feasible when hosts
need to communicate with other hosts. need to communicate directly with other hosts.
2.3.2.4. NDP Recommendations 2.3.2.4. NDP Recommendations
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 recommendation also applies when DHCPv6 is used as RA hosts. This recommendation also applies when DHCPv6 is used as RAs
are used to discover the default router(s) and for on-link prefix are used to discover the default router(s) and for on-link prefix
determination. This line of defense is most effective when determination. This line of defense is most effective when
incomplete fragments are dropped by routers and switches as described incomplete fragments are dropped by routers and switches as described
in Section 2.2.3. The generated log should also be analyzed to in Section 2.2.3. The generated log should also be analyzed to
identify and act on violations. Network operators should be aware identify and act on violations. Network operators should be aware
that RA-Guard and SAVI do not work or could even be harmful in that RA-Guard and SAVI do not work or could even be harmful in
specific network configurations (notably when there could be multiple specific network configurations (notably when there could be multiple
routers). Only trivial cases (e.g., a Wi-Fi network having the routers). Only trivial cases (e.g., a Wi-Fi network having the
routers on the uplink interfaces of the As) should have RA-guard and routers on the uplink interfaces of the As) should have RA-guard and
SAVI enabled by default. SAVI enabled by default.
2.3.3. Securing DHCP 2.3.3. Securing DHCP
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described
in [RFC8415], enables DHCP servers to pass configuration parameters in [RFC8415], enables DHCP servers to pass configuration parameters
such as IPv6 network addresses and other configuration information to such as IPv6 network addresses and other configuration information to
IPv6 nodes such as an hostile recursive DNS server. DHCP plays an IPv6 nodes such as a hostile recursive DNS server. DHCP plays an
important role in most large networks by providing robust stateful important role in most large networks by providing robust stateful
configuration in the context of automated system provisioning. configuration in the context of 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 clients to cause a denial incorrect configuration information to the clients to cause a denial-
of service attack or to mount on path attack. While unintentional, a of-service attack or to mount on path attack. While unintentional, a
misconfigured DHCP server can have the same impact. Additional misconfigured DHCP server can have the same impact. Additional
threats against DHCP are discussed in the security considerations threats against DHCP are discussed in the security considerations
section of [RFC8415]. section of [RFC8415].
DHCPv6-Shield, [RFC7610], specifies a mechanism for protecting DHCPv6-Shield, [RFC7610], 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;
i.e., the administrator specifies the interfaces connected to DHCPv6 i.e., the administrator specifies the interfaces connected to DHCPv6
servers. However, 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.
skipping to change at page 14, line 16 skipping to change at page 14, line 16
mobile host's address). mobile host's 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 networks, DHCPv6 and DHCP-PD are also used.
2.3.5. Impact of Multicast Traffic 2.3.5. Impact of Multicast Traffic
IPv6 uses multicast extensively for signaling messages on the local IPv6 uses multicast extensively for signaling messages on the local
link to avoid broadcast messages for on-the-wire efficiency. link to avoid broadcast messages for on-the-wire efficiency.
The use of multicast has some side effects on wireless networks, such The use of multicast has some side effects on wireless networks, such
as a negative impact on battery life of smartphones and other as a negative impact on battery life of smartphones and other
battery-operated devices that are connected to such networks. battery-operated devices that are connected to such networks.
[RFC7772], [RFC6775] (for specific wireless networks) are discussing [RFC7772], [RFC6775] (for specific wireless networks) discuss
methods to rate limit RAs and other ND messages on wireless networks methods to rate-limit RAs and other ND messages on wireless networks
in order to address this issue. in order to address this issue.
The use of link-layer multicast addresses (e.g., ff02::1 for the all The use of link-layer multicast addresses (e.g., ff02::1 for the all
nodes link-local multicast address) could also be mis-used for an nodes link-local multicast address) could also be misused for an
amplification attack. Image, a hostile node sending an ICMPv6 amplification attack. Imagine, a hostile node sending an ICMPv6
ECHO_REQUEST to ff02::1 with a spoofed source address, then, all ECHO_REQUEST to ff02::1 with a spoofed source address, then, all
link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the
source address. This could be a DoS for the victim. This attack is source address. This could be a DoS attack for the address owner.
purely local to the layer-2 network as packets with a link-local This attack is purely local to the layer-2 network as packets with
destination are never forwarded by an IPv6 router. a link-local destination are never forwarded by an IPv6 router.
This is the reason why large Wi-Fi network deployments limit the use This is the reason why large Wi-Fi network deployments limit the use
of link-layer multicast either from or to the uplink of the Wi-Fi of link-layer multicast either from or to the uplink of the Wi-Fi
access point; i.e., Wi-Fi stations cannot send link-local multicast access point; i.e., Wi-Fi stations cannot send link-local multicast
to their direct neighboring Wi-Fi stations. to their direct neighboring Wi-Fi stations.
2.3.6. SeND and CGA 2.3.6. 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
skipping to change at page 15, line 32 skipping to change at page 15, line 32
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 widely specifications, CGA and SeND do not have support from widely
used end points; hence, their usefulness is limited and should not be deployed IPv6 devices; hence, their usefulness is limited and should not be
relied upon. relied upon.
2.4. Control Plane Security 2.4. Control Plane Security
[RFC6192] defines the router control plane and provides detailed [RFC6192] defines the router control plane and provides detailed
guidance to secure it for IPv4 and IPv6 networks. This definition is guidance to secure it for IPv4 and IPv6 networks. 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).
skipping to change at page 16, line 33 skipping to change at page 16, line 33
plane processor is then unable to process valid control packets and plane processor is then unable to process valid control packets and
the router can lose OSPF or BGP adjacencies which can cause a severe the router can lose OSPF or BGP adjacencies which can cause a severe
network disruption. network disruption.
[RFC6192] provides detailed guidance to protect the router control [RFC6192] provides detailed guidance to protect the router control
plane in IPv6 networks. The rest of this section contains simplified plane in IPv6 networks. The rest of this section contains simplified
guidance. guidance.
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 packets 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 frequency of Dijsktra the Dijkstra algorithm, therefore, the frequency of Dijsktra
calculations 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, RIPng,
extension Neighbor Discovery and ICMP and by extension, NDP and ICMP
o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc
o Packet exceptions: normal data packets which requires a specific o Packet exceptions: normal data packets which require a specific
processing such as generating a packet-too-big ICMP message or processing such as generating a packet-too-big ICMP message or
processing the hop-by-hop options header. 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, RIPng, NDP, ICMP.
An ingress ACL to be applied on all the router interfaces for packets An ingress ACL to be applied on all the router interfaces for packets
to be processed by the RP should be configured so as to: to be processed by the RP should be configured to:
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
(except for OSPFv3 virtual links) (except for OSPFv3 virtual links)
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 that are unable to parse the IPsec
ESP or AH extension headers. ESP or AH extension headers during ACL classification.
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, RESTCONF, NETCONF, gRPC, syslog, NTP, This class includes: SSH, SNMP, RESTCONF, NETCONF, gRPC, syslog, NTP,
etc. 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 for packets destined features of the platform) should be configured for packets destined
to the RP such as: to the RP 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); others 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 Network Operations Center (NOC), then the ACL should permit
NOC prefix. TCP port 22 packets only from the NOC prefix.
Rate limiting of the valid packets should be done. The exact Rate-limiting of valid packets should be done. The exact
configuration will depend on the available resources of the router. configuration will depend on the available router resources.
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 (required to packet cannot be forwarded because it is too large (required to
discover the Path MTU); discover the Path MTU);
skipping to change at page 18, line 40 skipping to change at page 18, line 40
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] highlight 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 rate-limit
rate of those packet exceptions forwarded to the RP, this means that those packet exceptions that are forwarded to the RP, this means that
some data plane packets will be dropped without an ICMP message sent some data plane packets will be dropped without an ICMP message sent
to the source which may delay Path MTU discovery and cause drops. 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 rate-limit the generation of ICMP
messages. This is important both to preserve RP resources and also messages. This is important both to preserve RP resources and also
to prevent an amplification attack using the router as a reflector. to prevent an amplification attack using the router as a reflector.
It is worth noting that some platforms implement this rate limiting It is worth noting that some platforms implement this rate-limiting
in hardware. Of course, a consequence of not generating an ICMP in hardware. Of course, a consequence of not generating an ICMP
message will break some IPv6 mechanisms such as Path MTU discovery or message will break some IPv6 mechanisms such as Path MTU discovery or
a simple traceroute. a simple traceroute.
2.5. Routing Security 2.5. Routing Security
Preamble: IPv6 routing security is congruent with IPv4 routing Preamble: IPv6 routing security is congruent with IPv4 routing
security at the exception of OSPv3 neighbor authentication (see security with the exception of OSPv3 neighbor authentication (see
Section 2.5.2). Section 2.5.2).
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
2. Securing routing updates between peers 2. Securing routing updates between peers
3. Route filtering 3. Route filtering
skipping to change at page 20, line 14 skipping to change at page 20, line 14
[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
outages. There have been instances where any re-keying cause outages outages. There have been instances where any re-keying causes outages
and therefore, the tradeoff between utilizing this functionality and therefore, the tradeoff between utilizing this functionality
needs to be weighed against the protection it provides. needs to be weighed against the protection it provides.
2.5.3. Securing Routing Updates 2.5.3. Securing Routing Updates
IPv6 initially mandated the provisioning of IPsec capability in all IPv6 initially mandated the provisioning of IPsec capability in all
nodes. However, in the updated IPv6 Nodes Requirement standard nodes. However, in the updated IPv6 Nodes Requirement standard
[RFC8504] is a 'SHOULD' and not a 'MUST' implement. Theoretically it [RFC8504] is a 'SHOULD' and not a 'MUST' implement. Theoretically, it
is possible that communication between two IPv6 nodes, especially is possible that communication between two IPv6 nodes, especially
routers exchanging routing information be encrypted using IPsec. In routers exchanging routing information, be encrypted using IPsec. In
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. hardware and software limitations of the various platforms deployed.
2.5.4. Route Filtering 2.5.4. 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
skipping to change at page 20, line 50 skipping to change at page 20, line 50
[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 formally validate the origin ASs of BGP announcements in
[RFC8210]. [RFC8210].
Some good guidance can be found at [RFC7454]. Some good guidance can be found at [RFC7454].
A valid routing table can also be used apply network ingress A valid routing table can also be used to apply network ingress
filtering (see [RFC2827]). filtering (see [RFC2827]).
2.6. Logging/Monitoring 2.6. Logging/Monitoring
In order to perform forensic research in the cases of a security In order to perform forensic research in the cases of a security
incidents or detection abnormal behavior, network operators should incident or detecting abnormal behavior, network operators should
log multiple pieces of information in some cases this requires a log multiple pieces of information. In some cases, this requires a
frequent poll of devices via a Network Management Station. frequent poll of devices via a Network Management Station.
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;
skipping to change at page 22, line 29 skipping to change at page 22, line 29
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
canonical format [RFC5952] for IPv6 addresses in all possible cases. canonical format [RFC5952] for IPv6 addresses in all possible cases.
If the existing application cannot log under the canonical format, If the existing application cannot log using the canonical format,
then it is recommended to use an external program in order to then it is recommended to use an external post-procesing program in order to
canonicalize all IPv6 addresses. canonicalize all IPv6 addresses.
For example, this perl script can be used: For example, this perl script can be used:
<CODE BEGINS> <CODE BEGINS>
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict ; use strict ;
use warnings ; use warnings ;
use Socket ; use Socket ;
skipping to change at page 23, line 40 skipping to change at page 23, line 40
<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.
The IP version is the ipVersion element defined in [IANA-IPFIX]. The IP version is the ipVersion element defined in [IANA-IPFIX].
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, and
sourceMacAddress. sourceMacAddress.
skipping to change at page 24, line 18 skipping to change at page 24, line 18
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.
There are also YANG modules about the two IP addresses families and There are also YANG modules relating to the two IP addresses families and
can be used with [RFC6241] and [RFC8040]. This memo recommends the can be used with [RFC6241] and [RFC8040]. This memo recommends the
use of: use of:
o interfaces-state/interface/statistics from ietf- o interfaces-state/interface/statistics from ietf-
interfaces@2018-02-20.yang [RFC8343] which contains counters for interfaces@2018-02-20.yang [RFC8343] which contains counters for
interface . interface .
o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the
content of the Neighbor cache, i.e., the mapping between IPv6 and content of the Neighbor cache, i.e., the mapping between IPv6 and
data-link layer addresses. data-link layer addresses.
skipping to change at page 24, line 44 skipping to change at page 24, line 44
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] and [RFC8040] to o using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to
collect the operational state of the neighbor cache; collect the 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 (CLI) 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. This could be quite frequently IPv6 address appears on the network. This could be quite frequently
with privacy extension addresses [RFC4941] or when they are removed with privacy extension addresses [RFC4941] or when they are removed
when the state goes from UNREACH to removed (the default time for a when 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 host using Windows 7). This means that the content 38 seconds for a host using Windows 7). This means that the content
of the neighbor cache must periodically be fetched at an interval of the neighbor cache must periodically be fetched at an interval
which does not exhaust the router resources and still provides which does not exhaust the router resources and still provides
valuable information (suggested value is 30 seconds but to be checked valuable information (suggested value is 30 seconds but this should be
in the actual setup) and stored for later use. verified in the actual deployment) 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 the 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 is commonly IPv6 addresses/prefixes and data-link layer addresses as is commonly
used in IPv4 networking . used in IPv4 networking.
It is not so easy in the IPv6 networks because not all nodes will use It is not so easy in the 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 information, or even an opaque number which is useless for
operational security. Moreover, when the DUID is based on the data- operational security. Moreover, when the DUID is based on the data-
link address, this address can be of any client interface (such as link address, this address can be of any client interface (such as
the wireless interface while the client actually uses its wired the wireless interface while the client actually uses its wired
interface to connect to the network). interface to connect to the network).
If a lightweight DHCP relay agent [RFC6221] is used in a layer-2 If a lightweight DHCP relay agent [RFC6221] is used in a layer-2
switche, then the DHCP servers also receives the Interface-ID switch, then the DHCP servers 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
on which the switch 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 for IPv4 In short, the DHCPv6 lease file is less interesting than for IPv4
networks. If possible, it is recommended to use DHCPv6 servers that networks. If possible, it is recommended to use DHCPv6 servers that
keep the relayed data-link layer address in addition to the DUID in keep the relayed data-link layer address in addition to the DUID in
skipping to change at page 26, line 45 skipping to change at page 26, line 45
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. 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 the has control over all resources, the source of information can be the
neighbor cache, or, if not found, the 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).
skipping to change at page 28, line 16 skipping to change at page 28, line 16
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 nodes that never transmitted packets traversing the discover silent nodes that never transmitted packets traversing the
the IPFIX target router. Also, it must be noted that link-local the IPFIX target router. Also, it must be noted that link-local
addresses will never be discovered by this means. addresses will never be discovered by 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 that works only for local network, consists in sending a Another way that works only for a local network, consists of 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
addresses all IPv6 nodes on the network. All nodes should reply to addresses all IPv6 nodes on the network. All nodes should reply to
this ECHO_REQUEST per [RFC4443]. this 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
skipping to change at page 29, line 20 skipping to change at page 29, line 20
2.6.2.4. Abnormal Behavior Detection 2.6.2.4. Abnormal Behavior Detection
Abnormal behavior (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 o Sudden increase of traffic detected by interface counter (SNMP) or
by aggregated traffic from IPFIX records [RFC7012]. by aggregated traffic from IPFIX records [RFC7012].
o Change in traffic pattern (number of connections per second, o Change in traffic pattern (number of connections per second,
number of connection per host...) with the use of IPFIX [RFC7012]. number of connection per host...) observed 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 the same IPv6 The fact that there are multiple ways to express the same IPv6
address in a character string renders the use of filters mandatory address in a character string renders the use of filters mandatory
skipping to change at page 29, line 46 skipping to change at page 29, line 46
mode, 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 termination 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 attendant complexities.
From an operational security perspective, this now means that the From an operational security perspective, this now means that the
network operator has twice the exposure. One needs to think about network operator has twice the exposure. One needs to think about
protecting both protocols now. At a minimum, the IPv6 portion of a protecting both protocols now. At a minimum, the IPv6 portion of a
dual-stacked network should be consistent with IPv4 from a security dual-stacked network should be consistent with IPv4 from a security
policy point of view. Typically, the following methods are employed policy point of view. Typically, the following methods are employed
to protect IPv4 networks at the edge or security perimeter: to protect IPv4 networks at the edge or security perimeter:
o ACLs to permit or deny traffic; o ACLs to permit or deny traffic;
skipping to change at page 31, line 9 skipping to change at page 31, line 9
information (for example the tunnel endpoints and the information (for example the tunnel endpoints and the
encapsulation protocol) can forge a packet which looks like a encapsulation protocol) can forge a packet which looks like a
legit and valid encapsulated packet that will gladly be accepted legit and valid encapsulated packet that will gladly be accepted
by the destination tunnel endpoint, this is a specific case of by the destination tunnel endpoint, this is a specific case of
spoofing; 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 on-path attack can also be with the absence of authentication, an on-path attack can also be
mounted; 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 the 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 a malevolent of the tunnel, then it may neither inspect nor detect malevolent
IPv6 traffic transmitted over the tunnel. IPv6 traffic 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 (Section 2.7.2.8) tunnels.
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
[RFC4301] in transport mode and protecting the encapsulated IPv4 [RFC4301] in transport mode and protecting the encapsulated IPv4
packets is recommended for those tunnels. Alternatively, IPsec in packets is recommended for those tunnels. Alternatively, IPsec in
tunnel mode can be used to transport IPv6 traffic over a non-trusted tunnel mode can be used to transport IPv6 traffic over a non-trusted
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 a 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 [RFC6324] and [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 few security issues other than 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 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 VPNs as described in [RFC4364], the
security properties of these networks are also similar to those security properties of these networks are also similar to those
described in [RFC4381]. It relies on: described in [RFC4381]. They rely 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
as these addresses cannot be reached from outside of the link, the as these addresses cannot be reached from outside of the link, the
security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP security of 6PE and 6VPE is even higher than an IPv4 BGP/MPLS IP
VPN. VPN.
LDPv6 itself does not induce new risks, see also [RFC7552]. LDPv6 itself does not induce new risks, see also [RFC7552].
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 as it includes IPv4 NAPT. further (Section 2.7.3.3) in this document as it includes IPv4 NAPT.
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) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access and Port (MAP) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access
network is purely an IPv6 network and MAP protocols are used to network is purely an IPv6 network and MAP protocols are used to
connect IPv4 hosts on the subscriber network access to IPv4 hosts on provide IPv4 hosts on the subscriber network access to IPv4 hosts on
the Internet. The subscriber router does stateful operations in the Internet. The subscriber router does stateful operations in
order to map all internal IPv4 addresses and layer-4 ports to the order to map all internal IPv4 addresses and layer-4 ports to the
IPv4 address and the set of layer-4 ports received through MAP IPv4 address and the set of layer-4 ports received through MAP
configuration process. The SP equipment always does stateless configuration process. The SP equipment always does stateless
operations (either decapsulation or stateless translation). operations (either decapsulation or stateless translation).
Therefore, as opposed to Section 2.7.3.3 there is no state-exhaustion Therefore, as opposed to Section 2.7.3.3, there is no state-exhaustion
DoS attack against the SP equipment because there is no state and DoS attack against the SP equipment because there is no state and
there is no operation caused by a new layer-4 connection (no logging there is no operation caused by a new layer-4 connection (no logging
operation). 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.
skipping to change at page 34, line 43 skipping to change at page 34, line 43
most environments, 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 and by default were running updated operating systems may be present and by default were running
Teredo. 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 with each individual mechanism. For the
most part, they specifically mention interference with IPsec or most part, they specifically mention interference with IPsec or
DNSSEC deployments, how to mitigate spoofed traffic, and what some DNSSEC deployments, how to mitigate spoofed traffic, and what some
effective filtering strategies may be. effective 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
networks. networks.
2.7.3.1. Carrier-Grade NAT (CGN) 2.7.3.1. Carrier-Grade NAT (CGN)
skipping to change at page 35, line 45 skipping to change at page 35, line 45
some solutions to enforce policies on misbehaving nodes when address some solutions to enforce policies on misbehaving nodes when address
sharing is used. [RFC7857] also updates the NAT behavioral sharing is used. [RFC7857] also updates the NAT behavioral
requirements. requirements.
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 has similar security aspects but 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.
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 an IPv4-only server over an IPv6-only network. 464XLAT access to an IPv4-only server over an IPv6-only network. 464XLAT
shares the same security considerations as NAT64 and DNS64, however shares the same security considerations as NAT64 and DNS64, however
it can be used without DNS64, avoiding the DNSSEC implications. it can 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
IPv4 NAPT. IPv4 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] and section 2 of [RFC7785] describe important Section 11 of [RFC6333] and section 2 of [RFC7785] describe important
security issues associated with this technology. security issues associated with this technology.
2.8. General Device Hardening 2.8. General Device Hardening
With almost all devices being IPv6 enabled by default and with many With almost all devices being IPv6 enabled by default and with many
end points having IPv6 connectivity to the Internet, it is critical end points having IPv6 connectivity to the Internet, it is critical
to also harden those devices against attacks over IPv6. to also harden those devices against attacks over IPv6.
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 device, be it an individual host, router,
firewall, load-balancer, server, etc. device. firewall, load-balancer, server, etc.
o Restrict device access 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.)
o Use host firewall capabilities to control traffic that gets o Use host firewall capabilities to control traffic that gets
processed by upper layer protocols processed by upper-layer protocols
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 [RFC7381] generally have robust network security policies Enterprises [RFC7381] generally have robust network security policies
in place to protect existing IPv4 networks. These policies have been in place 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 SP networs, i.e., the part of the network where the SP of all SP networs, i.e., the part of the network where the SP
employees are connected. employees are 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 groups - 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 provider's 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]). Section 3.2 of established sessions, inbound (see also [RFC6092]). Section 3.2 of
[RFC7381] also provides similar recommendations. [RFC7381] also provides similar recommendations.
Here are a few more things that could enhance the default policy: Here are a few more things that could enhance the default policy:
o Filter internal-use IPv6 addresses at the perimeter this will also o Filter internal-use IPv6 addresses at the perimeter this will also
skipping to change at page 38, line 14 skipping to change at page 38, line 14
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, see [RFC2827] and [RFC3704] control planes, see [RFC2827] and [RFC3704]
o Implement appropriate rate limiters and control-plane policers o Implement appropriate rate-limiters and control-plane policers
Having global IPv6 address on all the enterprises sites is different Having global IPv6 address on all the enterprises sites is different
than in IPv4 where [RFC1918] addresses are used internally and not than in IPv4 where [RFC1918] addresses are used internally and not
routed usually over the Internet. [RFC7359] and [WEBER_VPN] explain usually routed over the Internet. [RFC7359] and [WEBER_VPN] explain
that without careful design, there could be IPv6 leakages out of that without careful design, there could be IPv6 leakages out of
layer-3 VPN. layer-3 VPN.
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 end hosts. Internal networks of perimeter of the network, including end hosts. Internal networks of
enterprises are often different: University campus, wireless guest enterprises are often different: University campus, wireless guest
access, ... so there is no "one size fits all" recommendations. access, ... so there is no "one size fits all" recommendation.
The most significant concerns here are related to Neighbor Discovery. The most significant concerns here are related to Neighbor Discovery.
At the network level, it is recommended that all security At the network level, it is recommended that all security
considerations discussed in Section 2.3 be reviewed carefully and the considerations discussed in Section 2.3 be reviewed carefully and the
recommendations be considered in-depth as well. Section 4.1 of recommendations be considered in-depth as well. Section 4.1 of
[RFC7381] also provides some recommendations. [RFC7381] also provides some recommendations.
As mentioned in Section 2.7.2, care must be taken when running As mentioned in Section 2.7.2, care must be taken when running
automated IPv6-in-IPv4 tunnels. automated IPv6-in-IPv4 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
use of IPv4 private address space [RFC1918], sites might be able to use of IPv4 private address space [RFC1918], sites might be able to
communicate with each other over the Internet even when the VPN communicate with each other over the Internet even when the VPN
mechanism is not available and hence no traffic encryption is mechanism is not available and hence no traffic encryption is
performed and traffic could be injected from the Internet into the performed and traffic could be injected from the Internet into the
site, see [WEBER_VPN]. It is recommended to filter at the Internet site, see [WEBER_VPN]. It is recommended to filter at Internet
connection(s) packets having a source or destination address connection(s) packets having a source or destination address
belonging to the site internal prefix(es); this should be done for belonging to the site internal prefix(es); this should be done for
ingress and egress traffic. ingress and egress traffic.
Hosts need to be hardened directly through security policy to protect Hosts need to be hardened directly through security policy to protect
against security threats. The host firewall default capabilities against security threats. The host firewall default capabilities
have to be clearly understood. In some cases, 3rd party firewalls have to be clearly understood. In some cases, 3rd party firewalls
have no IPv6 support whereas the native firewall installed by default have no IPv6 support whereas the native firewall installed by default
has IPv6 support. General device hardening guidelines are provided has IPv6 support. General device hardening guidelines are provided
in Section 2.8. in Section 2.8.
skipping to change at page 39, line 31 skipping to change at page 39, line 31
o TTL security (which becomes hop-limit security in IPv6) as o TTL security (which becomes hop-limit security in IPv6) as
[RFC5082]; [RFC5082];
o bogon AS filtering, see [CYMRU]; o bogon AS filtering, see [CYMRU];
o Prefix filtering. o Prefix filtering.
These are explained in more detail in Section 2.5. Also, the These are explained in more detail in Section 2.5. Also, the
recommendations of [RFC7454] should be considered. recommendations of [RFC7454] should be considered.
4.1.1. Remote Triggered Black Hole Filtering 4.1.1. Remote Triggered Black Hole (RTBH) Filtering
RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has
allocated the 100::/64 prefix to be used as the discard prefix allocated the 100::/64 prefix to be used as the discard prefix
[RFC6666]. [RFC6666].
4.2. Transition/Coexistence Mechanism 4.2. Transition/Coexistence Mechanism
SP will typically use transition mechanisms such as 6rd, 6PE, MAP, SPs will typically use transition mechanisms such as 6rd, 6PE, MAP,
NAT64 which have been analyzed in the transition and coexistence and NAT64 which have been analyzed in the transition and coexistence
Section 2.7 section. Section 2.7 section.
4.3. Lawful Intercept 4.3. Lawful Intercept
The Lawful Intercept requirements are similar for IPv6 and IPv4 The Lawful Intercept requirements are similar for IPv6 and IPv4
architectures and will be subject to the laws enforced in varying architectures and will be subject to the laws enforced in different
geographic regions. The local issues with each jurisdiction can make geographic regions. The local issues with each jurisdiction can make
this challenging and both corporate legal and privacy personnel this challenging and both corporate legal and privacy personnel
should be involved in discussions pertaining to what information gets should be involved in discussions pertaining to what information gets
logged and what the logging retention policies will be. logged and the respective log retention policies for this information.
The target of interception will usually be a residential subscriber The target of interception will usually be a residential subscriber
(e.g., his/her PPP session or physical line or CPE MAC address). (e.g., his/her PPP session, physical line, or CPE MAC address).
With the absence of IPv6 NAT on the CPE, IPv6 has the possibility to With the absence of IPv6 NAT on the CPE, IPv6 has the possibility to
allow for intercepting the traffic from a single host (a /128 target) allow for intercepting the traffic from a single host (i.e., a /128 target)
rather than the whole set of hosts of a subscriber (which could be a rather than the whole set of subscriber hosts (which could be a
/48, a /60 or /64). /48, /60, or /64).
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
establishes a data connection it gets a new IID). establishes a data connection 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 standards and guidelines The IETF Homenet working group is working on standards and guidelines
for IPv6 residential networks; this obviously includes operational for IPv6 residential networks; this obviously includes operational
security considerations; but this is still work in progress in early security considerations; but this is still work in progress in early
2020. [RFC8520] is an interesting approach on how firewalls could 2020. [RFC8520] is an interesting approach on how firewalls could
retrieve and apply specific security policies to some residential retrieve and apply specific security policies to some residential
devices. devices.
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 (e.g., security or networking. As most of the recent hosts (e.g.,
smartphones, tablets) all have IPv6 enabled by default, IPv6 security smartphones, tablets) have IPv6 enabled by default, IPv6 security
is important for those users. Even with an IPv4-only ISP, those is important for those users. Even with an IPv4-only ISP, those
users can get IPv6 Internet access with the help of Teredo users can get IPv6 Internet access with the help of Teredo
(Section 2.7.2.8) tunnels. Several peer-to-peer programs support (Section 2.7.2.8) tunnels. Several peer-to-peer programs support
IPv6 and those programs can initiate a Teredo tunnel through an IPv4 IPv6 and those programs can initiate a Teredo tunnel through an IPv4
residential gateway, with the consequence of making the internal host residential gateway, with the consequence of making the internal host
reachable from any IPv6 host on the Internet. It is therefore reachable from any IPv6 host on the Internet. It is therefore
recommended that all host security products (including personal recommended that all host security products (including personal
firewalls) are configured with a dual-stack security policy. firewalls) are configured with a dual-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 a 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
block all externally initiated ones, which is a common default block all externally initiated ones, which is a common default
security policy enforced by IPv4 Residential Gateway doing NAPT security policy enforced by IPv4 Residential Gateway doing NAPT
but it also breaks the end-to-end reachability promise of IPv6. but it also breaks the end-to-end reachability promise of IPv6.
[RFC6092] lists several recommendations to design such a CPE; [RFC6092] lists several recommendations to design such a CPE;
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 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.
6. Further Reading 6. Further Reading
There are several documents that describe in more details the There are several documents that describe in more detail 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 the reader's IETF and some of them are dated but are listed here for the reader's
convenience: convenience:
1. Guidelines for the Secure Deployment of IPv6 [NIST] 1. Guidelines for the Secure Deployment of IPv6 [NIST]
2. North American IPv6 Task Force Technology Report - IPv6 Security 2. North American IPv6 Task Force Technology Report - IPv6 Security
Technology Paper [NAv6TF_Security] Technology Paper [NAv6TF_Security]
3. IPv6 Security [IPv6_Security_Book] 3. IPv6 Security [IPv6_Security_Book]
7. Acknowledgements 7. Acknowledgements
The authors would like to thank the following people for their useful The authors would like to thank the following people for their useful
comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali,
Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti,
Markus de Bruen, Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee Markus de Bruen, Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee
Howard, Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari, Howard, Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari,
Ted Lemon, Mark Lentczner, Jen Linkova (and her detailed review), Ted Lemon, Mark Lentczner, Acee Lindem, Jen Linkova (and her detailed
Gyan S. Mishra, Jordi Palet, Bob Sleigh, Donald Smith, Tarko Tikan, review), Gyan Mishra, Jordi Palet, Bob Sleigh, Donald Smith, Tarko Tikan,
Ole Troan, Bernie Volz (by alphabetical order). Ole Troan, Bernie Volz (by alphabetical order).
8. Security Considerations 8. 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 for an IPv6-only network and for operating an IPv6 network both for an IPv6-only network and for
networks utilizing the most widely deployed IPv4/IPv6 coexistence networks utilizing the most widely deployed IPv4/IPv6 coexistence
strategies. strategies.
9. References 9. References
 End of changes. 104 change blocks. 
134 lines changed or deleted 134 lines changed or added

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