nanog mailing list archives
Re: NIST IPv6 document
From: TJ <trejrco () gmail com>
Date: Fri, 7 Jan 2011 09:30:50 -0500
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 beMost 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
Current thread:
- Re: NIST IPv6 document, (continued)
- Re: NIST IPv6 document Jeff Wheeler (Jan 06)
- Re: NIST IPv6 document Owen DeLong (Jan 06)
- Re: NIST IPv6 document Jeff Wheeler (Jan 06)
- Message not available
- Re: NIST IPv6 document Jeff Wheeler (Jan 06)
- Re: NIST IPv6 document Mark Smith (Jan 07)
- Re: NIST IPv6 document Dobbins, Roland (Jan 07)
- Re: NIST IPv6 document Mark Smith (Jan 07)
- Re: NIST IPv6 document Owen DeLong (Jan 07)
- Re: NIST IPv6 document Mark Smith (Jan 08)
- Re: NIST IPv6 document Dobbins, Roland (Jan 07)
- Re: NIST IPv6 document TJ (Jan 07)
- Re: NIST IPv6 document Dobbins, Roland (Jan 07)
- Re: NIST IPv6 document TJ (Jan 07)
- Re: NIST IPv6 document Justin M. Streiner (Jan 07)
- Re: NIST IPv6 document Owen DeLong (Jan 07)
- Message not available
- Re: NIST IPv6 document Tim Chown (Jan 10)
- Re: NIST IPv6 document Owen DeLong (Jan 10)
- Re: NIST IPv6 document Jack Bates (Jan 10)
- Re: NIST IPv6 document Iljitsch van Beijnum (Jan 05)
- Re: NIST IPv6 document Jeff Wheeler (Jan 05)
- Re: NIST IPv6 document Joel Jaeggli (Jan 05)