NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

Sun Jul 17 20:32:42 UTC 2011

On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler <jsw at inconcepts.biz> wrote:
> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin <bill at herrin.us> wrote:
>> My off-the-cuff naive solution to this problem would be to discard the
>> oldest incomplete solicitation to fit the new one and, upon receiving
>> an apparently unsolicited response to a discarded solicitation,
>> restart the process flagging that particular query non-discardable.
>
> Do you mean to write, "flagging that ND entry non-discardable?"

Hi Jeff,

I meant flagging the new incomplete solicitation ineligible for
previous sentence's early load-based discard. When you get a response
to a solicitation you no longer remember making, solicit again and
don't forget about it until the normal protocol timeouts this time.

>> Where does this naive approach break down?
>
> It breaks down because the control-plane can't handle the relatively
> small number of punts which must be generated in order to send ND
> solicits, and without the ability to install "incomplete" entries into
> the data-plane, those punts cannot be policed without, by design,
> discarding some "good" punts along with the "bad" punts resulting from
> DoS traffic.

Let me try to restate what you've said to make sure I understand. When
the data plane knows what ARP or ND is underway, it can guard against
overwhelming the control plane by discarding excessive traffic for the
same yet-unresolved destination while allowing packets for new
destinations on the lan through to the control plane. Without that
knowledge, it can only have one queue causing the data plane to
discard packets which would initiate neighbor discovery prior to the
control plane seeing them, preventing any solicitation or implementing
the logic I described.

This doesn't sound particularly hard to me.

Most CPE has the control and data planes on the same silicon. A guard
at the data plane is pointless in the first place. Just punt the
packet up and move on.

On the bigger iron where the planes are on running on different chips,
you can move the initial ND solicitation packet into the data plane.
After failing to find an incomplete ND, generate and send the ND
solicitation and THEN make the decision whether to punt to the control
plane or discard. If you discard, the control plane will find out
about the "good" ones when the response comes back.

This means you could multiply a unicast flood into a multicast flood
but you'll have to pump out several orders of magnitude more packets
than with the original problem before it causes me grief.

Still, you've sold me on part of the claim: A /64 is inherently
vulnerable to a remote DOS attack that a /120 is not.

Now sell me on the other part: How does this require effort on the
attacker's part that's enough smaller than the general form "flood his
link" attack that I should care about it beyond poking my vendors to
see if they've reasonably covered the high-load corner cases?

I see how the original attack could kill a lan with a relatively small
number of packets. With the naive solution, it seems to require
something a lot closer to a steady flood.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004