One document matched: draft-vyncke-opsec-v6-00.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 I-D.ietf-savi-threat-scope PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-savi-threat-scope.xml">
<!ENTITY I-D.ietf-savi-fcfs PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-savi-fcfs.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.ietf-v6ops-v6nd-problems PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-v6nd-problems.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">
]>
<?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-00" 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="5" month="March" 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>In this document, the key words "MAY", "MUST, "MUST NOT",
"OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in <xref target="RFC2119">RFC2119</xref></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>Some text</t>
</section>
<!--structure-->
<section anchor="ula" title="Use of ULAs">
<t>Some text</t>
</section>
<!--ula-->
<section anchor="p2p" title="Point-to-Point Links">
<t>Some text</t>
</section>
<!--p2p-->
<section anchor="priv" title="Privacy Addresses">
<t>Some text</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. 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="I-D.ietf-v6ops-v6nd-problems"/> 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 point of view, this now means that
you have twice the exposure. One needs to think about protecting
both protocols now. <xref target="RFC4942"/> brings to light many
security considerations that one must account for while deploying
IPv6.</t>
<t>A major difference between the co-existing IPv4 and IPv6 networks
will be at the network edge where IPv4 NAT and other security
policies are likely implemented. The advent of NAT gave network
security administrators a sense of security through obscurity. NAT's
real purpose in prolonging the exhaustion of IPv4 addresses has been
well served. However, the model of security through obscurity serves
little to no purpose in today's threat landscape where
application-level attack vectors abound. 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. 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>
<t>The following are typical methods 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>
<t>Firewalls with deep packet inspection that provide filtering
capabilities extending all the way to the application layer</t>
</list></t>
<t>At a minimum, a dual stacked network should aim to maintain
parity with IPv4 from a policy point of view. 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.</t>
<t>Here is a sample IPv6 Perimeter policy that builds on top of the
default policy: <list style="symbols">
<t>Filter ICMPv6 - allow what you need</t>
<t>Accept only certain ICMPv6 error messages (simply blocking
all ICMP is not optional with IPv6, due to the way Neighbor
Discovery and Path MTU Discovery work)</t>
<t>Care must be taken not to reject ICMPv6 packets whose source
address used with DAD is the unspecified address (::/128)</t>
<t>Permit ICMPv6 ping</t>
<t>Filter specific extension headers, although not many
implementations support this at the moment</t>
<t>Filter unneeded services at the perimeter</t>
<t>Implement Anti-spoof filtering</t>
</list></t>
<t>While attention to security at the edge is important in dual
stack networks, equally important is to ensure that the right
network monitoring software systems are in place to assure business
continuity. Network operators us a variety of NMS's ranging from
home grown custom solutions to off-the-shelf third party solutions.
It is important to ensure that such software packages fully support
IPv6 networks as operational security depends heavily not he ability
to quickly react to issues reported in real time. An important first
step in transitioning towards enhanced IPv6 tools support is
implementing some kind of flow export that allows for IPv6
application, bandwidth and forensics analysis.</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 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>.</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 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>
<!--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">
<section anchor="perimeter" title="Perimeter Security">
<t>There are a variety of network setups that provide perimeter
security for enterprise networks: ACLs to permit or deny traffic
Firewalls with stateful packet inspection Firewalls with deep packet
inspection that provide filtering capabilities that extend all the way
to the application layer</t>
<t>At a minimum, IPv6 perimeter policy should aim to maintain parity
with IPv4 from a policy point of view. 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.</t>
<t>Here is a sample IPv6 Perimeter policy that builds on top of 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 only certain ICMPv6 error messages (simply blocking all
ICMP is no longer an option with IPv6, due to the way Neighbor
Discovery and Path MTU discovery work) see also <xref
target="RFC4890"/></t>
<t>Permit ICMPv6 ping</t>
<t>Filter specific extension headers, where possible</t>
<t>Filter unneeded services at the perimeter</t>
<t>Anti-spoof filtering</t>
</list></t>
</section>
<!-- perimeter-->
<section anchor="enttrans" title="Transition Mechanism">
<t>tbd: will need to reference the security considerations of relevant
RFC. including dual-stack & ISATAP</t>
<!-- isatap-->
</section>
<!-- enttrans-->
</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;
&I-D.ietf-savi-threat-scope;
&I-D.ietf-savi-fcfs;
&I-D.ietf-savi-dhcp;
&I-D.ietf-savi-framework;
&I-D.ietf-sidr-rpki-rtr;
&I-D.ietf-v6ops-v6nd-problems;
&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;
<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 05:55:13 |