< draft-ietf-opsec-v6-24.txt.orig | draft-ietf-opsec-v6-24.txt > | |||
---|---|---|---|---|
skipping to change at page 1, line 28 ¶ | skipping to change at page 1, line 28 ¶ | |||
Knowledge and experience on how to operate IPv4 securely is | Knowledge and experience on how to operate IPv4 securely is | |||
available: whether it is the Internet or an enterprise internal | available: whether it is the Internet or an enterprise internal | |||
network. However, IPv6 presents some new security challenges. RFC | network. However, IPv6 presents some new security challenges. RFC | |||
4942 describes the security issues in the protocol, but network | 4942 describes the security issues in the protocol, but network | |||
managers also need a more practical, operations-minded document to | managers also need a more practical, operations-minded document to | |||
enumerate advantages and/or disadvantages of certain choices. | enumerate advantages and/or disadvantages of certain choices. | |||
This document analyzes the operational security issues associated | This document analyzes the operational security issues associated | |||
with several types of network and proposes technical and procedural | with several types of network and proposes technical and procedural | |||
mitigation techniques. This document is only applicable to managed | mitigation techniques. This document is only applicable to managed | |||
networks, such as enterprise building networks. The recommendations | networks, such as enterprise networks. The recommendations | |||
in this document are not applicable to residential user cases, even | in this document are not applicable to residential user cases, even | |||
in cases where a Service Provider may be managing the home gateway. | in cases where a Service Provider may be managing the home gateway. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
skipping to change at page 4, line 9 ¶ | skipping to change at page 4, line 9 ¶ | |||
This document complements [RFC4942] by listing all security issues | This document complements [RFC4942] by listing all security issues | |||
when operating a network (including various transition technologies). | when operating a network (including various transition technologies). | |||
It also provides more recent operational deployment experiences where | It also provides more recent operational deployment experiences where | |||
warranted. | warranted. | |||
1.1. Applicability Statement | 1.1. Applicability Statement | |||
This document is applicable to managed networks, i.e., when the | This document is applicable to managed networks, i.e., when the | |||
network is operated by the user organization itself. Indeed, many of | network is operated by the user organization itself. Indeed, many of | |||
the recommended mitigation techniques must be configured with the | the recommended mitigation techniques must be configured with | |||
detailed knowledge of the network (which are the default router, | detailed knowledge of the network (which are the default routers, | |||
which are the switch trunk ports, etc.). This covers Service | which are the switch trunk ports, etc.). This covers Service | |||
Provider (SP), enterprise networks and some knowledgeable-home-user- | Provider (SP), enterprise networksl and some knowledgeable-home-user- | |||
managed residential network. This applicability statement especially | managed residential network. This applicability statement especially | |||
applies to Section 2.3 and Section 2.5.4. | applies to Section 2.3 and Section 2.5.4. | |||
For example, an exception to the generic recommendations of this | For example, an exception to the generic recommendations of this | |||
document is when a residential or enterprise network is multi-homed. | document is when a residential or enterprise network is multi-homed. | |||
2. Generic Security Considerations | 2. Generic Security Considerations | |||
2.1. Addressing Architecture | 2.1. Addressing Architecture | |||
skipping to change at page 4, line 39 ¶ | skipping to change at page 4, line 39 ¶ | |||
could be utilized for IPv6 site renumbering and tries to cover most | could be utilized for IPv6 site renumbering and tries to cover most | |||
of the explicit issues and requirements associated with IPv6 | of the explicit issues and requirements associated with IPv6 | |||
renumbering. | renumbering. | |||
A key task for a successful IPv6 deployment is to prepare an | A key task for a successful IPv6 deployment is to prepare an | |||
addressing plan. Because an abundance of address space is available, | addressing plan. Because an abundance of address space is available, | |||
structuring an address plan around both services and geographic | structuring an address plan around both services and geographic | |||
locations allow address space to become a basis for more structured | locations allow address space to become a basis for more structured | |||
security policies to permit or deny services between geographic | security policies to permit or deny services between geographic | |||
regions. [RFC6177] documents some operational considerations of | regions. [RFC6177] documents some operational considerations of | |||
using different prefix size for address assignments to end sites. | using different prefix sizes for address assignments at end sites. | |||
A common question is whether companies should use Provider | A common question is whether companies should use Provider | |||
Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from | Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from | |||
a security perspective there is little difference. However, one | a security perspective there is little difference. However, one | |||
aspect to keep in mind is who has administrative ownership of the | aspect to keep in mind is who has administrative ownership of the | |||
address space and who is technically responsible if/when there is a | address space and who is technically responsible if/when there is a | |||
need to enforce restrictions on routability of the space, e.g., due | need to enforce restrictions on routability of the space, e.g., due | |||
to malicious criminal activity originating from it. Relying on PA | to malicious criminal activity originating from it. Relying on PA | |||
address may also force the use of NPTv6 and therefore augmenting the | address may also force the use of NPTv6 and therefore augmenting the | |||
complexity of the operations including the security operations. | complexity of the operations including the security operations. | |||
skipping to change at page 5, line 44 ¶ | skipping to change at page 5, line 44 ¶ | |||
point links. While this practice could further reduce the attack | point links. While this practice could further reduce the attack | |||
surface of infrastructure devices, the operational disadvantages also | surface of infrastructure devices, the operational disadvantages also | |||
need to be carefully considered; see also [RFC7404]. | need to be carefully considered; see also [RFC7404]. | |||
2.1.3. Loopback Addresses | 2.1.3. Loopback Addresses | |||
Many operators reserve a /64 block for all loopback addresses in | Many operators reserve a /64 block for all loopback addresses in | |||
their infrastructure and allocate a /128 out of this reserved /64 | their infrastructure and allocate a /128 out of this reserved /64 | |||
prefix for each loopback interface. This practice facilitates | prefix for each loopback interface. This practice facilitates | |||
configuration of Access Control List (ACL) rules to enforce a | configuration of Access Control List (ACL) rules to enforce a | |||
security policy for those loopback addresses | security policy for those loopback addresses. | |||
2.1.4. Stable Addresses | 2.1.4. Stable Addresses | |||
When considering how to assign stable addresses (either by static | When considering how to assign stable addresses (either by static | |||
configuration or by pre-provisioned DHCPv6 lease Section 2.1.6), it | configuration or by pre-provisioned DHCPv6 lease Section 2.1.6), it | |||
is necessary to take into consideration the effectiveness of | is necessary to take into consideration the effectiveness of | |||
perimeter security in a given environment. | perimeter security in a given environment. | |||
There is a trade-off between ease of operation (where some portions | There is a trade-off between ease of operation (where some portions | |||
of the IPv6 address could be easily recognizable for operational | of the IPv6 address could be easily recognizable for operational | |||
skipping to change at page 6, line 26 ¶ | skipping to change at page 6, line 26 ¶ | |||
The use of well-known IPv6 addresses (such as ff02::1 for all link- | The use of well-known IPv6 addresses (such as ff02::1 for all link- | |||
local nodes) or the use of commonly repeated addresses could make it | local nodes) or the use of commonly repeated addresses could make it | |||
easy to figure out which devices are name servers, routers, or other | easy to figure out which devices are name servers, routers, or other | |||
critical devices; even a simple traceroute will expose most of the | critical devices; even a simple traceroute will expose most of the | |||
routers on a path. There are many scanning techniques possible and | routers on a path. There are many scanning techniques possible and | |||
operators should not rely on the 'impossible to find because my | operators should not rely on the 'impossible to find because my | |||
address is random' paradigm (a.k.a. "security by obscurity"), even if | address is random' paradigm (a.k.a. "security by obscurity"), even if | |||
it is common practice to have the stable addresses randomly | it is common practice to have the stable addresses randomly | |||
distributed across /64 subnets and to always use DNS (as IPv6 | distributed across /64 subnets and to always use DNS (as IPv6 | |||
addresses are hard to remember for the human brains). | addresses are hard for human brains to remember). | |||
While in some environments obfuscating addresses could be considered | While in some environments obfuscating addresses could be considered | |||
an added benefit, it does not preclude enforcement of perimeter rules | an added benefit, it does not preclude enforcement of perimeter rules | |||
and that stable addresses follow some logical allocation scheme for | and that stable addresses follow some logical allocation scheme for | |||
ease of operation (as simplicity always helps security). | ease of operation (as simplicity always helps security). | |||
Typical deployments will have a mix of stable and non-stable | Typical deployments will have a mix of stable and non-stable | |||
addresses; the stable addresses being either predicatable (e.g., ::25 | addresses; the stable addresses being either predicatable (e.g., ::25 | |||
for a mail server) or obfuscated (i.e., appearing as a random 64-bit | for a mail server) or obfuscated (i.e., appearing as a random 64-bit | |||
number). | number). | |||
skipping to change at page 7, line 51 ¶ | skipping to change at page 7, line 51 ¶ | |||
2.1.6. DHCP and DNS Considerations | 2.1.6. DHCP and DNS Considerations | |||
Even if the use of DHCP is not mandated by [RFC8504], some | Even if the use of DHCP is not mandated by [RFC8504], some | |||
environments use DHCPv6 to provision addresses and other parameters | environments use DHCPv6 to provision addresses and other parameters | |||
in order to ensure auditability and traceability (see | in order to ensure auditability and traceability (see | |||
Section 2.6.1.5) for the limitations of DHCPv6 for auditability. | Section 2.6.1.5) for the limitations of DHCPv6 for auditability. | |||
A main security concern is the ability to detect and counteract rogue | A main security concern is the ability to detect and counteract rogue | |||
DHCP servers (Section 2.3.3). It must be noted that as opposed to | DHCP servers (Section 2.3.3). It must be noted that as opposed to | |||
DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For | DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For | |||
DHCPv4, the lease is bond to the 'client identifier', which may | DHCPv4, the lease is bound to the 'client identifier', which may | |||
contain a hardware address, or it may contain another type of | contain a hardware address, or it may contain another type of | |||
identifier, such as a DNS name. For DHCPv6, the lease is bound to | identifier, such as a DNS name. For DHCPv6, the lease is bound to | |||
the client DHCP Unique ID (DUID) which is also not always bound to | the client DHCP Unique ID (DUID) which is also not always bound to | |||
the client link-layer address. [RFC7824] describes the privacy | the client link-layer address. [RFC7824] describes the privacy | |||
issues associated with the use of DHCPv6 by Internet users. The | issues associated with the use of DHCPv6 by Internet users. The | |||
anonymity profiles [RFC7844] are designed for clients that wish to | anonymity profiles [RFC7844] are designed for clients that wish to | |||
remain anonymous to the visited network. [RFC7707] recommends that | remain anonymous to the visited network. [RFC7707] recommends that | |||
DHCPv6 servers issue addresses randomly from a large pool. | DHCPv6 servers issue addresses randomly from a large pool. | |||
While there are no fundamental differences with IPv4 and IPv6 DNS | While there are no fundamental differences with IPv4 and IPv6 DNS | |||
skipping to change at page 8, line 32 ¶ | skipping to change at page 8, line 32 ¶ | |||
[RFC8273] especially in a shared environment. This allows for easier | [RFC8273] especially in a shared environment. This allows for easier | |||
user attribution (typically based on the host MAC address) as its /64 | user attribution (typically based on the host MAC address) as its /64 | |||
prefix is stable even if applications within the host can change | prefix is stable even if applications within the host can change | |||
their IPv6 address within this /64 prefix. | their IPv6 address within this /64 prefix. | |||
2.1.8. Privacy consideration of Addresses | 2.1.8. Privacy consideration of Addresses | |||
Beside the security aspects of IPv6 addresses, there are also privacy | Beside the security aspects of IPv6 addresses, there are also privacy | |||
considerations: mainly because they are of global scope and visible | considerations: mainly because they are of global scope and visible | |||
globally. [RFC7721] goes into more detail on the privacy | globally. [RFC7721] goes into more detail on the privacy | |||
considerations for IPv6 addresses by comparing the manually | considerations for IPv6 addresses by comparing manually | |||
configured IPv6 address, DHCPv6 or SLAAC. | configured IPv6 addresses, DHCPv6, and SLAAC. | |||
2.2. Extension Headers | 2.2. Extension Headers | |||
Extension headers are an important difference between IPv4 and IPv6. | Extension headers are an important difference between IPv4 and IPv6. | |||
In IPv4-based packets, it's trivial to find the upper layer protocol | In IPv4-based packets, it's trivial to find the upper-layer protocol | |||
type and protocol header, while in IPv6 it is more complex since the | type and protocol header, while in IPv6 it is more complex since the | |||
extension header chain must be parsed completely (even if not | extension header chain must be parsed completely (even if not | |||
processed) in order to find the upper layer protocol header. IANA | processed) in order to find the upper-layer protocol header. IANA | |||
has closed the existing empty "Next Header Types" registry to new | has closed the existing empty "Next Header Types" registry to new | |||
entries and is redirecting its users to a new "IPv6 Extension Header | entries and is redirecting its users to a new "IPv6 Extension Header | |||
Types" registry per [RFC7045]. | Types" registry per [RFC7045]. | |||
Extension headers have also become a very controversial topic since | Extension headers have also become a very controversial topic since | |||
forwarding nodes that discard packets containing extension headers | forwarding nodes that discard packets containing extension headers | |||
are known to cause connectivity failures and deployment problems | are known to cause connectivity failures and deployment problems | |||
[RFC7872]. Understanding the role of varying extension headers is | [RFC7872]. Understanding the role of varying extension headers is | |||
important and this section enumerates the ones that need careful | important and this section enumerates the ones that need careful | |||
consideration. | consideration. | |||
skipping to change at page 9, line 32 ¶ | skipping to change at page 9, line 32 ¶ | |||
While [RFC8200] recommends the order and the maximum repetition of | While [RFC8200] recommends the order and the maximum repetition of | |||
extension headers, there are still IPv6 implementations, at the time | extension headers, there are still IPv6 implementations, at the time | |||
of writing, which support a non-recommended order of headers (such as | of writing, which support a non-recommended order of headers (such as | |||
ESP before routing) or an illegal repetition of headers (such as | ESP before routing) or an illegal repetition of headers (such as | |||
multiple routing headers). The same applies for options contained in | multiple routing headers). The same applies for options contained in | |||
the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]). | the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]). | |||
In some cases, it has led to nodes crashing when receiving or | In some cases, it has led to nodes crashing when receiving or | |||
forwarding wrongly formatted packets. | forwarding wrongly formatted packets. | |||
A firewall or edge device should be used to enforce the recommended | A firewall or edge device should be used to enforce the recommended | |||
order and the maximum of occurrences of extension headers. | order and the maximum occurrences of extension headers. | |||
2.2.2. Hop-by-Hop Options Header | 2.2.2. Hop-by-Hop Options Header | |||
In the previous IPv6 specification [RFC2460], the hop-by-hop options | In the previous IPv6 specification [RFC2460], the hop-by-hop options | |||
header, when present in an IPv6 packet, forced all nodes to inspect | header, when present in an IPv6 packet, forced all nodes to inspect | |||
and possibly process this header. This enabled denial-of-service | and possibly process this header. This enabled denial-of-service | |||
attacks as most, if not all, routers can not process this kind of | attacks as most, if not all, routers cannot process this type of | |||
packet in hardware but have to process this packet in software hence | packet in hardware but have to process these packets in software and | |||
competing with other software tasks such as handling the control and | hence compete with other software tasks, such as, control and management | |||
management planes. | plane processing. | |||
Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has | Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has | |||
taken this attack vector into account and made the processing of hop- | taken this attack vector into account and made the processing of hop- | |||
by-hop options header by intermediate routers explicitly | by-hop options headers by intermediate routers explicitly | |||
configurable. | configurable. | |||
2.2.3. Fragment Header | 2.2.3. Fragment Header | |||
The fragment header is used by the source (and only the source) when | The fragment header is used by the source (and only the source) when | |||
it has to fragment packets. [RFC7112] and section 4.5 of [RFC8200] | it has to fragment packets. [RFC7112] and section 4.5 of [RFC8200] | |||
explain why it is important that: | explain why it is important that: | |||
Firewall and security devices should drop first fragments that do | Firewall and security devices should drop first fragments that do | |||
not contain the entire ipv6 header chain (including the transport- | not contain the entire ipv6 header chain (including the transport- | |||
skipping to change at page 10, line 29 ¶ | skipping to change at page 10, line 29 ¶ | |||
If those requirements are not met, stateless filtering could be | If those requirements are not met, stateless filtering could be | |||
bypassed by a hostile party. [RFC6980] applies a stricter rule to | bypassed by a hostile party. [RFC6980] applies a stricter rule to | |||
Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented | Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented | |||
NDP packets. [RFC7113] describes how the RA-guard function described | NDP packets. [RFC7113] describes how the RA-guard function described | |||
in [RFC6105] should behave in the presence of fragmented RA packets. | in [RFC6105] should behave in the presence of fragmented RA packets. | |||
2.2.4. IP Security Extension Header | 2.2.4. IP Security Extension Header | |||
The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP | The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP | |||
[RFC4303]) are required if IPsec is to be utilized for network level | [RFC4303]) are required if IPsec is to be utilized for network level | |||
security. But IPsec is no more required for normal IPv6 nodes: in | security. But IPsec is no longer required for normal IPv6 nodes: in | |||
the updated IPv6 Nodes Requirement standard <xref target="RFC8504"/> | the updated IPv6 Nodes Requirement standard [RFC8504], | |||
IPsec is a 'SHOULD' and not a 'MUST' implement. | IPsec is a 'SHOULD' and not a 'MUST' implement. | |||
2.3. Link-Layer Security | 2.3. Link-Layer Security | |||
IPv6 relies heavily on NDP [RFC4861] to perform a variety of link | IPv6 relies heavily on NDP [RFC4861] to perform a variety of link | |||
operations such as discovering other nodes on the link, resolving | operations such as discovering other nodes on the link, resolving | |||
their link-layer addresses, and finding routers on the link. If not | their link-layer addresses, and finding routers on the link. If not | |||
secured, NDP is vulnerable to various attacks such as router/neighbor | secured, NDP is vulnerable to various attacks such as router/neighbor | |||
message spoofing, redirect attacks, Duplicate Address Detection (DAD) | message spoofing, redirect attacks, Duplicate Address Detection (DAD) | |||
DoS attacks, etc. Many of these security threats to NDP have been | DoS attacks, etc. Many of these security threats to NDP have been | |||
documented in IPv6 ND Trust Models and Threats [RFC3756] and in | documented in IPv6 ND Trust Models and Threats [RFC3756] and in | |||
[RFC6583]. | [RFC6583]. | |||
NDP has even issues when the attacker is off-link see the section | NDP even has issues when the attacker is off-link, see the section | |||
below Section 2.3.1; but, most of the issues are only when the | below Section 2.3.1; but, most of the issues are only when the | |||
attacker is on the same link. | attacker is on the same link. | |||
2.3.1. Neighbor Solicitation Rate Limiting | 2.3.1. Neighbor Solicitation Rate-Limiting | |||
Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial | Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial- | |||
of service (DoS) attacks; for example, when a router is forced to | of-service (DoS) attacks; for example, when a router is forced to | |||
perform address resolution for a large number of unassigned | perform address resolution for a large number of unassigned | |||
addresses, i.e., a neighbor cache exhaustion attack. This can keep | addresses, i.e., a neighbor cache exhaustion attack. This can keep | |||
new devices from joining the network or render the last hop router | new devices from joining the network or render the last-hop router | |||
ineffective due to high CPU usage. Easy mitigative steps include | ineffective due to high CPU usage. Easy mitigative steps include | |||
rate limiting Neighbor Solicitations, restricting the amount of state | rate-limiting Neighbor Solicitations, restricting the amount of state | |||
reserved for unresolved solicitations, and clever cache/timer | reserved for unresolved solicitations, and clever cache/timer | |||
management. | management. | |||
[RFC6583] discusses the potential for off-link DoS in detail and | [RFC6583] discusses the potential for off-link DoS in detail and | |||
suggests implementation improvements and operational mitigation | suggests implementation improvements and operational mitigation | |||
techniques that may be used to mitigate or alleviate the impact of | techniques that may be used to mitigate or alleviate the impact of | |||
such attacks. Here are some feasible mitigation options that can be | such attacks. Here are some feasible mitigation options that can be | |||
employed by network operators today: | employed by network operators today: | |||
o Ingress filtering of unused addresses by ACL. These require | o Ingress filtering of unused addresses by ACL. These require | |||
stable configuration of the addresses; for example, allocating the | stable configuration of the addresses; for example, allocating the | |||
addresses out of a /120 and using a specific ACL to only allow | addresses out of a /120 and using a specific ACL to only allow | |||
traffic to this /120 (of course, the actual hosts are configured | traffic to this /120 (of course, the actual hosts are configured | |||
with a /64 prefix for the link). | with a /64 prefix for the link). | |||
o Tuning of NDP process (where supported). | o Tuning of NDP process (where supported). | |||
o Using /127 on point-to-point link per [RFC6164]. | o Using /127 on point-to-point link per [RFC6164]. | |||
o Using link-local addresses only on links where there are only | o Using link-local addresses only on links where there are only | |||
routers see [RFC7404] | routers, see [RFC7404] | |||
2.3.2. Router and Neighbor Advertisements Filtering | 2.3.2. Router and Neighbor Advertisements Filtering | |||
2.3.2.1. Router Advertisement Filtering | 2.3.2.1. Router Advertisement Filtering | |||
Router Advertisement spoofing is a well-known on-link attack vector | Router Advertisement spoofing is a well-known on-link attack vector | |||
and has been extensively documented. The presence of rogue RAs, | and has been extensively documented. The presence of rogue RAs, | |||
either unintentional or malicious, can cause partial or complete | either unintentional or malicious, can cause partial or complete | |||
failure of operation of hosts on an IPv6 link. For example, a host | failure of operation of hosts on an IPv6 link. For example, a host | |||
can select an incorrect router address which can be used as on-path | can select an incorrect router address which can be used as on-path | |||
attack or can assume wrong prefixes to be used for SLAAC. [RFC6104] | attack or can assume wrong prefixes to be used for SLAAC. [RFC6104] | |||
summarizes the scenarios in which rogue RAs may be observed and | summarizes the scenarios in which rogue RAs may be observed and | |||
presents a list of possible solutions to the problem. [RFC6105] (RA- | presents a list of possible solutions to the problem. [RFC6105] (RA- | |||
Guard) describes a solution framework for the rogue RA problem where | Guard) describes a solution framework for the rogue RA problem where | |||
network segments are designed around switching devices that are | network segments are designed around switching devices that are | |||
capable of identifying invalid RAs and blocking them before the | capable of identifying invalid RAs and blocking them before the | |||
attack packets actually reach the target nodes. | attack packets actually reach the target nodes. | |||
However, several evasion techniques that circumvent the protection | However, several evasion techniques that circumvent the protection | |||
provided by RA-Guard have surfaced. A key challenge to this | provided by RA-Guard have surfaced. A key challenge to this | |||
mitigation technique is introduced by IPv6 fragmentation. Attacker | mitigation technique is introduced by IPv6 fragmentation. Attackers | |||
can conceal their attack by fragmenting their packets into multiple | can conceal their attack by fragmenting their packets into multiple | |||
fragments such that the switching device that is responsible for | fragments such that the switching device that is responsible for | |||
blocking invalid RAs cannot find all the necessary information to | blocking invalid RAs cannot find all the necessary information to | |||
perform packet filtering of the same packet. [RFC7113] describes | perform packet filtering of the same packet. [RFC7113] describes | |||
such evasion techniques and provides advice to RA-Guard implementers | such evasion techniques and provides advice to RA-Guard implementers | |||
such that the aforementioned evasion vectors can be eliminated. | such that the aforementioned evasion vectors can be eliminated. | |||
Given that the IPv6 Fragmentation Header can be leveraged to | Given that the IPv6 Fragmentation Header can be leveraged to | |||
circumvent current implementations of RA-Guard, [RFC6980] updates | circumvent current implementations of RA-Guard, [RFC6980] updates | |||
[RFC4861] such that use of the IPv6 Fragmentation Header is forbidden | [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden | |||
skipping to change at page 12, line 29 ¶ | skipping to change at page 12, line 29 ¶ | |||
worked on other ways to mitigate the effects of such attacks. | worked on other ways to mitigate the effects of such attacks. | |||
[RFC7513] helps in creating bindings between a DHCPv4 [RFC2131] | [RFC7513] helps in creating bindings between a DHCPv4 [RFC2131] | |||
/DHCPv6 [RFC8415] assigned source IP address and a binding anchor | /DHCPv6 [RFC8415] assigned source IP address and a binding anchor | |||
[RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean | [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean | |||
similar bindings when DHCP is not used. The bindings can be used to | similar bindings when DHCP is not used. The bindings can be used to | |||
filter packets generated on the local link with forged source IP | filter packets generated on the local link with forged source IP | |||
addresses. | addresses. | |||
2.3.2.3. Host Isolation | 2.3.2.3. Host Isolation | |||
Isolating hosts for the NDP traffic canbe done by using a /64 per | Isolating hosts for the NDP traffic can be done by using a /64 per | |||
host Section 2.1.7 as NDP is only relevant within a /64 on-link | host as NDP is only relevant within a /64 on-link prefix, refer to | |||
prefix; 3GPP Section 2.3.4 uses a similar mechanism. | Section 2.7.1. 3GPP Section 2.3.4 uses a similar mechanism. | |||
A more drastic technique to prevent all NDP attacks is based on | A more drastic technique to prevent all NDP attacks is based on | |||
isolation of all hosts with specific configurations. Hosts (i.e., | isolation of all hosts with specific configurations. Hosts (i.e., | |||
all nodes that are not routers) are unable to send data-link layer | all nodes that are not routers) are unable to send data-link layer | |||
frames to other hosts, therefore, no host-to-host attacks can happen. | frames to other hosts, therefore, no host-to-host attacks can happen. | |||
This specific setup can be established on some switches or Wi-Fi | This specific setup can be established on some switches or Wi-Fi | |||
access points. Of course, this is not always feasible when hosts | access points. Of course, this is not always feasible when hosts | |||
need to communicate with other hosts. | need to communicate directly with other hosts. | |||
2.3.2.4. NDP Recommendations | 2.3.2.4. NDP Recommendations | |||
It is still recommended that RA-Guard and SAVI be employed as a first | It is still recommended that RA-Guard and SAVI be employed as a first | |||
line of defense against common attack vectors including misconfigured | line of defense against common attack vectors including misconfigured | |||
hosts. This recommendation also applies when DHCPv6 is used as RA | hosts. This recommendation also applies when DHCPv6 is used as RAs | |||
are used to discover the default router(s) and for on-link prefix | are used to discover the default router(s) and for on-link prefix | |||
determination. This line of defense is most effective when | determination. This line of defense is most effective when | |||
incomplete fragments are dropped by routers and switches as described | incomplete fragments are dropped by routers and switches as described | |||
in Section 2.2.3. The generated log should also be analyzed to | in Section 2.2.3. The generated log should also be analyzed to | |||
identify and act on violations. Network operators should be aware | identify and act on violations. Network operators should be aware | |||
that RA-Guard and SAVI do not work or could even be harmful in | that RA-Guard and SAVI do not work or could even be harmful in | |||
specific network configurations (notably when there could be multiple | specific network configurations (notably when there could be multiple | |||
routers). Only trivial cases (e.g., a Wi-Fi network having the | routers). Only trivial cases (e.g., a Wi-Fi network having the | |||
routers on the uplink interfaces of the As) should have RA-guard and | routers on the uplink interfaces of the As) should have RA-guard and | |||
SAVI enabled by default. | SAVI enabled by default. | |||
2.3.3. Securing DHCP | 2.3.3. Securing DHCP | |||
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described | Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described | |||
in [RFC8415], enables DHCP servers to pass configuration parameters | in [RFC8415], enables DHCP servers to pass configuration parameters | |||
such as IPv6 network addresses and other configuration information to | such as IPv6 network addresses and other configuration information to | |||
IPv6 nodes such as an hostile recursive DNS server. DHCP plays an | IPv6 nodes such as a hostile recursive DNS server. DHCP plays an | |||
important role in most large networks by providing robust stateful | important role in most large networks by providing robust stateful | |||
configuration in the context of automated system provisioning. | configuration in the context of automated system provisioning. | |||
The two most common threats to DHCP clients come from malicious | The two most common threats to DHCP clients come from malicious | |||
(a.k.a., rogue) or unintentionally misconfigured DHCP servers. A | (a.k.a., rogue) or unintentionally misconfigured DHCP servers. A | |||
malicious DHCP server is established with the intent of providing | malicious DHCP server is established with the intent of providing | |||
incorrect configuration information to the clients to cause a denial | incorrect configuration information to the clients to cause a denial- | |||
of service attack or to mount on path attack. While unintentional, a | of-service attack or to mount on path attack. While unintentional, a | |||
misconfigured DHCP server can have the same impact. Additional | misconfigured DHCP server can have the same impact. Additional | |||
threats against DHCP are discussed in the security considerations | threats against DHCP are discussed in the security considerations | |||
section of [RFC8415]. | section of [RFC8415]. | |||
DHCPv6-Shield, [RFC7610], specifies a mechanism for protecting | DHCPv6-Shield, [RFC7610], specifies a mechanism for protecting | |||
connected DHCPv6 clients against rogue DHCPv6 servers. This | connected DHCPv6 clients against rogue DHCPv6 servers. This | |||
mechanism is based on DHCPv6 packet-filtering at the layer-2 device; | mechanism is based on DHCPv6 packet-filtering at the layer-2 device; | |||
i.e., the administrator specifies the interfaces connected to DHCPv6 | i.e., the administrator specifies the interfaces connected to DHCPv6 | |||
servers. However, extension headers could be leveraged to bypass | servers. However, extension headers could be leveraged to bypass | |||
DHCPv6-Shield unless [RFC7112] is enforced. | DHCPv6-Shield unless [RFC7112] is enforced. | |||
skipping to change at page 14, line 16 ¶ | skipping to change at page 14, line 16 ¶ | |||
mobile host's address). | mobile host's address). | |||
The 3GPP link model itself mitigates most of the known NDP-related | The 3GPP link model itself mitigates most of the known NDP-related | |||
Denial-of-Service attacks. In practice, the GGSN/PGW only needs to | Denial-of-Service attacks. In practice, the GGSN/PGW only needs to | |||
route all traffic to the mobile host that falls under the prefix | route all traffic to the mobile host that falls under the prefix | |||
assigned to it. As there is also a single host on the 3GPP link, | assigned to it. As there is also a single host on the 3GPP link, | |||
there is no need to defend that IPv6 address. | there is no need to defend that IPv6 address. | |||
See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP | See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP | |||
link model, NDP on it and the address configuration details. In some | link model, NDP on it and the address configuration details. In some | |||
mobile network, DHCPv6 and DHCP-PD are also used. | mobile networks, DHCPv6 and DHCP-PD are also used. | |||
2.3.5. Impact of Multicast Traffic | 2.3.5. Impact of Multicast Traffic | |||
IPv6 uses multicast extensively for signaling messages on the local | IPv6 uses multicast extensively for signaling messages on the local | |||
link to avoid broadcast messages for on-the-wire efficiency. | link to avoid broadcast messages for on-the-wire efficiency. | |||
The use of multicast has some side effects on wireless networks, such | The use of multicast has some side effects on wireless networks, such | |||
as a negative impact on battery life of smartphones and other | as a negative impact on battery life of smartphones and other | |||
battery-operated devices that are connected to such networks. | battery-operated devices that are connected to such networks. | |||
[RFC7772], [RFC6775] (for specific wireless networks) are discussing | [RFC7772], [RFC6775] (for specific wireless networks) discuss | |||
methods to rate limit RAs and other ND messages on wireless networks | methods to rate-limit RAs and other ND messages on wireless networks | |||
in order to address this issue. | in order to address this issue. | |||
The use of link-layer multicast addresses (e.g., ff02::1 for the all | The use of link-layer multicast addresses (e.g., ff02::1 for the all | |||
nodes link-local multicast address) could also be mis-used for an | nodes link-local multicast address) could also be misused for an | |||
amplification attack. Image, a hostile node sending an ICMPv6 | amplification attack. Imagine, a hostile node sending an ICMPv6 | |||
ECHO_REQUEST to ff02::1 with a spoofed source address, then, all | ECHO_REQUEST to ff02::1 with a spoofed source address, then, all | |||
link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the | link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the | |||
source address. This could be a DoS for the victim. This attack is | source address. This could be a DoS attack for the address owner. | |||
purely local to the layer-2 network as packets with a link-local | This attack is purely local to the layer-2 network as packets with | |||
destination are never forwarded by an IPv6 router. | a link-local destination are never forwarded by an IPv6 router. | |||
This is the reason why large Wi-Fi network deployments limit the use | This is the reason why large Wi-Fi network deployments limit the use | |||
of link-layer multicast either from or to the uplink of the Wi-Fi | of link-layer multicast either from or to the uplink of the Wi-Fi | |||
access point; i.e., Wi-Fi stations cannot send link-local multicast | access point; i.e., Wi-Fi stations cannot send link-local multicast | |||
to their direct neighboring Wi-Fi stations. | to their direct neighboring Wi-Fi stations. | |||
2.3.6. SeND and CGA | 2.3.6. SeND and CGA | |||
SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a | SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a | |||
mechanism that was designed to secure ND messages. This approach | mechanism that was designed to secure ND messages. This approach | |||
skipping to change at page 15, line 32 ¶ | skipping to change at page 15, line 32 ¶ | |||
SeND does NOT: | SeND does NOT: | |||
o Protect statically configured addresses | o Protect statically configured addresses | |||
o Protect addresses configured using fixed identifiers (i.e., EUI- | o Protect addresses configured using fixed identifiers (i.e., EUI- | |||
64) | 64) | |||
o Provide confidentiality for NDP communications | o Provide confidentiality for NDP communications | |||
o Compensate for an unsecured link - SEND does not require that the | o Compensate for an unsecured link - SeND does not require that the | |||
addresses on the link and Neighbor Advertisements correspond. | addresses on the link and Neighbor Advertisements correspond. | |||
However, at this time and over a decade since their original | However, at this time and over a decade since their original | |||
specifications, CGA and SeND do not have wide support from widely | specifications, CGA and SeND do not have support from widely | |||
used end points; hence, their usefulness is limited and should not be | deployed IPv6 devices; hence, their usefulness is limited and should not be | |||
relied upon. | relied upon. | |||
2.4. Control Plane Security | 2.4. Control Plane Security | |||
[RFC6192] defines the router control plane and provides detailed | [RFC6192] defines the router control plane and provides detailed | |||
guidance to secure it for IPv4 and IPv6 networks. This definition is | guidance to secure it for IPv4 and IPv6 networks. This definition is | |||
repeated here for the reader's convenience. Please note that the | repeated here for the reader's convenience. Please note that the | |||
definition is completely protocol-version agnostic (most of this | definition is completely protocol-version agnostic (most of this | |||
section applies to IPv6 in the same way as to IPv4). | section applies to IPv6 in the same way as to IPv4). | |||
skipping to change at page 16, line 33 ¶ | skipping to change at page 16, line 33 ¶ | |||
plane processor is then unable to process valid control packets and | plane processor is then unable to process valid control packets and | |||
the router can lose OSPF or BGP adjacencies which can cause a severe | the router can lose OSPF or BGP adjacencies which can cause a severe | |||
network disruption. | network disruption. | |||
[RFC6192] provides detailed guidance to protect the router control | [RFC6192] provides detailed guidance to protect the router control | |||
plane in IPv6 networks. The rest of this section contains simplified | plane in IPv6 networks. The rest of this section contains simplified | |||
guidance. | guidance. | |||
The mitigation techniques are: | The mitigation techniques are: | |||
o To drop non-legit control packet before they are queued to the RP | o To drop non-legit control packets before they are queued to the RP | |||
(this can be done by a forwarding plane ACL) and | (this can be done by a forwarding plane ACL) and | |||
o To rate limit the remaining packets to a rate that the RP can | o To rate-limit the remaining packets to a rate that the RP can | |||
sustain. Protocol specific protection should also be done (for | sustain. Protocol-specific protection should also be done (for | |||
example, a spoofed OSPFv3 packet could trigger the execution of | example, a spoofed OSPFv3 packet could trigger the execution of | |||
the Dijkstra algorithm, therefore, the frequency of Dijsktra | the Dijkstra algorithm, therefore, the frequency of Dijsktra | |||
calculations should be also rate limited). | calculations should be also rate-limited). | |||
This section will consider several classes of control packets: | This section will consider several classes of control packets: | |||
o Control protocols: routing protocols: such as OSPFv3, BGP and by | o Control protocols: routing protocols: such as OSPFv3, BGP, RIPng, | |||
extension Neighbor Discovery and ICMP | and by extension, NDP and ICMP | |||
o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc | o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc | |||
o Packet exceptions: normal data packets which requires a specific | o Packet exceptions: normal data packets which require a specific | |||
processing such as generating a packet-too-big ICMP message or | processing such as generating a packet-too-big ICMP message or | |||
processing the hop-by-hop options header. | processing the hop-by-hop options header. | |||
2.4.1. Control Protocols | 2.4.1. Control Protocols | |||
This class includes OSPFv3, BGP, NDP, ICMP. | This class includes OSPFv3, BGP, RIPng, NDP, ICMP. | |||
An ingress ACL to be applied on all the router interfaces for packets | An ingress ACL to be applied on all the router interfaces for packets | |||
to be processed by the RP should be configured so as to: | to be processed by the RP should be configured to: | |||
o drop OSPFv3 (identified by Next-Header being 89) and RIPng | o drop OSPFv3 (identified by Next-Header being 89) and RIPng | |||
(identified by UDP port 521) packets from a non link-local address | (identified by UDP port 521) packets from a non link-local address | |||
(except for OSPFv3 virtual links) | (except for OSPFv3 virtual links) | |||
o allow BGP (identified by TCP port 179) packets from all BGP | o allow BGP (identified by TCP port 179) packets from all BGP | |||
neighbors and drop the others | neighbors and drop the others | |||
o allow all ICMP packets (transit and to the router interfaces) | o allow all ICMP packets (transit and to the router interfaces) | |||
Note: dropping OSPFv3 packets which are authenticated by IPsec could | Note: dropping OSPFv3 packets which are authenticated by IPsec could | |||
be impossible on some routers whose ACL are unable to parse the IPsec | be impossible on some routers that are unable to parse the IPsec | |||
ESP or AH extension headers. | ESP or AH extension headers during ACL classification. | |||
Rate limiting of the valid packets should be done. The exact | Rate-limiting of the valid packets should be done. The exact | |||
configuration will depend on the available resources of the router | configuration will depend on the available resources of the router | |||
(CPU, TCAM, ...). | (CPU, TCAM, ...). | |||
2.4.2. Management Protocols | 2.4.2. Management Protocols | |||
This class includes: SSH, SNMP, RESTCONF, NETCONF, gRPC, syslog, NTP, | This class includes: SSH, SNMP, RESTCONF, NETCONF, gRPC, syslog, NTP, | |||
etc. | etc. | |||
An ingress ACL to be applied on all the router interfaces (or at | An ingress ACL to be applied on all the router interfaces (or at | |||
ingress interfaces of the security perimeter or by using specific | ingress interfaces of the security perimeter or by using specific | |||
features of the platform) should be configured for packets destined | features of the platform) should be configured for packets destined | |||
to the RP such as: | to the RP such as: | |||
o Drop packets destined to the routers except those belonging to | o Drop packets destined to the routers except those belonging to | |||
protocols which are used (for example, permit TCP 22 and drop all | protocols which are used (for example, permit TCP 22 and drop all | |||
when only SSH is used); | others when only SSH is used); | |||
o Drop packets where the source does not match the security policy, | o Drop packets where the source does not match the security policy, | |||
for example if SSH connections should only be originated from the | for example, if SSH connections should only be originated from the | |||
NOC, then the ACL should permit TCP port 22 packets only from the | Network Operations Center (NOC), then the ACL should permit | |||
NOC prefix. | TCP port 22 packets only from the NOC prefix. | |||
Rate limiting of the valid packets should be done. The exact | Rate-limiting of valid packets should be done. The exact | |||
configuration will depend on the available resources of the router. | configuration will depend on the available router resources. | |||
2.4.3. Packet Exceptions | 2.4.3. Packet Exceptions | |||
This class covers multiple cases where a data plane packet is punted | This class covers multiple cases where a data plane packet is punted | |||
to the route processor because it requires specific processing: | to the route processor because it requires specific processing: | |||
o generation of an ICMP packet-too-big message when a data plane | o generation of an ICMP packet-too-big message when a data plane | |||
packet cannot be forwarded because it is too large (required to | packet cannot be forwarded because it is too large (required to | |||
discover the Path MTU); | discover the Path MTU); | |||
skipping to change at page 18, line 40 ¶ | skipping to change at page 18, line 40 ¶ | |||
generic RP. This could include for example the processing of a long | generic RP. This could include for example the processing of a long | |||
extension header chain in order to apply an ACL based on layer-4 | extension header chain in order to apply an ACL based on layer-4 | |||
information. [RFC6980] and more generally [RFC7112] highlight the | information. [RFC6980] and more generally [RFC7112] highlight the | |||
security implications of oversized extension header chains on routers | security implications of oversized extension header chains on routers | |||
and updates the original IPv6 specifications, [RFC2460], such that | and updates the original IPv6 specifications, [RFC2460], such that | |||
the first fragment of a packet is required to contain the entire IPv6 | the first fragment of a packet is required to contain the entire IPv6 | |||
header chain. Those changes are incorporated in the IPv6 standard | header chain. Those changes are incorporated in the IPv6 standard | |||
[RFC8200] | [RFC8200] | |||
An ingress ACL cannot mitigate a control plane attack using these | An ingress ACL cannot mitigate a control plane attack using these | |||
packet exceptions. The only protection for the RP is to limit the | packet exceptions. The only protection for the RP is to rate-limit | |||
rate of those packet exceptions forwarded to the RP, this means that | those packet exceptions that are forwarded to the RP, this means that | |||
some data plane packets will be dropped without an ICMP message sent | some data plane packets will be dropped without an ICMP message sent | |||
to the source which may delay Path MTU discovery and cause drops. | to the source which may delay Path MTU discovery and cause drops. | |||
In addition to limiting the rate of data plane packets queued to the | In addition to limiting the rate of data plane packets queued to the | |||
RP, it is also important to limit the generation rate of ICMP | RP, it is also important to rate-limit the generation of ICMP | |||
messages. This is important both to preserve RP resources and also | messages. This is important both to preserve RP resources and also | |||
to prevent an amplification attack using the router as a reflector. | to prevent an amplification attack using the router as a reflector. | |||
It is worth noting that some platforms implement this rate limiting | It is worth noting that some platforms implement this rate-limiting | |||
in hardware. Of course, a consequence of not generating an ICMP | in hardware. Of course, a consequence of not generating an ICMP | |||
message will break some IPv6 mechanisms such as Path MTU discovery or | message will break some IPv6 mechanisms such as Path MTU discovery or | |||
a simple traceroute. | a simple traceroute. | |||
2.5. Routing Security | 2.5. Routing Security | |||
Preamble: IPv6 routing security is congruent with IPv4 routing | Preamble: IPv6 routing security is congruent with IPv4 routing | |||
security at the exception of OSPv3 neighbor authentication (see | security with the exception of OSPv3 neighbor authentication (see | |||
Section 2.5.2). | Section 2.5.2). | |||
Routing security in general can be broadly divided into three | Routing security in general can be broadly divided into three | |||
sections: | sections: | |||
1. Authenticating neighbors/peers | 1. Authenticating neighbors/peers | |||
2. Securing routing updates between peers | 2. Securing routing updates between peers | |||
3. Route filtering | 3. Route filtering | |||
skipping to change at page 20, line 14 ¶ | skipping to change at page 20, line 14 ¶ | |||
[RFC7166] changes OSPFv3 reliance on IPsec by appending an | [RFC7166] changes OSPFv3 reliance on IPsec by appending an | |||
authentication trailer to the end of the OSPFv3 packets; it does not | authentication trailer to the end of the OSPFv3 packets; it does not | |||
specifically authenticate the specific originator of an OSPFv3 | specifically authenticate the specific originator of an OSPFv3 | |||
packet; rather, it allows a router to confirm that the packet has | packet; rather, it allows a router to confirm that the packet has | |||
been issued by a router that had access to the shared authentication | been issued by a router that had access to the shared authentication | |||
key. | key. | |||
With all authentication mechanisms, operators should confirm that | With all authentication mechanisms, operators should confirm that | |||
implementations can support re-keying mechanisms that do not cause | implementations can support re-keying mechanisms that do not cause | |||
outages. There have been instances where any re-keying cause outages | outages. There have been instances where any re-keying causes outages | |||
and therefore, the tradeoff between utilizing this functionality | and therefore, the tradeoff between utilizing this functionality | |||
needs to be weighed against the protection it provides. | needs to be weighed against the protection it provides. | |||
2.5.3. Securing Routing Updates | 2.5.3. Securing Routing Updates | |||
IPv6 initially mandated the provisioning of IPsec capability in all | IPv6 initially mandated the provisioning of IPsec capability in all | |||
nodes. However, in the updated IPv6 Nodes Requirement standard | nodes. However, in the updated IPv6 Nodes Requirement standard | |||
[RFC8504] is a 'SHOULD' and not a 'MUST' implement. Theoretically it | [RFC8504] is a 'SHOULD' and not a 'MUST' implement. Theoretically, it | |||
is possible that communication between two IPv6 nodes, especially | is possible that communication between two IPv6 nodes, especially | |||
routers exchanging routing information be encrypted using IPsec. In | routers exchanging routing information, be encrypted using IPsec. In | |||
practice however, deploying IPsec is not always feasible given | practice however, deploying IPsec is not always feasible given | |||
hardware and software limitations of various platforms deployed. | hardware and software limitations of the various platforms deployed. | |||
2.5.4. Route Filtering | 2.5.4. Route Filtering | |||
Route filtering policies will be different depending on whether they | Route filtering policies will be different depending on whether they | |||
pertain to edge route filtering vs internal route filtering. At a | pertain to edge route filtering vs internal route filtering. At a | |||
minimum, IPv6 routing policy as it pertains to routing between | minimum, IPv6 routing policy as it pertains to routing between | |||
different administrative domains should aim to maintain parity with | different administrative domains should aim to maintain parity with | |||
IPv4 from a policy perspective, e.g., | IPv4 from a policy perspective, e.g., | |||
o Filter internal-use, non-globally routable IPv6 addresses at the | o Filter internal-use, non-globally routable IPv6 addresses at the | |||
skipping to change at page 20, line 50 ¶ | skipping to change at page 20, line 50 ¶ | |||
[RFC8190]); | [RFC8190]); | |||
o Configure ingress route filters that validate route origin, prefix | o Configure ingress route filters that validate route origin, prefix | |||
ownership, etc. through the use of various routing databases, | ownership, etc. through the use of various routing databases, | |||
e.g., [RADB]. There is additional work being done in this area to | e.g., [RADB]. There is additional work being done in this area to | |||
formally validate the origin ASs of BGP announcements in | formally validate the origin ASs of BGP announcements in | |||
[RFC8210]. | [RFC8210]. | |||
Some good guidance can be found at [RFC7454]. | Some good guidance can be found at [RFC7454]. | |||
A valid routing table can also be used apply network ingress | A valid routing table can also be used to apply network ingress | |||
filtering (see [RFC2827]). | filtering (see [RFC2827]). | |||
2.6. Logging/Monitoring | 2.6. Logging/Monitoring | |||
In order to perform forensic research in the cases of a security | In order to perform forensic research in the cases of a security | |||
incidents or detection abnormal behavior, network operators should | incident or detecting abnormal behavior, network operators should | |||
log multiple pieces of information in some cases this requires a | log multiple pieces of information. In some cases, this requires a | |||
frequent poll of devices via a Network Management Station. | frequent poll of devices via a Network Management Station. | |||
This logging should include: | This logging should include: | |||
o logs of all applications using the network (including user space | o logs of all applications using the network (including user space | |||
and kernel space) when available (for example web servers); | and kernel space) when available (for example web servers); | |||
o data from IP Flow Information Export [RFC7011] also known as | o data from IP Flow Information Export [RFC7011] also known as | |||
IPFIX; | IPFIX; | |||
skipping to change at page 22, line 29 ¶ | skipping to change at page 22, line 29 ¶ | |||
o 2001:DB8::1 (in uppercase) | o 2001:DB8::1 (in uppercase) | |||
o 2001:0db8::0001 (with leading 0) | o 2001:0db8::0001 (with leading 0) | |||
o and many other ways including the reverse DNS mapping into a FQDN | o and many other ways including the reverse DNS mapping into a FQDN | |||
(which should not be trusted). | (which should not be trusted). | |||
[RFC5952] explains this problem in detail and recommends the use of a | [RFC5952] explains this problem in detail and recommends the use of a | |||
single canonical format. This document recommends the use of | single canonical format. This document recommends the use of | |||
canonical format [RFC5952] for IPv6 addresses in all possible cases. | canonical format [RFC5952] for IPv6 addresses in all possible cases. | |||
If the existing application cannot log under the canonical format, | If the existing application cannot log using the canonical format, | |||
then it is recommended to use an external program in order to | then it is recommended to use an external post-procesing program in order to | |||
canonicalize all IPv6 addresses. | canonicalize all IPv6 addresses. | |||
For example, this perl script can be used: | For example, this perl script can be used: | |||
<CODE BEGINS> | <CODE BEGINS> | |||
#!/usr/bin/perl -w | #!/usr/bin/perl -w | |||
use strict ; | use strict ; | |||
use warnings ; | use warnings ; | |||
use Socket ; | use Socket ; | |||
skipping to change at page 23, line 40 ¶ | skipping to change at page 23, line 40 ¶ | |||
<CODE ENDS> | <CODE ENDS> | |||
2.6.1.2. IP Flow Information Export by IPv6 Routers | 2.6.1.2. IP Flow Information Export by IPv6 Routers | |||
IPFIX [RFC7012] defines some data elements that are useful for | IPFIX [RFC7012] defines some data elements that are useful for | |||
security: | security: | |||
o in section 5.4 (IP Header fields): nextHeaderIPv6 and | o in section 5.4 (IP Header fields): nextHeaderIPv6 and | |||
sourceIPv6Address; | sourceIPv6Address; | |||
o in section 5.6 (Sub-IP fields) sourceMacAddress. | o in section 5.6 (Sub-IP fields): sourceMacAddress. | |||
The IP version is the ipVersion element defined in [IANA-IPFIX]. | The IP version is the ipVersion element defined in [IANA-IPFIX]. | |||
Moreover, IPFIX is very efficient in terms of data handling and | Moreover, IPFIX is very efficient in terms of data handling and | |||
transport. It can also aggregate flows by a key such as | transport. It can also aggregate flows by a key such as | |||
sourceMacAddress in order to have aggregated data associated with a | sourceMacAddress in order to have aggregated data associated with a | |||
specific sourceMacAddress. This memo recommends the use of IPFIX and | specific sourceMacAddress. This memo recommends the use of IPFIX and | |||
aggregation on nextHeaderIPv6, sourceIPv6Address, and | aggregation on nextHeaderIPv6, sourceIPv6Address, and | |||
sourceMacAddress. | sourceMacAddress. | |||
skipping to change at page 24, line 18 ¶ | skipping to change at page 24, line 18 ¶ | |||
RFC 4293 [RFC4293] defines a Management Information Base (MIB) for | RFC 4293 [RFC4293] defines a Management Information Base (MIB) for | |||
the two address families of IP. This memo recommends the use of: | the two address families of IP. This memo recommends the use of: | |||
o ipIfStatsTable table which collects traffic counters per | o ipIfStatsTable table which collects traffic counters per | |||
interface; | interface; | |||
o ipNetToPhysicalTable table which is the content of the Neighbor | o ipNetToPhysicalTable table which is the content of the Neighbor | |||
cache, i.e., the mapping between IPv6 and data-link layer | cache, i.e., the mapping between IPv6 and data-link layer | |||
addresses. | addresses. | |||
There are also YANG modules about the two IP addresses families and | There are also YANG modules relating to the two IP addresses families and | |||
can be used with [RFC6241] and [RFC8040]. This memo recommends the | can be used with [RFC6241] and [RFC8040]. This memo recommends the | |||
use of: | use of: | |||
o interfaces-state/interface/statistics from ietf- | o interfaces-state/interface/statistics from ietf- | |||
interfaces@2018-02-20.yang [RFC8343] which contains counters for | interfaces@2018-02-20.yang [RFC8343] which contains counters for | |||
interface . | interface . | |||
o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the | o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the | |||
content of the Neighbor cache, i.e., the mapping between IPv6 and | content of the Neighbor cache, i.e., the mapping between IPv6 and | |||
data-link layer addresses. | data-link layer addresses. | |||
skipping to change at page 24, line 44 ¶ | skipping to change at page 24, line 44 ¶ | |||
collect the current entries in the Neighbor Cache, notably but not | collect the current entries in the Neighbor Cache, notably but not | |||
limited to: | limited to: | |||
o the SNMP MIB (Section 2.6.1.3) as explained above; | o the SNMP MIB (Section 2.6.1.3) as explained above; | |||
o using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to | o using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to | |||
collect the operational state of the neighbor cache; | collect the operational state of the neighbor cache; | |||
o also by connecting over a secure management channel (such as SSH) | o also by connecting over a secure management channel (such as SSH) | |||
and explicitly requesting a neighbor cache dump via the Command | and explicitly requesting a neighbor cache dump via the Command | |||
Line Interface or another monitoring mechanism. | Line Interface (CLI) or another monitoring mechanism. | |||
The neighbor cache is highly dynamic as mappings are added when a new | The neighbor cache is highly dynamic as mappings are added when a new | |||
IPv6 address appears on the network. This could be quite frequently | IPv6 address appears on the network. This could be quite frequently | |||
with privacy extension addresses [RFC4941] or when they are removed | with privacy extension addresses [RFC4941] or when they are removed | |||
when the state goes from UNREACH to removed (the default time for a | when the state goes from UNREACH to removed (the default time for a | |||
removal per Neighbor Unreachability Detection [RFC4861] algorithm is | removal per Neighbor Unreachability Detection [RFC4861] algorithm is | |||
38 seconds for a host using Windows 7). This means that the content | 38 seconds for a host using Windows 7). This means that the content | |||
of the neighbor cache must periodically be fetched at an interval | of the neighbor cache must periodically be fetched at an interval | |||
which does not exhaust the router resources and still provides | which does not exhaust the router resources and still provides | |||
valuable information (suggested value is 30 seconds but to be checked | valuable information (suggested value is 30 seconds but this should be | |||
in the actual setup) and stored for later use. | verified in the actual deployment) and stored for later use. | |||
This is an important source of information because it is trivial (on | This is an important source of information because it is trivial (on | |||
a switch not using the SAVI [RFC7039] algorithm) to defeat the | a switch not using the SAVI [RFC7039] algorithm) to defeat the | |||
mapping between data-link layer address and IPv6 address. Let us | mapping between data-link layer address and IPv6 address. Let us | |||
rephrase the previous statement: having access to the current and | rephrase the previous statement: having access to the current and | |||
past content of the neighbor cache has a paramount value for forensic | past content of the neighbor cache has a paramount value for the forensic | |||
and audit trail. | and audit trail. | |||
When using one /64 per host (Section 2.1.7) or DHCP-PD, it is | When using one /64 per host (Section 2.1.7) or DHCP-PD, it is | |||
sufficient to keep the history of the allocated prefixes when | sufficient to keep the history of the allocated prefixes when | |||
combined with strict source address prefix enforcement on the routers | combined with strict source address prefix enforcement on the routers | |||
and layer-2 switches to prevent IPv6 spoofing. | and layer-2 switches to prevent IPv6 spoofing. | |||
2.6.1.5. Stateful DHCPv6 Lease | 2.6.1.5. Stateful DHCPv6 Lease | |||
In some networks, IPv6 addresses/prefixes are managed by a stateful | In some networks, IPv6 addresses/prefixes are managed by a stateful | |||
DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to | DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to | |||
clients. It is indeed quite similar to DHCP for IPv4 so it can be | clients. It is indeed quite similar to DHCP for IPv4 so it can be | |||
tempting to use this DHCP lease file to discover the mapping between | tempting to use this DHCP lease file to discover the mapping between | |||
IPv6 addresses/prefixes and data-link layer addresses as is commonly | IPv6 addresses/prefixes and data-link layer addresses as is commonly | |||
used in IPv4 networking . | used in IPv4 networking. | |||
It is not so easy in the IPv6 networks because not all nodes will use | It is not so easy in the IPv6 networks because not all nodes will use | |||
DHCPv6 (there are nodes which can only do stateless | DHCPv6 (there are nodes which can only do stateless | |||
autoconfiguration) but also because DHCPv6 clients are identified not | autoconfiguration) but also because DHCPv6 clients are identified not | |||
by their hardware-client address as in IPv4 but by a DHCP Unique ID | by their hardware-client address as in IPv4 but by a DHCP Unique ID | |||
(DUID) which can have several formats: some being the data-link layer | (DUID) which can have several formats: some being the data-link layer | |||
address, some being data-link layer address prepended with time | address, some being data-link layer address prepended with time | |||
information, or even an opaque number which is useless for | information, or even an opaque number which is useless for | |||
operational security. Moreover, when the DUID is based on the data- | operational security. Moreover, when the DUID is based on the data- | |||
link address, this address can be of any client interface (such as | link address, this address can be of any client interface (such as | |||
the wireless interface while the client actually uses its wired | the wireless interface while the client actually uses its wired | |||
interface to connect to the network). | interface to connect to the network). | |||
If a lightweight DHCP relay agent [RFC6221] is used in a layer-2 | If a lightweight DHCP relay agent [RFC6221] is used in a layer-2 | |||
switche, then the DHCP servers also receives the Interface-ID | switch, then the DHCP servers also receive the Interface-ID | |||
information which could be saved in order to identify the interface | information which could be saved in order to identify the interface | |||
on which the switch received a specific leased IPv6 address. Also, | on which the switch received a specific leased IPv6 address. Also, | |||
if a 'normal' (not lightweight) relay agent adds the data-link layer | if a 'normal' (not lightweight) relay agent adds the data-link layer | |||
address in the option for Relay Agent Remote-ID [RFC4649] or | address in the option for Relay Agent Remote-ID [RFC4649] or | |||
[RFC6939], then the DHCPv6 server can keep track of the data-link and | [RFC6939], then the DHCPv6 server can keep track of the data-link and | |||
leased IPv6 addresses. | leased IPv6 addresses. | |||
In short, the DHCPv6 lease file is less interesting than for IPv4 | In short, the DHCPv6 lease file is less interesting than for IPv4 | |||
networks. If possible, it is recommended to use DHCPv6 servers that | networks. If possible, it is recommended to use DHCPv6 servers that | |||
keep the relayed data-link layer address in addition to the DUID in | keep the relayed data-link layer address in addition to the DUID in | |||
skipping to change at page 26, line 45 ¶ | skipping to change at page 26, line 45 ¶ | |||
2.6.2. Use of Collected Data | 2.6.2. Use of Collected Data | |||
This section leverages the data collected as described before | This section leverages the data collected as described before | |||
(Section 2.6.1) in order to achieve several security benefits. | (Section 2.6.1) in order to achieve several security benefits. | |||
Section 9.1 of [RFC7934] contains more details about host tracking. | Section 9.1 of [RFC7934] contains more details about host tracking. | |||
2.6.2.1. Forensic and User Accountability | 2.6.2.1. Forensic and User Accountability | |||
The forensic use case is when the network operator must locate an | The forensic use case is when the network operator must locate an | |||
IPv6 address that was present in the network at a certain time or is | IPv6 address that was present in the network at a certain time or is | |||
still currently in the network. | currently in the network. | |||
To locate an IPv6 address in an enterprise network where the operator | To locate an IPv6 address in an enterprise network where the operator | |||
has control over all resources, the source of information can be the | has control over all resources, the source of information can be the | |||
neighbor cache, or, if not found, the DHCP lease file. Then, the | neighbor cache, or, if not found, the DHCP lease file. Then, the | |||
procedure is: | procedure is: | |||
1. Based on the IPv6 prefix of the IPv6 address, find the router(s) | 1. Based on the IPv6 prefix of the IPv6 address, find the router(s) | |||
which is(are) used to reach this prefix (assuming that anti- | which is(are) used to reach this prefix (assuming that anti- | |||
spoofing mechanisms are used). | spoofing mechanisms are used). | |||
skipping to change at page 28, line 16 ¶ | skipping to change at page 28, line 16 ¶ | |||
list of all IPv6 source addresses to find all IPv6 nodes that sent | list of all IPv6 source addresses to find all IPv6 nodes that sent | |||
packets through a router. This is very efficient but, alas, will not | packets through a router. This is very efficient but, alas, will not | |||
discover silent nodes that never transmitted packets traversing the | discover silent nodes that never transmitted packets traversing the | |||
the IPFIX target router. Also, it must be noted that link-local | the IPFIX target router. Also, it must be noted that link-local | |||
addresses will never be discovered by this means. | addresses will never be discovered by this means. | |||
The second way is again to use the collected neighbor cache content | The second way is again to use the collected neighbor cache content | |||
to find all IPv6 addresses in the cache. This process will also | to find all IPv6 addresses in the cache. This process will also | |||
discover all link-local addresses. See Section 2.6.1.4. | discover all link-local addresses. See Section 2.6.1.4. | |||
Another way that works only for local network, consists in sending a | Another way that works only for a local network, consists of sending a | |||
ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which | ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which | |||
addresses all IPv6 nodes on the network. All nodes should reply to | addresses all IPv6 nodes on the network. All nodes should reply to | |||
this ECHO_REQUEST per [RFC4443]. | this ECHO_REQUEST per [RFC4443]. | |||
Other techniques involve obtaining data from DNS, parsing log files, | Other techniques involve obtaining data from DNS, parsing log files, | |||
leveraging service discovery such as mDNS [RFC6762] and [RFC6763]. | leveraging service discovery such as mDNS [RFC6762] and [RFC6763]. | |||
Enumerating DNS zones, especially looking at reverse DNS records and | Enumerating DNS zones, especially looking at reverse DNS records and | |||
CNAMES, is another common method employed by various tools. As | CNAMES, is another common method employed by various tools. As | |||
already mentioned in [RFC7707], this allows an attacker to prune the | already mentioned in [RFC7707], this allows an attacker to prune the | |||
skipping to change at page 29, line 20 ¶ | skipping to change at page 29, line 20 ¶ | |||
2.6.2.4. Abnormal Behavior Detection | 2.6.2.4. Abnormal Behavior Detection | |||
Abnormal behavior (such as network scanning, spamming, denial of | Abnormal behavior (such as network scanning, spamming, denial of | |||
service) can be detected in the same way as in an IPv4 network. | service) can be detected in the same way as in an IPv4 network. | |||
o Sudden increase of traffic detected by interface counter (SNMP) or | o Sudden increase of traffic detected by interface counter (SNMP) or | |||
by aggregated traffic from IPFIX records [RFC7012]. | by aggregated traffic from IPFIX records [RFC7012]. | |||
o Change in traffic pattern (number of connections per second, | o Change in traffic pattern (number of connections per second, | |||
number of connection per host...) with the use of IPFIX [RFC7012]. | number of connection per host...) observed with the use of IPFIX [RFC7012]. | |||
2.6.3. Summary | 2.6.3. Summary | |||
While some data sources (IPFIX, MIB, switch CAM tables, logs, ...) | While some data sources (IPFIX, MIB, switch CAM tables, logs, ...) | |||
used in IPv4 are also used in the secure operation of an IPv6 | used in IPv4 are also used in the secure operation of an IPv6 | |||
network, the DHCPv6 lease file is less reliable and the neighbor | network, the DHCPv6 lease file is less reliable and the neighbor | |||
cache is of prime importance. | cache is of prime importance. | |||
The fact that there are multiple ways to express the same IPv6 | The fact that there are multiple ways to express the same IPv6 | |||
address in a character string renders the use of filters mandatory | address in a character string renders the use of filters mandatory | |||
skipping to change at page 29, line 46 ¶ | skipping to change at page 29, line 46 ¶ | |||
mode, the different transition mechanisms must be deployed and | mode, the different transition mechanisms must be deployed and | |||
operated in a secure way. This section proposes operational | operated in a secure way. This section proposes operational | |||
guidelines for the most known and deployed transition techniques. | guidelines for the most known and deployed transition techniques. | |||
2.7.1. Dual Stack | 2.7.1. Dual Stack | |||
Dual stack is often the first deployment choice for network | Dual stack is often the first deployment choice for network | |||
operators. Dual stacking the network offers some advantages over | operators. Dual stacking the network offers some advantages over | |||
other transition mechanisms. Firstly, the impact on existing IPv4 | other transition mechanisms. Firstly, the impact on existing IPv4 | |||
operations is reduced. Secondly, in the absence of tunnels or | operations is reduced. Secondly, in the absence of tunnels or | |||
address translation, the IPv4 and IPv6 traffics are native (easier to | address translation, the IPv4 and IPv6 traffic are native (easier to | |||
observe and secure) and should have the same network processing | observe and secure) and should have the same network processing | |||
(network path, quality of service, ...). Dual stack enables a | (network path, quality of service, ...). Dual stack enables a | |||
gradual termination of the IPv4 operations when the IPv6 network is | gradual termination of the IPv4 operations when the IPv6 network is | |||
ready for prime time. On the other hand, the operators have to | ready for prime time. On the other hand, the operators have to | |||
manage two network stacks with the added complexities. | manage two network stacks with the attendant complexities. | |||
From an operational security perspective, this now means that the | From an operational security perspective, this now means that the | |||
network operator has twice the exposure. One needs to think about | network operator has twice the exposure. One needs to think about | |||
protecting both protocols now. At a minimum, the IPv6 portion of a | protecting both protocols now. At a minimum, the IPv6 portion of a | |||
dual-stacked network should be consistent with IPv4 from a security | dual-stacked network should be consistent with IPv4 from a security | |||
policy point of view. Typically, the following methods are employed | policy point of view. Typically, the following methods are employed | |||
to protect IPv4 networks at the edge or security perimeter: | to protect IPv4 networks at the edge or security perimeter: | |||
o ACLs to permit or deny traffic; | o ACLs to permit or deny traffic; | |||
skipping to change at page 31, line 9 ¶ | skipping to change at page 31, line 9 ¶ | |||
information (for example the tunnel endpoints and the | information (for example the tunnel endpoints and the | |||
encapsulation protocol) can forge a packet which looks like a | encapsulation protocol) can forge a packet which looks like a | |||
legit and valid encapsulated packet that will gladly be accepted | legit and valid encapsulated packet that will gladly be accepted | |||
by the destination tunnel endpoint, this is a specific case of | by the destination tunnel endpoint, this is a specific case of | |||
spoofing; | spoofing; | |||
o traffic interception: no confidentiality is provided by the tunnel | o traffic interception: no confidentiality is provided by the tunnel | |||
protocols (without the use of IPsec or alternative encryption | protocols (without the use of IPsec or alternative encryption | |||
methods), therefore anybody on the tunnel path can intercept the | methods), therefore anybody on the tunnel path can intercept the | |||
traffic and have access to the clear-text IPv6 packet; combined | traffic and have access to the clear-text IPv6 packet; combined | |||
with the absence of authentication, a on-path attack can also be | with the absence of authentication, an on-path attack can also be | |||
mounted; | mounted; | |||
o service theft: as there is no authorization, even a non-authorized | o service theft: as there is no authorization, even a non-authorized | |||
user can use a tunnel relay for free (this is a specific case of | user can use a tunnel relay for free (this is a specific case of | |||
tunnel injection); | tunnel injection); | |||
o reflection attack: another specific use case of tunnel injection | o reflection attack: another specific use case of tunnel injection | |||
where the attacker injects packets with an IPv4 destination | where the attacker injects packets with an IPv4 destination | |||
address not matching the IPv6 address causing the first tunnel | address not matching the IPv6 address causing the first tunnel | |||
endpoint to re-encapsulate the packet to the destination... Hence, | endpoint to re-encapsulate the packet to the destination... Hence, | |||
the final IPv4 destination will not see the original IPv4 address | the final IPv4 destination will not see the original IPv4 address | |||
but only the IPv4 address of the relay router. | but only the IPv4 address of the relay router. | |||
o bypassing security policy: if a firewall or an IPS is on the path | o bypassing security policy: if a firewall or an IPS is on the path | |||
of the tunnel, then it may neither inspect nor detect a malevolent | of the tunnel, then it may neither inspect nor detect malevolent | |||
IPv6 traffic transmitted over the tunnel. | IPv6 traffic transmitted over the tunnel. | |||
To mitigate the bypassing of security policies, it is recommended to | To mitigate the bypassing of security policies, it is recommended to | |||
block all default configuration tunnels by denying IPv4 packets | block all default configuration tunnels by denying IPv4 packets | |||
matching: | matching: | |||
o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 | o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 | |||
(Section 2.7.2.7), 6rd (Section 2.7.2.3) as well as 6in4 | (Section 2.7.2.7), 6rd (Section 2.7.2.3), as well as, 6in4 | |||
(Section 2.7.2.1) tunnels; | (Section 2.7.2.1) tunnels; | |||
o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; | o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; | |||
o UDP protocol 3544: this will block the default encapsulation of | o UDP protocol 3544: this will block the default encapsulation of | |||
Teredo (Section 2.7.2.8) tunnels. | Teredo (Section 2.7.2.8) tunnels. | |||
Ingress filtering [RFC2827] should also be applied on all tunnel | Ingress filtering [RFC2827] should also be applied on all tunnel | |||
endpoints if applicable to prevent IPv6 address spoofing. | endpoints if applicable to prevent IPv6 address spoofing. | |||
As several of the tunnel techniques share the same encapsulation | As several of the tunnel techniques share the same encapsulation | |||
(i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6 | (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6 | |||
address, there are a set of well-known looping attacks described in | address, there are a set of well-known looping attacks described in | |||
RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. | RFC 6324 [RFC6324]. This RFC also proposes mitigation techniques. | |||
2.7.2.1. Site-to-Site Static Tunnels | 2.7.2.1. Site-to-Site Static Tunnels | |||
Site-to-site static tunnels are described in RFC 2529 [RFC2529] and | Site-to-site static tunnels are described in RFC 2529 [RFC2529] and | |||
in GRE [RFC2784]. As the IPv4 endpoints are statically configured | in GRE [RFC2784]. As the IPv4 endpoints are statically configured | |||
and are not dynamic they are slightly more secure (bi-directional | and are not dynamic, they are slightly more secure (bi-directional | |||
service theft is mostly impossible) but traffic interception and | service theft is mostly impossible) but traffic interception and | |||
tunnel injection are still possible. Therefore, the use of IPsec | tunnel injection are still possible. Therefore, the use of IPsec | |||
[RFC4301] in transport mode and protecting the encapsulated IPv4 | [RFC4301] in transport mode and protecting the encapsulated IPv4 | |||
packets is recommended for those tunnels. Alternatively, IPsec in | packets is recommended for those tunnels. Alternatively, IPsec in | |||
tunnel mode can be used to transport IPv6 traffic over a non-trusted | tunnel mode can be used to transport IPv6 traffic over a non-trusted | |||
IPv4 network. | IPv4 network. | |||
2.7.2.2. ISATAP | 2.7.2.2. ISATAP | |||
ISATAP tunnels [RFC5214] are mainly used within a single | ISATAP tunnels [RFC5214] are mainly used within a single | |||
administrative domain and to connect a single IPv6 host to the IPv6 | administrative domain and to connect a single IPv6 host to the IPv6 | |||
network. This often implies that those systems are usually managed | network. This often implies that those systems are usually managed | |||
by a single entity; therefore, audit trail and strict anti-spoofing | by a single entity; therefore, audit trail and strict anti-spoofing | |||
are usually possible and this raises the overall security. | are usually possible and this raises the overall security. | |||
Special care must be taken to avoid a looping attack by implementing | Special care must be taken to avoid a looping attack by implementing | |||
the measures of RFC 6324 [RFC6324] and of [RFC6964]. | the measures of [RFC6324] and [RFC6964]. | |||
IPsec [RFC4301] in transport or tunnel mode can be used to secure the | IPsec [RFC4301] in transport or tunnel mode can be used to secure the | |||
IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and | IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and | |||
prevent service theft. | prevent service theft. | |||
2.7.2.3. 6rd | 2.7.2.3. 6rd | |||
While 6rd tunnels share the same encapsulation as 6to4 tunnels | While 6rd tunnels share the same encapsulation as 6to4 tunnels | |||
(Section 2.7.2.7), they are designed to be used within a single SP | (Section 2.7.2.7), they are designed to be used within a single SP | |||
domain, in other words they are deployed in a more constrained | domain, in other words, they are deployed in a more constrained | |||
environment than 6to4 tunnels and have few security issues other than | environment than 6to4 tunnels and have few security issues other than | |||
lack of confidentiality. The security considerations (Section 12) of | lack of confidentiality. The security considerations (Section 12) of | |||
[RFC5969] describes how to secure 6rd tunnels. | [RFC5969] describes how to secure 6rd tunnels. | |||
IPsec [RFC4301] for the transported IPv6 traffic can be used if | IPsec [RFC4301] for the transported IPv6 traffic can be used if | |||
confidentiality is important. | confidentiality is important. | |||
2.7.2.4. 6PE, 6VPE, and LDPv6 | 2.7.2.4. 6PE, 6VPE, and LDPv6 | |||
Organizations using MPLS in their core can also use 6PE [RFC4798] and | Organizations using MPLS in their core can also use 6PE [RFC4798] and | |||
6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are | 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are | |||
really similar to BGP/MPLS IP VPN described in [RFC4364], the | really similar to BGP/MPLS IP VPNs as described in [RFC4364], the | |||
security properties of these networks are also similar to those | security properties of these networks are also similar to those | |||
described in [RFC4381]. It relies on: | described in [RFC4381]. They rely on: | |||
o Address space, routing and traffic separation with the help of | o Address space, routing, and traffic separation with the help of | |||
VRFs (only applicable to 6VPE); | VRFs (only applicable to 6VPE); | |||
o Hiding the IPv4 core, hence removing all attacks against | o Hiding the IPv4 core, hence removing all attacks against | |||
P-routers; | P-routers; | |||
o Securing the routing protocol between CE and PE; in the case of | o Securing the routing protocol between CE and PE; in the case of | |||
6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and | 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and | |||
as these addresses cannot be reached from outside of the link, the | as these addresses cannot be reached from outside of the link, the | |||
security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP | security of 6PE and 6VPE is even higher than an IPv4 BGP/MPLS IP | |||
VPN. | VPN. | |||
LDPv6 itself does not induce new risks, see also [RFC7552]. | LDPv6 itself does not induce new risks, see also [RFC7552]. | |||
2.7.2.5. DS-Lite | 2.7.2.5. DS-Lite | |||
DS-lite is also a translation mechanism and is therefore analyzed | DS-lite is also a translation mechanism and is therefore analyzed | |||
further (Section 2.7.3.3) in this document as it includes IPv4 NAPT. | further (Section 2.7.3.3) in this document as it includes IPv4 NAPT. | |||
2.7.2.6. Mapping of Address and Port | 2.7.2.6. Mapping of Address and Port | |||
With the encapsulation and translation versions of mapping of Address | With the encapsulation and translation versions of mapping of Address | |||
and Port (MAP) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access | and Port (MAP) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access | |||
network is purely an IPv6 network and MAP protocols are used to | network is purely an IPv6 network and MAP protocols are used to | |||
connect IPv4 hosts on the subscriber network access to IPv4 hosts on | provide IPv4 hosts on the subscriber network access to IPv4 hosts on | |||
the Internet. The subscriber router does stateful operations in | the Internet. The subscriber router does stateful operations in | |||
order to map all internal IPv4 addresses and layer-4 ports to the | order to map all internal IPv4 addresses and layer-4 ports to the | |||
IPv4 address and the set of layer-4 ports received through MAP | IPv4 address and the set of layer-4 ports received through MAP | |||
configuration process. The SP equipment always does stateless | configuration process. The SP equipment always does stateless | |||
operations (either decapsulation or stateless translation). | operations (either decapsulation or stateless translation). | |||
Therefore, as opposed to Section 2.7.3.3 there is no state-exhaustion | Therefore, as opposed to Section 2.7.3.3, there is no state-exhaustion | |||
DoS attack against the SP equipment because there is no state and | DoS attack against the SP equipment because there is no state and | |||
there is no operation caused by a new layer-4 connection (no logging | there is no operation caused by a new layer-4 connection (no logging | |||
operation). | operation). | |||
The SP MAP equipment should implement all the security considerations | The SP MAP equipment should implement all the security considerations | |||
of [RFC7597]; notably, ensuring that the mapping of the IPv4 address | of [RFC7597]; notably, ensuring that the mapping of the IPv4 address | |||
and port are consistent with the configuration. As MAP has a | and port are consistent with the configuration. As MAP has a | |||
predictable IPv4 address and port mapping, the audit logs are easier | predictable IPv4 address and port mapping, the audit logs are easier | |||
to manage. | to manage. | |||
skipping to change at page 34, line 43 ¶ | skipping to change at page 34, line 43 ¶ | |||
most environments, so, it is less of a threat, however, special | most environments, so, it is less of a threat, however, special | |||
consideration must be taken in case of devices with older or non- | consideration must be taken in case of devices with older or non- | |||
updated operating systems may be present and by default were running | updated operating systems may be present and by default were running | |||
Teredo. | Teredo. | |||
2.7.3. Translation Mechanisms | 2.7.3. Translation Mechanisms | |||
Translation mechanisms between IPv4 and IPv6 networks are alternate | Translation mechanisms between IPv4 and IPv6 networks are alternate | |||
coexistence strategies while networks transition to IPv6. While a | coexistence strategies while networks transition to IPv6. While a | |||
framework is described in [RFC6144], the specific security | framework is described in [RFC6144], the specific security | |||
considerations are documented in each individual mechanism. For the | considerations are documented with each individual mechanism. For the | |||
most part, they specifically mention interference with IPsec or | most part, they specifically mention interference with IPsec or | |||
DNSSEC deployments, how to mitigate spoofed traffic, and what some | DNSSEC deployments, how to mitigate spoofed traffic, and what some | |||
effective filtering strategies may be. | effective filtering strategies may be. | |||
While not really a transition mechanism to IPv6, this section also | While not really a transition mechanism to IPv6, this section also | |||
includes the discussion about the use of heavy IPv4-to-IPv4 network | includes the discussion about the use of heavy IPv4-to-IPv4 network | |||
address and port translation to prolong the life of IPv4-only | address and port translation to prolong the life of IPv4-only | |||
networks. | networks. | |||
2.7.3.1. Carrier-Grade NAT (CGN) | 2.7.3.1. Carrier-Grade NAT (CGN) | |||
skipping to change at page 35, line 45 ¶ | skipping to change at page 35, line 45 ¶ | |||
some solutions to enforce policies on misbehaving nodes when address | some solutions to enforce policies on misbehaving nodes when address | |||
sharing is used. [RFC7857] also updates the NAT behavioral | sharing is used. [RFC7857] also updates the NAT behavioral | |||
requirements. | requirements. | |||
2.7.3.2. NAT64/DNS64 and 464XLAT | 2.7.3.2. NAT64/DNS64 and 464XLAT | |||
Stateful NAT64 translation [RFC6146] allows IPv6-only clients to | Stateful NAT64 translation [RFC6146] allows IPv6-only clients to | |||
contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used | contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used | |||
in conjunction with DNS64 [RFC6147], a mechanism which synthesizes | in conjunction with DNS64 [RFC6147], a mechanism which synthesizes | |||
AAAA records from existing A records. There is also a stateless | AAAA records from existing A records. There is also a stateless | |||
NAT64 [RFC7915] which is similar for the security aspects with the | NAT64 [RFC7915] which has similar security aspects but with the | |||
added benefit of being stateless, so, less prone to a state | added benefit of being stateless, so, less prone to a state | |||
exhaustion attack. | exhaustion attack. | |||
The Security Consideration sections of [RFC6146] and [RFC6147] list | The Security Consideration sections of [RFC6146] and [RFC6147] list | |||
the comprehensive issues. A specific issue with the use of NAT64 is | the comprehensive issues. A specific issue with the use of NAT64 is | |||
that it will interfere with most IPsec deployments unless UDP | that it will interfere with most IPsec deployments unless UDP | |||
encapsulation is used. DNSSEC has an impact on DNS64 see section 3.1 | encapsulation is used. DNSSEC has an impact on DNS64, see section 3.1 | |||
of [RFC7050]. | of [RFC7050]. | |||
Another translation mechanism relying on a combination of stateful | Another translation mechanism relying on a combination of stateful | |||
and stateless translation, 464XLAT [RFC6877], can be used to do host | and stateless translation, 464XLAT [RFC6877], can be used to do host | |||
local translation from IPv4 to IPv6 and a network provider | local translation from IPv4 to IPv6 and a network provider | |||
translation from IPv6 to IPv4, i.e., giving IPv4-only application | translation from IPv6 to IPv4, i.e., giving IPv4-only application | |||
access to an IPv4-only server over an IPv6-only network. 464XLAT | access to an IPv4-only server over an IPv6-only network. 464XLAT | |||
shares the same security considerations as NAT64 and DNS64, however | shares the same security considerations as NAT64 and DNS64, however | |||
it can be used without DNS64, avoiding the DNSSEC implications. | it can be used without DNS64, avoiding the DNSSEC implications. | |||
2.7.3.3. DS-Lite | 2.7.3.3. DS-Lite | |||
Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that | Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that | |||
enables a service provider to share IPv4 addresses among customers by | enables a service provider to share IPv4 addresses among customers by | |||
combining two well-known technologies: IP in IP (IPv4-in-IPv6) and | combining two well-known technologies: IP in IP (IPv4-in-IPv6) and | |||
IPv4 NAPT. | IPv4 NAPT. | |||
Security considerations with respect to DS-Lite mainly revolve around | Security considerations with respect to DS-Lite mainly revolve around | |||
logging data, preventing DoS attacks from rogue devices (as the | logging data, preventing DoS attacks from rogue devices (as the | |||
Address Family Translation Router (AFTR) [RFC6333] function is | Address Family Translation Router (AFTR) [RFC6333] function is | |||
stateful and restricting service offered by the AFTR only to | stateful) and restricting service offered by the AFTR only to | |||
registered customers. | registered customers. | |||
Section 11 of [RFC6333] and section 2 of [RFC7785] describe important | Section 11 of [RFC6333] and section 2 of [RFC7785] describe important | |||
security issues associated with this technology. | security issues associated with this technology. | |||
2.8. General Device Hardening | 2.8. General Device Hardening | |||
With almost all devices being IPv6 enabled by default and with many | With almost all devices being IPv6 enabled by default and with many | |||
end points having IPv6 connectivity to the Internet, it is critical | end points having IPv6 connectivity to the Internet, it is critical | |||
to also harden those devices against attacks over IPv6. | to also harden those devices against attacks over IPv6. | |||
The following guidelines should be used to ensure appropriate | The following guidelines should be used to ensure appropriate | |||
hardening of the host, be it an individual computer or router, | hardening of the device, be it an individual host, router, | |||
firewall, load-balancer, server, etc. device. | firewall, load-balancer, server, etc. | |||
o Restrict device access to authorized individuals | o Restrict device access to authorized individuals | |||
o Monitor and audit access to the device | o Monitor and audit access to the device | |||
o Turn off any unused services on the end node | o Turn off any unused services on the end node | |||
o Understand which IPv6 addresses are being used to source traffic | o Understand which IPv6 addresses are being used to source traffic | |||
and change defaults if necessary | and change defaults if necessary | |||
o Use cryptographically protected protocols for device management if | o Use cryptographically protected protocols for device management if | |||
possible (SCP, SNMPv3, SSH, TLS, etc.) | possible (SCP, SNMPv3, SSH, TLS, etc.) | |||
o Use host firewall capabilities to control traffic that gets | o Use host firewall capabilities to control traffic that gets | |||
processed by upper layer protocols | processed by upper-layer protocols | |||
o Use virus scanners to detect malicious programs | o Use virus scanners to detect malicious programs | |||
3. Enterprises Specific Security Considerations | 3. Enterprises Specific Security Considerations | |||
Enterprises [RFC7381] generally have robust network security policies | Enterprises [RFC7381] generally have robust network security policies | |||
in place to protect existing IPv4 networks. These policies have been | in place to protect existing IPv4 networks. These policies have been | |||
distilled from years of experiential knowledge of securing IPv4 | distilled from years of experiential knowledge of securing IPv4 | |||
networks. At the very least, it is recommended that enterprise | networks. At the very least, it is recommended that enterprise | |||
networks have parity between their security policies for both | networks have parity between their security policies for both | |||
protocol versions. This section also applies to the enterprise part | protocol versions. This section also applies to the enterprise part | |||
of all SP networs, i.e., the part of the network where the SP | of all SP networs, i.e., the part of the network where the SP | |||
employees are connected. | employees are connected. | |||
Security considerations in the enterprise can be broadly categorized | Security considerations in the enterprise can be broadly categorized | |||
into two sections - External and Internal. | into two groups - External and Internal. | |||
3.1. External Security Considerations | 3.1. External Security Considerations | |||
The external aspect deals with providing security at the edge or | The external aspect deals with providing security at the edge or | |||
perimeter of the enterprise network where it meets the service | perimeter of the enterprise network where it meets the service | |||
providers network. This is commonly achieved by enforcing a security | provider's network. This is commonly achieved by enforcing a security | |||
policy either by implementing dedicated firewalls with stateful | policy either by implementing dedicated firewalls with stateful | |||
packet inspection or a router with ACLs. A common default IPv4 | packet inspection or a router with ACLs. A common default IPv4 | |||
policy on firewalls that could easily be ported to IPv6 is to allow | policy on firewalls that could easily be ported to IPv6 is to allow | |||
all traffic outbound while only allowing specific traffic, such as | all traffic outbound while only allowing specific traffic, such as | |||
established sessions, inbound (see also [RFC6092]). Section 3.2 of | established sessions, inbound (see also [RFC6092]). Section 3.2 of | |||
[RFC7381] also provides similar recommendations. | [RFC7381] also provides similar recommendations. | |||
Here are a few more things that could enhance the default policy: | Here are a few more things that could enhance the default policy: | |||
o Filter internal-use IPv6 addresses at the perimeter this will also | o Filter internal-use IPv6 addresses at the perimeter this will also | |||
skipping to change at page 38, line 14 ¶ | skipping to change at page 38, line 14 ¶ | |||
o Filter packets having an illegal IPv6 headers chain at the | o Filter packets having an illegal IPv6 headers chain at the | |||
perimeter (and if possible, inside the network as well), see | perimeter (and if possible, inside the network as well), see | |||
Section 2.2 | Section 2.2 | |||
o Filter unneeded services at the perimeter | o Filter unneeded services at the perimeter | |||
o Implement ingress and egress anti-spoofing in the forwarding and | o Implement ingress and egress anti-spoofing in the forwarding and | |||
control planes, see [RFC2827] and [RFC3704] | control planes, see [RFC2827] and [RFC3704] | |||
o Implement appropriate rate limiters and control-plane policers | o Implement appropriate rate-limiters and control-plane policers | |||
Having global IPv6 address on all the enterprises sites is different | Having global IPv6 address on all the enterprises sites is different | |||
than in IPv4 where [RFC1918] addresses are used internally and not | than in IPv4 where [RFC1918] addresses are used internally and not | |||
routed usually over the Internet. [RFC7359] and [WEBER_VPN] explain | usually routed over the Internet. [RFC7359] and [WEBER_VPN] explain | |||
that without careful design, there could be IPv6 leakages out of | that without careful design, there could be IPv6 leakages out of | |||
layer-3 VPN. | layer-3 VPN. | |||
3.2. Internal Security Considerations | 3.2. Internal Security Considerations | |||
The internal aspect deals with providing security inside the | The internal aspect deals with providing security inside the | |||
perimeter of the network, including end hosts. Internal networks of | perimeter of the network, including end hosts. Internal networks of | |||
enterprises are often different: University campus, wireless guest | enterprises are often different: University campus, wireless guest | |||
access, ... so there is no "one size fits all" recommendations. | access, ... so there is no "one size fits all" recommendation. | |||
The most significant concerns here are related to Neighbor Discovery. | The most significant concerns here are related to Neighbor Discovery. | |||
At the network level, it is recommended that all security | At the network level, it is recommended that all security | |||
considerations discussed in Section 2.3 be reviewed carefully and the | considerations discussed in Section 2.3 be reviewed carefully and the | |||
recommendations be considered in-depth as well. Section 4.1 of | recommendations be considered in-depth as well. Section 4.1 of | |||
[RFC7381] also provides some recommendations. | [RFC7381] also provides some recommendations. | |||
As mentioned in Section 2.7.2, care must be taken when running | As mentioned in Section 2.7.2, care must be taken when running | |||
automated IPv6-in-IPv4 tunnels. | automated IPv6-in-IPv4 tunnels. | |||
When site-to-site VPNs are used it should be kept in mind that, given | When site-to-site VPNs are used it should be kept in mind that, given | |||
the global scope of IPv6 global addresses as opposed to the common | the global scope of IPv6 global addresses as opposed to the common | |||
use of IPv4 private address space [RFC1918], sites might be able to | use of IPv4 private address space [RFC1918], sites might be able to | |||
communicate with each other over the Internet even when the VPN | communicate with each other over the Internet even when the VPN | |||
mechanism is not available and hence no traffic encryption is | mechanism is not available and hence no traffic encryption is | |||
performed and traffic could be injected from the Internet into the | performed and traffic could be injected from the Internet into the | |||
site, see [WEBER_VPN]. It is recommended to filter at the Internet | site, see [WEBER_VPN]. It is recommended to filter at Internet | |||
connection(s) packets having a source or destination address | connection(s) packets having a source or destination address | |||
belonging to the site internal prefix(es); this should be done for | belonging to the site internal prefix(es); this should be done for | |||
ingress and egress traffic. | ingress and egress traffic. | |||
Hosts need to be hardened directly through security policy to protect | Hosts need to be hardened directly through security policy to protect | |||
against security threats. The host firewall default capabilities | against security threats. The host firewall default capabilities | |||
have to be clearly understood. In some cases, 3rd party firewalls | have to be clearly understood. In some cases, 3rd party firewalls | |||
have no IPv6 support whereas the native firewall installed by default | have no IPv6 support whereas the native firewall installed by default | |||
has IPv6 support. General device hardening guidelines are provided | has IPv6 support. General device hardening guidelines are provided | |||
in Section 2.8. | in Section 2.8. | |||
skipping to change at page 39, line 31 ¶ | skipping to change at page 39, line 31 ¶ | |||
o TTL security (which becomes hop-limit security in IPv6) as | o TTL security (which becomes hop-limit security in IPv6) as | |||
[RFC5082]; | [RFC5082]; | |||
o bogon AS filtering, see [CYMRU]; | o bogon AS filtering, see [CYMRU]; | |||
o Prefix filtering. | o Prefix filtering. | |||
These are explained in more detail in Section 2.5. Also, the | These are explained in more detail in Section 2.5. Also, the | |||
recommendations of [RFC7454] should be considered. | recommendations of [RFC7454] should be considered. | |||
4.1.1. Remote Triggered Black Hole Filtering | 4.1.1. Remote Triggered Black Hole (RTBH) Filtering | |||
RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has | RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has | |||
allocated the 100::/64 prefix to be used as the discard prefix | allocated the 100::/64 prefix to be used as the discard prefix | |||
[RFC6666]. | [RFC6666]. | |||
4.2. Transition/Coexistence Mechanism | 4.2. Transition/Coexistence Mechanism | |||
SP will typically use transition mechanisms such as 6rd, 6PE, MAP, | SPs will typically use transition mechanisms such as 6rd, 6PE, MAP, | |||
NAT64 which have been analyzed in the transition and coexistence | and NAT64 which have been analyzed in the transition and coexistence | |||
Section 2.7 section. | Section 2.7 section. | |||
4.3. Lawful Intercept | 4.3. Lawful Intercept | |||
The Lawful Intercept requirements are similar for IPv6 and IPv4 | The Lawful Intercept requirements are similar for IPv6 and IPv4 | |||
architectures and will be subject to the laws enforced in varying | architectures and will be subject to the laws enforced in different | |||
geographic regions. The local issues with each jurisdiction can make | geographic regions. The local issues with each jurisdiction can make | |||
this challenging and both corporate legal and privacy personnel | this challenging and both corporate legal and privacy personnel | |||
should be involved in discussions pertaining to what information gets | should be involved in discussions pertaining to what information gets | |||
logged and what the logging retention policies will be. | logged and the respective log retention policies for this information. | |||
The target of interception will usually be a residential subscriber | The target of interception will usually be a residential subscriber | |||
(e.g., his/her PPP session or physical line or CPE MAC address). | (e.g., his/her PPP session, physical line, or CPE MAC address). | |||
With the absence of IPv6 NAT on the CPE, IPv6 has the possibility to | With the absence of IPv6 NAT on the CPE, IPv6 has the possibility to | |||
allow for intercepting the traffic from a single host (a /128 target) | allow for intercepting the traffic from a single host (i.e., a /128 target) | |||
rather than the whole set of hosts of a subscriber (which could be a | rather than the whole set of subscriber hosts (which could be a | |||
/48, a /60 or /64). | /48, /60, or /64). | |||
In contrast, in mobile environments, since the 3GPP specifications | In contrast, in mobile environments, since the 3GPP specifications | |||
allocate a /64 per device, it may be sufficient to intercept traffic | allocate a /64 per device, it may be sufficient to intercept traffic | |||
from the /64 rather than specific /128's (since each time the device | from the /64 rather than specific /128's (since each time the device | |||
establishes a data connection it gets a new IID). | establishes a data connection it gets a new IID). | |||
A sample architecture which was written for informational purposes is | A sample architecture which was written for informational purposes is | |||
found in [RFC3924]. | found in [RFC3924]. | |||
5. Residential Users Security Considerations | 5. Residential Users Security Considerations | |||
The IETF Homenet working group is working standards and guidelines | The IETF Homenet working group is working on standards and guidelines | |||
for IPv6 residential networks; this obviously includes operational | for IPv6 residential networks; this obviously includes operational | |||
security considerations; but this is still work in progress in early | security considerations; but this is still work in progress in early | |||
2020. [RFC8520] is an interesting approach on how firewalls could | 2020. [RFC8520] is an interesting approach on how firewalls could | |||
retrieve and apply specific security policies to some residential | retrieve and apply specific security policies to some residential | |||
devices. | devices. | |||
Some residential users have less experience and knowledge about | Some residential users have less experience and knowledge about | |||
security or networking. As most of the recent hosts (e.g., | security or networking. As most of the recent hosts (e.g., | |||
smartphones, tablets) all have IPv6 enabled by default, IPv6 security | smartphones, tablets) have IPv6 enabled by default, IPv6 security | |||
is important for those users. Even with an IPv4-only ISP, those | is important for those users. Even with an IPv4-only ISP, those | |||
users can get IPv6 Internet access with the help of Teredo | users can get IPv6 Internet access with the help of Teredo | |||
(Section 2.7.2.8) tunnels. Several peer-to-peer programs support | (Section 2.7.2.8) tunnels. Several peer-to-peer programs support | |||
IPv6 and those programs can initiate a Teredo tunnel through an IPv4 | IPv6 and those programs can initiate a Teredo tunnel through an IPv4 | |||
residential gateway, with the consequence of making the internal host | residential gateway, with the consequence of making the internal host | |||
reachable from any IPv6 host on the Internet. It is therefore | reachable from any IPv6 host on the Internet. It is therefore | |||
recommended that all host security products (including personal | recommended that all host security products (including personal | |||
firewalls) are configured with a dual-stack security policy. | firewalls) are configured with a dual-stack security policy. | |||
If the residential CPE has IPv6 connectivity, [RFC7084] defines the | If the residential CPE has IPv6 connectivity, [RFC7084] defines the | |||
requirements of an IPv6 CPE and does not take position on the debate | requirements of an IPv6 CPE and does not take a position on the debate | |||
of default IPv6 security policy as defined in [RFC6092]: | of default IPv6 security policy as defined in [RFC6092]: | |||
o outbound only: allowing all internally initiated connections and | o outbound only: allowing all internally initiated connections and | |||
block all externally initiated ones, which is a common default | block all externally initiated ones, which is a common default | |||
security policy enforced by IPv4 Residential Gateway doing NAPT | security policy enforced by IPv4 Residential Gateway doing NAPT | |||
but it also breaks the end-to-end reachability promise of IPv6. | but it also breaks the end-to-end reachability promise of IPv6. | |||
[RFC6092] lists several recommendations to design such a CPE; | [RFC6092] lists several recommendations to design such a CPE; | |||
o open/transparent: allowing all internally and externally initiated | o open/transparent: allowing all internally and externally initiated | |||
connections, therefore restoring the end-to-end nature of the | connections, therefore restoring the end-to-end nature of the | |||
Internet for the IPv6 traffic but having a different security | Internet for IPv6 traffic but having a different security | |||
policy for IPv6 than for IPv4. | policy for IPv6 than for IPv4. | |||
[RFC6092] REC-49 states that a choice must be given to the user to | [RFC6092] REC-49 states that a choice must be given to the user to | |||
select one of those two policies. | select one of those two policies. | |||
6. Further Reading | 6. Further Reading | |||
There are several documents that describe in more details the | There are several documents that describe in more detail the | |||
security of an IPv6 network; these documents are not written by the | security of an IPv6 network; these documents are not written by the | |||
IETF and some of them are dated but are listed here for the reader's | IETF and some of them are dated but are listed here for the reader's | |||
convenience: | convenience: | |||
1. Guidelines for the Secure Deployment of IPv6 [NIST] | 1. Guidelines for the Secure Deployment of IPv6 [NIST] | |||
2. North American IPv6 Task Force Technology Report - IPv6 Security | 2. North American IPv6 Task Force Technology Report - IPv6 Security | |||
Technology Paper [NAv6TF_Security] | Technology Paper [NAv6TF_Security] | |||
3. IPv6 Security [IPv6_Security_Book] | 3. IPv6 Security [IPv6_Security_Book] | |||
7. Acknowledgements | 7. Acknowledgements | |||
The authors would like to thank the following people for their useful | The authors would like to thank the following people for their useful | |||
comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, | comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, | |||
Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, | Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, | |||
Markus de Bruen, Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee | Markus de Bruen, Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee | |||
Howard, Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari, | Howard, Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari, | |||
Ted Lemon, Mark Lentczner, Jen Linkova (and her detailed review), | Ted Lemon, Mark Lentczner, Acee Lindem, Jen Linkova (and her detailed | |||
Gyan S. Mishra, Jordi Palet, Bob Sleigh, Donald Smith, Tarko Tikan, | review), Gyan Mishra, Jordi Palet, Bob Sleigh, Donald Smith, Tarko Tikan, | |||
Ole Troan, Bernie Volz (by alphabetical order). | Ole Troan, Bernie Volz (by alphabetical order). | |||
8. Security Considerations | 8. Security Considerations | |||
This memo attempts to give an overview of security considerations of | This memo attempts to give an overview of security considerations of | |||
operating an IPv6 network both for an IPv6-only network and for | operating an IPv6 network both for an IPv6-only network and for | |||
networks utilizing the most widely deployed IPv4/IPv6 coexistence | networks utilizing the most widely deployed IPv4/IPv6 coexistence | |||
strategies. | strategies. | |||
9. References | 9. References | |||
End of changes. 104 change blocks. | ||||
134 lines changed or deleted | 134 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |