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

[Owen DeLong <owen () delong com>]

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

> On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler <jsw () inconcepts biz> wrote:
> > On Sun, Jul 17, 2011 at 11:42 AM, William Herrin <bill () 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


_____
NANOG mailing list
NANOG () nanog org
https://mailman.nanog.org/mailman/listinfo/nanog