Abstract
Knowledge and experience on how to operate IPv4 securely is
available: whether it is the Internet or an enterprise internal
network. However, IPv6 presents some new security challenges. RFC
4942 describes the security issues in the protocol but network
managers also need a more practical, operations-minded best common
practices.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Generic Security Considerations . . . . . . . . . . . . . . . 4
2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4
2.1.1. Overall Structure . . . . . . . . . . . . . . . . . . 4
2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . . 6
2.1.4. Privacy Extension Addresses . . . . . . . . . . . . . 6
2.1.5. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7
2.2. Link-Layer Security . . . . . . . . . . . . . . . . . . . 7
2.2.1. SeND and CGA . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. DHCP Snooping . . . . . . . . . . . . . . . . . . . . 8
2.2.3. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 9
2.2.4. ND/RA Filtering . . . . . . . . . . . . . . . . . . . 10
2.2.5. 3GPP Link-Layer Security . . . . . . . . . . . . . . . 11
2.3. Control Plane Security . . . . . . . . . . . . . . . . . . 11
2.3.1. Control Protocols . . . . . . . . . . . . . . . . . . 12
2.3.2. Management Protocols . . . . . . . . . . . . . . . . . 13
2.3.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 13
2.4. Routing Security . . . . . . . . . . . . . . . . . . . . . 14
2.4.1. Authenticating Neighbors/Peers . . . . . . . . . . . . 14
2.4.2. Securing Routing Updates Between Peers . . . . . . . . 15
2.4.3. Route Filtering . . . . . . . . . . . . . . . . . . . 15
2.5. Logging/Monitoring . . . . . . . . . . . . . . . . . . . . 16
2.5.1. Data Sources . . . . . . . . . . . . . . . . . . . . . 17
2.5.2. Use of Collected Data . . . . . . . . . . . . . . . . 20
2.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 22
2.6. Transition/Coexistence Technologies . . . . . . . . . . . 22
2.6.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . . 22
2.6.2. Transition Mechanisms . . . . . . . . . . . . . . . . 23
2.6.3. Translation Mechanisms . . . . . . . . . . . . . . . . 26
2.7. General Device Hardening . . . . . . . . . . . . . . . . . 28
3. Enterprises Specific Security Considerations . . . . . . . . . 28
3.1. External Security Considerations: . . . . . . . . . . . . 29
3.2. Internal Security Considerations: . . . . . . . . . . . . 29
4. Service Providers Security Considerations . . . . . . . . . . 30
Chittimaneni, et al. Expires May 12, 2013 [Page 2]
Internet-Draft OPsec IPV6 November 2012
4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 30
4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . . 30
4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . . 30
5. Residential Users Security Considerations . . . . . . . . . . 31
6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Chittimaneni, et al. Expires May 12, 2013 [Page 3]
Internet-Draft OPsec IPV6 November 2012
1. Introduction
Running an IPv6 network is new for most operators not only because
they are not yet used to large scale IPv6 networks but also because
there are subtle differences between IPv4 and IPv6 especially with
respect to security. For example, all layer-2 interactions are now
done by Neighbor Discovery Protocol [RFC4861] rather than by Address
Resolution Protocol [RFC0826]. Also, there are subtle differences
between NAT44 and NPTv6 [RFC6296] which are explicitly pointed out in
the latter's security considerations section.
IPv6 networks are deployed using a variety of techniques, each of
which have their own specific security concerns.
This document complements [RFC4942] by listing all security issues
when operating a network utilizing varying transition technologies
and updating with ones that have been standardized since 2007. It
also provides more recent operational deployment experiences where
warranted.
1.1. Requirements Language
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 [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.
2. Generic Security Considerations
2.1. Addressing Architecture
IPv6 address allocations and overall architecture are an important
part of securing IPv6.
2.1.1. Overall Structure
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.
There still exists a debate whether companies should use PI vs PA
Chittimaneni, et al. Expires May 12, 2013 [Page 4]
Internet-Draft OPsec IPV6 November 2012
space [I-D.ietf-v6ops-enterprise-incremental-ipv6] but from a
security perspective there is little difference. However, one aspect
to keep in mind is who has ownership of the address space and who is
responsible if/when Law Enforcement may need to enforce restrictions
on routability of the space due to malicious criminal activity.
When considering how to assign manually configured addresses it is
necessary to take into consideration the effectiveness of perimeter
security in a given environment. There is a trade-off between ease
of operational deployment where some portions of the IPv6 address
could be easily recognizable for operational debugging and
troubleshooting versus the risk of scanning; [SCANNING] shows that
there are scientifically based mechanisms that make scanning for IPv6
reachable nodes more realizable than expected. The use of common
multicast groups which are defined for important networked devices
and the use of commonly repeated addresses could make it easy to
figure out which devices are name servers, routers or other critical
devices. While in some environments the perimeter security is so
poor that obfuscating addresses is considered a benefit; it is a much
better practice to ensure that perimeter rules are actively checked
and enforced and that manually configured addresses follow some
logical allocation scheme for ease of operation.
2.1.2. Use of ULAs
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 (as they force the use of address
translation to reach the Internet), it may create an issue in the
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 and Port Translation (IPv6 NAPT --
not an IETF work item). The latter would be problematic in trying to
track specific machines that may source malware although this is less
of an issue if appropriate logging is done which includes utilizing
accurate timestamps and logging a node's source ports [RFC6302].
The use of ULA does not isolate 'by magic' the part of the network
using ULA from other parts of the network (including the Internet).
Routers will happily forward packets whose source or destination
address is ULA as long as they have a route to the destination and
there is no ACL blocking those packets. This means that using ULA
does not prevent route and packet filters to be implemented and
monitored.
It is important to carefully weigh the benefits of using ULAs versus
Chittimaneni, et al. Expires May 12, 2013 [Page 5]
Internet-Draft OPsec IPV6 November 2012
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.
2.1.3. Point-to-Point Links
[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.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. However, [RFC6164] describes why
a /127 should be utilized instead.
Some environments are also using link-local addressing for point-to-
point links. While this practice could further reduce the attack
surface against infrastructure devices, the operational disadvantages
need also to be carefully considered [I-D.ietf-opsec-lla-only].
2.1.4. Privacy Extension Addresses
Randomly generating an interface ID, as described in [RFC4941], 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
extensions attempts to mitigate this threat.
As privacy extensions could also be used to hide illegal and unsavory
activities, privacy extensions addresses can be assigned, audited,
and controlled in managed enterprise networks via DHCPv6.
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.
The decision to utilize privacy addresses can come down to whether
the network is managed versus unmanaged. In some environments full
visibility into the network is required at all times which requires
Chittimaneni, et al. Expires May 12, 2013 [Page 6]
Internet-Draft OPsec IPV6 November 2012
that all traffic be attributable to where it is sourced or where it
is destined to within a specific network. This situation is
dependent on what level of logging is performed. If logging
considerations include utilizing accurate timestamps and logging a
node's source ports [RFC6302] then there should always exist
appropriate attribution needed to get to the source of any malware
originator or source of criminal activity.
2.1.5. DHCP/DNS Considerations
Many environments use DHCPv6 in their environments to ensure
audibility and traceability (but see Section 2.5.1.5). A main
security concern is the ability to detect and mitigate against rogue
DHCP servers (Section 2.2.2).
DNS is often used for malware activities and while there are no
fundamental differences with IPv4 and IPv6 security concerns, there
are specific consideration in DNS64 [RFC6147] environments that need
to be understood. Specifically the interactions and potential to
interference with DNSsec implementation need to be understood - these
are pointed out in detail in Section 2.6.3.2.
2.2. Link-Layer Security
IPv6 relies heavily on the Neighbor Discovery protocol (NDP)
[RFC4861] to perform a variety of link operations such as discovering
other nodes on the link, resolving their link-layer addresses, and
finding routers on the link. If not secured, NDP is vulnerable to
various attacks such as router/neighbor message spoofing, redirect
attacks, Duplicate Address Detection (DAD) DoS attacks, etc. many of
these security threats to NDP have been documented in IPv6 ND Trust
Models and Threats [RFC3756] and in [RFC6583].
2.2.1. SeND and CGA
The original NDP specification called for using IPsec to protect
Neighbor Discovery messages. However, manually configuring security
associations among multiple hosts on a large network can be very
challenging. In many environments the tradeoff between using
technologies that require an effective key management lifecycle
process creates more of an operational burden than the protection
offered by a given technology. IPsec protection for NDP typically
falls under this category.
SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a
mechanism that was designed to secure ND messages without having to
rely on manual IPsec configuration. This approach involves the use
of new NDP options to carry public key based signatures.
Chittimaneni, et al. Expires May 12, 2013 [Page 7]
Internet-Draft OPsec IPV6 November 2012
Cryptographically Generated Addresses (CGA), as described in
[RFC3972], are used to ensure that the sender of a Neighbor Discovery
message is the actual "owner" of the claimed IPv6 address. A new NDP
option, the CGA option, was introduced and is used to carry the
public key and associated parameters. Another NDP option, the RSA
Signature option, is used to protect all messages relating to
neighbor and Router discovery.
SeND protects against:
o Neighbor Solicitation/Advertisement Spoofing
o Neighbor Unreachability Detection Failure
o Duplicate Address Detection DoS Attack
o Router Solicitation and Advertisement Attacks
o Replay Attacks
o Neighbor Discovery DoS Attacks
SeND does NOT:
o Protect statically configured addresses
o Protect addresses configured using fixed identifiers (i.e.
EUI-64)
o Provide confidentiality for NDP communications
o Compensate for an unsecured link - SEND does not require that the
addresses on the link and Neighbor Advertisements correspond
However, at this time, CGA and SeND do not have wide support from
generic operating system; hence, their usefulness is limited.
2.2.2. DHCP Snooping
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in
[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.
The two most common threats to DHCP clients come from malicious or
misconfigured DHCP servers. A malicious DHCP server is one that is
Chittimaneni, et al. Expires May 12, 2013 [Page 8]
Internet-Draft OPsec IPV6 November 2012
established with the intent of providing incorrect configuration
information to the client. The motivation for doing so may be to
mount a "man in the middle" attack instead of a valid server for
services such as DNS or to cause a denial of service attack through
misconfiguration of the client that causes all network communication
from the client to fail. A misconfigured, or sometimes referred to
as rogue, DHCP server is one that has unintentionally been configured
to answer DHCP client requests with incorrect configuration
parameters. Some additional threats against DHCP are discussed in
the security considerations section of [RFC3315]
[I-D.gont-opsec-dhcpv6-shield] specifies a mechanism for protecting
hosts connected to a broadcast network against rogue DHCPv6 servers.
This mechanism is based on DHCPv6 packet-filtering at the layer-2
device on which the packets are received. Before the DCHPv6-Shield
device is deployed, the administrator specifies the layer-2 port(s)
on which DHCPv6 packets meant for DHCPv6 clients are allowed. Only
those ports to which a DHCPv6 server is to be connected should be
specified as such. Once deployed, the DHCPv6-Shield device inspects
received packets, and allows DHCPv6 messages meant for DHCPv6 clients
only if they are received on layer-2 ports that have been explicitly
configured for such purpose.
Additionally, the Source Address Validation Improvements (SAVI)
working group is currently working on other ways to mitigate the
effects of such attacks. [I-D.ietf-savi-dhcp] would help in creating
bindings between a DHCPv4 [RFC2131] /DHCPv6 [RFC3315] assigned source
IP address and a binding anchor [I-D.ietf-savi-framework] on a SAVI
device. Also, [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.
2.2.3. ND/RA Rate Limiting
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.
[RFC6583] discusses the potential for DOS in detail and suggests
implementation improvements and operational mitigation techniques
that may be used to mitigate or alleviate the impact of such attacks.
Here are some feasible mitigation options that can be employed by
network operators today:
Chittimaneni, et al. Expires May 12, 2013 [Page 9]
Internet-Draft OPsec IPV6 November 2012
o Ingress filtering of unused addresses by ACL, route filtering,
longer than /64 prefix; These require static configuration of the
addresses.
o Tuning of NDP process (where supported)
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:
o [I-D.thubert-savi-ra-throttler]
o [I-D.chakrabarti-nordmark-energy-aware-nd]
2.2.4. ND/RA Filtering
Router Advertisement spoofing is a well-known attack vector and has
been extensively documented. The presence of rogue RAs, either
intentional or malicious, can cause partial or complete failure of
operation of hosts on an IPv6 link. For example, a host can select
an incorrect router address which can be used as a man-in-the-middle
(MITM) attack or can assume wrong prefixes to be used for stateless
address configuration (SLAAC). [RFC6104] summarizes the scenarios in
which rogue RAs may be observed and presents a list of possible
solutions to the problem. [RFC6105] (RA-Guard) describes a solution
framework for the rogue RA problem where network segments are
designed around switching devices that are capable of identifying
invalid RAs and blocking them before the attack packets actually
reach the target nodes.
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.
[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.
Given that the IPv6 Fragmentation Header can be leveraged to
circumvent current implmentations of RA-Guard,
Chittimaneni, et al. Expires May 12, 2013 [Page 10]
Internet-Draft OPsec IPV6 November 2012
[I-D.gont-6man-nd-extension-headers] aims to update [RFC4861] such
that use of the IPv6 Fragmentation Header is forbidden in all
Neighbor Discovery messages except "Certification Path
Advertisement", thus allowing for simple and effective measures to
counter Neighbor Discovery attacks.
It is still recommended that RA-Guard be be employed as a first line
of defense against common attack vectors including misconfigured
hosts.
2.2.5. 3GPP Link-Layer Security
The 3GPP link is a point-to-point like link that has no link-layer
address. This implies there can only be an end host and the first-
hop router i.e., a GGSN or a PGW on that link. The GGSN/PGW never
configures a non link-local address on the link using the prefix
advertised on it and the advertised prefix must not be used for on-
link determination. There is no need for an address resolution on
the 3GPP link, since there are no link-layer addresses. Furthermore,
the GGSN/PGW assigns a prefix that is unique within each 3GPP link
that uses IPv6 stateless address autoconfiguration. This avoids the
necessity to perform DAD at the network level for every address built
by the cellular host. The GGSN/PGW always provides an IID to the
cellular host for the purpose of configuring the link-local address
and ensures the uniqueness of the IID on the link (i.e., no
collisions between its own link-local address and the cellular
host's).
The 3GPP link model itself mitigates most of the known NDP-related
Denial-of-Service attacks. In practice, the GGSN/PGW only needs to
route all traffic to the cellular host that fall under the prefix
assigned to it. This implies the GGSN/PGW may implement a minimal
neighbor discovery protocol subset; since, due the point-to-point
link model and the absence of link-layer addressing the address
resolution can be entirely statically configured per each 3GPP link,
and there is no need to defend any other address than the link-local
address for very unlikely duplicates.
See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP
link model, NDP on it and the address configuration detail.
2.3. Control Plane Security
[RFC6192] defines the router control plane and this definition is
repeated here for the reader's convenience.
Modern router architecture design maintains a strict separation of
forwarding and router control plane hardware and software. The
Chittimaneni, et al. Expires May 12, 2013 [Page 11]
Internet-Draft OPsec IPV6 November 2012
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.
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.
The mitigation technique is:
o To drop non legit control packet before they are queued to the RP
(this can be done by a forwarding plane ACL) and
o To rate limit the remaining packets to a rate that the RP can
sustain. Protocol specific protection should also be done (for
example, a spoofed OSPFv3 packet could trigger the execution of
the Dijkstra algorithm, therefore the number of Dijsktra execution
should be also rate limited).
This section will consider several classes of control packets:
o Control protocols: routing protocols: such as OSPFv3, BGP and by
extension Neighbor Discovery and ICMP
o Management protocols: SSH, SNMP, IPfix, etc
o 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.
2.3.1. Control Protocols
This class includes OSPFv3, BGP, NDP, ICMP.
An ingress ACL to be applied on all the router interfaces SHOULD be
configured such as:
Chittimaneni, et al. Expires May 12, 2013 [Page 12]
Internet-Draft OPsec IPV6 November 2012
o drop OSPFv3 (identified by Next-Header being 89) and RIPng
(identified by UDP port 521) packets from a non link-local address
o allow BGP (identified by TCP port 179) packets from all BGP
neighbors and drop the others
o allow all ICMP packets (transit and to the router interfaces)
Note: dropping OSPFv3 packets which are authenticated by IPsec could
be impossible on some routers whose ACL are unable to parse the IPsec
ESP or AH extension headers.
Rate limiting of the valid packets SHOULD be done. The exact
configuration obviously depends on the power of the Route Processor.
2.3.2. Management Protocols
This class includes: SSH, SNMP, syslog, NTP, etc
An ingress ACL to be applied on all the router interfaces SHOULD be
configured such as:
o 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);
o 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.
Rate limiting of the valid packets SHOULD be done. The exact
configuration obviously depends on the power of the Route Processor.
2.3.3. Packet Exceptions
This class covers multiple cases where a data plane packet is punted
to the route processor because it requires specific processing:
o generation of an ICMP packet-too-big message when a data plane
packet cannot be forwarded because it is too large;
o generation of an ICMP hop-limit-expired message when a data plane
packet cannot be forwarded because its hop-limit field has reached
0;
o generation of an ICMP destination-unreachable message when a data
plane packet cannot be forwarded for any reason;
Chittimaneni, et al. Expires May 12, 2013 [Page 13]
Internet-Draft OPsec IPV6 November 2012
o processing of the hop-by-hop extension header. See
[I-D.krishnan-ipv6-hopbyhop]
On some routers, not everything can be done by the specialized data
plane hardware which requires some packets to be 'punted' to the
generic RP. This could include for example the processing of a long
extension header chain in order to apply an ACL based on layer 4
information.
An ingress ACL cannot help to mitigate a control plane attack using
those packet exceptions. The only protection for the RP is to limit
the rate of those packet exceptions forwarded to the RP, this means
that some data plane packets will be dropped without any ICMP
messages back to the source which will cause Path MTU holes. But,
there is no other solution.
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.
2.4. Routing Security
Routing security in general can be broadly divided into three
sections:
1. Authenticating neighbors/peers
2. Securing routing updates between peers
3. Route filtering
[I-D.jdurand-bgp-security] covers these sections specifically for BGP
in detail.
2.4.1. Authenticating Neighbors/Peers
A basic element of routing is the process of forming adjacencies,
neighbor, or peering relationships with other routers. From a
security perspective, it is very important to establish such
relationships only with routers and/or administrative domains that
one trusts. A traditional approach has been to use MD5 HMAC, which
allows routers to authenticate each other prior to establishing a
routing relationship.
OSPFv3 can rely on IPsec to fulfill the authentication function.
However, it should be noted that IPsec support is not standard on all
routing platforms. In some cases, this requires specialized hardware
Chittimaneni, et al. Expires May 12, 2013 [Page 14]
Internet-Draft OPsec IPV6 November 2012
that offloads crypto over to dedicated ASICs or enhanced software
images (both of which often come with added financial cost) to
provide such functionality. An added detail is to determine whether
OSPFv3 IPsec implementations use AH or ESP-Null for integrity
protection. In early implementations all OSPFv3 IPsec configurations
relied on AH since the details weren't specified in [RFC2740] and the
updated [RFC5340]. However, the document which specifically
describes how IPsec should be implemented for OSPFv3 [RFC4552]
specifically states that ESP-Null MUST and AH MAY be implemented
since it follows the overall IPsec standards wordings. OSPFv3 can
also use normal ESP to encrypt the OSPFv3 payload to hide the routing
information.
[RFC6506] changes OSPFv3's reliance on IPsec by appending an
authentication trailer to the end of the OSPFv3 packets. This
document does not specifically provide for a mechanism that will
authenticate the specific originator of a packet. Rather, it will
allow a router to confirm that the packet has indeed been issued by a
router that had access to the shared authentication key.
With all authentication mechanisms, operators should confirm that
implementations can support re-keying mechanisms that do not cause
outages. There have been instances where any re-keying cause outages
and therefore the tradeoff between utilizing this functionality needs
to be weighed against the protection it provides.
2.4.2. Securing Routing Updates Between Peers
IPv6 initially mandated the provisioning of IPsec capability in all
nodes. However, in the updated IPv6 Nodes Requirement standard
[RFC6434] is now a SHOULD and not MUST implement. Theoretically it
is possible, and recommended, that communication between two IPv6
nodes, including routers exchanging routing information be encrypted
using IPsec. In practice however, deploying IPsec is not always
feasible given hardware and software limitations of various platforms
deployed, as described in the earlier section. Additionally, in a
protocol such as OSPFv3 where adjacencies are formed on a one-to-many
basis, IPsec key management becomes difficult to maintain and is not
often utilized.
2.4.3. Route Filtering
Route filtering policies will be different depending on whether they
pertain to edge route filtering vs internal route filtering. At a
minimum, IPv6 routing policy as it pertains to routing between
different administrative domains should aim to maintain parity with
IPv4 from a policy perspective e.g.,
Chittimaneni, et al. Expires May 12, 2013 [Page 15]
Internet-Draft OPsec IPV6 November 2012
o Filter internal-use, non-globally routable IPv6 addresses at the
perimeter
o Discard packets from and to bogon and reserved space
o 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
[I-D.ietf-sidr-rpki-rtr]
Some good recommendations for filtering can be found from Team CYMRU
at [CYMRU].
2.5. Logging/Monitoring
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.
This includes:
o logs of all applications when available (for example web servers);
o use of IP Flow Information Export [RFC5101] also known as IPfix;
o use of SNMP MIB [RFC4293];
o use of the Neighbor cache;
o use of stateful DHCPv6 [RFC3315] lease cache.
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.
All those pieces of information will be used for:
o forensic (Section 2.5.2.1) research to answer questions such as
who did what and when?
o correlation (Section 2.5.2.3): which IP addresses were used by a
specific node (assuming the use of privacy extensions addresses
[RFC4941])
o inventory (Section 2.5.2.2): which IPv6 nodes are on my network?
Chittimaneni, et al. Expires May 12, 2013 [Page 16]
Internet-Draft OPsec IPV6 November 2012
o abnormal behavior detection (Section 2.5.2.4): 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, ...)
2.5.1. Data Sources
This section lists the most important sources of data that are useful
for operational security.
2.5.1.1. Logs of Applications
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:
o 2001:DB8::1 (in uppercase)
o 2001:0db8::0001 (with leading 0)
o and many other ways.
RFC 5952 [RFC5952] explains this problem in detail and recommends the
use of a single canonical format (in short use lower case and
suppress leading 0). This memo recommends the use of canonical
format [RFC5952] 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.
For example, this perl script can be used:
Chittimaneni, et al. Expires May 12, 2013 [Page 17]
Internet-Draft OPsec IPV6 November 2012
#!/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 =
) {
@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" ;
}
2.5.1.2. IP Flow Information Export by IPv6 Routers
IPfix [RFC5102] defines some data elements that are useful for
security:
o in section 5.4 (IP Header fields): nextHeaderIPv6 and
sourceIPv6Address;
o in section 5.6 (Sub-IP fields) sourceMacAddress.
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.
2.5.1.3. SNMP MIB by IPv6 Routers
RFC 4293 [RFC4293] defines a Management Information Base (MIB) for
the two address families of IP. This memo recommends the use of:
o ipIfStatsTable table which collects traffic counters per
interface;
Chittimaneni, et al. Expires May 12, 2013 [Page 18]
Internet-Draft OPsec IPV6 November 2012
o ipNetToPhysicalTable table which is the content of the Neighbor
cache, i.e. the mapping between IPv6 and data-link layer
addresses.
2.5.1.4. Neighbor Cache of IPv6 Routers
The neighbor cache of routers contains all mappings between IPv6
addresses and data-link layer addresses. It is usually available by
two means:
o the SNMP MIB (Section 2.5.1.3) as explained above;
o also by connecting over a secure management channel (such as SSH
or HTTPS) and explicitely requesting a neighbor cache dump.
The neighbor cache is highly dynamic as mappings are added when a new
IPv6 address appears on the network (could be quite often with
privacy extension addresses [RFC4941] or when they are removed when
the state goes from UNREACH to removed (the default time for a
removal per Neighbor Unreachability Detection [RFC4861] 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.
This is an important source of information because it is trivial (on
a switch not using the SAVI [I-D.ietf-savi-framework] algorithm) to
defeat the mapping between data-link layer address and IPv6 address.
Let us rephrase the previous statement: having access to the current
and past content of the neighbor cache has a paramount value for
forensic and audit trail.
2.5.1.5. Stateful DHCPv6 Lease
In some networks, IPv6 addresses are managed by stateful DHCPv6
server [RFC3315] 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.
It is not so easy in the IPv6 era because not all nodes will use
DHCPv6 (there are nodes which can only do stateless
autoconfiguration) but also because DHCPv6 clients are identified not
by their hardware-client address as in IPv4 but by a DHCP Unique ID
(DUID) which can have several formats: some being the data-link layer
address, some being data-link layer address prepended with time
information or even an opaque number which is useless for operation
security. Moreover, when the DUID is based on the data-link address,
this address can be of any interface of the client (such as the
Chittimaneni, et al. Expires May 12, 2013 [Page 19]
Internet-Draft OPsec IPV6 November 2012
wireless interface while the client actually uses its wired interface
to connect to the network).
In short, the DHCPv6 lease file is less interesting than in the IPv4
era. DHCPv6 servers that keeps the relayed data-link layer address
in addition to the DUID in the lease file do not suffer from this
limitation. On a managed network where all hosts support DHCPv6,
special care must be taken to prevent stateless autoconfiguration
anyway (and if applicable) by sending RA with all announced prefixes
without the A-bit set.
The mapping between data-link layer address and the IPv6 address can
be secured by using switches implementing the SAVI
[I-D.ietf-savi-dhcp] algorithms.
2.5.1.6. Other Data Sources
There are other data sources that must be kept exactly as in the IPv4
network:
o historical mapping of MAC address to RADIUS user authentication in
a IEEE 802.1X network or an IPsec-based remote access VPN;
o historical mapping of MAC address to switch interface in a wired
network.
2.5.2. Use of Collected Data
This section leverages the data collected as described before
(Section 2.5.1) in order to achieve several security benefits.
2.5.2.1. Forensic
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.
The source of information can be, in decreasing order, neighbor
cache, DHCP lease file. Then, the procedure is:
1. based on the IPv6 prefix of the IPv6 address find the router(s)
which are used to reach this prefix;
2. 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;
Chittimaneni, et al. Expires May 12, 2013 [Page 20]
Internet-Draft OPsec IPV6 November 2012
3. 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.
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.
2.5.2.2. Inventory
RFC 5157 [RFC5157] 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.
There are two ways to do an inventory of an IPv6 network.
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.
The second way is again to use the collected neighbor cache content
to find all IPv6 addresses in the cache. This process will also
discover all link-local addresses. See Section 2.5.1.4.
2.5.2.3. Correlation
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.
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...
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
Chittimaneni, et al. Expires May 12, 2013 [Page 21]
Internet-Draft OPsec IPV6 November 2012
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.
2.5.2.4. Abnormal Behavior Detection
Abnormal behaviors (such as network scanning, spamming, denial of
service) can be detected in the same way as in an IPv4 network
o sudden increase of traffic detected by interface counter (SNMP) or
by aggregated traffic from IPfix records [RFC5102];
o change of traffic pattern (number of connection per second, number
of connection per host...) with the use of IPfix [RFC5102]
2.5.3. Summary
While some data sources (IPfix, MIB, switch CAM tables, logs, ...)
used in IPv4 are also used in the secure operation of an IPv6
network, the DHCPv6 lease file is less reliable and the neighbor
cache is of prime importance.
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.
2.6. Transition/Coexistence Technologies
Some text
2.6.1. Dual Stack
Dual stack has established itself as the preferred deployment choice
for most network operators without a MPLS core where 6PE [RFC4798] is
quite common. Dual stacking the network offers many advantages over
other transition mechanisms. Firstly, it is easy to turn on without
impacting normal IPv4 operations. Secondly, perhaps more
importantly, it is easier to troubleshoot when things break. Dual
stack allows you to gradually turn IPv4 operations down when your
IPv6 network is ready for prime time.
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
Chittimaneni, et al. Expires May 12, 2013 [Page 22]
Internet-Draft OPsec IPV6 November 2012
IPv4 networks at the edge:
o ACLs to permit or deny traffic
o Firewalls with stateful packet inspection
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 Section 2.7
2.6.2. Transition Mechanisms
There are many tunnels used for specific use cases. Except when
protected by IPsec [RFC4301], all those tunnels have a couple of
security issues (most of them being described in RFC 6169 [RFC6169]);
o 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;
o 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;
o service theft: as