Mailing List Archive: Neighbor Cache Exhaustion, was Re: Question about IPAM tools for v6

Hi Guillaume,

willing to share your lab setup / results?
We did some testing ourselves in a Cisco-only setting and couldn't cause any problems. [for details see here: http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1/]

After that I asked for other practical experience on the ipv6-hackers mailing list, but got no responses besides some "I heard this is a problem in $SOME_SETTING" and references to Jeff Wheeler's paper (which works on the - wrong - assumption that an "incomplete" entry can stay in the cache for a long time, which is not true for stacks implementing ND in conformance with RFC 4861).
So your statement is actually the first first-hand proof of NCE being a real-world problem I ever hear of. thanks in advance for any additional detail.

best

Enno

On Fri, Jan 31, 2014 at 02:59:24PM +0100, Aur??lien wrote:
> On Fri, Jan 31, 2014 at 2:07 PM, Ole Troan <ot@cisco.com> wrote:
>
> > >> Consensus around here is that we support DHCPv6 for non-/64 subnets
> > >> (particularly in the context of Prefix Delegation), but the immediate
> > >> next question is "Why would you need that?"
> > >
> > > /64 netmask opens up nd cache exhaustion as a DoS vector.
> >
> > FUD.
> >
> >
> Hi Ole,
>
> I personnally verified that this type of attack works with at least one
> major firewall vendor, provided you know/guess reasonably well the network
> behind it. (I'm not implying that this is a widespread attack type).
>
> I also found this paper: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf
>
> I'm looking for other information sources, do you know other papers dealing
> with this problem ? Why do you think this is FUD ?
>
> Thanks,
> --
> Aur??lien Guillaume

--
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

On 01/31/2014 11:16 AM, Enno Rey wrote:
> Hi Guillaume,
>
> willing to share your lab setup / results? We did some testing
> ourselves in a Cisco-only setting and couldn't cause any problems.
> [for details see here:
> http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1/]
>
> After that I asked for other practical experience on the
> ipv6-hackers mailing list, but got no responses besides some "I heard
> this is a problem in $SOME_SETTING" and references to Jeff Wheeler's
> paper (which works on the - wrong - assumption that an "incomplete"
> entry can stay in the cache for a long time, which is not true for
> stacks implementing ND in conformance with RFC 4861). So your
> statement is actually the first first-hand proof of NCE being a
> real-world problem I ever hear of. thanks in advance for any
> additional detail.

Are we talking about Ciscos, specifically?

I recall reproducing this sort of thing on BSDs, Linux, and Windows.

Note: In some cases, the problem is that even when the entries in the
INCOMPLETE state are timeout, if the rate is lower than the rate at
which you "produce" them, it's still a problem.

Too bad -- we do have plenty of experience with this.. e.g., managing
the IP reassembly queue.

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1