One document matched: draft-vyncke-opsec-v6-01.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 RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC2529 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2529.xml">
<!ENTITY RFC5214 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5214.xml">
<!ENTITY RFC4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
<!ENTITY RFC3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY RFC5969 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml">
<!ENTITY RFC2784 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY RFC6324 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6324.xml">
<!ENTITY RFC6169 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6169.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 RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.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 RFC3756 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3756.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 RFC4213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!ENTITY RFC4293 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4293.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.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 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 RFC5952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.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 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 RFC6506 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6506.xml">
<!ENTITY RFC6583 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6583.xml">
<!ENTITY RFC6620 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6620.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.ietf-sidr-rpki-rtr PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-rpki-rtr.xml">
<!ENTITY I-D.krishnan-ipv6-hopbyhop PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.krishnan-ipv6-hopbyhop.xml">
<!ENTITY I-D.chakrabarti-nordmark-energy-aware-nd PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chakrabarti-nordmark-energy-aware-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-v6ops-ra-guard-implementation PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ra-guard-implementation.xml">
<!ENTITY I-D.gont-6man-nd-extension-headers PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gont-6man-nd-extension-headers.xml">
<!ENTITY I-D.ietf-v6ops-6to4-to-historic PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-6to4-to-historic.xml">
<!ENTITY I-D.templin-v6ops-isops PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-v6ops-isops.xml">
<!ENTITY I-D.ietf-softwire-map PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-map.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-vyncke-opsec-v6-01" 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>ISC</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<country>USA</country>
<code>94063</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="16" month="July" year="2012"/>
<!-- 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>Operational Security Capabilities for IPv6 Network
Infrastructure</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>
<!-- 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>Network managers know how to operate securely IPv4 network: whether
it is the Internet or an enterprise internal network. IPv6 presents some
new security challenges. RFC 4942 describes the security issues in the
protocol but network managers need also a more practical,
operation-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 network 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"/>. Moreover, for end-users
that usually combination in a single box Customer Premice Equipment
(CPE) of firewall and <xref target="RFC3022">Network Address and Port
Translation</xref> has lead to the common feeling that NATPT equals
security and with IPv6 NATPT is no more needed.</t>
<t>The deployment of IPv6 network is commonly done with the dual-stack
technique <xref target="RFC4213"/> which also leads to specific security
issues.</t>
<t>This document complements <xref target="RFC4942"/> by listing all
security issues when operating a network.</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 import
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>An important consideration for manually configured addressing is
to make them hard to guess whenever possible. When manually
configuring interface ID's, the more common forms of starting at the
beginning or end of a subnet boundary (i.e using a 1 or FF for
routers) should be avoided. This will make any potential
reconnaissance attack attempt much more difficult. Although some
common multicast groups are defined for important networked devices
and use of commonly repeated addresses make it easy figure out what
the name servers, routers or other critical devices are, a
non-random manual address scheme also makes it easy for a potential
attacker using a "dictionary attack" of commonly used interface IDs
to find your critical infrastructure.</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. While ULAs can be
useful for infrastructure hiding, it may create an issue in future
if the decision at some point is to make the machines using ULAs
globally reachable. This would require renumbering or perhaps even
stateful IPv6 Network Address Translation (NAT). The latter would
again be problematic in trying to track specific machines that may
source malware. 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>RFC3627 indicates that the use of a /64 is the best solution for
point-to-point links while a /112 can be used if that's not
possible. However, in current deployments where it is felt that
using a /64 is wasteful for point-to-point links, many opt to use a
/127 or /126 subnet boundary and create manually defined IPv6
addresses for the point-to-point or tunnel endpoints.</t>
</section>
<!--p2p-->
<section anchor="priv" title="Privacy Addresses">
<t>Randomly generating an interface ID, as described in RFC 3041, is
part of stateless autoconfiguration and used to address some
security concerns. Stateless autoconfiguration relies on the
automatically generated EUI-64 node address, which together with the
/64 prefix make up the global unique IPv6 address. The EUI-64
address is generated from the MAC address. Since MAC addresses for
specific vendor equipment can be know, it may be easy for a
potential attacker to perform a more directed intelligent scan to
try and ascertain specific vendor device reachability for
exploitation. Privacy addressing attempts to mitigate this
threat.</t>
<t>As privacy addressing could also be used to hide illegal and
unsavory activities, privacy addressing can be assigned, audited,
and controlled in managed enterprise networks via DHCPv6.</t>
<t>Some people also feel that stateless addressing means that we may
not know addresses operating in our networks ahead of time in order
to to build 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.</t>
</section>
<!--priv-->
<section anchor="dhcpdns" title="DHCP/DNS Considerations">
<t>Some text</t>
</section>
<!--dchpdns-->
</section>
<!--v6addressing-->
<section anchor="linklayer" title="Link Layer Security">
<t>Link layer security is quite possibly the most important and
visible security consideration for most operators. IPv6 relied heavily
on the Neighbor Discovery protocol (NDP) <xref target="RFC4861"/> to
perform a variety of link operations such as discovering other nodes
not he 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"/></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. SEcure Neighbor Discovery (SEND), as described in <xref
target="RFC3971"/>, is a mechanism designed to secure ND messages
without having to rely on manual IPsec configuration.
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 address. A
new NDP option, the CGA option, 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>
</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.
Misconfigured (rogue) or malicious DHCP servers can be leveraged to
attack IPv6 nodes either by denying nodes from getting a valid
address/prefix or by disseminating incorrect information to end
nodes for malicious purposes. Some of these scenarios are discussed
in <xref target="RFC3315"/></t>
<t>The Source Address Validation Improvements (SAVI) group is
currently working on 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 SAVI (Source Address
Validation Improvements) device. <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 mplementation improvements and operational
mitigation techniques that may be used to mitigate or alleviate the
impact of such attacks.</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-energy-aware-nd"/></t>
</list></t>
</section>
<!--ratelim-->
<section anchor="filter" title="ND/RA Filtering">
<t>Router Advertising 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"/>
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. This mechanism is
commonly employed as a first line of defense against common attack
vectors.</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><xref target="I-D.gont-6man-nd-extension-headers"/> attempts to
analyze the security implications of using IPv6 Extension Headers
with Neighbor Discovery (ND) messages. The ultimate goal of this doc
is to update RFC 4861 such that use of the IPv6 Fragmentation Header
is forbidden in all Neighbor Discovery messages, thus allowing for
simple and effective measures to counter Neighbor Discovery
attacks.</t>
</section>
<!--filter-->
</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.</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 which 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, IPfix, 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. See <xref
target="I-D.krishnan-ipv6-hopbyhop"/></t>
</list></t>
<t>On some routers, not everything can be done by the specialized
data plane hardware.. then some packets are '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.</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 with 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>
<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 passwords,
which allows routers to authenticate each other prior to
establishing a routing relationship. Most open standard protocols,
with the notable exception of OSPFv3, are able to provide this type
of authentication mechanism.</t>
<t>OSPFv3 relies 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. <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 authentication key.</t>
</section>
<!--auth-->
<section anchor="updates"
title="Securing Routing Updates Between Peers">
<t>IPv6 mandates the provisioning of IPSEC capability in all nodes.
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, most key management mechanisms are designed for a
one-to-one communication model. However, in a protocol such as
OSPFv3 where adjacencies are formed on a one-to-many basis, IPSEC
key management becomes difficult to maintain.</t>
</section>
<!--updates-->
<section anchor="rifler" title="Route Filtering">
<t>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="I-D.ietf-sidr-rpki-rtr"/></t>
</list></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="RFC5102">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 to do:<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
more details 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 Socket ;
use Socket6 ;
my (@words, $word, $binary_address) ;
## go through the file one line at a time
while (my $line = <STDIN>) {
@words = split /[ \n]/, $line ;
foreach $word (@words) {
$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 title="Neighbor Cache of IPv6 Routers">
<t>The neighbor cache of routers contains all mappings between
IPv4 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).</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 not
trivial on a switch using the <xref
target="I-D.ietf-savi-framework">SAVI</xref> algorithm to defeat
the mapping between data-link layer address and IPv6 address.</t>
</section>
<section 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 world 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. 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 wireless 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.</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,
...) 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. 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="tunnel" title="Tunneling 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 using 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="I-D.templin-v6ops-isops"/>.</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"/></t>
<t>They suffer from several technical issues as well as <xref
target="RFC3964">security issues</xref>. Their use is no more
recommended (see <xref
target="I-D.ietf-v6ops-6to4-to-historic"/>).</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="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 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 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-->
</section>
<!--tunnel-->
<section anchor="xlate" title="Translation Mechanisms">
<t>Some text</t>
<section anchor="cgn" title="Carrier Grade Nat (CGN)">
<t>Some text</t>
</section>
<!--cgn-->
<section anchor="nat64" title="NAT64/DNS64">
<t>Some text</t>
</section>
<section anchor="dslite" title="DS-lite">
<t>Some text</t>
</section>
<!--nat64-->
</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-Spoof filtering</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>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>tbd</t>
<section anchor="rtbh" title="Remote Triggered Black Hole">
<t>tbd</t>
</section>
<!-- RTBH -->
</section>
<!-- BGP-->
<section anchor="sptrans" title="Transition Mechanism">
<t>tbd: will need to reference the security considerations of relevant
RFC.</t>
<section anchor="sixpe" title="6PE and 6VPE">
<t>tbd.</t>
</section>
<!-- 6pe-->
<section title="6rd">
<t>tbd. refer to <xref target="sixrd">6rd section</xref></t>
</section>
<!-- 6rd -->
<section anchor="ds-lite" title="DS-lite">
<t>tbd.</t>
</section>
<!-- ds-lite -->
</section>
<!-- sptrans-->
<section anchor="li" title="Lawful Intercept">
<t>tbd.</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 networks have usually little clue 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 restauring 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>
</section>
<!-- residential-->
<section anchor="Acknowledgements" title="Acknowledgements"/>
<!-- Possibly a 'Contributors' 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 but also in a
dual-stack environment.</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;
&RFC2784;
&RFC2827;
&RFC3022;
&RFC3056;
&RFC3068;
&RFC3315;
&RFC3756;
&RFC3964;
&RFC3971;
&RFC3972;
&RFC4301;
&RFC4213;
&RFC4293;
&RFC4380;
&RFC4861;
&RFC4890;
&RFC4941;
&RFC4942;
&RFC5102;
&RFC5157;
&RFC5214;
&RFC5952;
&RFC5969;
&RFC6092;
&RFC6192;
&RFC6169;
&RFC6204;
&RFC6324;
&RFC6506;
&RFC6583;
&RFC6620;
&I-D.ietf-savi-dhcp;
&I-D.ietf-savi-framework;
&I-D.ietf-sidr-rpki-rtr;
&I-D.krishnan-ipv6-hopbyhop;
&I-D.thubert-savi-ra-throttler;
&I-D.ietf-v6ops-ra-guard-implementation;
&I-D.gont-6man-nd-extension-headers;
&I-D.chakrabarti-nordmark-energy-aware-nd;
&I-D.ietf-v6ops-6to4-to-historic;
&I-D.templin-v6ops-isops;
&I-D.ietf-softwire-map;
<reference anchor="evyncke_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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:32 |