| Internet Engineering Task Force | M.R. Smith |
| Internet-Draft | IMOT |
| Intended status: Informational | April 07, 2014 |
| Expires: October 09, 2014 |
Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00
For each of their IPv6 unicast or anycast addresses, nodes join a Solicited-Node multicast group, formed using the lower 24 bits of the address. This group membership can be used by routers to further mitigate the Neighbor Discovery cache Denial of Service attack.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 09, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
When an IPv6 unicast or anycast address is added to or removed from an interface, the node also joins or leaves the Solicited-Node multicast group that corresponds to the address [RFC4291] [RFC4861] [RFC3810]. The Solicited-Node multicast group the node joins or leaves is determined by appending the lower 24 bits of the address to the IPv6 multicast prefix FF02:0:0:0:0:1:FF00::/104 [RFC4291].
The presence of a Solicited-Node multicast group on a link indicates that at least one unicast or anycast address that maps to the Solicited-Node multicast group is present. Conversely, the absence of a Solicited-Node multicast group indicates that no unicast or anycast addresses that would map to it are present on the link.
This presence or absence of Solicited-Node multicast groups can be used by a router to determine if it needs to send Neighbor Solicitations for unresolved addresses on to the link. If the to-be-resolved address maps to a non-existent Solicited-Node multicast group, the router can drop the packet, rather than sending a Neighbor Solicitation for its destination.
For links with prefixes with lengths shorter than or equal to /104, such as a /64, the total number of Solicited-Node multicast groups possible on a link is 2^24, or 16 777 216 groups. The number of Solicited-Node multicast groups present on a link is equal to the number of IPv6 unicast or anycast addresses present on the link which have unique lower 24 bits, used to form the Solicited-Node multicast group address.
For most links the number of present Solicited-Node multicast groups present is going to be in the order of 10s, 100s or perhaps on rarer occasions in the low 1000s. This means that Neighbor Solicitations do not have to be sent for very large numbers of unresolved unicast or anycast addresses for which the corresonding Solicited-Node multicast group is not present. This can significantly reduce the attack surface for the ND cache exhaustion denial of service attack [RFC3756]. For example, if a link has 1000 present Solicited-Node multicast groups, then Neighbor Solicitations do not have to be sent for addresses that would map to the absent 16 776 216 Solicited-Node multicast groups, which is more than 99.99% of the possible Solicited-Node multicast groups.
This memo describes how a router collects Solicited-Node multicast group membership and how it uses this information as part of its neighbor presence discovery procedure, for the purposes of further mitigating the ND cache exhaustion attack.
Note that this method has been independently suggested by Greg Daley and perhaps others.
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 RFC 2119 [RFC2119].
To track Solicited-Node multicast group presence on a link, a router uses the multicast listener discovery procedures specified in [RFC2710] or [RFC3810], without modification.
Note that the procedures specified in [RFC2710] and [RFC3810] do not require that a router performing them to be forwarding multicast packets, or to be participating in a multicast routing protocol with other multicast routers. The ND cache DoS mitigation method described in this memo can be used regardless of whether the other routers in the network, including other on-link routers, are performing multicast forwarding.
If a router using this ND cache DoS mitigation method is not performing multicast forwarding, it may choose to only track Solicited-Node multicast group presence, ignoring the presence information it receives for other multicast groups. This may usefully reduce the router's resources consumption. If a router using this optimisation becomes a multicast forwarding router, it will need to collect presence information for all multicast groups, using the Querier Election procedure [RFC2710] [RFC3810], as though it had no knowledge of the presence any of the multicast groups.
When a router receives a packet for a destination for which it does not have a neighbor cache entry, it uses the [RFC4291] specified method to form a Solicited-Node multicast group address from the destination address.
The router then compares the resulting Solicited-Node multicast group address with its list of present Solicited-Node multicast groups on the link.
If the Solicited-Node multicast group is present, the router then performs the address resolution procedure for the packet's destination IPv6 address as specified in [RFC4861], starting with sending a Neighbor Solicitation towards the Solicited-Node multicast group that corresponds to the address.
If the resulting Solicited-Node multicast group is not present then the router would normally drop the packet. It may alternatively perform some other action with the packet which may be useful to the router's operator, perhaps for security purposes.
The method described in this memo further mitigates the ND cache exhaustion DoS attack. It does not prevent it.
Using this method, neighbor presence discovery will occur for any of the unicast or anycast addresses that map to the present Solicited-Node multicast groups. As a Solicited-Node multicast group can map to up to 2^40 unicast or anycast addresses (for a /64 prefix, 2^(64 - 24)), the ND implementation is likely to continue to be vulnerable to a ND cache exhaustion denial of service for addresses covered by the present Solicited-Node multicast groups. While the number of non-existent addresses that can be targetted remains very large, it is very significantly smaller than the targettable non-existent addresses possible in the on-link prefixes without this measure.
The severity of this threat depends on two factors:
The severity of the threat is lower with lesser numbers of Solicited-Node multicast groups, and less predictable and sparsely distributed Solicited-Node multicast group addresses.
[I-D.ietf-6man-stable-privacy-addresses] proposes the use of stable yet random and less predictable IIDs, on a per-prefix basis. This will increase the number of present Solicited-Node multicast groups, by up to the number of prefixes multiplied by the number of hosts implementing [I-D.ietf-6man-stable-privacy-addresses]. This will reduce the effectiveness of the measure proposed in this memo. However, it will also conversely increase the effectiveness of this measure, as the IIDs and therefore the Solicited-Node multicast groups become less predictable and sparsely distributed.
To protect against ND cache DoS attacks for non-existent addresses that map to present Solicited-Node multicast groups, other ND cache protection measures, such as those described in [RFC6583] should be implemented.
When a packet is sent to a destination that is unresolved and is not covered by a present Solicited-Node multicast group, instead of being dropped, it could alternatively be forwarded to an [RFC6018] greynet collector for further analysis.
Review and comments were provided by YOUR NAME HERE!
This memo was prepared using the xml2rfc tool.
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00, initial version, 2014-04-08
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |