[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Jul 17, 2011, at 1:32 PM, William Herrin wrote:

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

If you're going to solicit again rather than wait for a new packet, what's
the point of not just installing a complete entry?

After all, if someone sends you a spurious response, they'll likely also
be able to respond to the solicit, so, you don't really protect anything
by sending the solicit.

I figured you stick the ineligible incomplete entry in the table and wait for
the retransmit of the original packet.

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

I think Jeff's focus here is on the kinds of core and TOR switches that
are mostly used in datacenters, not so much the CPE end of the world.
> 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.

More accurately, the larger your single subnet address space, the more
vulnerable you are to table overflow attacks.

A /120 is exactly as vulnerable as an IPv4 /24.
A /96 is exactly as vulnerable as an IPv4 /0.

With bigger address spaces come new challenges. In the real world,
I think this is less of an issue because:

	a.	While the attack surface is large, the benefits of carrying out such
		an attack are relatively small.

	b.	It's a relatively easy attack to spot, identify, quench, and likely