Operational Security Considerations for IPv6
NetworksCiscoDe Kleetlaan 6aDiegemBelgium1831+32 2 778 4677evyncke@cisco.comkk.chittimaneni@gmail.comDouble Shot Security3518 Fremont Ave N 363SeattleUnited States of America98103+12066696394merike@doubleshotsecurity.comERNWCarl-Bosch-Str. 4Heidelberg Baden-Wuertemberg69115Germany+49 6221 480390erey@ernw.de
Operations and Management
OPSECIPv6SecurityOperational SecurityKnowledge and experience on how to operate IPv4 networks securely is
available, whether the operator is an Internet Service Provider (ISP) or an enterprise
internal network. However, IPv6 presents some new security challenges.
RFC 4942 describes security issues in the protocol, but network managers
also need a more practical, operations-minded document to enumerate
advantages and/or disadvantages of certain choices.This document analyzes the operational security issues associated
with several types of networks and proposes technical and procedural
mitigation techniques. This document is only applicable to managed
networks, such as enterprise networks, service provider networks, or
managed residential networks.IntroductionRunning an IPv6 network is new for most operators not only because
they are not yet used to large-scale IPv6 networks but also because
there are subtle but critical and important differences between IPv4 and
IPv6, especially with respect to security. For example, all Layer 2 (L2)
interactions are now done using the Neighbor Discovery Protocol (NDP) rather than the Address Resolution
Protocol . Also, there is no Network
Address Port Translation
(NAPT) defined in for IPv6 even if specifies an IPv6-to-IPv6 Network Prefix
Translation
(NPTv6), which is a 1-to-1 mapping of IPv6 addresses. Another important
difference is that IPv6 is extensible with the use of extension
headers.IPv6 networks are deployed using a variety of techniques, each of
which have their own specific security concerns.This document complements by listing
security issues when operating a network (including various transition
technologies).
It also provides operational deployment
experiences where warranted.Applicability StatementThis document is applicable to managed networks, i.e., when the
network is operated by the user organization itself. Indeed, many of
the recommended mitigation techniques must be configured with detailed
knowledge of the network (which are the default routers, the switch
trunk ports, etc.). This covers Service Providers (SPs), enterprise
networks, and some knowledgeable home-user-managed residential
networks. This applicability statement especially applies to Sections and .Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Generic Security ConsiderationsAddressingIPv6 address allocations and overall architecture are important
parts of securing IPv6. Initial designs, even if intended to be
temporary, tend to last much longer than expected. Although
IPv6 was initially thought to make renumbering easy, in practice, it may be
extremely difficult to renumber without a proper IP Address Management
(IPAM) system. introduces the mechanisms that
could be utilized for IPv6 site renumbering and tries to cover most of
the explicit issues and requirements associated with IPv6
renumbering.A key task for a successful IPv6 deployment is to prepare an
addressing plan. Because an abundance of address space is available,
structuring an address plan around both services and geographic
locations allows address space to become a basis for more structured
security policies to permit or deny services between geographic
regions. documents some operational
considerations of using different prefix sizes for address assignments
at end sites.A common question is whether companies should use Provider-Independent (PI) or Provider-Aggregated (PA) space , but, from a security perspective, there is little
difference. However, one aspect to keep in mind is who has
administrative ownership of the address space and who is technically
responsible if/when there is a need to enforce restrictions on
routability of the space, e.g., due to malicious criminal activity
originating from it.
Relying on PA address space may also increase the
perceived need for address translation techniques, such as NPTv6;
thereby, the complexity of the operations, including the
security operations, is augmented.In , it is recommended that IPv6 network
deployments provide multiple IPv6 addresses from each prefix to
general-purpose hosts, and it specifically does not recommend limiting
a host to only one IPv6 address per prefix. It also recommends that
the network give the host the ability to use new addresses without
requiring explicit requests (for example, by using Stateless Address
Autoconfiguration (SLAAC)). Privacy
extensions, as of ,
constitute one of the main scenarios where
hosts are expected to generate multiple addresses from the same prefix,
and having multiple IPv6 addresses per interface is a major change
compared to the unique IPv4 address per interface for hosts (secondary
IPv4 addresses are not common), especially for audits (see
).Use of ULAsUnique Local Addresses (ULAs) are
intended for scenarios where interfaces are not globally reachable,
despite being routed within a domain. They formally have global
scope, but specifies that they must be
filtered at domain boundaries. ULAs are different from the addresses described in and have different use cases. One use
of ULAs is described in ; another one is
for internal communication stability in networks where external
connectivity may come and go (e.g., some ISPs provide ULAs in home
networks connected via a cable modem). It should further be kept in
mind that ULA /48s from the fd00::/8 space (L=1) MUST be generated
with a pseudorandom algorithm, per .Point-to-Point Links specifies the
rationale
of using /127 for inter-router, point-to-point links to prevent the
ping-pong issue between routers not correctly implementing , and it also prevents a denial-of-service
(DoS) attack on the Neighbor Cache. The previous recommendation of has
been obsoleted and marked Historic by .Some environments are also using link-local addressing for
point-to-point links. While this practice could further reduce the
attack surface of infrastructure devices, the operational
disadvantages also need to be carefully considered; see .Loopback AddressesMany operators reserve a /64 block for all loopback addresses in
their infrastructure and allocate a /128 out of this reserved /64
prefix for each loopback interface. This practice facilitates
configuration of Access Control List (ACL) rules to enforce a
security policy for those loopback addresses.Stable AddressesWhen considering how to assign stable addresses for nodes (either
by static configuration or by pre-provisioned DHCPv6 lease ()), it is necessary to take into consideration the
effectiveness of perimeter security in a given environment.There is a trade-off between ease of operation (where some
portions of the IPv6 address could be easily recognizable for
operational debugging and troubleshooting) versus the risk of
trivial scanning used for reconnaissance.
shows that there are scientifically based mechanisms that make
scanning for IPv6-reachable nodes more feasible than expected; see
.Stable addresses also allow easy enforcement of a security policy
at the perimeter based on IPv6 addresses. For example, Manufacturer Usage Description (MUD) is a
mechanism where the perimeter defense can retrieve the security policy
template based on the type of internal device and apply the right
security policy based on the device's IPv6 address.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 easy to figure out which devices are name servers, routers,
or other critical devices; even a simple traceroute will expose most
of the routers on a path. There are many scanning techniques
possible and operators should not rely on the 'impossible to find
because my address is random' paradigm (a.k.a. "security by
obscurity") even if it is common practice to have the stable
addresses randomly distributed across /64 subnets and to always use
DNS (as IPv6 addresses are hard for human brains to remember).While, in some environments, obfuscating addresses could be
considered an added benefit, it should not preclude enforcement of
perimeter rules. Stable addresses following some logical allocation
scheme may ease the operation (as simplicity always helps
security).Typical deployments will have a mix of stable and non-stable
addresses; the stable addresses being either predictable (e.g., ::25
for a mail server) or obfuscated (i.e., appearing as a random 64-bit
number).Temporary Addresses for SLAACHistorically, Stateless Address Autoconfiguration (SLAAC) makes
up the globally unique IPv6 address based on an automatically
generated 64-bit interface identifier (IID) based on the 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC)
address combined with the /64 prefix (received in the Prefix
Information Option (PIO) of the Router Advertisement (RA)). The
EUI-64 address is generated from the stable 48-bit MAC address and
does not change even if the host moves to another network; this is
of course bad for privacy, as a host can be traced from network
(home) to network (office or Wi-Fi in hotels). recommends against the use of EUI-64 addresses,
and it must be noted that most host operating systems do not use
EUI-64 addresses anymore and rely on either
or .Randomly generating an interface ID, as described in , is part of SLAAC with so-called privacy
extension addresses and is used to address some privacy concerns.
Privacy extension addresses, a.k.a. temporary addresses, may help to
mitigate the correlation of activities of a node within the same
network and may also reduce the attack exposure window. But using
privacy extension addresses as described in might
prevent the operator from building host-specific access control lists
(ACLs). These privacy extension addresses
could also be used to obfuscate some malevolent activities, and
specific user attribution/accountability procedures should be put in
place, as described in . combined with the address generation
mechanism of specifies another way to
generate an address while still keeping the same IID for each
network prefix; this allows SLAAC nodes to always have the same
stable IPv6 address on a specific network while having different
IPv6 addresses on different networks.In some specific use cases where user accountability is more
important than user privacy, network operators may consider
disabling SLAAC and relying only on DHCPv6; however, not all operating
systems support DHCPv6, so some hosts will not get any IPv6
connectivity. Disabling SLAAC and privacy extension addresses can be
done for most operating systems by sending RA messages with a hint
to get addresses via DHCPv6 by setting the M-bit and disabling SLAAC
by resetting all A-bits in all PIOs. However,
attackers could still find ways to bypass this mechanism if it is not
enforced at the switch/router level.However, in scenarios where anonymity is a strong desire
(protecting user privacy is more important than user attribution),
privacy extension addresses should be used. When mechanisms
recommended by are available, the stable
privacy address is probably a good balance between privacy (among
different networks) and security/user attribution (within a
network).DHCP ConsiderationsSome environments use DHCPv6 to provision addresses and other
parameters in order to ensure auditability and traceability (see
for the limitations of DHCPv6 for
auditability).A main security concern is the ability to detect and counteract
rogue DHCP servers (). It must be noted
that, as opposed to DHCPv4, DHCPv6 can lease several IPv6 addresses per
client. For DHCPv4, the lease is bound to the 'client identifier',
which may contain a hardware address or another type
of identifier, such as a DNS name. For DHCPv6, the lease is bound to
the client DHCP Unique Identifier (DUID), which may or may not be bound to
the client L2 address. describes
the privacy issues associated with the use of DHCPv6 by Internet
users. The anonymity profiles are designed
for clients that wish to remain anonymous to the visited network.
recommends that DHCPv6 servers issue
addresses randomly from a large pool.DNS ConsiderationsWhile the security concerns of DNS are not fundamentally
different between IPv4 and IPv6, there are specific considerations
in DNS64 environments that need to be
understood. Specifically, the interactions and the potential of
interference with DNSSEC implementation
need to be understood -- these are pointed out in more detail in
.Using a /64 per HostAn interesting approach is using a /64 per host, as proposed in
, especially in a shared environment.
This allows for easier user attribution (typically based on the host MAC
address), as its /64 prefix is stable, even if applications within the
host can change their IPv6 address within this /64 prefix.This can also be useful for the generation of ACLs once
individual systems (e.g., admin workstations) have their own
prefixes.Privacy Consideration of AddressesIn addition to the security aspects of IPv6 addresses, there are also
privacy considerations: mainly because they are of global scope and
visible globally. goes into more detail on
the privacy considerations for IPv6 addresses by comparing the
manually configured IPv6 address, DHCPv6, and SLAAC.Extension HeadersExtension headers are an important difference between IPv4 and
IPv6. In IPv4-based packets, it's trivial to find the upper-layer
protocol type and protocol header, while, in IPv6, it is more complex
since the extension header chain must be parsed completely (even if
not processed) in order to find the upper-layer protocol header. IANA
has closed the existing empty "Next Header Types" registry to new
entries and is redirecting its users to the "IPv6 Extension Header
Types" registry, per .Extension headers have also become a very controversial topic since
forwarding nodes that discard packets containing extension headers are
known to cause connectivity failures and deployment problems . Understanding the role of various extension
headers is important, and this section enumerates the ones that need
careful consideration.A clarification on how intermediate nodes should handle packets
with existing or future extension headers is found in . The uniform TLV format to be used for defining
future extension headers is described in .
Sections and
of
provide more
information on the processing of extension headers by IPv6 nodes.Vendors of filtering solutions and operations personnel responsible
for implementing packet filtering rules should be aware that the 'Next
Header' field in an IPv6 header can both point to an IPv6 extension
header or to an upper-layer protocol header. This has to be considered
when designing the user interface of filtering solutions or during the
creation of filtering rule sets. discusses filtering rules for those
extension headers at transit routers.Order and Repetition of Extension HeadersWhile recommends the order and the
maximum repetition of extension headers, at the time of writing, there are still IPv6
implementations that support an
order of headers that is not recommended (such as Encapsulating Security Payload (ESP)
before routing) or an
illegal repetition of headers (such as multiple routing headers).
The same applies for options contained in the extension headers (see
). In some
cases, it has led to nodes crashing when receiving or forwarding
wrongly formatted packets.A firewall or edge device should be used to enforce the
recommended order and the maximum occurrences of extension headers
by dropping nonconforming packets.Hop-by-Hop Options HeaderIn the previous IPv6 specification ,
the hop-by-hop options header, when present in an IPv6 packet, forced
all nodes to inspect and possibly process this header. This enabled
denial-of-service attacks as most, if not all, routers cannot
process this type of packet in hardware; they have to process these
packets in software and, hence, this task competes with other software tasks,
such as handling the control and management plane processing., the
current Internet Standard for IPv6, has taken this attack vector into account and
made the processing of hop-by-hop options headers by intermediate
routers explicitly configurable.Fragment HeaderThe fragment header is used by the source (and only the source)
when it has to fragment packets. and
explain why it is
important that:
Firewall and security devices should drop first fragments
that do not contain the entire IPv6 header chain (including the
transport-layer header).
Destination nodes should discard first fragments that do not
contain the entire IPv6 header chain (including the
transport-layer header).
If those requirements are not met, stateless filtering could be
bypassed by a hostile party. applies a
stricter rule to NDP by enforcing the
drop of fragmented NDP packets (except for "Certification Path
Advertisement" messages, as noted in section ). describes how the
RA-Guard function described in should
behave in the presence of fragmented RA packets.IP Security Extension HeaderThe IPsec extension headers (Authentication Header (AH) and ESP)
are required if IPsec is to be utilized for network-level security.
Previously, IPv6 mandated implementation of IPsec, but updated that recommendation by making support of
the IPsec architecture a
'SHOULD' for all
IPv6 nodes that are also retained in the latest IPv6 Nodes
Requirement standard .Link-Layer SecurityIPv6 relies heavily on NDP to perform a
variety of link operations, such as discovering other nodes on the
link, resolving their link-layer addresses, and finding routers on the
link. If not secured, NDP is vulnerable to various attacks, such as
router/neighbor message spoofing, redirect attacks, Duplicate Address
Detection (DAD) DoS attacks, etc. Many of these security threats to
NDP have been documented in "IPv6 Neighbor Discovery (ND) Trust Models and Threats"
and in "Operational Neighbor Discovery
Problems" .Most of the issues are only applicable when the attacker is on the
same link, but NDP also has security issues when the attacker is
off link; see below.Neighbor Solicitation Rate-LimitingNDP can be vulnerable to remote DoS attacks,
for example, when a router is forced to perform address resolution
for a large number of unassigned addresses, i.e., when a prefix is
scanned by an attacker in a fast manner. This can keep new devices
from joining the network or render the last-hop router ineffective
due to high CPU usage. Easy mitigative steps include rate limiting
Neighbor Solicitations, restricting the amount of state reserved for
unresolved solicitations, and cleverly managing the cache/timer. discusses the potential for off-link DoS
in detail and suggests implementation improvements and operational
mitigation techniques that may be used to mitigate or alleviate the
impact of such attacks. Here are some feasible mitigation options
that can be employed by network operators today:
Ingress filtering of unused addresses by ACL. These require
stable configuration of the addresses, e.g., allocating
the addresses out of a /120 and using a specific ACL to only
allow traffic to this /120 (of course, the actual hosts are
configured with a /64 prefix for the link).
Tuning of NDP process (where supported), e.g., enforcing
limits on data structures, such as the number of Neighbor Cache
entries in 'incomplete' state (e.g., 256 incomplete entries per
interface) or the rate of NA per interface (e.g., 100 NA per
second).
Using a /127 on a point-to-point link, per .
Using only link-local addresses on links where there are only
routers; see .
Router and Neighbor Advertisements FilteringRouter Advertisement FilteringRouter Advertisement spoofing is a well-known, on-link attack
vector and has been extensively documented. The presence of rogue
RAs, either unintentional or malicious, can cause partial or
complete failure of operation of hosts on an IPv6 link. For
example, a node can select an incorrect router address, which can
then be used for an on-path attack, or the node can assume wrong
prefixes to be used for SLAAC.
summarizes
the scenarios in which rogue RAs may be observed and presents a
list of possible solutions to the problem. (RA-Guard) describes a solution framework for
the rogue RA problem where network segments are designed around
switching devices that are capable of identifying invalid RAs and
blocking them before the attack packets actually reach the target
nodes.However, several evasion techniques that circumvent the
protection provided by RA-Guard have surfaced. A key challenge to
this mitigation technique is introduced by IPv6 fragmentation.
Attackers can conceal their attack by fragmenting their packets
into multiple fragments such that the switching device that is
responsible for blocking invalid RAs cannot find all the necessary
information to perform packet filtering of the same packet. describes such evasion techniques and provides
advice to RA-Guard implementers such that the aforementioned
evasion vectors can be eliminated.Given that the IPv6 Fragmentation Header can be leveraged to
circumvent some implementations of RA-Guard, updates such that use
of the IPv6 Fragmentation Header is forbidden in all Neighbor
Discovery messages, except "Certification Path Advertisement", thus
allowing for simple and effective measures to counter fragmented
NDP attacks.Neighbor Advertisement FilteringThe Source Address Validation Improvements (savi) Working Group
has worked on other ways to mitigate the effects of such attacks.
helps in creating bindings between a
source IP address assigned to
DHCPv4 or DHCPv6
and a binding anchor on a SAVI
device. Also, describes how to
glean similar bindings when
DHCP is not used. The bindings can be used to filter packets
generated on the local link with forged source IP addresses.Host IsolationIsolating hosts for the NDP traffic can be done by using a /64
per host, refer to , as NDP is
only relevant within a /64 on-link prefix; 3GPP () uses a similar mechanism.A more drastic technique to prevent all NDP attacks is based on
isolation of all hosts with specific configurations. In such a
scenario, hosts (i.e., 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. This specific setup can be
established on some switches or Wi-Fi access points. This is not
always feasible when hosts need to communicate with other hosts in
the same subnet, e.g., for access to file shares.NDP RecommendationsIt is still recommended that RA-Guard and SAVI be employed as a
first line of defense against common attack vectors, including
misconfigured hosts. This recommendation also applies when DHCPv6
is used, as RA messages are used to discover the default router(s)
and for on-link prefix determination. This line of defense is most
effective when incomplete fragments are dropped by routers and
L2 switches, as described in . The
generated log should also be analyzed to identify and act on violations.Network operators should be aware that RA-Guard and SAVI do not
work as expected or could even be harmful in specific network
configurations (notably when there could be multiple routers).Enabling RA-Guard by default in managed networks (e.g., Wi-Fi
networks, enterprise campus networks, etc.) should be strongly
considered except for specific use cases, such as in the presence of
homenet devices emitting router advertisements.Securing DHCPThe Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as
described in , enables DHCP servers to pass
configuration parameters, such as IPv6 network addresses and other
configuration information, to IPv6 nodes. DHCP plays an important
role in most large networks by providing robust stateful
configuration in the context of automated system provisioning.The two most common threats to DHCP clients come from malicious
(a.k.a. rogue) or unintentionally misconfigured DHCP servers. In
these scenarios, a malicious DHCP server is established with the
intent of providing incorrect configuration information to the
clients to cause a denial-of-service attack or to mount an on-path
attack. While unintentional, a misconfigured DHCP server can have
the same impact. Additional threats against DHCP are discussed in
the security considerations section of .DHCPv6-Shield specifies a
mechanism for protecting connected DHCPv6 clients against rogue
DHCPv6 servers. This mechanism is based on DHCPv6 packet filtering
at the L2 device, i.e., the administrator specifies the
interfaces connected to DHCPv6 servers. However, extension headers
could be leveraged to bypass DHCPv6-Shield unless is enforced.It is recommended to use DHCPv6-Shield and to analyze the
corresponding log messages.3GPP Link-Layer SecurityThe 3GPP link is a point-to-point-like link that has no
link-layer address. This implies there can only be one end host (the
mobile handset) and the first-hop router (i.e., a Gateway GPRS
Support Node (GGSN) or a Packet Data Network Gateway (PGW)) on that link. The
GGSN/PGW never configures a non-link-local address on the link using
the advertised /64 prefix on it; see .
The advertised prefix must not be used for on-link determination.
There is no need for address resolution on the 3GPP link, since
there are no link-layer addresses. Furthermore, the GGSN/PGW assigns
a prefix that is unique within each 3GPP link that uses IPv6
Stateless Address Autoconfiguration. This avoids the necessity to
perform DAD at the network level for every address generated by the
mobile host. The GGSN/PGW always provides an IID to the cellular
host for the purpose of configuring the link-local address and
ensures the uniqueness of the IID on the link (i.e., no collisions
between its own link-local address and the mobile host's
address).The 3GPP link model itself mitigates most of the known
NDP-related DoS attacks. In practice, the GGSN/PGW
only needs to 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, there is no need to defend that IPv6 address.See for a more detailed
discussion on the 3GPP link model, NDP, and the address
configuration details. In some mobile networks, DHCPv6 and DHCP Prefix Delegation
(DHCP-PD) are also used.Impact of Multicast TrafficIPv6 uses multicast extensively for signaling messages on the
local link to avoid broadcast messages for on-the-wire
efficiency.The use of multicast has some side effects on wireless networks,
such as a negative impact on battery life of smartphones and other
battery-operated devices that are connected to such networks. and (for specific
wireless networks) discuss methods to rate-limit RAs and other ND
messages on wireless networks in order to address this issue.The use of link-layer multicast addresses (e.g., ff02::1 for the
all nodes link-local multicast address) could also be misused for an
amplification attack. Imagine a hostile node sending an ICMPv6
ECHO_REQUEST to ff02::1 with a spoofed source address, then all
link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the
source address. This could be a DoS attack for the address owner.
This attack is purely local to the L2 network, as packets with a
link-local destination are never forwarded by an IPv6 router.This is the reason why large Wi-Fi network deployments often
limit the use of link-layer multicast, either from or to the uplink
of the Wi-Fi access point, i.e., Wi-Fi stations are prevented to
send link-local multicast to their direct neighboring Wi-Fi
stations; this policy also blocks service discovery via Multicast DNS (mDNS)
and Link-Local Multicast Name
Resolution (LLMNR) .SEND and CGASEcure Neighbor Discovery (SEND), as described in , is a mechanism that was designed to secure ND
messages. This approach involves the use of new NDP options to carry
public-key-based signatures. Cryptographically Generated Addresses
(CGA), as described in , are used to ensure
that the sender of a Neighbor Discovery message is the actual
"owner" of the claimed IPv6 address. A new NDP option, the CGA
option, was introduced and is used to carry the public key and
associated parameters. Another NDP option, the RSA Signature option,
is used to protect all messages relating to neighbor and router
discovery.SEND protects against:
Neighbor Solicitation/Advertisement Spoofing
Neighbor Unreachability Detection Failure
Duplicate Address Detection DoS Attack
Router Solicitation and Advertisement Attacks
Replay Attacks
Neighbor Discovery DoS Attacks
SEND does NOT:
protect statically configured addresses
protect addresses configured using fixed identifiers (i.e.,
EUI-64)
provide confidentiality for NDP communications
compensate for an unsecured link -- SEND does not require that
the addresses on the link and Neighbor Advertisements
correspond
However, at this time and over a decade since their original
specifications, CGA and SEND do not have support from widely
deployed IPv6 devices; hence, their usefulness is limited and should
not be relied upon.Control Plane Security defines the router control plane and
provides detailed guidance to secure it for IPv4 and IPv6 networks.
This definition is repeated here for the reader's convenience. Please
note that the definition is completely protocol-version agnostic (most
of this section applies to IPv6 in the same way as to IPv4).Modern router architecture design maintains a strict separation of
forwarding and router control plane hardware and software. The router
control plane supports routing and management functions. It is
generally described as the router architecture hardware and software
components for handling packets destined to the device itself as well
as building and sending packets originated locally on the device. The
forwarding plane is typically described as the router architecture
hardware and software components responsible for receiving a packet on
an incoming interface, performing a lookup to identify the packet's IP
next hop and best outgoing interface towards the destination, and
forwarding the packet through the appropriate outgoing interface.While the forwarding plane is usually implemented in high-speed
hardware, the control plane is implemented by a generic processor
(referred to as the routing processor (RP)) and cannot process packets
at a high rate. Hence, this processor can be attacked by flooding its
input queue with more packets than it can process. The control plane
processor is then unable to process valid control packets and the
router can lose IGP or BGP adjacencies, which can cause a severe
network disruption. provides detailed guidance to protect the
router control plane in IPv6 networks. The rest of this section
contains simplified guidance.The mitigation techniques are:
to drop illegitimate or potentially harmful control packets before
they are queued to the RP (this can be done by a forwarding plane
ACL) and
to rate-limit the remaining packets to a rate that the RP can
sustain. Protocol-specific protection should also be done (for
example, a spoofed OSPFv3 packet could trigger the execution of
the Dijkstra algorithm; therefore, the frequency of Dijkstra
calculations should also be rate limited).
This section will consider several classes of control packets:
Control protocols:
routing protocols, such as OSPFv3, BGP,
Routing Information Protocol Next Generation (RIPng), and, by extension, NDP and
ICMP
Management protocols:
Secure Shell (SSH), SNMP, Network Configuration Protocol (NETCONF), RESTCONF,
IP Flow Information Export (IPFIX), etc.
Packet exceptions:
normal data packets that require a specific
processing, such as generating a packet-too-big ICMP message or
processing the hop-by-hop options header
Control ProtocolsThis class includes OSPFv3, BGP, NDP, and ICMP.An ingress ACL to be applied on all the router interfaces for
packets to be processed by the RP should be configured to:
drop OSPFv3 (identified by Next-Header being 89) and RIPng
(identified by UDP port 521) packets from a non-link-local
address (except for OSPFv3 virtual links)
allow BGP (identified by TCP port 179) packets from all BGP
neighbors and drop the others
allow all ICMP packets (transit and to the router
interfaces)
Rate-limiting of the valid packets should be done; see for a side benefit for OSPv3. The exact
configuration will depend on the available resources of the router
(CPU, Ternary Content-Addressable Memory (TCAM), etc.).Management ProtocolsThis class includes SSH, SNMP, RESTCONF, NETCONF, gRPC Remote Procedure Calls
(gRPC), syslog, NTP, etc.An ingress ACL to be applied on all the router interfaces (or at
ingress interfaces of the security perimeter or by using specific
features of the platform) should be configured for packets destined
to the RP, such as:
drop packets destined to the routers, except those belonging
to protocols that are used (for example, permit TCP 22 and drop
all others when only SSH is used) and
drop packets where the source does not match the security
policy (for example, if SSH connections should only be
originated from the Network Operation Center (NOC), then the ACL
should permit TCP port 22 packets only from the NOC prefix).
Rate-limiting of valid packets should be done. The exact
configuration will depend on the available router resources.Packet ExceptionsThis class covers multiple cases where a data plane packet is
punted to the route processor because it requires specific
processing:
generation of an ICMP packet-too-big message when a data
plane packet cannot be forwarded because it is too large
(required to discover the Path MTU);
generation of an ICMP hop-limit-expired message when a data
plane packet cannot be forwarded because its hop-limit field has
reached 0 (also used by the traceroute utility);
generation of an ICMP destination-unreachable message when a
data plane packet cannot be forwarded for any reason;
processing of the hop-by-hop options header; new
implementations follow where this processing is optional; or
more specific to some router implementations, an oversized
extension header chain that cannot be processed by the hardware
and cannot force the packet to be punted to the RP.
On some routers, not everything can be done by the specialized
data plane hardware that requires some packets to be 'punted' to
the generic RP. This could include, for example, the processing of a
long extension header chain in order to apply an ACL based on
Layer 4 information. and more generally
highlight the security implications of
oversized extension header chains on routers and update the
original IPv6 specifications such that
the first fragment of a packet is required to contain the entire
IPv6 header chain. Those changes are incorporated in the IPv6
standard .An ingress ACL cannot mitigate a control plane attack using these
packet exceptions. The only protection for the RP is to rate-limit
those packet exceptions that are forwarded to the RP. This means
that some data plane packets will be dropped without an ICMP message
sent to the source, which may delay Path MTU Discovery and cause
drops.In addition to limiting the rate of data plane packets queued to
the RP, it is also important to rate-limit the generation of ICMP
messages. This is important both to preserve RP resources and also
to prevent an amplification attack using the router as a reflector.
It is worth noting that some platforms implement this rate-limiting
in hardware. Of course, a consequence of not generating an ICMP
message will break some IPv6 mechanisms, such as Path MTU Discovery
or a simple traceroute.Routing SecurityRouting security in general can be broadly divided into three
sections:
authenticating neighbors/peers
securing routing updates between peers
route filtering
is also applicable to IPv6 and can ensure
that routing protocol packets are coming from the local network; it
must also be noted that in IPv6 all interior gateway protocols use
link-local addresses.As for IPv4, it is recommended to enable a routing protocol only on
interfaces where it is required.BGP SecurityAs BGP is identical for IPv4 and IPv6 and as covers all the security aspects for BGP in
detail, is also applicable to IPv6.Authenticating OSPFv3 NeighborsOSPFv3 can rely on IPsec to fulfill the authentication function.
Operators should note that IPsec support is not standard on all
routing platforms. In some cases, this requires specialized hardware
that offloads crypto over to dedicated Application-Specific Integrated Circuits
(ASICs) or enhanced software
images (both of which often come with added financial cost) to
provide such functionality. An added detail is to determine whether
OSPFv3 IPsec implementations use AH or ESP-NULL for integrity
protection. In early implementations, all OSPFv3 IPsec
configurations relied on AH since the details weren't specified in
.
However, the document that specifically
describes how IPsec should be implemented for OSPFv3 states that "implementations MUST support ESP[-NULL] and
MAY support AH" since it follows the overall IPsec standards
wording. OSPFv3 can also use normal ESP to encrypt the OSPFv3
payload to provide confidentiality for the routing information. changes OSPFv3 reliance on IPsec by
appending an authentication trailer to the end of the OSPFv3
packets. It does not authenticate the specific
originator of an OSPFv3 packet; rather, it allows a router to
confirm that the packet has been issued by a router that had access
to the shared authentication key.With all authentication mechanisms, operators should confirm that
implementations can support rekeying mechanisms that do not cause
outages. There have been instances where any rekeying causes
outages; therefore, the trade-off between utilizing this
functionality needs to be weighed against the protection it
provides. documents some guidelines for
crypto keys management.Securing Routing UpdatesIPv6 initially mandated the provisioning of IPsec capability in
all nodes. However, in the updated IPv6 Nodes Requirement standard
, IPsec is a 'SHOULD' and not a
'MUST'
implementation. Theoretically, it is possible that all communication
between two IPv6 nodes, especially routers exchanging routing
information, is encrypted using IPsec. However, in practice,
deploying IPsec is not always feasible given hardware and software
limitations of the various platforms deployed.Many routing protocols support the use of cryptography to protect
the routing updates; the use of this protection is recommended.
is a YANG data model for key chains
that includes rekeying functionality.Route FilteringRoute filtering policies will be different depending on whether
they pertain to edge route filtering or internal route filtering.
At a minimum, the IPv6 routing policy, as it pertains to routing between
different administrative domains, should aim to maintain parity with
IPv4 from a policy perspective, for example:
filter internal-use IPv6 addresses that are not globally routable at
the perimeter;
discard routes
for bogon and reserved
space (see ); and
configure ingress route filters that validate route origin,
prefix ownership, etc., through the use of various routing
databases, e.g., .
formally validates the origin Autonomous Systems (ASes) of BGP announcements.
Some good guidance can be found at .A valid routing table can also be used to apply network ingress
filtering (see ).Logging/MonitoringIn order to perform forensic research in the cases of a security
incident or detecting abnormal behavior, network operators should log
multiple pieces of information. In some cases, this requires a
frequent poll of devices via a Network Management Station.This logging should include but is not limited to:
logs of all applications using the network (including user
space and kernel space) when available (for example, web servers
that the network operator manages);
data from IP Flow Information Export
, also known as IPFIX;
data from various SNMP MIBs or
YANG data via RESTCONF or NETCONF;
historical data of Neighbor Cache entries;
stateful DHCPv6 lease cache,
especially when a relay agent is
used;
Source Address Validation Improvement
(SAVI) events, especially the binding of an IPv6
address to a MAC address and a specific switch or router
interface;
firewall ACL logs;
authentication server logs; and
RADIUS accounting records.
Please note that there are privacy issues or regulations related to
how these logs are collected, stored, used, and safely discarded.
Operators are urged to check their country legislation (e.g., General
Data Protection Regulation in the
European Union).All those pieces of information can be used for:
forensic investigations:
who did what and when?
correlation: which IP
addresses were used by a specific node (assuming the use of privacy extensions addresses )?
inventory: which IPv6 nodes
are on my network?
abnormal behavior
detection: unusual traffic patterns are often the symptoms
of an abnormal behavior, which is in turn a potential attack
(denial of service, network scan, a node being part of a botnet,
etc.).
Data SourcesThis section lists the most important sources of data that are
useful for operational security.Application LogsThose logs are usually text files where the remote IPv6 address
is stored in cleartext (not binary). This can complicate the
processing since one IPv6 address, for example, 2001:db8::1, can be
written in multiple ways, such as:
2001:DB8::1 (in uppercase),
2001:0db8::0001 (with leading 0), and
many other ways, including the reverse DNS mapping into
a Fully Qualified Domain Name (FQDN) (which should not be trusted).
explains this problem in detail and
recommends the use of a single canonical format. This document
recommends the use of canonical
format for IPv6 addresses in all possible cases. If the
existing application cannot log using the canonical format, then
it is recommended to use an external post-processing program in
order to canonicalize all IPv6 addresses.IP Flow Information Export by IPv6 RoutersIPFIX defines some data elements
that are useful for security:
nextHeaderIPv6, sourceIPv6Address, and
destinationIPv6Address
sourceMacAddress and destinationMacAddress
The IP version is the ipVersion element defined in .Moreover, IPFIX is very efficient in terms of data handling and
transport. It can also aggregate flows by a key, such as
sourceMacAddress, in order to have aggregated data associated with
a specific sourceMacAddress. This memo recommends the use of IPFIX
and aggregation on nextHeaderIPv6, sourceIPv6Address, and
sourceMacAddress.SNMP MIB and NETCONF/RESTCONF YANG Modules Data by IPv6 Routers defines a Management
Information Base (MIB) for the two address families of IP. This
memo recommends the use of:
ipIfStatsTable table, which collects traffic counters per
interface, and
ipNetToPhysicalTable table, which is the content of the
Neighbor Cache, i.e., the mapping between IPv6 and data-link
layer addresses.
There are also YANG modules relating to the two IP address
families and that can be used with and . This memo recommends the use of:
interfaces-state/interface/statistics from ietf-interfaces@2018-02-20.yang, which
contains counters for interfaces, and
ipv6/neighbor from ietf-ip@2018-02-22.yang, which is the
content of the Neighbor Cache, i.e., the mapping between IPv6
and data-link layer addresses.
Neighbor Cache of IPv6 RoutersThe Neighbor Cache of routers contains all mappings between
IPv6 addresses and data-link layer addresses. There are multiple
ways to collect the current entries in the Neighbor Cache, notably,
but not limited to:
using the SNMP MIB, as
explained above;
using streaming telemetry or NETCONF and RESTCONF to collect the operational
state of the Neighbor Cache; and
connecting over a secure management channel (such
as SSH) and explicitly requesting a Neighbor Cache dump via
the Command-Line Interface (CLI) or another monitoring
mechanism.
The Neighbor Cache is highly dynamic, as mappings are added when
a new IPv6 address appears on the network. This could be quite
frequently with privacy extension
addresses or when they are removed when the state goes from
UNREACH to removed (the default time for a removal per Neighbor Unreachability Detection
algorithm is 38 seconds for a host using Windows 7). This means
that the content of the Neighbor Cache must be
fetched periodically at an interval that does not exhaust the router resources
and still provides valuable information (the suggested value is 30
seconds, but this should be verified in the actual deployment) and
stored for later use.This is an important source of information because it is
trivial (on a switch not using the SAVI algorithm) to defeat the mapping
between data-link layer address and an IPv6 address. Put another way, having access to the current and past
content of the Neighbor Cache has a paramount value for the
forensic and audit trails. It should also be noted that, in certain
threat models, this information is also deemed valuable and could
itself be a target.When using one /64 per host ()
or DHCP-PD, it is sufficient to keep the history of the allocated
prefixes when combined with strict source address prefix
enforcement on the routers and L2 switches to prevent IPv6
spoofing.Stateful DHCPv6 LeaseIn some networks, IPv6 addresses/prefixes are managed by a
stateful DHCPv6 server that leases
IPv6 addresses/prefixes to clients. It is indeed quite similar to
DHCP for IPv4, so it can be tempting to use this DHCP lease file
to discover the mapping between IPv6 addresses/prefixes and
data-link layer addresses, as is commonly used in IPv4
networking.It is not so easy in the IPv6 networks, because not all nodes
will use DHCPv6 (there are nodes that can only do stateless
autoconfiguration) and also because DHCPv6 clients are identified
not by their hardware-client address, as in IPv4, but by a DHCP
Unique Identifier (DUID). The DUID can have several formats: the
data-link layer address, the data-link layer address
prepended with time information, or even an opaque number that
requires correlation with another data source to be usable for
operational security. Moreover, when the DUID is based on the
data-link address, this address can be of any client interface
(such as the wireless interface, while the client actually uses its
wired interface to connect to the network).If a lightweight DHCP relay
agent
is used in a L2 switch, then the DHCP servers also receive
the interface ID information, which could be saved in order to
identify the interface on which the switch received a specific
leased IPv6 address. Also, if a 'normal' (not lightweight) relay
agent adds the data-link layer address in the option for Relay Agent
Remote-ID , then the DHCPv6 server can keep
track of the data-link and leased IPv6 addresses.In short, the DHCPv6 lease file is less interesting than lease files for
IPv4 networks. If possible, it is recommended to use DHCPv6
servers that keep the relayed data-link layer address in addition
to the DUID in the lease file, as those servers have the equivalent
information to IPv4 DHCP servers.The mapping between the data-link layer address and the IPv6
address can be secured by deploying switches implementing the
SAVI mechanisms. Of course, this
also requires that the data-link layer address be protected by
using a L2 mechanism, such as .RADIUS Accounting LogFor interfaces where the user is authenticated via a RADIUS server, and if RADIUS accounting is
enabled, then the RADIUS server receives accounting
Acct-Status-Type records at the start and at the end of the
connection, which include all IPv6 (and IPv4) addresses used by the
user. This technique can be used notably for Wi-Fi networks with
Wi-Fi Protected Access (WPA) or other IEEE 802.1X wired interfaces on an
Ethernet switch.Other Data SourcesThere are other data sources for log information that must be
collected (as currently collected in IPv4 networks):
historical mappings of IPv6 addresses to users of remote
access VPN and
historical mappings of MAC addresses to switch ports in a
wired network.
Use of Collected DataThis section leverages the data collected, as described in , in order to
achieve several security benefits. contains more details about host tracking.Forensic and User AccountabilityThe forensic use case is when the network operator must locate
an IPv6 address (and the associated port, access point/switch, or
VPN tunnel) that was present in the network at a certain time or
is currently in the network.To locate an IPv6 address in an enterprise network where the
operator has control over all resources, the source of information
can be the Neighbor Cache, or, if not found, the DHCP lease file.
Then, the procedure is:
based on the IPv6 prefix of the IPv6 address; find one or more
routers that are used to reach this prefix (assuming
that anti-spoofing mechanisms are used), perhaps based on an
IPAM.
based on this limited set of routers, on the incident time,
and on the IPv6 address; retrieve the data-link address from
the live Neighbor Cache, from the historical Neighbor Cache
data, or from SAVI events, or retrieve the data-link address
from the DHCP lease file ().
based on the data-link layer address; look up the switch
interface associated with the data-link layer address. In the
case of wireless LAN with RADIUS accounting (see ), the RADIUS log has the mapping
between the user identification and the MAC address. If a
Configuration Management Database (CMDB) is used, then it can
be used to map the data-link layer address to a switch
port.
At the end of the process, the interface of the host
originating or the subscriber identity associated with the
activity in question has been determined.To identify the subscriber of an IPv6 address in a residential
Internet Service Provider, the starting point is the DHCP-PD
leased prefix covering the IPv6 address; this prefix can often be
linked to a subscriber via the RADIUS log. Alternatively, the
Forwarding Information Base (FIB) of the Cable Modem Termination
System (CMTS) or Broadband Network Gateway (BNG) indicates the Customer Premises
Equipment (CPE)
of the subscriber and the RADIUS log can be used to retrieve the
actual subscriber.More generally, a mix of the above techniques can be used in
most, if not all, networks.Inventory describes the
difficulties for an attacker to scan an IPv6 network due to the
vast number of IPv6 addresses per link (and why in some cases it
can still be done). While the huge addressing space can sometimes
be perceived as a 'protection', it also makes the inventory task
difficult in an IPv6 network while it was trivial to do in an IPv4
network (a simple enumeration of all IPv4 addresses, followed by a
ping and a TCP/UDP port scan). Getting an inventory of all
connected devices is of prime importance for a secure network
operation.There are many ways to do an inventory of an IPv6 network.The first technique is to use passive inspection, such as IPFIX.
Using exported IPFIX information and extracting the list of all
IPv6 source addresses allows finding all IPv6 nodes that sent
packets through a router. This is very efficient but, alas, will
not discover silent nodes that never transmitted packets
traversing the IPFIX target router. Also, it must be noted that
link-local addresses will never be discovered by this means. The second way is again to use the collected Neighbor Cache
content to find all IPv6 addresses in the cache. This process will
also discover all link-local addresses. See .Another way that works only for a local network consists of
sending an ICMP ECHO_REQUEST to the link-local multicast address
ff02::1, which addresses all IPv6 nodes on the network. All nodes
should reply to this ECHO_REQUEST, per .Other techniques involve obtaining data from DNS, parsing log
files, and leveraging service discovery, such as mDNS .Enumerating DNS zones, especially looking at reverse DNS
records and CNAMEs, is another common method employed by various
tools. As already mentioned in , this
allows an attacker to prune the IPv6 reverse DNS tree and hence
enumerate it in a feasible time. Furthermore, authoritative
servers that allow zone transfers (i.e., Authoritative Transfers (AXFRs)) may be a further
information source. An interesting research paper has analyzed the
entropy in various IPv6 addresses: see .CorrelationIn an IPv4 network, it is easy to correlate multiple logs, for
example, to find events related to a specific IPv4 address. A
simple Unix grep command is enough to scan through multiple
text-based files and extract all lines relevant to a specific IPv4
address.In an IPv6 network, this is slightly more difficult because
different character strings can express the same IPv6 address.
Therefore, the simple Unix grep command cannot be used. Moreover,
an IPv6 node can have multiple IPv6 addresses.In order to do correlation in IPv6-related logs, it is advised
to have all logs in a format with only canonical IPv6 addresses
. Then, the current (or
historical) Neighbor Cache data set must be searched to find the data-link layer
address of the IPv6 address. Next, the current and historical
Neighbor Cache data sets must be searched for all IPv6 addresses
associated with this data-link layer address to derive the search
set. The last step is to search in all log files (containing only
IPv6 addresses in canonical format) for any IPv6 addresses in the
search set.Moreover, recommends using multiple
IPv6 addresses per prefix, so the correlation must also be done
among those multiple IPv6 addresses, for example, by discovering all IPv6 addresses
associated with the same MAC address and interface in
the NDP cache.Abnormal Behavior DetectionAbnormal behavior (such as network scanning, spamming,
DoS) can be detected in the same way as in an IPv4
network:
a sudden increase of traffic detected by interface counter
(SNMP) or by aggregated traffic from IPFIX records,
rapid growth of ND cache size, or
change in traffic pattern (number of connections per
second, number of connections per host, etc.) observed with the
use of IPFIX.
SummaryWhile some data sources (IPFIX, MIB, switch Content Addressable Memory (CAM)
tables, logs, etc.) used in IPv4 are also used in the secure operation of an IPv6
network, the DHCPv6 lease file is less reliable and the Neighbor
Cache is of prime importance.The fact that there are multiple ways to express the same IPv6
address in a character string renders the use of filters mandatory
when correlation must be done.Transition/Coexistence TechnologiesAs it is expected that some networks will not run in a pure
IPv6-only mode, the different transition mechanisms must be deployed
and operated in a secure way. This section proposes operational
guidelines for the most-known and deployed transition techniques.
also contains security considerations for
transition or coexistence scenarios.Dual StackDual stack is often the first deployment choice for network
operators. Dual stacking the network offers some advantages over
other transition mechanisms. Firstly, the impact on existing IPv4
operations is reduced. Secondly, in the absence of tunnels or
address translation, the IPv4 and IPv6 traffic are native (easier to
observe and secure) and should have the same network processing
(network path, quality of service, etc.). Dual stack enables a
gradual termination of the IPv4 operations when the IPv6 network is
ready for prime time. On the other hand, the operators have to
manage two network stacks with the added complexities.From an operational security perspective, this now means that the
network operator has twice the exposure. One needs to think about
protecting both protocols now. At a minimum, the IPv6 portion of a
dual-stacked network should be consistent with IPv4 from a security
policy point of view. Typically, the following methods are employed
to protect IPv4 networks at the edge or security perimeter:
ACLs to permit or deny traffic,
firewalls with stateful packet inspection, and
application firewalls inspecting the application flows.
It is recommended that these ACLs and/or firewalls be
additionally configured to protect IPv6 communications. The enforced
IPv6 security must be congruent with the IPv4 security policy;
otherwise, the attacker will use the protocol version that has the more
relaxed security policy. Maintaining the congruence between security
policies can be challenging (especially over time); it is
recommended to use a firewall or an ACL manager that is dual stack,
i.e., a system that can apply a single ACL entry to a mixed group of
IPv4 and IPv6 addresses.Application firewalls work at the application layer and are
oblivious to the IP version, i.e., they work as well for IPv6 as for
IPv4 and the same application security policy will work for both
protocol versions.Also, given the end-to-end connectivity that IPv6 provides, it is
recommended that hosts be fortified against threats. General device
hardening guidelines are provided in .For many years, all host operating systems have IPv6 enabled by
default, so it is possible even in an 'IPv4-only' network to attack
L2-adjacent victims via their IPv6 link-local address or via a
global IPv6 address when the attacker provides rogue RAs or a rogue
DHCPv6 service. discusses the security implications of
native IPv6 support and IPv6 transition/coexistence technologies on
'IPv4-only' networks and describes possible mitigations for the
aforementioned issues.Encapsulation MechanismsThere are many tunnels used for specific use cases. Except when
protected by IPsec or alternative
tunnel encryption methods, all those tunnels have a number of
security issues, as described in :
tunnel injection:
A malevolent actor knowing a few pieces of
information (for example, the tunnel endpoints and the
encapsulation protocol) can forge a packet that looks like a
legitimate and valid encapsulated packet that will gladly be
accepted by the destination tunnel endpoint. This is a specific
case of spoofing.
traffic interception:
No confidentiality is provided by the
tunnel protocols (without the use of IPsec or alternative
encryption methods); therefore, anybody on the tunnel path can
intercept the traffic and have access to the cleartext IPv6
packet. Combined with the absence of authentication, an on-path
attack can also be mounted.
service theft:
As there is no authorization, even an
unauthorized user can use a tunnel relay for free (this is a
specific case of tunnel injection).
reflection attack:
Another specific use case of tunnel
injection where the attacker injects packets with an IPv4
destination address not matching the IPv6 address causing the
first tunnel endpoint to re-encapsulate the packet to the
destination. Hence, the final IPv4 destination will not see
the original IPv4 address but only the IPv4 address of the relay
router.
bypassing security policy:
If a firewall or an Intrusion
Prevention System (IPS) is on the path of the tunnel, then it
may neither inspect nor detect malevolent IPv6 traffic
transmitted over the tunnel.
To mitigate the bypassing of security policies, it is often
recommended to block all automatic tunnels in default OS
configuration (if they are not required) by denying IPv4 packets
matching:
IP protocol 41:
This will block Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (), 6to4 (), 6rd (), and 6in4 () tunnels.
IP protocol 47:
This will block GRE ()
tunnels.
UDP port 3544:
This will block the default encapsulation of Teredo
() tunnels.
Ingress filtering should also
be applied on all tunnel endpoints, if applicable, to prevent IPv6
address spoofing.The reflection attack cited above should also be prevented by
using an IPv6 ACL preventing the hair pinning of the traffic.As several of the tunnel techniques share the same encapsulation
(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
. This RFC also proposes
mitigation techniques.Site-to-Site Static TunnelsSite-to-site static tunnels are described in and in GRE. As the IPv4 endpoints are statically
configured and are not dynamic, they are slightly more secure
(bidirectional service theft is mostly impossible), but traffic
interception and tunnel injection are still possible. Therefore,
the use of IPsec in transport mode
to protect the encapsulated IPv4 packets is recommended for those
tunnels. Alternatively, IPsec in tunnel mode can be used to
transport IPv6 traffic over an untrusted IPv4 network.ISATAPISATAP tunnels are mainly used within
a single administrative domain and to connect a single IPv6 host
to the IPv6 network. This often implies that those systems are
usually managed by a single entity; therefore, audit trail and
strict anti-spoofing are usually possible, and this raises the
overall security. Even if ISATAP is no more often used, its
security issues are relevant, per .Special care must be taken to avoid a looping attack by
implementing the measures of and (especially in Section ).IPsec in transport or tunnel mode
can be used to secure the IPv4 ISATAP traffic to provide IPv6
traffic confidentiality and prevent service theft.6rdWhile 6rd tunnels share the same encapsulation as 6to4 tunnels, they are designed to be
used within a single SP domain; in other words, they are deployed
in a more constrained environment (e.g., anti-spoofing, protocol
41 filtering at the edge) than 6to4 tunnels and have few security
issues other than lack of confidentiality. The security
considerations in
describes how to secure 6rd tunnels.IPsec for the transported
IPv6 traffic can be used if confidentiality is important.6PE, 6VPE, and LDPv6Organizations using MPLS in their core can also use IPv6 Provider Edge (6PE) and IPv6 Virtual Private Extension (6VPE) to enable
IPv6 access over MPLS. As 6PE and 6VPE are really similar to
BGP/MPLS IP VPNs described in , the
security properties of these networks are also similar to those
described in (please note that this RFC
may resemble a published IETF work, but it is not based on an IETF
review and the IETF disclaims any knowledge of the fitness of this
RFC for any purpose). They rely on:
address space, routing, and traffic separation with the
help of VRFs (only applicable to 6VPE);
hiding the IPv4 core, hence, removing all attacks against
P-routers; and
securing the routing protocol between Customer Edge (CE) and Provider
Edge (PE); in the
case of 6PE and 6VPE, link-local addresses (see ) can be used, and, as these addresses cannot
be reached from outside of the link, the security of 6PE and
6VPE is even higher than an IPv4 BGP/MPLS IP VPN.
LDPv6 itself does not induce new risks; see .DS-LiteDual-Stack Lite (DS-Lite) is also a translation mechanism and is therefore
analyzed further in this document,
as it includes IPv4 NAPT.Mapping of Address and PortWith the encapsulation and translation versions of Mapping of
Address and Port (MAP) -- abbreviated MAP-E and MAP-T -- the access
network is purely
an IPv6 network, and MAP protocols are used to provide IPv4 hosts
on the subscriber network access to IPv4 hosts on the Internet.
The subscriber router does stateful operations in order to map all
internal IPv4 addresses and Layer 4 ports to the IPv4 address and
the set of Layer 4 ports received through the MAP configuration
process. The SP equipment always does stateless operations (either
decapsulation or stateless translation). Therefore, as opposed to
, there is no state exhaustion DoS attack
against the SP equipment because there is no state and there is no
operation caused by a new Layer 4 connection (no logging
operation).The SP MAP equipment should implement all the security
considerations of , notably ensuring that
the mapping of the IPv4 address and port are consistent with the
configuration. As MAP has a predictable IPv4 address and port
mapping, the audit logs are easier to use, as there is a clear
mapping between the IPv6 address and the IPv4 address and
ports.6to4In , 6to4 tunnels require
a public-routable IPv4 address in order to work correctly. They can be used
to provide either single IPv6 host connectivity to the IPv6
Internet or multiple IPv6 networks connectivity to the IPv6
Internet. The 6to4 relay was historically the anycast address
defined in , which has been
deprecated by
and is no longer used by recent
Operating
Systems. Some security considerations are explained in . points out that if an operator
provides well-managed servers and relays for 6to4,
nonencapsulated IPv6 packets will pass through well-defined
points (the native IPv6 interfaces of those servers and relays) at
which security mechanisms may be applied. Client usage of 6to4 by
default is now discouraged, and significant precautions are needed
to avoid operational problems.TeredoTeredo tunnels are mainly used in a
residential environment because Teredo easily traverses an IPv4
NAPT device thanks to its UDP encapsulation. Teredo tunnels
connect a single host to the IPv6 Internet.
Teredo shares the same
issues as other tunnels: no authentication, no confidentiality,
possible spoofing, and reflection attacks.IPsec for the transported IPv6
traffic is recommended.The biggest threat to Teredo is probably for an IPv4-only
network, as Teredo has been designed to easily traverse IPv4 NAT-PT
devices, which are quite often co-located with a stateful firewall.
Therefore, if the stateful IPv4 firewall allows unrestricted UDP
outbound and accepts the return UDP traffic, then Teredo actually
punches a hole in this firewall for all IPv6 traffic to
and from the Internet. Host policies can be deployed to
block Teredo in an IPv4-only network in order to avoid this
firewall bypass. On the IPv4 firewall, all outbound UDPs should be
blocked except for the commonly used services (e.g., port 53 for
DNS, port 123 for NTP, port 443 for QUIC, port 500 for Internet Key Exchange
Protocol (IKE), port 3478 for Session Traversal Utilities for NAT (STUN),
etc.).Teredo is now hardly ever used and no longer enabled by default
in most environments so it is less of a threat; however, special
consideration must be made in cases when devices with older or
operating systems that have not been updated may be present and by default were
running Teredo.Translation MechanismsTranslation mechanisms between IPv4 and IPv6 networks are
alternate coexistence strategies while networks transition to IPv6.
While a framework is described in , the
specific security considerations are documented with each individual
mechanism. For the most part, they specifically mention interference
with IPsec or DNSSEC deployments, how to mitigate spoofed traffic,
and what some effective filtering strategies may be.While not really a transition mechanism to IPv6, this section
also includes the discussion about the use of heavy IPv4-to-IPv4
network addresses and port translation to prolong the life of
IPv4-only networks.Carrier-Grade NAT (CGN)Carrier-Grade NAT (CGN), also called NAT444 CGN or Large-Scale
NAT (LSN) or SP NAT, is described in and
is utilized as an interim measure to extend the use of IPv4 in a
large service provider network until the provider can deploy an
effective IPv6 solution. requested a
specific IANA-allocated /10 IPv4 address block to be used as
address space shared by all access networks using CGN. This has
been allocated as 100.64.0.0/10. lists some specific
security-related issues caused by large-scale address sharing. The
Security Considerations section of also
lists some specific mitigation techniques for potential misuse of
shared address space. Some law enforcement agencies have
identified CGN as impeding their cybercrime investigations (for
example, see the Europol press
release on
CGN). Many translation techniques (NAT64, DS-Lite, etc.)
have the same security issues as CGN when one part of the
connection is IPv4 only. has recommendations for
Internet-facing servers to also log the source TCP or UDP ports of
incoming connections in an attempt to help identify the users
behind such a CGN. suggests the use of deterministic
address mapping in order to reduce logging requirements for CGN.
The idea is to have a known algorithm for mapping the internal
subscriber to/from public TCP and UDP ports. lists common requirements for CGNs.
analyzes some solutions to enforce
policies on misbehaving nodes when address sharing is used. also updates the NAT behavioral
requirements.NAT64/DNS64 and 464XLATStateful NAT64 translation allows
IPv6-only clients to contact IPv4 servers using unicast UDP, TCP,
or ICMP. It can be used in conjunction with DNS64 , a mechanism that synthesizes AAAA records
from existing A records. There is also a stateless NAT64 , which has similar security aspects but
with the added benefit of being stateless and is thereby less prone to a state exhaustion attack.The Security Consideration sections of
and list the comprehensive issues; in
, there are some
considerations on the interaction between NAT64 and DNSSEC. A
specific issue with the use of NAT64 is that it will interfere
with most IPsec deployments unless UDP encapsulation is used.Another translation mechanism relying on a combination of
stateful and stateless translation, 464XLAT ,
can be used to do a host-local translation from
IPv4 to IPv6 and a network provider translation from IPv6 to IPv4,
i.e., giving IPv4-only application access to an IPv4-only server
over an IPv6-only network. 464XLAT shares the same security
considerations as NAT64 and DNS64; however, it can be used without
DNS64, avoiding the DNSSEC implications.DS-LiteDual-Stack Lite (DS-Lite) is a
transition technique that enables a service provider to share IPv4
addresses among customers by combining two well-known
technologies: IP in IP (IPv4-in-IPv6) and IPv4 NAPT.Security considerations, with respect to DS-Lite, mainly revolve
around logging data, preventing DoS attacks from rogue devices (as
the Address Family Translation Router (AFTR) function is stateful), and restricting service
offered by the AFTR only to registered customers. and describe important security issues associated
with this technology.General Device HardeningWith almost all devices being IPv6 enabled by default and with many
endpoints having IPv6 connectivity to the Internet, it is critical to
also harden those devices against attacks over IPv6.The same techniques used to protect devices against attacks over IPv4
should be used for IPv6 and should include but are not limited to:
restricting device access to authorized individuals;
monitoring and auditing access to the device;
turning off any unused services on the end node
understanding which IPv6 addresses are being used to source
traffic and changing defaults if necessary;
using cryptographically protected protocols for device management
(Secure Copy Protocol (SCP), SNMPv3, SSH, TLS, etc.);
using host firewall capabilities to control traffic that gets
processed by upper-layer protocols;
applying firmware, OS, and application patches/upgrades to the
devices in a timely manner;
using multifactor credentials to authenticate to devices; and
using virus scanners to detect malicious programs.
Enterprises-Specific Security ConsiderationsEnterprises generally have robust network
security policies in place to protect existing IPv4 networks. These
policies have been distilled from years of experiential knowledge of
securing IPv4 networks. At the very least, it is recommended that
enterprise networks have parity between their security policies for both
protocol versions. This section also applies to the enterprise part of
all SP networks, i.e., the part of the network where the SP employees
are connected.Security considerations in the enterprise can be broadly categorized
into two groups: external and internal.External Security ConsiderationsThe external aspect deals with providing security at the edge or
perimeter of the enterprise network where it meets the service
provider's network. This is commonly achieved by enforcing a security
policy, either by implementing dedicated firewalls with stateful packet
inspection or a router with ACLs. A common default IPv4 policy on
firewalls that could easily be ported to IPv6 is to allow all traffic
outbound while only allowing specific traffic, such as established
sessions, inbound (see ).
also provides similar
recommendations.Here are a few more things that could enhance the default policy:
Filter internal-use IPv6 addresses at the perimeter; this will
also mitigate the vulnerabilities listed in .
Discard packets from and to bogon and reserved space; see
and .
Accept certain ICMPv6 messages to allow proper operation of ND
and Path MTU Discovery (PMTUD); see or for hosts.
Based on the use of the network, filter specific extension
headers by accepting only the required ones (permit list approach),
such as ESP, AH, and not forgetting the required transport layers:
ICMP, TCP, UDP, etc. This filtering should be done where applicable
at the edge and possibly inside the perimeter; see .
Filter packets having an illegal IPv6 header chain at the
perimeter (and, if possible, inside the network as well); see .
Filter unneeded services at the perimeter.
Implement ingress and egress anti-spoofing in the forwarding
and control planes; see and .
Implement appropriate rate-limiters and control plane policers
based on traffic baselines.
Having global IPv6 addresses on all the enterprise sites is
different than in IPv4, where addresses are
often used internally and not routed over the Internet. and explain that without
careful design, there could be IPv6 leakages from Layer 3 VPNs.Internal Security ConsiderationsThe internal aspect deals with providing security inside the
perimeter of the network, including end hosts. Internal networks of
enterprises are often different, e.g., University campus, wireless guest
access, etc., so there is no "one size fits all" recommendation.The most significant concerns here are related to Neighbor
Discovery. At the network level, it is recommended that all security
considerations discussed in be reviewed
carefully and the recommendations be considered in-depth as well.
also provides some
recommendations.As mentioned in , care must be taken
when running automated IPv6-in-IPv4 tunnels.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 use of IPv4 private address space ,
sites might be able to communicate with each other over the Internet
even when the VPN mechanism is not available. Hence, no traffic
encryption is performed and traffic could be injected from the
Internet into the site; see . It is
recommended to filter at Internet connection(s) packets having a
source or destination address belonging to the site internal
prefix or prefixes; this should be done for ingress and egress traffic.Hosts need to be hardened directly through security policy to
protect against security threats. The host firewall default
capabilities have to be clearly understood. In some cases, third-party
firewalls have no IPv6 support, whereas the native firewall installed
by default has IPv6 support. General device hardening guidelines are
provided in .It should also be noted that many hosts still use IPv4 for
transporting logs for RADIUS, DIAMETER, TACACS+, syslog, etc.
Operators cannot rely on an IPv6-only security policy to secure such
protocols that are still using IPv4.Service Provider Security ConsiderationsBGPThe threats and mitigation techniques are identical between IPv4
and IPv6. Broadly speaking, they are:
authenticating the TCP session;
TTL security (which becomes hop-limit security in IPv6), as in
;
bogon AS filtering; see ; and
prefix filtering.
These are explained in more detail in .
Also, the recommendations of should be
considered.Remote Triggered Black Hole FilteringA Remote Triggered Black Hole (RTBH) works identically in IPv4 and IPv6.
IANA has allocated the 100::/64 prefix to be used as the discard
prefix .Transition/Coexistence MechanismSPs will typically use transition mechanisms, such as 6rd, 6PE, MAP,
and NAT64, which have been analyzed in the transition and coexistence
().Lawful InterceptThe lawful intercept requirements are similar for IPv6 and IPv4
architectures and will be subject to the laws enforced in different
geographic regions. The local issues with each jurisdiction can make
this challenging and both corporate legal and privacy personnel should
be involved in discussions pertaining to what information gets logged
and with regard to the respective log retention policies for this
information.The target of interception will usually be a residential subscriber
(e.g., his/her PPP session, physical line, or CPE MAC address). In the
absence of IPv6 NAT on the CPE, IPv6 has the possibility to 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
/48, /60, or /64).In contrast, in mobile environments, since the 3GPP specifications
allocate a /64 per device, it may be sufficient to intercept traffic
from the /64 rather than specific /128s (since each time the device
establishes a data connection, it gets a new IID).Residential Users Security ConsiderationsThe IETF Home Networking (homenet) Working Group is working on standards and
guidelines
for IPv6 residential networks; this obviously includes operational
security considerations, but this is still a work in progress. is an interesting approach on how firewalls could
retrieve and apply specific security policies to some residential
devices.Some residential users have less experience and knowledge about
security or networking than experimented operators. As most of the
recent hosts (e.g., smartphones and tablets) have IPv6 enabled by default,
IPv6 security is important for those users. Even with an IPv4-only ISP,
those users can get IPv6 Internet access with the help of Teredo tunnels. Several peer-to-peer programs
support IPv6, and those programs can initiate a Teredo tunnel through an
IPv4 residential gateway, with the consequence of making the internal
host reachable from any IPv6 host on the Internet. Therefore, it is
recommended that all host security products (including personal
firewalls) are configured with a dual-stack security policy.If the residential CPE has IPv6 connectivity, defines the requirements of an IPv6 CPE and does not
take a position on the debate of default IPv6 security policy, as defined
in :
outbound only:
Allowing all internally initiated connections and
blocking all externally initiated ones, which is a common default
security policy enforced by IPv4 residential gateway doing NAPT, but
it also breaks the end-to-end reachability promise of IPv6. lists several recommendations to design such a
CPE.
open/transparent:
Allowing all internally and externally
initiated connections, therefore, restoring the end-to-end nature of
the Internet for IPv6 traffic but having a different security policy
for IPv6 than for IPv4.
REC-49 states that a choice must be given to
the user to select one of those two policies .Further ReadingThere are several documents that describe in more detail 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 convenience:
Guidelines for the Secure Deployment of IPv6
North American IPv6 Task Force Technology Report - IPv6 Security Technology Paper
IPv6 Security
Security ConsiderationsThis memo attempts to give an overview of security considerations of
operating an IPv6 network both for an IPv6-only network and for networks
utilizing the most widely deployed IPv4/IPv6 coexistence strategies.IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesInformative ReferencesIP Flow Information Export (IPFIX) EntitiesIANARecommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit RoutersIEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access
ControlIEEEMapping the Great Void - Smarter scanning for IPv6IPv6 SecurityCiscoPressNorth American IPv6 Task Force (NAv6TF) Technology Report "IPv6
Security Technology PaperRegulation (EU) 2016/679 of the European Parliament and of
the Council of 27 April 2016 on the protection of natural persons
with regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (General
Data Protection Regulation)European UnionOfficial Journal of the European UnionRADb: The Internet Routing RegistryMerit Network, Inc.Are you sharing the same IP address as a criminal? Law enforcement call for the end of Carrier Grade Nat (CGN) to increase accountability onlineEuropolGuidelines for the Secure Deployment of IPv6Dynamic IPv6 Prefix - Problems and VPNsThe Bogon ReferenceTeam CymruLocal Packet Filtering with IPv6Plight at the End of the Tunnel: Legacy IPv6 Transition
Mechanisms in the WildEntropy/IP: Uncovering Structure in IPv6 AddressesAcknowledgementsThe authors would like to thank the following people for their useful
comments (in alphabetical order): , ,
, , , ,
,
(IESG Review), ,
(IESG review), , ,
, ,
(IESG
review), , ,
,
(IESG review), , ,
(and his detailed
nits), (and her detailed review),
(the
Document Shepherd), ,
(IESG review), (IESG review),
, ,
, , and
.