Basic IPv6 Security Considerations
This chapter covers the topics of flows, ICMPv6, neighbor discovery, routing headers, and DNS issues.
IPv6 Flow Labels Issues
RFC 3697 defines in IPv6 Flow Labels. The 20-bit Flow Label field in the IPv6 header is used by a source to label packets of a flow. A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. Flows are associated with a source and destination address pair. A flow could consist of all packets in a specific transport connection or a media stream; however, a flow is not necessarily mapped one-to-one to a transport connection.
The usage of the 3-tuple of the Flow Label and the Source and Destination Address fields enables efficient IPv6 flow classification, where only IPv6 main header fields in fixed positions are used. The minimum level of IPv6 flow support consists of labeling the flows. IPv6 source nodes supporting the flow labeling must be able to label known flows (e.g., Transmission Control Protocol [TCP] connections, application streams), even if the node itself would not require any flow-specific treatment. Doing this enables load spreading and receiver oriented resource reservations, for example. Packet classifiers use the triplet of Flow Label, Source Address, and Destination Address fields to identify to which flow a particular packet belongs. Packets are processed in a flow-specific manner by the nodes that have been set up with flow-specific state.
The security issues raised by the use of a flow include the potential for denial-of-service attacks and the possibility of theft of service by unauthorized traffic. Also, there is no authorization mechanism and there are issues with tunneling via IPsec. Inspection of unencrypted Flow Labels by an intruder may allow some forms of traffic analysis* by revealing some structure of the underlying communications. Even if the Flow Label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and crypto analysis. In addition, if Flow Labels were to be encrypted, many devices would not be able to read the information to assist with traffic shaping. It is important for security administrators to understand that firewalls cannot trust Flow Labels for decisions.
Denial-of-Service Attacks. Because the mapping of network traffic to flow-specific treatment is triggered by the IP addresses and Flow Label value of the IPv6 header, an intruder may be able to obtain better service by modifying the IPv6 header or by injecting packets with false addresses or labels. This can also give rise to a denial-of-service attack as the possibility exists for a large amount of malicious traffic to be sent with a high priority. A device would then prioritize the malicious traffic and this could potentially impact valid traffic on the network. The treatment of IP headers by nodes is typically unverified in the IPv6 environment and there is no guarantee that Flow Labels sent by a node follow the syntactically correct form specified by the RFCs. Therefore, any assumptions made by the network about header fields such as Flow Labels should be limited to the extent that the upstream nodes are explicitly trusted. Because flows are identified by the 3-tuple of the Flow Label and the Source and Destination Addresses, the risk of theft or denial of service introduced by the Flow Label is related to the risk of theft or denial of service by address spoofing. An intruder who can forge an address is also likely to be able to forge a label, and vice versa. Refer to RFC 3697 for more details.
IPsec Issues. Note that the IPsec protocol does not include the IPv6 header's Flow Label in any of its cryptographic calculations (in the case of tunnel mode, it is the outer IPv6 header's Flow Label that is not included). Hence, modification of the Flow Label by a network node has no effect on IPsec end-to-end security because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an intruder's modification of the Flow Label; i.e., a man-in-the-middle attack. Refer to RFC 3697 for more details.
Internet Control Message Protocol (ICMP) Version 6 (ICMPv6) plays a key role in IPv6. Capabilities implemented with ICMPv6 include:
- Address auto-configuration
- Duplicate address detection
- Echo request and echo reply
- Error notifications
- Neighbor reachability and address resolution
- PMTU (Path Maximum Transmission Unit) discovery
- Router and prefix discovery
- Router renumbering
Broadcast amplification is a concern in IPv4 networks. The IPv6 specification removes the concept of dedicated broadcast from the protocol and specifies specific language in RFC 2463 to mitigate these types of attacks by specifying the following:
"ICMPv6 messages should not be generated as a response to a packet with an IPv6 multicast destination address, a link-layer multicast address, or a link-layer broadcast address."
Security considerations include the following:
- Are Router Advertisements coming from an authorized router?
- Are there security requirements for Neighbor Advertisements?
- Are redirects coming from the router to which the packet was actually sent?
"Unusual" router advertisements, such as, but not limited to, the ones below, need to be filtered at the firewall:
- Routers advertising the same established prefixes;
- Routers advertising any new prefixes;
- Prefix changes outside of renumbering and transition periods.
Some of these issues are addressed in the sections (and chapters) that follow.
Neighbor Discovery Issues
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. NDP is defined in RFC 2461 and RFC 2462. It turns out that the basic NDP lacks a mechanism for determining authorized neighbors. If not secured, NDP is vulnerable to various attacks: redirection, stealing addresses, denial of service advertisement, and parameter spoofing could occur. A suggestion (RFC 3682) of using a "hop count of 255" has only rather limited value. The use of IPsec Authentication Header (AH) or Encapsulating Security Payload (ESP) only works with manual keying and pre-established security associations.
Nodes on the same link use NDP to discover each other's presence and link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. NDP is used by both hosts and routers. Its functions include Neighbor Discovery (ND), Router Discovery (RD), Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection (NUD) (a mechanism used for tracking the reachability of neighbors), Duplicate Address Detection (DAD), and Redirection. The original NDP specifications called for the use of IPsec to protect NDP messages. However, the RFCs do not give detailed instructions for using IPsec to do this. In this particular application, IPsec can only be used with a manual configuration of security associations because of bootstrapping problems in using the Internet Key Exchange (IKE) Protocol (IKE is a protocol in the IPsec architecture). Furthermore, the number of manually configured security associations needed for protecting NDP can be very large, making that approach impractical for most purposes.
IPv6 Neighbor Discovery Attacks include the following:
- Neighbor Solicitation
- Redirect traffic to bogus link-layer address
- Unreachability Detection error
- Duplicate Address Detection: "Address in Use" DoS
- Malicious Last-Hop Router-bogus router or false parameters for real routers
- Eliminate Legitimate Routers-crash, DoS, bogus Router Advertisement
- Nodes send to off -link hosts as if they were on-link-impersonate off -link nodes
- Spoofed redirect-route packets to different link-layer address
- Bogus on-link prefix
- Impersonate nodes on bogus link
- Nodes use source with bogus prefix and get no response
- Bogus Parameters-set low hop limit from router, use stateful address configuration (DHCP)
- Replay Attacks-replay any previous neighbor or router discovery packet
- Neighbor Discovery DoS-send packet to unused address and cause router to perform neighbor discovery
To address the issue, RFC 3971 specifies security mechanisms for NDP; unlike those in the original NDP specifications, these mechanisms do not use IPsec. RFC 3971 specifies the SEcure Neighbor Discovery (SEND) protocol, which is designed to counter the threats to NDP. SEND is applicable in environments where physical security on the link is not assured (such as over wireless) and attacks on NDP are a concern. The Neighbor Discovery Protocol has several functions, most of which are implemented using ICMP messages, such as the ICMPv6 Neighbor Advertisement message. The main functions of NDP as discussed in RFC 3971 are: Neighbor Discovery, Router Discovery, Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection, Duplicate Address Detection, and Redirection. Specifically, The Router Discovery function allows IPv6 hosts to discover the local routers on an attached link. The main purpose of Router Discovery is to find neighboring routers willing to forward packets on behalf of hosts. Subnet prefix discovery involves determining which destinations are directly on a link; this information is necessary in order to know whether a packet should be sent to a router or directly to the destination node.
- The Redirect function is used for automatically redirecting a host to a better first-hop router, or to inform hosts that a destination is in fact a neighbor; i.e., on-link.
- Address Autoconfiguration is used for automatically assigning addresses to a host. This allows hosts to operate without explicit configuration related to IP connectivity. The default autoconfiguration mechanism is stateless. To create IP addresses, hosts use any prefix information delivered to them during Router Discovery and then test the newly formed addresses for uniqueness. A stateful mechanism, DHCPv6, provides additional autoconfiguration features.
- DAD is used for preventing address collisions during Address Autoconfiguration. A node that intends to assign a new address to one of its interfaces first runs the DAD procedure to verify that no other node is using the same address. As the rules forbid the use of an address until it has been found unique, no higher-layer traffic is possible until this procedure has been completed. Thus, preventing attacks against DAD can help ensure the availability of communications for the node in question.
- The Address Resolution function allows a node on the link to resolve another node's IPv6 address to the corresponding link-layer address. Address Resolution is defined in RFC 2461, and it is used for hosts and routers alike. Again, no higher-level traffic can proceed until the sender knows the link-layer address of the destination node or the next hop router. Note that the source link-layer address on link-layer frames is not checked against the information learned through Address Resolution. This allows for an easier addition of network elements such as bridges and proxies and eases the stack implementation requirements, as less information has to be passed from layer to layer.
- NUD is used for tracking the reachability of neighboring nodes, both hosts and routers. NUD is security sensitive, because an attacker could claim that reachability exists when in fact it does not.
The NDP messages follow the ICMPv6 message format, as shown in Figure 1. All NDP functions are realized by using the Router Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and Redirect messages. An actual NDP message includes an NDP message header, consisting of an ICMPv6 header and ND message-specific data, and zero or more NDP options. The NDP message options are formatted in the Type-Length-Value format.
Figure 1. NDP message.
SEND secures the various functions in NDP, where a set of new Neighbor Discovery options is introduced. These options are used to protect NDP messages. This specification introduces these options, an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in NDP. The components of the solution are as follows:
- Certification paths, anchored on trusted parties, are expected to certify the authority of routers. A host must be configured with a trust anchor to which the router has a certification path before the host can adopt the router as its default gateway (router). Certification Path Solicitation and Advertisement messages are used to discover a certification path to the trust anchor without requiring the actual Router Discovery messages to carry lengthy certification paths. The receipt of a protected Router Advertisement message for which no certification path is available triggers the authorization delegation discovery process.
- Cryptographically Generated Addresses (CGA) are used to make sure that the sender of a Neighbor Discovery message is the "owner" of the claimed address. A public-private key pair is generated by all nodes before they can claim an address. A new NDP option, the CGA option, is used to carry the public key and associated parameters. This specification also allows a node to use non-CGAs with certificates that authorize their use. However, the details of such use are beyond the scope of this specification and are left for future work.
- A new NDP option, the RSA Signature option, is used to protect all messages relating to Neighbor and Router discovery. Public key signatures protect the integrity of the messages and authenticate the identity of their sender. The authority of a public key is established either with the authorization delegation process, by using certificates, or through the address ownership proof mechanism, by using CGAs, or with both, depending on configuration and the type of the message protected. Note: RSA is mandated because having multiple signature algorithms would break compatibility between implementations or increase implementation complexity by forcing the implementation of multiple algorithms and the mechanism to select among them. A second signature algorithm is only necessary as a recovery mechanism, in case a flaw is found in RSA. If this happens, a stronger signature algorithm can be selected, and SEND can be revised. The relationship between the new algorithm and the RSA-based SEND described in this document would be similar to that between the RSA-based SEND and ND without SEND. Information signed with the stronger algorithm has precedence over that signed with RSA, in the same way that RSA-signed information now takes precedence over unsigned information. Implementations of the current and revised specs would still be compatible
- In order to prevent replay attacks, two new Neighbor Discovery options, Timestamp and Nonce, are introduced. Given that Neighbor and Router Discovery messages are in some cases sent to multicast addresses, the Timestamp option offers replay protection without any previously established state or sequence numbers. When the messages are used in solicitation advertisement pairs, they are protected with the Nonce option. Nonce is a term that means "for the present time" or "for a single occasion or purpose."
In the context of security a Nonce is a "number used once," for example, a random or pseudorandom number issued in an authentication protocol to ensure that previous communications cannot be reused to unleash "replay attacks." Hence, it is a random or non-repeating value that is included in data exchanged by a protocol, usually for the purpose of guaranteeing liveness and thus detecting and protecting against replay attacks.
All IPv6 nodes must be able to process Routing Extension Headers. These Routing Extension Headers can be used to evade access controls based on destination address. All nodes can act as routers; a node processes routing header and forwards packets to other destinations. Observers recommend limiting traffic with routing headers to only those nodes that participate in IP mobility or impose strict policies for forwarding on all nodes.
The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purpose of generating denial-of-service traffic. RFC 5095 deprecates the use of IPv6 Type 0 Routing Headers, in light of this security concern. RFC 2460 defined an IPv6 extension header called "Routing Header," identified by a Next Header value of 43 in the immediately preceding header. A particular Routing Header subtype denoted as "Type 0" (RH0) is also defined. A single RH0 may contain multiple intermediate node addresses, and the same address may be included more than once in the same
RH0. This allows a packet to be constructed such that it will oscillate between two RH0-processing hosts or routers many times. In addition, this allows a stream of packets from an attacker to be amplified along the path between two remote routers, which could be used to cause congestion along arbitrary remote paths and hence act as a denial-of-service mechanism. This attack is particularly serious in that it affects the entire path between the two exploited nodes, not only the nodes themselves or their local networks.
RFC 5095 notes that it is to be expected that it will take some time before all IPv6 nodes are updated to remove support for RH0. Some of the uses of RH0 can be mitigated using ingress filtering. A site security policy intended to protect against attacks using RH0 should include the implementation of ingress filtering at the site border.
While security considerations in reference to with DNS (e.g., DNS Security (DNSSEC)) are not specific to IPv6, improper configuration and use with IPv6 can impact performance. Practitioners identify the following as points to remember:
- Local addresses should never be published.
- Security models based on source address validation are weak and not recommended.
- Setting up an authorization mechanism (e.g., a shared secret, or public-private keys) between a node and the DNS server has to be done manually and may require quite a bit of time and expertise.
- Setting up the reverse tree is somewhat more complicated, but reverse DNS checks provide weak security at best.
- The only (questionable) security-related use for them may be in conjunction with other mechanisms when authenticating a user.
- Reverse chains for 6to4 addresses and Teredo addresses are impractical with Dynamic DNS Updates.
Minimum Security Plan
As a minimum, the following steps should be undertaken with regard to IPv6 security by an organization:
- Develop an IPv6 Security Plan
- Create appropriate policy
- Manage Routers/Switches appropriately
- Disable IPv6/Tunnels
- Develop Access Control Lists (ACL) to Block IPv6/Tunnels on core/edge/outside enclave
- Network protection devices/tools
- Contact vendors for IPv6 advice
- Block IPv6 (Type 41) tunnels
- Enable IPv6 IDS/IPS features
- Manage End Nodes appropriately
- Enable IPv6 host firewalls on all end devices
- Disable IPv6 if not used
- Monitor Core and Enclave Boundaries
In conclusion, one needs to keep in mind that "security in IPv6" is a much broader topic than just a discussion on IPsec. While IPsec is mandatory in IPv6 (as we see in the chapter that follows), the same practical issues with IPsec deployment remain from IPv4, namely configuration complexity and key management. Even when using IPsec, there are numerous threats that still remain issues in IP networking: end-to-end encryption impedes granular visibility in the network (firewalls, SSL offload, IDS), and this may have the effect of countering, removing, or weakening controls that are already put into place. For example, IPv4 ARP attacks are replaced with IPv6 ND attacks; IPv4 DHCP attacks are possibly aggravated by stateless auto-configuration attacks-this is in addition to traditional DHCP issues for IPv6. It follows that detailed planning is needed by the network or security administrator to set up a trustworthy IPv6