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