One document matched: draft-ietf-opsec-v6-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0826 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0826.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2529 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2529.xml">
<!ENTITY RFC2740 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2740.xml">
<!ENTITY RFC2784 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC3068 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3068.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3627.xml">
<!ENTITY RFC3756 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3756.xml">
<!ENTITY RFC3924 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3924.xml">
<!ENTITY RFC3964 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3964.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4293 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4293.xml">
<!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
<!ENTITY RFC4381 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4381.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4552.xml">
<!ENTITY RFC4659 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4659.xml">
<!ENTITY RFC4798 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4798.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4864 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml">
<!ENTITY RFC4890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4890.xml">
<!ENTITY RFC4941 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY RFC4942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4942.xml">
<!ENTITY RFC5101 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml">
<!ENTITY RFC5102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5102.xml">
<!ENTITY RFC5157 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5157.xml">
<!ENTITY RFC5214 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5214.xml">
<!ENTITY RFC5340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml">
<!ENTITY RFC5635 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5635.xml">
<!ENTITY RFC5952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.xml">
<!ENTITY RFC5969 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml">
<!ENTITY RFC6092 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6092.xml">
<!ENTITY RFC6104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6104.xml">
<!ENTITY RFC6105 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6105.xml">
<!ENTITY RFC6144 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6144.xml">
<!ENTITY RFC6146 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml">
<!ENTITY RFC6147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml">
<!ENTITY RFC6164 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6164.xml">
<!ENTITY RFC6169 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6169.xml">
<!ENTITY RFC6192 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6192.xml">
<!ENTITY RFC6204 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6204.xml">
<!ENTITY RFC6264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6264.xml">
<!ENTITY RFC6269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml">
<!ENTITY RFC6296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6296.xml">
<!ENTITY RFC6302 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6302.xml">
<!ENTITY RFC6324 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6324.xml">
<!ENTITY RFC6333 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6333.xml">
<!ENTITY RFC6343 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6343.xml">
<!ENTITY RFC6434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6434.xml">
<!ENTITY RFC6459 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6459.xml">
<!ENTITY RFC6506 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6506.xml">
<!ENTITY RFC6547 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6547.xml">
<!ENTITY RFC6583 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6583.xml">
<!ENTITY RFC6598 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6598.xml">
<!ENTITY RFC6620 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6620.xml">
<!ENTITY RFC6666 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6666.xml">
<!ENTITY RFC6810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6810.xml">
<!ENTITY RFC6964 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6964.xml">
<!-- IETF drafts -->
<!ENTITY I-D.ietf-v6ops-enterprise-incremental-ipv6 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-enterprise-incremental-ipv6.xml">
<!ENTITY I-D.ietf-opsec-lla-only PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-lla-only.xml">
<!ENTITY I-D.ietf-savi-dhcp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-savi-dhcp.xml">
<!ENTITY I-D.ietf-savi-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-savi-framework.xml">
<!ENTITY I-D.chakrabarti-nordmark-6man-efficient-nd PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chakrabarti-nordmark-6man-efficient-nd.xml">
<!ENTITY I-D.thubert-savi-ra-throttler PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thubert-savi-ra-throttler.xml">
<!ENTITY I-D.ietf-behave-nat64-discovery-heuristic PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-nat64-discovery-heuristic.xml">
<!ENTITY I-D.ietf-v6ops-ra-guard-implementation PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ra-guard-implementation.xml">
<!ENTITY I-D.ietf-6man-nd-extension-headers PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-nd-extension-headers.xml">
<!ENTITY I-D.ietf-softwire-map PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-map.xml">
<!ENTITY I-D.ietf-opsec-dhcpv6-shield PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-dhcpv6-shield.xml">
<!ENTITY I-D.ietf-opsec-bgp-security PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-bgp-security.xml">
<!ENTITY I-D.ietf-6man-stable-privacy-addresses PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-stable-privacy-addresses.xml">
<!ENTITY I-D.ietf-6man-oversized-header-chain PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-oversized-header-chain.xml">
<!ENTITY I-D.v6ops-vyncke-balanced-ipv6-security PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.v6ops-vyncke-balanced-ipv6-security.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-opsec-v6-03" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="OPsec IPV6">Operational Security Considerations for IPv6
Networks</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Kiran Kumar Chittimaneni" initials="K"
surname="Chittimaneni">
<organization>Google</organization>
<address>
<postal>
<street>1600 Amphitheater Pkwy</street>
<city>Mountain View</city>
<country>USA</country>
<code>94043</code>
</postal>
<phone>+16502249772</phone>
<email>kk@google.com</email>
</address>
</author>
<author fullname="Merike Kaeo" initials="M" surname="Kaeo">
<organization>Double Shot Security</organization>
<address>
<postal>
<street>3518 Fremont Ave N 363</street>
<city>Seattle</city>
<country>USA</country>
<code>98103</code>
</postal>
<phone>+12066696394</phone>
<email>merike@doubleshotsecurity.com</email>
</address>
</author>
<author fullname="Eric Vyncke" initials="E" surname="Vyncke">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>Diegem</city>
<country>Belgium</country>
<code>1831</code>
</postal>
<phone>+32 2 778 4677</phone>
<email>evyncke@cisco.com</email>
</address>
</author>
<date day="15" month="July" year="2013"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Operations and Management</area>
<workgroup>OPSEC</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>IPv6</keyword>
<keyword>Security</keyword>
<keyword>Operational Security</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Knowledge and experience on how to operate IPv4 securely is
available: whether it is the Internet or an enterprise internal network.
However, IPv6 presents some new security challenges. RFC 4942 describes
the security issues in the protocol but network managers also need a
more practical, operations-minded best common practices.</t>
<t>This document analyzes the operational security issues in all places
of a network (service providers, enterprises and residential users) and
proposes technical and procedural mitigations techniques.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Running an IPv6 network is new for most operators not only because
they are not yet used to large scale IPv6 networks but also because
there are subtle differences between IPv4 and IPv6 especially with
respect to security. For example, all layer-2 interactions are now done
by Neighbor Discovery Protocol <xref target="RFC4861"/> rather than by
Address Resolution Protocol <xref target="RFC0826"/>. Also, there are
subtle differences between NAT44 and NPTv6 <xref target="RFC6296"/>
which are explicitly pointed out in the latter's security considerations
section.</t>
<t>IPv6 networks are deployed using a variety of techniques, each of
which have their own specific security concerns.</t>
<t>This document complements <xref target="RFC4942"/> by listing all
security issues when operating a network utilizing varying transition
technologies and updating with ones that have been standardized since
2007. It also provides more recent operational deployment experiences
where warranted.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/> when they appear in ALL CAPS. These words may also
appear in this document in lower case as plain English words, absent
their normative meanings.</t>
</section>
</section>
<section anchor="generic" title="Generic Security Considerations">
<section anchor="v6addressing" title="Addressing Architecture">
<t>IPv6 address allocations and overall architecture are an important
part of securing IPv6.</t>
<section anchor="structure" title="Overall Structure">
<t>Once an address allocation has been assigned, there should be
some thought given to an overall address allocation plan. A
structured address allocation plan can lead to more concise and
simpler firewall filtering rules. With the abundance of address
space available, an address allocation may be structured around
services along with geographic locations, which then can be a basis
for more structured network filters to permit or deny services
between geographic regions.</t>
<t>There still exists a debate whether companies should use PI vs PA
space <xref target="I-D.ietf-v6ops-enterprise-incremental-ipv6"/>
but from a security perspective there is little difference. However,
one aspect to keep in mind is who has ownership of the address space
and who is responsible if/when Law Enforcement may need to enforce
restrictions on routability of the space due to malicious criminal
activity.</t>
<t>When considering how to assign manually configured addresses it
is necessary to take into consideration the effectiveness of
perimeter security in a given environment. There is a trade-off
between ease of operational deployment where some portions of the
IPv6 address could be easily recognizable for operational debugging
and troubleshooting versus the risk of scanning; <xref
target="SCANNING"/> shows that there are scientifically based
mechanisms that make scanning for IPv6 reachable nodes more
realizable than expected. The use of common multicast groups which
are defined for important networked devices and the use of commonly
repeated addresses could make it easy to figure out which devices
are name servers, routers or other critical devices. While in some
environments the perimeter security is so poor that obfuscating
addresses is considered a benefit; it is a much better practice to
ensure that perimeter rules are actively checked and enforced and
that manually configured addresses follow some logical allocation
scheme for ease of operation.</t>
</section>
<!--structure-->
<section anchor="ula" title="Use of ULAs">
<t>ULAs are intended for scenarios where IP addresses will not have
global scope. The implicit expectation from the RFC is that all ULAs
will be randomly created as /48s. However, in practice some
environments have chosen to create ULAs as a /32 by removing the
random part of the address. The use of a /32 violates <xref
target="RFC4193"/> and greatly reduces the probability of
non-collision. ULAs are also useful for infrastructure hiding as
described in <xref target="RFC4864"/>. Although ULAs are supposed to
be used in conjunction with global addresses for hosts that desire
external connectivity, a few operators chose to use ULAs in
conjunction with some sort of address translation at the border in
order to maintain a perception of parity between their IPv4 and IPv6
setup. Additionally, there have been some issues with source address
selection, although these should be considered bugs to be fixed
rather than worked around using NAT. Some operators believe that
stateful IPv6 Network Address and Port Translation (NAPT) provides
some security not provided by NPTv6 (the authors of this document do
not share this point of view). The latter would be problematic in
trying to track specific machines that may source malware although
this is less of an issue if appropriate logging is done which
includes utilizing accurate timestamps and logging a node's source
ports <xref target="RFC6302"/>.</t>
<t>The use of ULA does not isolate 'by magic' the part of the
network using ULA from other parts of the network (including the
Internet). Although section 4.1 of <xref target="RFC4193"/>
explicitly states "If BGP is being used at the site border with an
ISP, the default BGP configuration must filter out any Local IPv6
address prefixes, both incoming and outgoing.", the operational
reality is that this guideline is not always followed. As written,
RFC4193 makes no changes to default routing behavior of exterior
protocols. Therefore, routers will happily forward packets whose
source or destination address is ULA as long as they have a route to
the destination and there is no ACL blocking those packets. This
means that using ULA does not prevent route and packet filters to be
implemented and monitored. This also means that all transit networks
should consider ULA as source or destination as bogons packets and
drop them.</t>
<t>It is important to carefully weigh the benefits of using ULAs
versus utilizing a section of the global allocation and creating a
more effective filtering strategy. A typical argument is that there
are too many mistakes made with filters and ULAs make things easier
to hide machines.</t>
</section>
<!--ula-->
<section anchor="p2p" title="Point-to-Point Links">
<t><xref target="RFC6164"/> recommends the use of /127 for
inter-router point-to-point links. /127 prevents the ping-pong
attack between routers non enforced RFC4443. However, it should be
noted that at the time of this writing, there are still many
networks out there that follow the advice provided by <xref
target="RFC3627"/> (Obsoleted and marked Historic by <xref
target="RFC6547"/>) and therefore continue to use /64's and/or
/112's. We recommend that the guidance provided by RFC6164 be
followed.</t>
<t>Some environments are also using link-local addressing for
point-to-point links. While this practice could further reduce the
attack surface against infrastructure devices, the operational
disadvantages need also to be carefully considered <xref
target="I-D.ietf-opsec-lla-only"/>.</t>
</section>
<!--p2p-->
<section anchor="priv"
title="Temporary Addresses - Privacy Extensions for SLAAC">
<t>Normal stateless address autoconfiguration (SLAAC) relies on the
automatically generated EUI-64 address, which together with the /64
prefix makes up the global unique IPv6 address. The EUI-64 address
is generated from the MAC address. Randomly generating an interface
ID, as described in <xref target="RFC4941"/>, is part of SLAAC with
so-called temporary addresses and used to address some privacy
concerns. Temporary addresses a.k.a. privacy extensions may help to
mitigate the correlation of activities of a node within the same
network, and may also reduce the attack exposure window.</t>
<t>As temporary address could also be used to obfuscate some illegal
activities (whether on purpose or not), it is advised in scenarios
where attribution is important to disable SLAAC and rely only on
DHCPv6. However, in scenarios where anonymity is a strong desire
since protecting user privacy is more important than attribution,
temporary addresses should be used</t>
<t>Some people also feel that SLAAC means that the operator may not
know addresses operating in the networks ahead of time in order to
to build host specific access control lists (ACLs) of authorized
users. While privacy addresses are truly generated randomly to
protect against user tracking, but assuming that nodes use the
EUI-64 format for global addressing, a list of expected
pre-authorized host addresses can be generated. It must be noted
that recent versions of Windows do not use the MAC address anymore
to build the stable address but use a mechanism similar to the one
described in <xref
target="I-D.ietf-6man-stable-privacy-addresses"/>, this also means
that such an ACL cannot be configured based solely on the MAC
address of the nodes, diminushing the value of such ACL. On the
other hand, different VLANs are often used to seggregate users, then
ACL can rely on a /64 prefix per VLAN rather than a per host ACL
entry.</t>
<t>The decision to utilize temporary addresses can come down to
whether the network is managed versus unmanaged. In some
environments full visibility into the network is required at all
times which requires that all traffic be attributable to where it is
sourced or where it is destined to within a specific network. This
situation is dependent on what level of logging is performed. If
logging considerations include utilizing accurate timestamps and
logging a node's source ports <xref target="RFC6302"/> then there
should always exist appropriate attribution needed to get to the
source of any malware originator or source of criminal activity.</t>
<t>However, there are several privacy issues still present with
<xref target="RFC4941"/> such as host tracking, and address scanning
attacks are still possible. More details are provided in Appendix A.
of <xref target="I-D.ietf-6man-stable-privacy-addresses"/>.</t>
<t>Disabling SLAAC and temporary addresses can be done by sending
Router Advertisement with a hint to use DHCPv6 by setting the M-bit
but also disabling SLAAC by resetting all A-bits in all prefixes
sent in the Router Advertisement message.</t>
</section>
<!--priv-->
<section anchor="dhcpdns" title="DHCP/DNS Considerations">
<t>Many environments use DHCPv6 in their environments to ensure
audibility and traceability (but see <xref
target="stateful_dhcp"/>). A main security concern is the ability to
detect and mitigate against rogue DHCP servers (<xref
target="snoop"/>).</t>
<t>DNS is often used for malware activities and while there are no
fundamental differences with IPv4 and IPv6 security concerns, there
are specific consideration in DNS64 <xref target="RFC6147"/>
environments that need to be understood. Specifically the
interactions and potential to interference with DNSsec
implementation need to be understood - these are pointed out in
detail in <xref target="nat64"/>.</t>
</section>
<!--dchpdns-->
</section>
<!--v6addressing-->
<section anchor="linklayer" title="Link-Layer Security">
<t>IPv6 relies heavily on the Neighbor Discovery protocol (NDP) <xref
target="RFC4861"/> to perform a variety of link operations such as
discovering other nodes on the link, resolving their link-layer
addresses, and finding routers on the link. If not secured, NDP is
vulnerable to various attacks such as router/neighbor message
spoofing, redirect attacks, Duplicate Address Detection (DAD) DoS
attacks, etc. many of these security threats to NDP have been
documented in IPv6 ND Trust Models and Threats <xref
target="RFC3756"/> and in <xref target="RFC6583"/>.</t>
<section anchor="send" title="SeND and CGA">
<t>The original NDP specification called for using IPsec to protect
Neighbor Discovery messages. However, manually configuring security
associations among multiple hosts on a large network can be very
challenging. In many environments the tradeoff between using
technologies that require an effective key management lifecycle
process creates more of an operational burden than the protection
offered by a given technology. IPsec protection for NDP typically
falls under this category.</t>
<t>SEcure Neighbor Discovery (SeND), as described in <xref
target="RFC3971"/>, is a mechanism that was designed to secure ND
messages without having to rely on manual IPsec configuration. This
approach involves the use of new NDP options to carry public key
based signatures. Cryptographically Generated Addresses (CGA), as
described in <xref target="RFC3972"/>, are used to ensure that the
sender of a Neighbor Discovery message is the actual "owner" of the
claimed IPv6 address. A new NDP option, the CGA option, was
introduced and is used to carry the public key and associated
parameters. Another NDP option, the RSA Signature option, is used to
protect all messages relating to neighbor and Router discovery.</t>
<t>SeND protects against: <list style="symbols">
<t>Neighbor Solicitation/Advertisement Spoofing</t>
<t>Neighbor Unreachability Detection Failure</t>
<t>Duplicate Address Detection DoS Attack</t>
<t>Router Solicitation and Advertisement Attacks</t>
<t>Replay Attacks</t>
<t>Neighbor Discovery DoS Attacks</t>
</list></t>
<t>SeND does NOT: <list style="symbols">
<t>Protect statically configured addresses</t>
<t>Protect addresses configured using fixed identifiers (i.e.
EUI-64)</t>
<t>Provide confidentiality for NDP communications</t>
<t>Compensate for an unsecured link - SEND does not require that
the addresses on the link and Neighbor Advertisements
correspond</t>
</list></t>
<t>However, at this time, CGA and SeND do not have wide support from
generic operating systems; hence, their usefulness is limited.</t>
</section>
<!--send-->
<section anchor="snoop" title="DHCP Snooping">
<t>Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as
detailed in <xref target="RFC3315"/>, enables DHCP servers to pass
configuration parameters such as IPv6 network addresses and other
configuration information to IPv6 nodes. DHCP plays an important
role in any large network by providing robust stateful
autoconfiguration and autoregistration of DNS Host Names.</t>
<t>The two most common threats to DHCP clients come from malicious
or misconfigured DHCP servers. A malicious DHCP server is one that
is established with the intent of providing incorrect configuration
information to the client. The motivation for doing so may be to
mount a "man in the middle" attack instead of a valid server for
services such as DNS or to cause a denial of service attack through
misconfiguration of the client that causes all network communication
from the client to fail. A misconfigured, or sometimes referred to
as rogue, DHCP server is one that has unintentionally been
configured to answer DHCP client requests with incorrect
configuration parameters. Some additional threats against DHCP are
discussed in the security considerations section of <xref
target="RFC3315"/></t>
<t><xref target="I-D.ietf-opsec-dhcpv6-shield"/> specifies a
mechanism for protecting hosts connected to a broadcast network
against rogue DHCPv6 servers. This mechanism is based on DHCPv6
packet-filtering at the layer-2 device on which the packets are
received. Before the DCHPv6-Shield device is deployed, the
administrator specifies the layer-2 port(s) on which DHCPv6 packets
meant for DHCPv6 clients are allowed. Only those ports to which a
DHCPv6 server is to be connected should be specified as such. Once
deployed, the DHCPv6-Shield device inspects received packets, and
allows DHCPv6 messages meant for DHCPv6 clients only if they are
received on layer-2 ports that have been explicitly configured for
such purpose.</t>
<t>Additionally, the Source Address Validation Improvements (SAVI)
working group is currently working on other ways to mitigate the
effects of such attacks. <xref target="I-D.ietf-savi-dhcp"/> would
help in creating bindings between a DHCPv4 <xref target="RFC2131"/>
/DHCPv6 <xref target="RFC3315"/> assigned source IP address and a
binding anchor <xref target="I-D.ietf-savi-framework"/> on a SAVI
device. Also, <xref target="RFC6620"/> describes how to glean
similar bindings when DHCP is not used. The bindings can be used to
filter packets generated on the local link with forged source IP
address.</t>
</section>
<!--snoop-->
<section anchor="ratelim" title="ND/RA Rate Limiting">
<t>Neighbor Discovery (ND) can be vulnerable to denial of service
(DoS) attacks in which a router is forced to perform address
resolution for a large number of unassigned addresses. Possible side
effects of this attack preclude new devices from joining the network
or even worse rendering the last hop router ineffective due to high
CPU usage. Easy mitigative steps include rate limiting Neighbor
Solicitations, restricting the amount of state reserved for
unresolved solicitations, and clever cache/timer management.</t>
<t><xref target="RFC6583"/> discusses the potential for DOS in
detail and suggests implementation improvements and operational
mitigation techniques that may be used to mitigate or alleviate the
impact of such attacks. Here are some feasible mitigation options
that can be employed by network operators today:<list
style="symbols">
<t>Ingress filtering of unused addresses by ACL, route
filtering, longer than /64 prefix; These require static
configuration of the addresses.</t>
<t>Tuning of NDP process (where supported).</t>
</list></t>
<t>Additionally, IPv6 ND uses multicast extensively for signaling
messages on the local link to avoid broadcast messages for
on-the-wire efficiency. However, this has some side effects on wifi
networks, especially a negative impact on battery life of
smartphones and other battery operated devices that are connected to
such networks. The following drafts are actively discussing methods
to rate limit RAs and other ND messages on wifi networks in order to
address this issue: <list style="symbols">
<t><xref target="I-D.thubert-savi-ra-throttler"/></t>
<t><xref
target="I-D.chakrabarti-nordmark-6man-efficient-nd"/></t>
</list></t>
</section>
<!--ratelim-->
<section anchor="filter" title="ND/RA Filtering">
<t>Router Advertisement spoofing is a well-known attack vector and
has been extensively documented. The presence of rogue RAs, either
intentional or malicious, can cause partial or complete failure of
operation of hosts on an IPv6 link. For example, a host can select
an incorrect router address which can be used as a man-in-the-middle
(MITM) attack or can assume wrong prefixes to be used for stateless
address configuration (SLAAC). <xref target="RFC6104"/> summarizes
the scenarios in which rogue RAs may be observed and presents a list
of possible solutions to the problem. <xref target="RFC6105"/>
(RA-Guard) describes a solution framework for the rogue RA problem
where network segments are designed around switching devices that
are capable of identifying invalid RAs and blocking them before the
attack packets actually reach the target nodes.</t>
<t>However, several evasion techniques that circumvent the
protection provided by RA-Guard have surfaced. A key challenge to
this mitigation technique is introduced by IPv6 fragmentation. An
attacker can conceal the attack by fragmenting his packets into
multiple fragments such that the switching device that is
responsible for blocking invalid RAs cannot find all the necessary
information to perform packet filtering in the same packet. <xref
target="I-D.ietf-v6ops-ra-guard-implementation"/> describes such
evasion techniques, and provides advice to RA-Guard implementers
such that the aforementioned evasion vectors can be eliminated.</t>
<t>Given that the IPv6 Fragmentation Header can be leveraged to
circumvent current implementations of RA-Guard, <xref
target="I-D.ietf-6man-nd-extension-headers"/> aims to update <xref
target="RFC4861"/> such that use of the IPv6 Fragmentation Header is
forbidden in all Neighbor Discovery messages except "Certification
Path Advertisement", thus allowing for simple and effective measures
to counter Neighbor Discovery attacks.</t>
<t>It is still recommended that RA-Guard be be employed as a first
line of defense against common attack vectors including
misconfigured hosts.</t>
</section>
<!--filter-->
<section anchor="threegpp" title="3GPP Link-Layer Security">
<t>The 3GPP link is a point-to-point like link that has no
link-layer address. This implies there can only be an end host and
the first-hop router i.e., a GGSN or a PGW on that link. The
GGSN/PGW never configures a non link-local address on the link using
the prefix advertised on it and the advertised prefix must not be
used for on-link determination. There is no need for an address
resolution on the 3GPP link, since there are no link-layer
addresses. Furthermore, the GGSN/PGW assigns a prefix that is unique
within each 3GPP link that uses IPv6 stateless address
autoconfiguration. This avoids the necessity to perform DAD at the
network level for every address built by the cellular host. The
GGSN/PGW always provides an IID to the cellular host for the purpose
of configuring the link-local address and ensures the uniqueness of
the IID on the link (i.e., no collisions between its own link-local
address and the cellular host's).</t>
<t>The 3GPP link model itself mitigates most of the known
NDP-related Denial-of-Service attacks. In practice, the GGSN/PGW
only needs to route all traffic to the cellular host that fall under
the prefix assigned to it. This implies the GGSN/PGW may implement a
minimal neighbor discovery protocol subset; since, due the
point-to-point link model and the absence of link-layer addressing
the address resolution can be entirely statically configured per
each 3GPP link, and there is no need to defend any other address
than the link-local address for very unlikely duplicates.</t>
<t>See Section 5 of <xref target="RFC6459"/> for a more detailed
discussion on the 3GPP link model, NDP on it and the address
configuration detail.</t>
</section>
<!--threegpp-->
</section>
<!--linklayer-->
<section anchor="copp" title="Control Plane Security">
<t><xref target="RFC6192"/> defines the router control plane and this
definition is repeated here for the reader's convenience.</t>
<t>Modern router architecture design maintains a strict separation of
forwarding and router control plane hardware and software. The router
control plane supports routing and management functions. It is
generally described as the router architecture hardware and software
components for handling packets destined to the device itself as well
as building and sending packets originated locally on the device. The
forwarding plane is typically described as the router architecture
hardware and software components responsible for receiving a packet on
an incoming interface, performing a lookup to identify the packet's IP
next hop and determine the best outgoing interface towards the
destination, and forwarding the packet out through the appropriate
outgoing interface.</t>
<t>While the forwarding plane is usually implemented in high-speed
hardware, the control plane is implemented by a generic processor
(named router processor RP) and cannot process packets at a high rate.
Hence, this processor can be attacked by flooding its input queue with
more packets than it can process. The control plane processor is then
unable to process valid control packets and the router can lose OSPF
or BGP adjacencies which can cause a severe network disruption.</t>
<t>The mitigation technique is: <list style="symbols">
<t>To drop non-legit control packet before they are queued to the
RP (this can be done by a forwarding plane ACL) and</t>
<t>To rate limit the remaining packets to a rate that the RP can
sustain. Protocol specific protection should also be done (for
example, a spoofed OSPFv3 packet could trigger the execution of
the Dijkstra algorithm, therefore the number of Dijsktra execution
should be also rate limited).</t>
</list></t>
<t>This section will consider several classes of control packets:
<list style="symbols">
<t>Control protocols: routing protocols: such as OSPFv3, BGP and
by extension Neighbor Discovery and ICMP</t>
<t>Management protocols: SSH, SNMP, IPfix, etc</t>
<t>Packet exceptions: which are normal data packets which requires
a specific processing such as generating a packet-too-big ICMP
message or having the hop-by-hop extension header.</t>
</list></t>
<section anchor="control" title="Control Protocols">
<t>This class includes OSPFv3, BGP, NDP, ICMP.</t>
<t>An ingress ACL to be applied on all the router interfaces SHOULD
be configured such as: <list style="symbols">
<t>drop OSPFv3 (identified by Next-Header being 89) and RIPng
(identified by UDP port 521) packets from a non link-local
address</t>
<t>allow BGP (identified by TCP port 179) packets from all BGP
neighbors and drop the others</t>
<t>allow all ICMP packets (transit and to the router
interfaces)</t>
</list></t>
<t>Note: dropping OSPFv3 packets which are authenticated by IPsec
could be impossible on some routers whose ACL are unable to parse
the IPsec ESP or AH extension headers.</t>
<t>Rate limiting of the valid packets SHOULD be done. The exact
configuration obviously depends on the power of the Route
Processor.</t>
</section>
<!--control-->
<section anchor="mgmt" title="Management Protocols">
<t>This class includes: SSH, SNMP, syslog, NTP, etc</t>
<t>An ingress ACL to be applied on all the router interfaces SHOULD
be configured such as: <list style="symbols">
<t>Drop packets destined to the routers except those belonging
to protocols which are used (for example, permit TCP 22 and drop
all when only SSH is used);</t>
<t>Drop packets where the source does not match the security
policy, for example if SSH connections should only be originated
from the NOC, then the ACL should permit TCP port 22 packets
only from the NOC prefix.</t>
</list></t>
<t>Rate limiting of the valid packets SHOULD be done. The exact
configuration obviously depends on the power of the Route
Processor.</t>
</section>
<!--mgmt-->
<section anchor="exception" title="Packet Exceptions">
<t>This class covers multiple cases where a data plane packet is
punted to the route processor because it requires specific
processing: <list style="symbols">
<t>generation of an ICMP packet-too-big message when a data
plane packet cannot be forwarded because it is too large;</t>
<t>generation of an ICMP hop-limit-expired message when a data
plane packet cannot be forwarded because its hop-limit field has
reached 0;</t>
<t>generation of an ICMP destination-unreachable message when a
data plane packet cannot be forwarded for any reason;</t>
<t>processing of the hop-by-hop extension header.</t>
</list></t>
<t>On some routers, not everything can be done by the specialized
data plane hardware which requires some packets to be 'punted' to
the generic RP. This could include for example the processing of a
long extension header chain in order to apply an ACL based on layer
4 information. <xref target="I-D.ietf-6man-oversized-header-chain"/>
highlights the security implications of oversized header chains on
routers and aims to update RFC2460 such that the first fragment of a
packet is required to contain the entire IPv6 header chain.</t>
<t>An ingress ACL cannot help to mitigate a control plane attack
using those packet exceptions. The only protection for the RP is to
limit the rate of those packet exceptions forwarded to the RP, this
means that some data plane packets will be dropped without any ICMP
messages back to the source which will cause Path MTU holes. But,
there is no other solution.</t>
<t>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
messages both the save the RP but also to prevent an amplification
attack using the router as a reflector.</t>
</section>
<!--exception-->
</section>
<!--copp-->
<section anchor="rsec" title="Routing Security">
<t>Routing security in general can be broadly divided into three
sections: <list style="numbers">
<t>Authenticating neighbors/peers</t>
<t>Securing routing updates between peers</t>
<t>Route filtering</t>
</list></t>
<t><xref target="I-D.ietf-opsec-bgp-security"/> covers these sections
specifically for BGP in detail.</t>
<section anchor="auth" title="Authenticating Neighbors/Peers">
<t>A basic element of routing is the process of forming adjacencies,
neighbor, or peering relationships with other routers. From a
security perspective, it is very important to establish such
relationships only with routers and/or administrative domains that
one trusts. A traditional approach has been to use MD5 HMAC, which
allows routers to authenticate each other prior to establishing a
routing relationship.</t>
<t>OSPFv3 can rely on IPsec to fulfill the authentication function.
However, it should be noted that IPsec support is not standard on
all routing platforms. In some cases, this requires specialized
hardware that offloads crypto over to dedicated ASICs or enhanced
software images (both of which often come with added financial cost)
to provide such functionality. An added detail is to determine
whether OSPFv3 IPsec implementations use AH or ESP-Null for
integrity protection. In early implementations all OSPFv3 IPsec
configurations relied on AH since the details weren't specified in
<xref target="RFC2740"/> and the updated <xref target="RFC5340"/>.
However, the document which specifically describes how IPsec should
be implemented for OSPFv3 <xref target="RFC4552"/> specifically
states that ESP-Null MUST and AH MAY be implemented since it follows
the overall IPsec standards wordings. OSPFv3 can also use normal ESP
to encrypt the OSPFv3 payload to hide the routing information.</t>
<t><xref target="RFC6506"/> changes OSPFv3's reliance on IPsec by
appending an authentication trailer to the end of the OSPFv3
packets. This document does not specifically provide for a mechanism
that will authenticate the specific originator of a packet. Rather,
it will allow a router to confirm that the packet has indeed been
issued by a router that had access to the shared authentication
key.</t>
<t>With all authentication mechanisms, operators should confirm that
implementations can support re-keying mechanisms that do not cause
outages. There have been instances where any re-keying cause outages
and therefore the tradeoff between utilizing this functionality
needs to be weighed against the protection it provides.</t>
</section>
<!--auth-->
<section anchor="updates"
title="Securing Routing Updates Between Peers">
<t>IPv6 initially mandated the provisioning of IPsec capability in
all nodes. However, in the updated IPv6 Nodes Requirement standard
<xref target="RFC6434"/> is now a SHOULD and not MUST implement.
Theoretically it is possible, and recommended, that communication
between two IPv6 nodes, including routers exchanging routing
information be encrypted using IPsec. In practice however, deploying
IPsec is not always feasible given hardware and software limitations
of various platforms deployed, as described in the earlier section.
Additionally, in a protocol such as OSPFv3 where adjacencies are
formed on a one-to-many basis, IPsec key management becomes
difficult to maintain and is not often utilized.</t>
</section>
<!--updates-->
<section anchor="rifler" title="Route Filtering">
<t>Route filtering policies will be different depending on whether
they pertain to edge route filtering vs internal route filtering. At
a minimum, IPv6 routing policy as it pertains to routing between
different administrative domains should aim to maintain parity with
IPv4 from a policy perspective e.g., <list style="symbols">
<t>Filter internal-use, non-globally routable IPv6 addresses at
the perimeter</t>
<t>Discard packets from and to bogon and reserved space</t>
<t>Configure ingress route filters that validate route origin,
prefix ownership, etc. through the use of various routing
databases, e.g., RADB. There is additional work being done in
this area to formally validate the origin ASs of BGP
announcements in <xref target="RFC6810"/></t>
</list></t>
<t>Some good recommendations for filtering can be found from Team
CYMRU at <xref target="CYMRU"/>.</t>
</section>
<!--rfilter-->
</section>
<!--rsec-->
<section anchor="log" title="Logging/Monitoring">
<t>In order to perform forensic research in case of any security
incident or to detect abnormal behaviors, network operator should log
multiple pieces of information.</t>
<t>This includes: <list style="symbols">
<t>logs of all applications when available (for example web
servers);</t>
<t>use of <xref target="RFC5101"> IP Flow Information Export
</xref> also known as IPfix;</t>
<t>use of SNMP <xref target="RFC4293">MIB</xref>;</t>
<t>use of the Neighbor cache;</t>
<t>use of <xref target="RFC3315">stateful DHCPv6</xref> lease
cache.</t>
</list></t>
<t>Please note that there are privacy issues related to how those logs
are collected, kept and safely discarded. Operators are urged to check
their country legislation.</t>
<t>All those pieces of information will be used for:<list
style="symbols">
<t><xref target="forensic">forensic</xref> research to answer
questions such as who did what and when?</t>
<t><xref target="correlation">correlation</xref>: which IP
addresses were used by a specific node (assuming the use of <xref
target="RFC4941">privacy extensions addresses </xref>)</t>
<t><xref target="inventory">inventory</xref>: which IPv6 nodes are
on my network?</t>
<t><xref target="abnormal_behavior">abnormal behavior
detection</xref>: unusual traffic patterns are often the symptoms
of a abnormal behavior which is in turn a potential attack (denial
of services, network scan, a node being part of a botnet, ...)</t>
</list></t>
<section anchor="data_sources" title="Data Sources">
<t>This section lists the most important sources of data that are
useful for operational security.</t>
<section title="Logs of Applications">
<t>Those logs are usually text files where the remote IPv6 address
is stored in all characters (not binary). This can complicate the
processing since one IPv6 address, 2001:db8::1 can be written in
multiple ways such as:<list style="symbols">
<t>2001:DB8::1 (in uppercase)</t>
<t>2001:0db8::0001 (with leading 0)</t>
<t>and many other ways.</t>
</list></t>
<t><xref target="RFC5952">RFC 5952</xref> explains this problem in
detail and recommends the use of a single canonical format (in
short use lower case and suppress leading 0). This memo recommends
the use of <xref target="RFC5952">canonical format</xref> for IPv6
addresses in all possible cases. If the existing application
cannot log under the canonical format, then this memo recommends
the use an external program (or filter) in order to canonicalize
all IPv6 addresses.</t>
<t>For example, this perl script can be used:</t>
<figure>
<artwork><![CDATA[#!/usr/bin/perl ?w
use strict ;
use warnings ;
use Socket ;
use Socket6 ;
my (@words, $word, $binary_address) ;
## go through the file one line at a time
while (my $line = <STDIN>) {
chomp $line;
foreach my $word (split /[ \n]/, $line) {
$binary_address = inet_pton AF_INET6, $word ;
if ($binary_address) {
print inet_ntop AF_INET6, $binary_address ;
} else {
print $word ;
}
print " " ;
}
print "\n" ;
}]]></artwork>
</figure>
</section>
<section title="IP Flow Information Export by IPv6 Routers">
<t><xref target="RFC5102">IPfix</xref> defines some data elements
that are useful for security:<list style="symbols">
<t>in section 5.4 (IP Header fields): nextHeaderIPv6 and
sourceIPv6Address;</t>
<t>in section 5.6 (Sub-IP fields) sourceMacAddress.</t>
</list></t>
<t>Moreover, IPfix is very efficient in terms of data handling and
transport. It can also aggregate flows by a key such as
sourceMacAddress in order to have aggregated data associated with
a specific sourceMacAddress. This memo recommends the use of IPfix
and aggregation on nextHeaderIPv6, sourceIPv6Address and
sourceMacAddress.</t>
</section>
<section anchor="mib" title="SNMP MIB by IPv6 Routers">
<t><xref target="RFC4293">RFC 4293</xref> defines a Management
Information Base (MIB) for the two address families of IP. This
memo recommends the use of:<list style="symbols">
<t>ipIfStatsTable table which collects traffic counters per
interface;</t>
<t>ipNetToPhysicalTable table which is the content of the
Neighbor cache, i.e. the mapping between IPv6 and data-link
layer addresses.</t>
</list></t>
</section>
<section anchor="ndp_cache" title="Neighbor Cache of IPv6 Routers">
<t>The neighbor cache of routers contains all mappings between
IPv6 addresses and data-link layer addresses. It is usually
available by two means:<list style="symbols">
<t>the <xref target="mib">SNMP MIB</xref> as explained
above;</t>
<t>also by connecting over a secure management channel (such
as SSH or HTTPS) and explicitely requesting a neighbor cache
dump.</t>
</list></t>
<t>The neighbor cache is highly dynamic as mappings are added when
a new IPv6 address appears on the network (could be quite often
with <xref target="RFC4941">privacy extension addresses</xref> or
when they are removed when the state goes from UNREACH to removed
(the default time for a removal per <xref
target="RFC4861">Neighbor Unreachability Detection</xref>
algorithm is 38 seconds for a typical host such as Windows 7).
This means that the content of the neighbor cache must
periodically be fetched every 30 seconds (to be on the safe side)
and stored for later use.</t>
<t>This is an important source of information because it is
trivial (on a switch not using the <xref
target="I-D.ietf-savi-framework">SAVI</xref> algorithm) to defeat
the mapping between data-link layer address and IPv6 address. Let
us rephrase the previous statement: having access to the current
and past content of the neighbor cache has a paramount value for
forensic and audit trail.</t>
</section>
<section anchor="stateful_dhcp" title="Stateful DHCPv6 Lease">
<t>In some networks, IPv6 addresses are managed by stateful <xref
target="RFC3315">DHCPv6 server</xref> that leases IPv6 addresses
to clients. It is indeed quite similar to DHCP for IPv4 so it can
be tempting to use this DHCP lease file to discover the mapping
between IPv6 addresses and data-link layer addresses as it was
usually done in the IPv4 era.</t>
<t>It is not so easy in the IPv6 era because not all nodes will
use DHCPv6 (there are nodes which can only do stateless
autoconfiguration) but also because DHCPv6 clients are identified
not 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 address, some being data-link layer address
prepended with time information or even an opaque number which is
useless for operation security. Moreover, when the DUID is based
on the data-link address, this address can be of any interface of
the client (such as the wireless interface while the client
actually uses its wired interface to connect to the network).</t>
<t>In short, the DHCPv6 lease file is less interesting than in the
IPv4 era. DHCPv6 servers that keeps the relayed data-link layer
address in addition to the DUID in the lease file do not suffer
from this limitation. On a managed network where all hosts support
DHCPv6, special care must be taken to prevent stateless
autoconfiguration anyway (and if applicable) by sending RA with
all announced prefixes without the A-bit set.</t>
<t>The mapping between data-link layer address and the IPv6
address can be secured by using switches implementing the <xref
target="I-D.ietf-savi-dhcp">SAVI</xref> algorithms.</t>
</section>
<section title="Other Data Sources">
<t>There are other data sources that must be kept exactly as in
the IPv4 network:<list style="symbols">
<t>historical mapping of MAC address to RADIUS user
authentication in a IEEE 802.1X network or an IPsec-based
remote access VPN;</t>
<t>historical mapping of MAC address to switch interface in a
wired network.</t>
</list></t>
</section>
</section>
<section title="Use of Collected Data">
<t>This section leverages the data collected as described <xref
format="default" target="data_sources">before</xref> in order to
achieve several security benefits.</t>
<section anchor="forensic" title="Forensic">
<t>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 still currently in the network.</t>
<t>The source of information can be, in decreasing order, neighbor
cache, DHCP lease file. Then, the procedure is:<list
style="numbers">
<t>based on the IPv6 prefix of the IPv6 address find the
router(s) which are used to reach this prefix;</t>
<t>based on this limited set of routers, on the incident time
and on IPv6 address to retrieve the data-link address from
live neighbor cache, from the historical data of the neighbor
cache, or from the DHCP lease file;</t>
<t>based on the data-link layer address, look-up on which
switch interface was this data-link layer address. In the case
of wireless LAN, the RADIUS log should have the mapping
between user identification and the MAC address.</t>
</list></t>
<t>At the end of the process, the interface where the malicious
user was connected or the username that was used by the malicious
user is found.</t>
</section>
<section anchor="inventory" title="Inventory">
<t><xref target="RFC5157">RFC 5157 </xref> is about the
difficulties to scan an IPv6 network due to the vast number of
IPv6 addresses per link. This has the side effect of making the
inventory task difficult in an IPv6 network while it was trivial
to do in an IPv4 network (a simple enumeration of all IPv4
addresses, followed by a ping and a TCP/UDP port scan). Getting an
inventory of all connected devices is of prime importance for a
secure operation of a network.</t>
<t>There are two ways to do an inventory of an IPv6 network.</t>
<t>The first technique is to use the IPfix information and extract
the list of all IPv6 source addresses to find all IPv6 nodes that
sent packets through a router. This is very efficient but alas
will not discover silent node that never transmitted such
packets... Also, it must be noted that link-local addresses will
never be discovered by this means.</t>
<t>The second way is again to use the collected neighbor cache
content to find all IPv6 addresses in the cache. This process will
also discover all link-local addresses. See <xref
target="ndp_cache"/>.</t>
<t>Another way works only for local network, it consists in
sending a ICMP ECHO_REQUEST to the link-local multicast address
ff02::1 which is all IPv6 nodes on the network. All nodes should
reply to this ECHO_REQUEST per <xref target="RFC4443"/>.</t>
</section>
<section anchor="correlation" title="Correlation">
<t>In an IPv4 network, it is easy to correlate multiple logs, for
example to find events related to a specific IPv4 address. A
simple Unix grep command was enough to scan through multiple
text-based files and extract all lines relevant to a specific IPv4
address.</t>
<t>In an IPv6 network, this is slightly more difficult because
different character strings can express the same IPv6 address.
Therefore, the simple Unix grep command cannot be used. Moreover,
an IPv6 node can have multiple IPv6 addresses...</t>
<t>In order to do correlation in IPv6-related logs, it is advised
to have all logs with canonical IPv6 addresses. Then, the neighbor
cache current (or historical) data set must be searched to find
the data-link layer address of the IPv6 address. Then, the current
and historical neighbor cache data sets must be searched for all
IPv6 addresses associated to this data-link layer address: this is
the search set. The last step is to search in all log files
(containing only IPv6 address in canonical format) for any IPv6
addresses in the search set.</t>
</section>
<section anchor="abnormal_behavior"
title="Abnormal Behavior Detection">
<t>Abnormal behaviors (such as network scanning, spamming, denial
of service) can be detected in the same way as in an IPv4
network<list style="symbols">
<t>sudden increase of traffic detected by interface counter
(SNMP) or by aggregated traffic from <xref
target="RFC5102">IPfix records</xref>;</t>
<t>change of traffic pattern (number of connection per second,
number of connection per host...) with the use of <xref
target="RFC5102">IPfix</xref></t>
</list></t>
</section>
</section>
<section title="Summary">
<t>While some data sources (IPfix, MIB, switch CAM tables, logs,
...) used in IPv4 are also used in the secure operation of an IPv6
network, the DHCPv6 lease file is less reliable and the neighbor
cache is of prime importance.</t>
<t>The fact that there are multiple ways to express in a character
string the same IPv6 address renders the use of filters mandatory
when correlation must be done.</t>
</section>
</section>
<!--log-->
<section anchor="coexistence"
title="Transition/Coexistence Technologies">
<t>Some text</t>
<section anchor="dual" title="Dual Stack">
<t>Dual stack has established itself as the preferred deployment
choice for most network operators without a MPLS core where 6PE
<xref target="RFC4798"/> is quite common. Dual stacking the network
offers many advantages over other transition mechanisms. Firstly, it
is easy to turn on without impacting normal IPv4 operations.
Secondly, perhaps more importantly, it is easier to troubleshoot
when things break. Dual stack allows you to gradually turn IPv4
operations down when your IPv6 network is ready for prime time.</t>
<t>From an operational security perspective, this now means that you
have twice the exposure. One needs to think about protecting both
protocols now. At a minimum, the IPv6 portion of a dual stacked
network should maintain parity with IPv4 from a security policy
point of view. Typically, the following methods are employed to
protect IPv4 networks at the edge: <list style="symbols">
<t>ACLs to permit or deny traffic</t>
<t>Firewalls with stateful packet inspection</t>
</list></t>
<t>It is recommended that these ACLs and/or firewalls be
additionally configured to protect IPv6 communications. Also, given
the end-to-end connectivity that IPv6 provides, it is also
recommended that hosts be fortified against threats. General device
hardening guidelines are provided in <xref target="device"/></t>
</section>
<!--dual-->
<section anchor="transition" title="Transition Mechanisms">
<t>There are many tunnels used for specific use cases. Except when
protected by <xref target="RFC4301">IPsec</xref>, all those tunnels
have a couple of security issues (most of them being described in
<xref target="RFC6169">RFC 6169</xref>);<list style="symbols">
<t>tunnel injection: a malevolent person knowing a few pieces of
information (for example the tunnel endpoints and the used
protocol) can forge a packet which looks like a legit and valid
encapsulated packet that will gladly be accepted by the
destination tunnel endpoint, this is a specific case of
spoofing;</t>
<t>traffic interception: no confidentiality is provided by the
tunnel protocols (without the use of IPsec), therefore anybody
on the tunnel path can intercept the traffic and have access to
the clear-text IPv6 packet;</t>
<t>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 tunnel injection);</t>
<t>reflection attack: another specific use case of tunnel
injection where the attacker injects packets with an IPv4
destination address not matching the IPv6 address causing the
first tunnel endpoint to re-encapsulate the packet to the
destination... Hence, the final IPv4 destination will not see
the original IPv4 address but only one IPv4 address of the relay
router.</t>
<t>bypassing security policy: if a firewall or an IPS is on the
path of the tunnel, then it will probably neither inspect not
detect an malevolent IPv6 traffic contained in the tunnel.</t>
</list></t>
<t>To mitigate the bypassing of security policies, it could be
helpful to block all default configuration tunnels by denying all
IPv4 traffic matching:<list style="symbols">
<t>IP protocol 41: this will block <xref
target="isatap">ISATAP</xref>, <xref
target="sixtofour">6to4</xref>, <xref target="sixrd">6rd</xref>
as well as <xref target="statictunnel">6in4</xref> tunnels;</t>
<t>IP protocol 47: this will block <xref
target="statictunnel">GRE</xref> tunnels;</t>
<t>UDP protocol 3544: this will block the default encapsulation
of <xref target="teredo">Teredo</xref> tunnels.</t>
</list></t>
<t><xref target="RFC2827">Ingress filtering</xref> should also be
applied on all tunnel endpoints if applicable to prevent IPv6
address spoofing.</t>
<t>As several of the tunnel techniques share the same encapsulation
(i.e. IPv4 protocol 41) and embeb the IPv4 address in the IPv6
address, there are a set of well-known looping attacks described in
<xref target="RFC6324">RFC 6324</xref>, this RFC also proposes
mitigation techniques.</t>
<section anchor="statictunnel" title="Site-to-Site Static Tunnels">
<t>Site-to-site static tunnels are described in <xref
target="RFC2529">RFC 2529</xref> and in <xref
target="RFC2784">GRE</xref>. As the IPv4 endpoints are statically
configured and are not dynamic they are slightly more secure
(bi-directional service theft is mostly impossible) but traffic
interception ad tunnel injection are still possible. Therefore,
the use of <xref target="RFC4301">IPsec</xref> in transport mode
and protecting the encapsulated IPv4 packets is recommended for
those tunnels. Alternatively, IPsec in tunnel mode can be used to
transport IPv6 traffic over a non-trusted IPv4 network.</t>
</section>
<section anchor="isatap" title="ISATAP">
<t>ISATAP tunnels <xref target="RFC5214"/> are mainly used within
a single administrative domain and to connect a single IPv6 host
to the IPv6 network. This means that endpoints and and the tunnel
endpoint are usually managed by a single entity; therefore, audit
trail and strict anti-spoofing are usually possible and this
raises the overall security.</t>
<t>Special care must be taken to avoid looping attack by
implementing the measures of <xref target="RFC6324">RFC
6324</xref> and of <xref target="RFC6964"/>.</t>
<t><xref target="RFC4301">IPsec</xref> in transport or tunnel mode
can be used to secure the IPv4 ISATAP traffic to provide IPv6
traffic confidentiality and prevent service theft.</t>
</section>
<section anchor="teredo" title="Teredo">
<t>Teredo tunnels <xref target="RFC4380"/> are mainly used in a
residential environment because that can easily traverse an IPv4
NAT-PT device thanks to its UDP encapsulation and they connect a
single host to the IPv6 Internet. Teredo shares the same issues as
other tunnels: no authentication, no confidentiality, possible
spoofing and reflection attacks.</t>
<t><xref target="RFC4301">IPsec</xref> for the transported IPv6
traffic is recommended.</t>
<t>The biggest threat to Teredo is probably for IPv4-only network
as Teredo has been designed to easily traverse IPV4 NAT-PT devices
which are quite often co-located with a stateful firewall.
Therefore, if the stateful IPv4 firewall allows unrestricted UDP
outbound and accept the return UDP traffic, then Teredo actually
punches a hole in this firewall for all IPv6 traffic to the
Internet and from the Internet. While host policies can be
deployed to block Teredo in an IPv4-only network in order to avoid
this firewall bypass, it would be more efficient to block all UDP
outbound traffic at the IPv4 firewall if deemed possible (of
course, at least port 53 should be left open for DNS traffic).</t>
</section>
<!--teredo-->
<section anchor="sixtofour" title="6to4">
<t><xref target="RFC3056">6to4 tunnels</xref> require a public
routable IPv4 address in order to work correctly. They can be used
to provide either one IPv6 host connectivity to the IPv6 Internet
or multiple IPv6 networks connectivity to the IPV6 Internet. The
6to4 relay is usually the anycast address defined in <xref
target="RFC3068"/>. Some security considerations are explained in
<xref target="RFC3964"/>.</t>
<t><xref target="RFC6343"/> points out that if an operator
provides well-managed servers and relays for 6to4,
non-encapsulated IPv6 packets will pass through well- defined
points (the native IPv6 interfaces of those servers and relays) at
which security mechanisms may be applied. Client usage of 6to4 by
default is now discouraged, and significant precautions are needed
to avoid operational problems</t>
</section>
<!--sixtofour-->
<section anchor="sixrd" title="6rd">
<t>While 6rd tunnels share the same encapsulation as <xref
target="sixtofour">6to4 tunnels</xref>, they are designed to be
used within a single SP domain, in other words they are deployed
in a more constrained environment than 6to4 tunnels and have
little security issues except lack of confidentiality. The
security considerations (Section 12) of <xref target="RFC5969"/>
describes how to secure the 6rd tunnels.</t>
<t><xref target="RFC4301">IPsec</xref> for the transported IPv6
traffic can be used if confidentiality is important.</t>
</section>
<!--rd-->
<section anchor="sixpe" title="6PE and 6VPE">
<t>Organizations using MPLS in their core can also use 6PE <xref
target="RFC4798"/> and 6VPE <xref target="RFC4659"/> to enable
IPv6 access over MPLS. As 6PE and 6VPE are really similar to
BGP/MPLS IP VPN described in <xref target="RFC4364"/>, the
security of these networks is also similar to the one described in
<xref target="RFC4381"/>. It relies on:<list style="symbols">
<t>Address space, routing and traffic seperation with the help
of VRF (only applicable to 6VPE);</t>
<t>Hiding the IPv4 core, hence removing all attacks against
P-routers;</t>
<t>Securing the routing protocol between CE and PE, in the
case of 6PE and 6VPE, link-local addresses (see <xref
target="I-D.ietf-opsec-lla-only"/>) can be used and as these
addresses cannot be reached from outside of the link, the
security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS
IP VPN.</t>
</list></t>
</section>
<section anchor="dslite_first" title="DS-Lite">
<t>DS-lite is more a translation mechanism and is therefore
analyzed <xref target="dslite">further</xref> in this
document.</t>
</section>
<section title="Mapping of Address and Port">
<t>With the tunnel and encapsulation versions of Mapping of
Address and Port (MAP <xref target="I-D.ietf-softwire-map"/>), the
access network is purely an IPv6 network and MAP protocols are
used to give IPv4 hosts on the subscriber network, access to IPv4
hosts on the Internet. The subscriber router does stateful
operations in order to map all internal IPv4 addresses and layer-4
ports to the IPv4 address and the set of layer-4 ports received
through MAP configuration process. The SP equipment always does
stateless operations (either decapsulation or stateless
translation). Therefore, as opposed to <xref target="dslite"/>
there is no state-exhaustion DoS attack against the SP equipment
because there is no state and there is no operation caused by a
new layer-4 connection (no logging operation).</t>
<t>The SP MAP equipment MUST implement all the security
considerations of <xref target="I-D.ietf-softwire-map"/>; notably,
ensuring that the mapping of the IPv4 address and port are
consistent with the configuration.</t>
</section>
<!--dslite_first-->
</section>
<!--tunnel-->
<section anchor="xlate" title="Translation Mechanisms">
<t>Translation mechanisms between IPv4 and IPv6 networks are
alternative coexistence strategies while networks transition to
IPv6. While a framework is described in <xref target="RFC6144"/> the
specific security considerations are documented in each individual
mechanism. For the most part they specifically mention interference
with IPsec or DNSSEC deployments, how to mitigate spoofed traffic
and what some effective filtering strategies may be.</t>
<section anchor="cgn" title="Carrier-Grade Nat (CGN)">
<t>Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale
NAT (LSN) or SP NAT is described in <xref target="RFC6264"/> and
is utilized as an interim measure to prolong the use of IPv4 in a
large service provider network until the provider can deploy and
effective IPv6 solution. <xref target="RFC6598"/> requested a
specific IANA allocated /10 IPv4 address block to be used as
address space shared by all access networks using CGN. This has
been allocated as 100.64.0.0/10.</t>
<t>Section 13 of <xref target="RFC6269"/> lists some specific
security-related issues caused by large scale address sharing. The
Security Considerations section of <xref target="RFC6598"/> also
lists some specific mitigation techniques for potential misuse of
shared address space.</t>
<t>[From Panos K: could mention the log size concern and
draft-donley-behave-deterministic-cgn that alleviates it]</t>
</section>
<!--cgn-->
<section anchor="nat64" title="NAT64/DNS64">
<t>Stateful NAT64 translation <xref target="RFC6146"/> allows
IPv6-only clients to contact IPv4 servers using unicast UDP, TCP,
or ICMP. It can be used in conjunction with DNS64 <xref
target="RFC6147"/>, a mechanism which synthesizes AAAA records
from existing A records.</t>
<t>The Security Consideration sections of <xref target="RFC6146"/>
and <xref target="RFC6147"/> list the comprehensive issues. A
specific issue with the use of NAT64 is that it will interfere
with most IPsec deployments unless UDP encapsulation is used.
DNS64 has an incidence on DNSSEC see section 3.1 of <xref
target="I-D.ietf-behave-nat64-discovery-heuristic"/>.</t>
</section>
<!--nat64-->
<section anchor="dslite" title="DS-lite">
<t>Dual-Stack Lite (DS-Lite) <xref target="RFC6333"/> is a
transition technique that enables a service provider to share IPv4
addresses among customers by combining two well-known
technologies: IP in IP (IPv4-in-IPv6) and Network Address and Port
Translation (NAPT)</t>
<t>Security considerations with respect to DS-Lite mainly revolve
around logging data, preventing DoS attacks from rogue devices and
restricting service offered by the AFTR only to registered
customers.</t>
<t>Section 11 of <xref target="RFC6333"/> describes important
security issues associated with this technology.</t>
</section>
<!--dslite-->
</section>
<!--xlate-->
</section>
<!--coexistence-->
<section anchor="device" title="General Device Hardening">
<t>There are many environments which rely too much on the network
infrastructure to disallow malicious traffic to get access to critical
hosts. In new IPv6 deployments it has been common to see IPv6 traffic
enabled but none of the typical access control mechanisms enabled for
IPv6 device access. With the possibility of network device
configuration mistakes and the growth of IPv6 in the overall Internet
it is important to ensure that all individual devices are hardened
agains miscreant behavior.</t>
<t>The following guidelines should be used to ensure appropriate
hardening of the host, be it an individual computer or router,
firewall, load-balancer,server, etc device. <list style="symbols">
<t>Restrict access to the device to authenticated and authorized
individuals</t>
<t>Monitor and audit access to the device</t>
<t>Turn off any unused services on the end node</t>
<t>Understand which IPv6 addresses are being used to source
traffic and change defaults if necessary</t>
<t>Use cryptographically protected protocols for device management
if possible (SCP, SNMPv3, SSH, TLS, etc)</t>
<t>Use host firewall capabilities to control traffic that gets
processed by upper layer protocols</t>
<t>Use virus scanners to detect malicious programs</t>
</list></t>
</section>
<!--device-->
</section>
<!--generic-->
<section anchor="enterprise"
title="Enterprises Specific Security Considerations">
<t>Enterprises generally have robust network security policies in place
to protect existing IPv4 networks. These policies have been distilled
from years of experiential knowledge of securing IPv4 networks. At the
very least, it is recommended that enterprise networks have parity
between their security policies for both protocol versions.</t>
<t>Security considerations in the enterprise can be broadly categorized
into two sections - External and Internal.</t>
<section anchor="external" title="External Security Considerations:">
<t>The external aspect deals with providing security at the edge or
perimeter of the enterprise network where it meets the service
providers network. This is commonly achieved by filtering traffic
either by implementing dedicated firewalls with stateful packet
inspection or a router with ACLs. A common default IPv4 policy on
firewalls that could easily be ported to IPv6 is to allow all traffic
outbound while only allowing specific traffic, such as established
sessions, inbound. Here are a few more things that could enhance the
default policy: <list style="symbols">
<t>Filter internal-use IPv6 addresses at the perimeter</t>
<t>Discard packets from and to bogon and reserved space</t>
<t>Accept certain ICMPv6 messages to allow proper operation of ND
and PMTUD, see also <xref target="RFC4890"/></t>
<t>Filter specific extension headers, where possible</t>
<t>Filter unneeded services at the perimeter</t>
<t>Implement anti-spoofing filtering or other anti-spoof
protections</t>
<t>Implement appropriate rate-limiters and control-plane
policers</t>
</list></t>
</section>
<!-- external-->
<section anchor="internal" title="Internal Security Considerations:">
<t>The internal aspect deals with providing security inside the
perimeter of the network, including the end host. The most significant
concerns here are related to Neighbor Discovery. At the network level,
it is recommended that all security considerations discussed in <xref
target="linklayer"/> be reviewed carefully and the recommendations be
considered in-depth as well.</t>
<t>As mentioned in Section 2.6.2, care must be taken when running
automated IPv6-in-IP4 tunnels.</t>
<t>Hosts need to be hardened directly through security policy to
protect against security threats. The host firewall default
capabilities have to be clearly understood, especially 3rd party ones
which can have different settings for IPv4 or IPv6 default permit/deny
behavior. In some cases, 3rd party firewalls have no IPv6 support
whereas the native firewall installed by default has it. General
device hardening guidelines are provided in <xref
target="device"/></t>
<t>It should also be noted that many hosts still use IPv4 for
transport for things like RADIUS, TACACS+, SYSLOG, etc. This will
require some extra level of due diligence on the part of the
operator.</t>
</section>
<!-- internal-->
</section>
<!-- enterprise-->
<section anchor="sp" title="Service Providers Security Considerations">
<section anchor="bgp" title="BGP">
<t>The threats and mitigation techniques are identical between IPv4
and IPv6. Broadly speaking they are: <list style="symbols">
<t>Authenticating the TCP session;</t>
<t>TTL security (which becomes hop-limit security in IPv6);</t>
<t>Prefix Filtering.</t>
</list> These are explained in more detail in section <xref
target="rsec"/>.</t>
<section anchor="rtbh" title="Remote Triggered Black Hole Filtering">
<t>RTBH <xref target="RFC5635"/> works identically in IPv4 and IPv6.
IANA has allocated 100::/64 as discard prefix <xref
target="RFC6666"/>.</t>
</section>
<!-- RTBH -->
</section>
<!-- BGP-->
<section anchor="sptrans" title="Transition Mechanism">
<t>SP will typically use transition mechanisms such as 6rd, 6PE, MAP,
DS-LITE which have been analyzed in the transition <xref
target="transition"/> section.</t>
</section>
<!-- sptrans-->
<section anchor="li" title="Lawful Intercept">
<t>The Lawful Intercept requirements are similar for IPv6 and IPv4
architectures and will be subject to the laws enforced in varying
geographic regions. The local issues with each jurisdiction can make
this challenging and both corporate legal and privacy personnel should
be involved in discussions pertaining to what information gets logged
and what the logging retention policies will be.</t>
<t>The target of interception will usually be a residential subscriber
(e.g. his/her PPP session or physical line or CPE MAC address). With
the absence of NAT on the CPE, IPv6 has the provision to allow for
intercepting the traffic from a single host (a /128 target) rather
than the whole set of hosts of a subscriber (which could be a /48, a
/60 or /64).</t>
<t>In contrast, in mobile environments, since the 3GPP specifications
allocate a /64 per device, it may be sufficient to intercept traffic
from the /64 rather than specific /128's (since each time the device
powers up it gets a new IID).</t>
<t>A sample architecture which was written for informational purposes
is found in <xref target="RFC3924"/>.</t>
</section>
<!-- li -->
</section>
<!-- SP-->
<section anchor="residential"
title="Residential Users Security Considerations">
<t>The IETF Homenet working group is working on how IPv6 residential
network should be done; this obviously includes operational security
considerations; but, this is still work in progress.</t>
<t>Residential users have usually less experience and knowledge about
security or networking. As most of the recent hosts, smartphones,
tablets have all IPv6 enabled by default, IPv6 security is important for
those users. Even with an IPv4-only ISP, those users can get IPv6
Internet access with the help of Teredo tunnels. Several peer-to-peer
programs (notably Bittorrent) support IPv6 and those programs can
initiate a Teredo tunnel through the IPv4 residential gateway, with the
consequence of making the internal host reachable from any IPv6 host on
the Internet. It is therefore recommended that all host security
products (personal firewall, ...) are configured with a dual-stack
security policy.</t>
<t>If the Residential Gateway has IPv6 connectivity, <xref
target="RFC6204"/> defines the requirements of an IPv6 CPE and does not
take position on the debate of default IPv6 security policy:<list
style="symbols">
<t>outbound only: allowing all internally initiated connections and
block all externally initiated ones, which is a common default
security policy enforced by IPv4 Residential Gateway doing NAT-PT
but it also breaks the end-to-end reachability promise of IPv6.
<xref target="RFC6092"/> lists several recommendations to design
such a CPE;</t>
<t>open: allowing all internally and externally initiated
connections, therefore restoring the end-to-end nature of the
Internet for the IPv6 traffic but having a different security policy
for IPv6 than for IPv4.</t>
</list></t>
<t><xref target="RFC6204"/> states that a clear choice must be given to
the user to select one of those two policies.</t>
<t>There is also an alternate solution which has been deployed notably
by Swisscom (<xref target="I-D.v6ops-vyncke-balanced-ipv6-security"/>:
open to all outbound and inbound connections at the exception of an
handful of TCP and UDP ports known as vulnerable.</t>
</section>
<!-- residentialThe -->
<section title="Further Reading">
<t>There are several documents that describe in more details the
security of an IPv6 network; these documents are not written by the IETF
but are listed here for your convenience:<list style="numbers">
<t><xref target="NIST">Guidelines for the Secure Deployment of
IPv6</xref></t>
<t><xref target="NAv6TF_Security">North American IPv6 Task Force
Technology Report - IPv6 Security Technology Paper</xref></t>
<t><xref target="IPv6_Security_Book">IPv6 Security</xref></t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the following people for their useful
comments: Mikael Abrahamsson, Brian Carpenter, Tim Chown, Fernando Gont,
Panos Kampanakis, Jouni Korhonen, Mark Lentczner, Tarko Tikan (by
alphabetical order).</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This memo attempts to give an overview of security considerations of
operating an IPv6 network both in an IPv6-only network and in utilizing
the most widely deployed IPv4/IPv6 coexistence strategies.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2119;
&RFC6104;
&RFC6105;
</references>
<references title="Informative References">
&RFC0826;
&RFC2131;
&RFC2529;
&RFC2740;
&RFC2784;
&RFC2827;
&RFC3056;
&RFC3068;
&RFC3315;
&RFC3627;
&RFC3756;
&RFC3924;
&RFC3964;
&RFC3971;
&RFC3972;
&RFC4193;
&RFC4293;
&RFC4301;
&RFC4364;
&RFC4380;
&RFC4381;
&RFC4443;
&RFC4552;
&RFC4659;
&RFC4798;
&RFC4861;
&RFC4864;
&RFC4890;
&RFC4941;
&RFC4942;
&RFC5101;
&RFC5102;
&RFC5157;
&RFC5214;
&RFC5340;
&RFC5635;
&RFC5952;
&RFC5969;
&RFC6092;
&RFC6144;
&RFC6146;
&RFC6147;
&RFC6164;
&RFC6169;
&RFC6192;
&RFC6204;
&RFC6264;
&RFC6269;
&RFC6296;
&RFC6302;
&RFC6324;
&RFC6343;
&RFC6333;
&RFC6434;
&RFC6459;
&RFC6506;
&RFC6547;
&RFC6583;
&RFC6598;
&RFC6620;
&RFC6666;
&RFC6810;
&RFC6964;
&I-D.ietf-v6ops-enterprise-incremental-ipv6;
&I-D.ietf-opsec-lla-only;
&I-D.ietf-savi-dhcp;
&I-D.ietf-savi-framework;
&I-D.ietf-behave-nat64-discovery-heuristic;
&I-D.thubert-savi-ra-throttler;
&I-D.ietf-v6ops-ra-guard-implementation;
&I-D.ietf-6man-nd-extension-headers;
&I-D.chakrabarti-nordmark-6man-efficient-nd;
&I-D.ietf-softwire-map;
&I-D.ietf-opsec-dhcpv6-shield;
&I-D.ietf-opsec-bgp-security;
&I-D.ietf-6man-stable-privacy-addresses;
&I-D.ietf-6man-oversized-header-chain;
&I-D.v6ops-vyncke-balanced-ipv6-security;
<reference anchor="SCANNING"
target="http://www.caida.org/workshops/isma/1202/slides/aims1202_rbarnes.pdf">
<front>
<title>Mapping the Great Void - Smarter scanning for IPv6</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="CYMRU"
target="http://www.team-cymru.org/ReadingRoom/Templates/IPv6Routers/xsp-recommendations.html">
<front>
<title>Packet Filter and Route Filter Recommendation for IPv6 at xSP
routers</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="IPv6_Security_Book">
<front>
<title>IPv6 Security</title>
<author fullname="Scott Hogg" surname="Hogg"/>
<author fullname="Eric Vyncke" surname="Vyncke"/>
<date month="December" year="2008"/>
</front>
<seriesInfo name="ISBN" value="1-58705-594-5"/>
<seriesInfo name="Publisher" value="CiscoPress"/>
</reference>
<reference anchor="NAv6TF_Security"
target="http://www.ipv6forum.com/dl/white/NAv6TF_Security_Report.pdf">
<front>
<title>North American IPv6 Task Force Technology Report - IPv6
Security Technology Paper</title>
<author fullname="Merike Kaeo" surname="Kaeo"/>
<author fullname="David Green" surname="Green"/>
<author fullname="Jim Bound" surname="Bound"/>
<author fullname="Yanick Pouffary" surname="Pouffary"/>
<date year="2006"/>
</front>
</reference>
<reference anchor="NIST"
target="http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf">
<front>
<title>Guidelines for the Secure Deployment of IPv6</title>
<author fullname="Sheila Frankel" surname="Frankel"/>
<author fullname="Richard Graveman" surname="Graveman"/>
<author fullname="John Pearce" surname="Pearce"/>
<author fullname="Mark Rooks " surname="Rooks"/>
<date year="2010"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:41:44 |