Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

[Owen DeLong <[e-mail]>]

> On Jul 31, 2020, at 08:13 , Ted Lemon <[e-mail]> wrote:
> 
> On Jul 30, 2020, at 6:26 PM, Pascal Thubert (pthubert) <pthubert=[e-mail] <mailto:pthubert=[e-mail]>> wrote:
>> I support GRAND because it is better than nothing and progressing just that at 6MAN seems to be an incredible achievement already. 
> 
> Indeed.  GRAND seems like a thing that one would be tempted to add to a stack even in the absence of a draft describing it. Having a draft that describes how to do it is better, because we can then have a discussion of what the benefits and drawbacks are, and mitigate the drawbacks. This concern about ND security seems like a useless digression: yes, ND is not secure, we know this. We’ve tried to address it with SEND, but that hasn’t gotten any traction in the market. 
> 
> Are we seeing L2 attacks on ND in the wild? What’s the threat model? If this is a real concern, let’s confront it head-on, rather than trying to address it piecemeal.

ND attacks are a concern in a very limited number of scenarios, most of which have not had significant v6 penetration yet…

1.	Public wifi networks (e.g. coffee houses, etc.)
2.	College/University settings (some v6 traction here, but often not on student-device accessible LANs)
3.	Other networks which must admit untrusted clients/devices

In reality, ND is not significantly better or worse than ARP in terms of attack surface. The primary difference with ND
is the ability to overrun {switch, router, host} neighbor tables. This doesn’t stem from the difference between ND
and ARP, but rather from the difference between networks that rarely have more than 256 possible L3 addresses
and networks which routinely have more than 18 quintillion possible addresses. There’s just not enough silicon
on the planet for every switch to support an n x 2^64 bit neighbor table.

Indeed, as an operator, IMHO, if there’s a place we need to focus on improving L2 attack surface in v6, it’s in
finding better ways for {routers, hosts, switches} to mitigate/absorb this type of resource exhaustion attack.
Unfortunately, this is a hard problem to solve, so we focus on moving the deck chairs we can move while
ignoring the elephant-sized hole in the bulkheads that we don’t know how to patch.

Owen