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.
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. On the bigger iron where the planes are on running on different chips, you can move the initial ND solicitation packet into the data plane. After failing to find an incomplete ND, generate and send the ND solicitation and THEN make the decision whether to punt to the control plane or discard. If you discard, the control plane will find out about the "good" ones when the response comes back. This means you could multiply a unicast flood into a multicast flood but you'll have to pump out several orders of magnitude more packets than with the original problem before it causes me grief. 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. Now sell me on the other part: How does this require effort on the attacker's part that's enough smaller than the general form "flood his link" attack that I should care about it beyond poking my vendors to see if they've reasonably covered the high-load corner cases? I see how the original attack could kill a lan with a relatively small number of packets. With the naive solution, it seems to require something a lot closer to a steady flood. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004