Re: 6man w.g. last call for <draft-ietf-6man-grand>

[Mark Smith <[e-mail]>]

Hi Pascal,

On Thu, 23 Jul 2020 at 17:47, Pascal Thubert (pthubert)
<[e-mail]> wrote:
>
>
> > Le 23 juil. 2020 à 03:44, Jen Linkova <[e-mail]> a écrit :
> >
> > On Thu, Jul 23, 2020 at 11:15 AM Jen Linkova <[e-mail]> wrote:
> >>> - helping mitigate ND cache exhaustion DoS attack by preloading the
> >>> cache with addresses
> >>
> >> I'm not sure I fully understand how it would help...Could you please elaborate?
> >> The attack is trying to create a lot of INCOMPLETE entries by sending
> >> packets to non-existing addresses.
> >> Unless we require that routers rely on GRAND only and never even try
> >> to create a new entry upon receiving a packet to an address never seen
> >> before, the router behaviour would still be the same.
>
> I hope it is clear by now that grand does not change the nature of the NCE, that is a cache. We cannot trust the ND cache to defeat a DoS attack. You can only do that when a hard state is proactively maintained for each address.
>

I agree, the way to prevent an ND cache resource exhaustion attack
from off-link nodes is to eliminate off-line nodes' ability to create
cache entries.

The fundamental problem with the ND cache (as well as IPv4's ARP
cache, just not to the same extent), is that data/forwarding plane
traffic from hosts that might not be trustworthy is being used to
create control plane state that is trusted.

> This means deploying an RFC 8505-only network. This is still allows both centralized (DHCP) and autoconf (SLAAC), address allocation is orthogonal to neighbor state management.
>

It seems to me that the harder issue is how to transition to an
address registration protocol like RFC 8505 incrementally, now that we
have billions of ND cache nodes and millions of ND cache routers
deployed. I think both routers and hosts would have to support both
methods concurrently.

Something like GRAND is not a solution to the ND cache DoS attack,
however it does improve the situation, and is a much smaller
incremental change compared to a transition to an address registration
protocol which still would have to co-exist with the ND cache
protocol.

Regards,
Mark.



> Keep safe,
>
> Pascal
>
>
> >
> > I stand corrected. Yeah, it might help as it makes it more likely that
> > an address which does not exist in the cache does not exist on the
> > network either.
> > So resolving such addresses could be deprioritized even more.
> > Funny enough the draft does say it already ;))
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------