Internet Engineering Task Force M. Smith
Internet-Draft IMOT
Intended status: Informational April 7, 2014
Expires: October 9, 2014
Further Mitigating Router ND Cache Exhaustion DoS Attacks Using
Solicited-Node Group Membership
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00
Abstract
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.
Status of This Memo
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 9, 2014.
Copyright Notice
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.
Smith Expires October 9, 2014 [Page 1]
Internet-DraMitigating Router ND Cache DoS using Solicited-N April 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Tracking Solicited-Node Multicast Group Presence . . . . 3
2.2. Neighbor Presence Discovery . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. Change Log [RFC Editor please remove] . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
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
Smith Expires October 9, 2014 [Page 2]
Internet-DraMitigating Router ND Cache DoS using Solicited-N April 2014
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.
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 RFC 2119 [RFC2119].
2. Method
2.1. Tracking Solicited-Node Multicast Group Presence
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,
Smith Expires October 9, 2014 [Page 3]
Internet-DraMitigating Router ND Cache DoS using Solicited-N April 2014
using the Querier Election procedure [RFC2710] [RFC3810], as though
it had no knowledge of the presence any of the multicast groups.
2.2. Neighbor Presence Discovery
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.
3. Security Considerations
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:
o the number of Solicited-Node multicast groups present on the link,
and
Smith Expires October 9, 2014 [Page 4]
Internet-DraMitigating Router ND Cache DoS using Solicited-N April 2014
o the ability of the attacker to stumble upon or discover non-
existent addresses that map to present Solicited-Node multicast
groups.
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.
4. Acknowledgements
Review and comments were provided by YOUR NAME HERE!
This memo was prepared using the xml2rfc tool.
5. Change Log [RFC Editor please remove]
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00, initial
version, 2014-04-08
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Smith Expires October 9, 2014 [Page 5]
Internet-DraMitigating Router ND Cache DoS using Solicited-N April 2014
6.2. Informative References
[I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
privacy-addresses-17 (work in progress), January 2014.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May
2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6018] Baker, F., Harrop, W., and G. Armitage, "IPv4 and IPv6
Greynets", RFC 6018, September 2010.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012.
Author's Address
Mark Smith
In My Own Time
PO BOX 521
HEIDELBERG, VIC 3084
AU
Email: markzzzsmith@yahoo.com.au
Smith Expires October 9, 2014 [Page 6]