On Jul 17, 2011, at 1:32 PM, William Herrin wrote: > On Sun, Jul 17, 2011 at 1:35 PM, Jeff Wheeler <j...@inconcepts.biz> wrote: >> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin <b...@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