NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
Owen DeLong
owen at delong.com
Sun Jul 17 20:57:34 UTC 2011
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
trace.
Owen
More information about the NANOG
mailing list