On Thu, Jan 6, 2011 at 21:13, Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong <owen@delong.com> wrote:
1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be
Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change.
Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are to use discrete network allocations for your infrastructure (loopbacks and PtP links, specifically) and to filter traffic destined to those at your edges ...
3. Police the ND issue rate on the router. Yes, it means that an ND attack could prevent some legitimate ND requests from getting through, but, at least it prevents ND overflow and the working hosts with existing ND entries continue to function. In most cases, this will be virtually all of the active hosts on the network.
You must understand that policing will not stop the NDCache from becoming full almost instantly under an attack. Since the largest existing routers have about 100k entries at most, an attack can fill that up in *one second.*
On some platforms, existing entries must be periodically refreshed by actual ARP/NDP exchange. If they are not refreshed, the entries go away, and traffic stops flowing. This is extremely bad because it can break even hosts with constant traffic flows, such as a server or infrastructure link to a neighboring router. Depending on the attack PPS and policer configuration, such hosts may remain broken for the duration of the attack.
Implementations differ greatly in this regard. All of them break under an attack. Every single current implementation breaks in some fashion. It's just a question of how bad.
And I am not saying there isn't a concern here that we should get vendors to allow us to mitigate, I think we just disagree on the severity of the issue at hand and the complexity of the solution. /TJ