[142892] in North American Network Operators' Group
Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was:
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sun Jul 17 17:02:03 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAP-guGUFpAH2sTpPwg46DVeOFfTx3qVzPHWG6_Cb2tgzPpNL6Q@mail.gmail.com>
Date: Sun, 17 Jul 2011 13:57:34 -0700
To: William Herrin <bill@herrin.us>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
