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