One document matched: draft-halpern-6man-nddos-mitigation-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact='yes'?>
<?rfc symrefs='yes'?>
<rfc docName="draft-halpern-6man-nddos-mitigation-00" ipr="trust200902">
  <?rfc toc='yes'?>

  <front>
<title abbrev="Mitigating ND Based DoS Attacks">Mitigating Neighbor
Discovery Based Denial of Service Attacks</title> 

    <author fullname="Joel M. Halpern" initials="J.M.H."
            surname="Halpern">
      <organization abbrev="Ericsson">Ericsson</organization>

      <address>
        <postal>
          <street>P. O. Box 6049</street>
          <city>Leesburg</city>
          <region>VA</region>
          <code>20178</code>
          <country>US</country>
        </postal>
        <email>joel.halpern@ericsson.com</email>
      </address>
    </author>

    <date month="October" year="2011" />

    <area>Internet</area>

    <workgroup>6Man</workgroup>

    <abstract>
      <t>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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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 <xref target="ndproblem"></xref>.  Some operational
techniques and small protocol adjustments have been proposed that can
help alleviate this problem are described in <xref
target="ndenhance"></xref>.  This draft proposes a slightly more drastic
optional behavior for routers, which can nearly eliminate this problem.
      </t>
      <t>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 <xref target="RFC4861"></xref> are
specified in this document.
      </t>
    </section>

   <section title="Terminology">
     <t>The terminology here follows that defined in <xref
target="RFC4861"></xref></t> 
     <t>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 <xref target="RFC2119"></xref>. 
    </t>
    </section>

    <section title="Problem Summary and Solution Approach">
      <t>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.
      </t>
      <t>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 <xref target="RFC4861">
</xref>
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 all the values in the subnet.  With
IPv6, which reommends subnets be /64s, such sizing is no longer
possible.
      </t>
      <t>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.</t> 
    </section>

    <section title="Basic Behavior">
      <t>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.
      </t>
      <t>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.
      </t>
    </section>

    <section title="Protocol Enhancements">
      <t>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.
      </t>
      <t>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.
      </t>

      <t>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.
      </t>

      <t>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.</t>
      <t>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. 
      </t>

      <t>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.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>There are currently no IANA considerations or assignments in 
this document.
      </t>
    </section>

    <section title="Security Considerations">
      <t>There are presumably security implications of this behavioral
change, but they have not been evaluated yet.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.RFC.4861" ?>
    </references>

    <references title="Informative References">
      <reference anchor="ndproblem">
        <front>
          <title>I-D.gashinsky-v6ops-v6nd-problems-00.txt</title>
          <author initials="W" surname="Kumari"/>
          <author initials="I" surname="Gashinsky"/>
          <author initials="J" surname="Jaegglie"/>
          <date year="2011"/>
        </front>
      </reference>
      <reference anchor="ndenhance">
        <front>
          <title>I-D.gashinsky-v6nd-enhance-00.txt</title>
          <author initials="W" surname="Kumari"/>
          <author initials="I" surname="Gashinsky"/>
          <author initials="J" surname="Jaegglie"/>
          <date month="October" year="2011" />
        </front>
      </reference>
    </references>
  </back>
</rfc>