Internet DRAFT - draft-halpern-6man-nddos-mitigation
draft-halpern-6man-nddos-mitigation
6Man J. Halpern
Internet-Draft Ericsson
Expires: April 19, 2012 October 17, 2011
Mitigating Neighbor Discovery Based Denial of Service Attacks
draft-halpern-6man-nddos-mitigation-00
Abstract
It has been observed that with the large space of IPv6 addresses
within a subnet, remote attackers can send packets that saturate a
rotuers ND cache, and potentially saturate a subnet with ND
Soliciation messages as well. Some operational techniques and small
protocol adjustments have been proposed that can help alleviate this
problem. This draft proposes a slightly more drastic optional
behavior for routers, which can nearly eliminate this problem.
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 April 19, 2012.
Copyright Notice
Copyright (c) 2011 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
Halpern Expires April 19, 2012 [Page 1]
Internet-Draft Mitigating ND Based DoS Attacks October 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Summary and Solution Approach . . . . . . . . . . . . . 3
4. Basic Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Enhancements . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Halpern Expires April 19, 2012 [Page 2]
Internet-Draft Mitigating ND Based DoS Attacks October 2011
1. Introduction
It has been observed that with the large space of IPv6 addresses
within a subnet, remote attackers can send packets that saturate a
routers ND cache, and potentially saturate a subnet with ND
Soliciation messages as well. A thorough description of the problem
can be found in [ndproblem]. Some operational techniques and small
protocol adjustments have been proposed that can help alleviate this
problem are described in [ndenhance]. This draft proposes a slightly
more drastic optional behavior for routers, which can nearly
eliminate this problem.
While the basic behavior described here can be looked upon as a local
matter, there are robustness issues if a router applies this solution
on its own. Therefore, additional enhancements to the basic ND
protocol behavior as defined in [RFC4861] are specified in this
document.
2. Terminology
The terminology here follows that defined in [RFC4861]
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
HOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
3. Problem Summary and Solution Approach
The basic problem under discussion is the ability for a remote
attacker to fill a routers neighbor cache with unresolved, and
unresolvable, entries. If done at a sufficient rate, this may
prevent the router from maintaining the necessaary entries for
actually reaching the hosts on a subnet the router directly serves.
Depending upon circumstances, the rate of Neighbor Soliciations
messages on the subnet may be high enough to casue difficulties,
since these are multicast messages.
An attacker causes this problem by sending IPv6 datagrams addressed
to distinct hypothetical nonexistant host systems on the subnet. the
attacker sends these messages continusously. The router receives
these messasges, and as specified in [RFC4861] it generates Neighbor
solicitation emssages for each unknown destination, and creates
INCOMPLETE Neighbor cache entries for each one. The attacker can use
random destination addresses, or even sequential addresses and count
on passing the actual hosts quickly. With IPv4, this problem could
be coped with in most cases by simply having a table large enough for
Halpern Expires April 19, 2012 [Page 3]
Internet-Draft Mitigating ND Based DoS Attacks October 2011
all the values in the subnet. With IPv6, which reommends subnets be
/64s, such sizing is no longer possible.
This proposals asks the question, what if the router never accepts
packets for unknown hosts on local subnets? In such a case, it would
never create INCOMPLETE cache entries, and would never generate
Neighbor Solicitation messages based upon received traffic. Instead
of soliciating such information, the router would learn of the hosts
(and neighboring routers) on the subnet from received information.
4. Basic Behavior
The basic operational model for the router is still that it maintains
a neighbor cache with IPv6->Media address resolution information. It
populates this cache upon receiving Rotuer Solicitation or Neighbor
Advertisement messages from hosts on the subnet.
It is still important thaat the router be able to tell whether hosts
are still reachable. As such, routers should assign lifetime
information to this ifnormation. As the lifetime approaches, rather
than discarding the information, the rotuer can issue a Neighbor
Soliciation message to revalidate the information. In the absence of
a response, such revalidaiton should be attempted several times. On
links were power consumption is a significant issue, it may make
sense to simply keep the neighbor cache information without
expiration or revalidation.
5. Protocol Enhancements
While the above description prevents the attack of concern, it has
several failure modes. In particular, if a rotuer comes up after a
subnet is operational, it will not learn the necessary information.
Also, it would seem desirable to provide additional robustness in the
learning process, in case too many messages get lost.
There are three protocol enhancements that can be used to help this
problem. The first mechanism, which has also been proposed for other
reasosn, is simply for all hosts on the subnet to keep sending Router
Solicitation messages, rather than ceasing after only three
transmissions. The rate of sending could be reduced. The message
load on the subnet would not be excessive. One might want to adjust
the router response to such messages, allowing the router to simply
maintain the steady rate of advertisement. This would ensure the
router learned of all the hosts on the network in a reasoanble time
even if there were unexpected behaviors (partition repair at the link
level, for example) which would otherwise interfere.
Halpern Expires April 19, 2012 [Page 4]
Internet-Draft Mitigating ND Based DoS Attacks October 2011
As a variation on the above, one could deefine a "please respond"
flag in the Router Advertisement, whcih the routers could set
tointermittently to refresh information. As the repeated Router
Solicitiations address other issues as well, that seems preferred.
While the above enhancement would be sufficient to ensure robustness,
it is desirable to be able to deploy this solution before all the
hsots on the subnet are upgraded to exhibit that behavior. As such,
other robustness techniques are recommended. These approaches rely
on the fact that the primary problem occurs when a new router joins
an active subnet with an already active serving router providing the
same prefix the new router would provide.
One thing the existing router could do, which would provided the
needed robustness, is to cause all the hsots it knows about to send
new Neighbor Advertisements. It can do this by sending each host a
Neghbor soliciation with a source address of the unspecified address.
This will cause the host to multicast the Neghbor Advertisement it
responds with.
One may consider that the message exchanges of such a triggering and
responding sequence is excessive. As a fall-back, one could easily
define an exchange protocol by which an operational router on the
subnet could send its neighbor cache to the new router. As this is
more complex, more detailed work on that is deferred until it is
deemed necessary.
6. IANA Considerations
There are currently no IANA considerations or assignments in this
document.
7. Security Considerations
There are presumably security implications of this behavioral change,
but they have not been evaluated yet.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Halpern Expires April 19, 2012 [Page 5]
Internet-Draft Mitigating ND Based DoS Attacks October 2011
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
8.2. Informative References
[ndproblem]
Kumari, W., Gashinsky, I., and J. Jaegglie,
"I-D.gashinsky-v6ops-v6nd-problems-00.txt", 2011.
[ndenhance]
Kumari, W., Gashinsky, I., and J. Jaegglie,
"I-D.gashinsky-v6nd-enhance-00.txt", October 2011.
Author's Address
Joel M. Halpern
Ericsson
P. O. Box 6049
Leesburg, VA 20178
US
Email: joel.halpern@ericsson.com
Halpern Expires April 19, 2012 [Page 6]
