< draft-ietf-opsec-v6-15.txt   draft-ietf-opsec-v6-16.txt >
OPSEC E. Vyncke, Ed. OPSEC E. Vyncke, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational K. Chittimaneni Intended status: Informational K. Chittimaneni
Expires: September 10, 2019 WeWork Expires: September 12, 2019 WeWork
M. Kaeo M. Kaeo
Double Shot Security Double Shot Security
E. Rey E. Rey
ERNW ERNW
March 9, 2019 March 11, 2019
Operational Security Considerations for IPv6 Networks Operational Security Considerations for IPv6 Networks
draft-ietf-opsec-v6-15 draft-ietf-opsec-v6-16
Abstract Abstract
Knowledge and experience on how to operate IPv4 securely is Knowledge and experience on how to operate IPv4 securely is
available: whether it is the Internet or an enterprise internal available: whether it is the Internet or an enterprise internal
network. However, IPv6 presents some new security challenges. RFC network. However, IPv6 presents some new security challenges. RFC
4942 describes the security issues in the protocol but network 4942 describes the security issues in the protocol but network
managers also need a more practical, operations-minded document to managers also need a more practical, operations-minded document to
enumerate advantages and/or disadvantages of certain choices. enumerate advantages and/or disadvantages of certain choices.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Generic Security Considerations . . . . . . . . . . . . . . . 4 2. Generic Security Considerations . . . . . . . . . . . . . . . 4
2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4
2.1.1. Statically Configured Addresses . . . . . . . . . . . 5 2.1.1. Statically Configured Addresses . . . . . . . . . . . 5
2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . 6 2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . 5
2.1.4. Temporary Addresses - Privacy Extensions for SLAAC . 6 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC . 6
2.1.5. Privacy consideration of Addresses . . . . . . . . . 7 2.1.5. Privacy consideration of Addresses . . . . . . . . . 7
2.1.6. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7 2.1.6. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7
2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 7 2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 7
2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 8 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Order and Repetition of Extension Headers . . . . . . 8 2.2.1. Order and Repetition of Extension Headers . . . . . . 8
2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 9 2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 8
2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 9 2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 8
2.2.4. IP Security Extension Header . . . . . . . . . . . . 9 2.2.4. IP Security Extension Header . . . . . . . . . . . . 9
2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9
2.3.1. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 10 2.3.1. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 9
2.3.2. RA/NA Filtering . . . . . . . . . . . . . . . . . . . 10 2.3.2. RA/NA Filtering . . . . . . . . . . . . . . . . . . . 10
2.3.3. Securing DHCP . . . . . . . . . . . . . . . . . . . . 11 2.3.3. Securing DHCP . . . . . . . . . . . . . . . . . . . . 11
2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 12 2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 12
2.3.5. SeND and CGA . . . . . . . . . . . . . . . . . . . . 13 2.3.5. SeND and CGA . . . . . . . . . . . . . . . . . . . . 12
2.4. Control Plane Security . . . . . . . . . . . . . . . . . 14 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 13
2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 15 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 14
2.4.2. Management Protocols . . . . . . . . . . . . . . . . 15 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 15
2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 15 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 15
2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 16 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 16
2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 17 2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 16
2.5.2. Securing Routing Updates Between Peers . . . . . . . 17 2.5.2. Securing Routing Updates Between Peers . . . . . . . 17
2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 18 2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 17
2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 18 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 18
2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 19 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 19
2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 23 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 23
2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 25 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 25
2.7. Transition/Coexistence Technologies . . . . . . . . . . . 25 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 25
2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 26 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 26
2.7.2. Transition Mechanisms . . . . . . . . . . . . . . . . 26 2.7.2. Transition Mechanisms . . . . . . . . . . . . . . . . 26
2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 30 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 30
2.8. General Device Hardening . . . . . . . . . . . . . . . . 32 2.8. General Device Hardening . . . . . . . . . . . . . . . . 32
3. Enterprises Specific Security Considerations . . . . . . . . 32 3. Enterprises Specific Security Considerations . . . . . . . . 32
skipping to change at page 5, line 34 skipping to change at page 5, line 34
an added benefit; it does not preclude that perimeter rules are an added benefit; it does not preclude that perimeter rules are
actively enforced and that statically configured addresses follow actively enforced and that statically configured addresses follow
some logical allocation scheme for ease of operation (as simplicity some logical allocation scheme for ease of operation (as simplicity
always helps security). Typical deployments will have a mix of always helps security). Typical deployments will have a mix of
static and non static addresses. static and non static addresses.
2.1.2. Use of ULAs 2.1.2. Use of ULAs
Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
where systems are not globally reachable, despite formally having where systems are not globally reachable, despite formally having
global scope. ULAs must not appear in the routing system outside the global scope. ULA looks similar to [RFC1918] addresses but have
administrative domain where they are considered valid. different use cases. One use of ULA is described in [RFC4864] and
some considerations on using ULA is described in the draft document
It is tempting to think that ULAs could be useful for infrastructure [I-D.ietf-v6ops-ula-usage-considerations].
hiding as described in [RFC4864]; but there are alternatives such as
infrastructure ACL or the use of link-local addresses only as
described in [RFC7404].
Even when using ULAs for the infrastructure; routers may also leak
their address to the Internet when generating ICMP messages.
Moreover ICMP error messages can also include ULA address as they
contain a copy of the offending packet.
It is recommended to consider filtering packets with ULA source
addresses or ULA destination addresses at the domain boundary.
Operators may consider to allow ICMP packets with a ULA source
address at the ingress of their network as long as the source does
not belong to a ULA used internally; this is to respect [RFC4890] and
allow for example path MTU discovery when some other operators use
internally ULA addresses.
ULAs should not be advertized over the global Internet.
2.1.3. Point-to-Point Links 2.1.3. Point-to-Point Links
[RFC6164] in section 5.1 documents the reasons why to use a /127 for [RFC6164] in section 5.1 documents the reasons why to use a /127 for
inter-router point-to-point links; notably, a /127 prevents the ping- inter-router point-to-point links; notably, a /127 prevents the ping-
pong attack between routers not implementing correctly [RFC4443] and pong attack between routers not implementing correctly [RFC4443] and
also prevents a DoS attack on the neighbor cache. The previous also prevents a DoS attack on the neighbor cache. The previous
recommendation of [RFC3627] has been obsoleted and marked Historic by recommendation of [RFC3627] has been obsoleted and marked Historic by
[RFC6547]). [RFC6547]).
Some environments are also using link-local addressing for point-to- Some environments are also using link-local addressing for point-to-
point links. While this practice could further reduce the attack point links. While this practice could further reduce the attack
surface against infrastructure devices, the operational disadvantages surface against infrastructure devices, the operational disadvantages
need also to be carefully considered; see also [RFC7404]. need also to be carefully considered; see also [RFC7404].
2.1.4. Temporary Addresses - Privacy Extensions for SLAAC 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC
Historically stateless address autoconfiguration (SLAAC) relies on Historically stateless address autoconfiguration (SLAAC) relied on an
the automatically generated EUI-64 address, which together with the automatically generated64 bit interface identifier (IID) based on the
/64 prefix makes up the global unique IPv6 address. The EUI-64 EUI-64 MAC address, which together with the /64 prefix makes up the
address is generated from the 48-bit stable MAC address. [RFC8064] globally unique IPv6 address. The EUI-64 address is generated from
recommends against the use of EUI-64 addresses and it must be noted the 48-bit stable MAC address. [RFC8064] recommends against the use
that most host operating systems do not use EUI-64 addresses anymore of EUI-64 addresses and it must be noted that most host operating
and rely on either [RFC4941] or [RFC8064]. systems do not use EUI-64 addresses anymore and rely on either
[RFC4941] or [RFC8064].
Randomly generating an interface ID, as described in [RFC4941], is Randomly generating an interface ID, as described in [RFC4941], is
part of SLAAC with so-called privacy extension addresses and used to part of SLAAC with so-called privacy extension addresses and used to
address some privacy concerns. Privacy extension addresses a.k.a. address some privacy concerns. Privacy extension addresses a.k.a.
temporary addresses may help to mitigate the correlation of temporary addresses may help to mitigate the correlation of
activities of a node within the same network, and may also somehow activities of a node within the same network, and may also somehow
reduce the attack exposure window. reduce the attack exposure window.
Using [RFC4941] privacy extension addresses prevents the operator Using [RFC4941] privacy extension addresses prevents the operator
from building host specific access control lists (ACLs). from building host specific access control lists (ACLs).
[RFC8064] specifies another way to generate while still keeping the [RFC8064] specifies another way to generate while still keeping the
same IID for each network prefix; this allows SLAAC nodes to always same IID for each network prefix; this allows SLAAC nodes to always
have the same stable IPv6 address on a specific network while having have the same stable IPv6 address on a specific network while having
different IPv6 address on different networks. different IPv6 address on different networks.
As [RFC4941] privacy extension addresses could also be used to As [RFC4941] privacy extension addresses could also be used to
obfuscate some malevolent activities (whether on purpose or not), obfuscate some malevolent activities (whether on purpose or not),
specific user attribution/accountability procedures must be put in specific user attribution/accountability procedures should be put in
place as described in section Section 2.6. place as described in section Section 2.6.
In some extreme use cases where user accountability is more important In some extreme use cases where user accountability is more important
than user privacy, network operators may consider to disable SLAAC than user privacy, network operators may consider to disable SLAAC
and rely only on DHCPv6; but, not all operating systems support and rely only on DHCPv6; but, not all operating systems support
DHCPv6 so some hosts will not get any IPv6 connectivity.Disabling DHCPv6 so some hosts will not get any IPv6 connectivity.Disabling
SLAAC and privacy extensions addresses can be done for most OS and SLAAC and privacy extensions addresses can be done for most OS and
for non-hacker users by sending RA messages with a hint to get for non-hacker users by sending RA messages with a hint to get
addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by
resetting all A-bits in all prefix information options. Hackers will resetting all A-bits in all prefix information options. Hackers will
skipping to change at page 38, line 11 skipping to change at page 38, line 11
Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), February 2017. in progress), February 2017.
[I-D.ietf-opsec-ipv6-eh-filtering] [I-D.ietf-opsec-ipv6-eh-filtering]
Gont, F. and W. LIU, "Recommendations on the Filtering of Gont, F. and W. LIU, "Recommendations on the Filtering of
IPv6 Packets Containing IPv6 Extension Headers", draft- IPv6 Packets Containing IPv6 Extension Headers", draft-
ietf-opsec-ipv6-eh-filtering-06 (work in progress), July ietf-opsec-ipv6-eh-filtering-06 (work in progress), July
2018. 2018.
[I-D.ietf-v6ops-ula-usage-considerations]
Liu, B. and S. Jiang, "Considerations For Using Unique
Local Addresses", draft-ietf-v6ops-ula-usage-
considerations-02 (work in progress), March 2017.
[I-D.kampanakis-6man-ipv6-eh-parsing] [I-D.kampanakis-6man-ipv6-eh-parsing]
Kampanakis, P., "Implementation Guidelines for parsing Kampanakis, P., "Implementation Guidelines for parsing
IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh- IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh-
parsing-01 (work in progress), August 2014. parsing-01 (work in progress), August 2014.
[I-D.thubert-savi-ra-throttler] [I-D.thubert-savi-ra-throttler]
Thubert, P., "Throttling RAs on constrained interfaces", Thubert, P., "Throttling RAs on constrained interfaces",
draft-thubert-savi-ra-throttler-01 (work in progress), draft-thubert-savi-ra-throttler-01 (work in progress),
June 2012. June 2012.
skipping to change at page 38, line 48 skipping to change at page 39, line 5
"Guidelines for the Secure Deployment of IPv6", 2010, "Guidelines for the Secure Deployment of IPv6", 2010,
<http://csrc.nist.gov/publications/nistpubs/800-119/ <http://csrc.nist.gov/publications/nistpubs/800-119/
sp800-119.pdf>. sp800-119.pdf>.
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982, RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>. <https://www.rfc-editor.org/info/rfc826>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, Domains without Explicit Tunnels", RFC 2529,
 End of changes. 16 change blocks. 
44 lines changed or deleted 37 lines changed or added

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