Re: [6lo] ND cache entries creation on first-hop routers

Hello Michael

6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the ones coming from the outside of the subnet, i.e., from a place that is out of touch and virtually nowhere.
This is because in an RFC 6775/8505-only network, there is no reactive operation, a packet coming from the outside of the subnet for a node that is not registered to the router is just dropped. Just like an AP does not copy a packet on the wireless for a MAC that is not associated.

I'm baffled that the reactive ND is still the official technique for IPv6 lookup at 6MAN. The operations that you have to do in an enterprise-class router on a data packet, punt the packet to software, run ND, program the hardware, protect ND cache and CPU against DOS, are just from another age. So we have to run our own things (e.g., a LISP MSMR) on our fabrics when modernizing ND would do the trick in a standard fashion (see draft-thubert-6lo-unicast-lookup) .

Your point below remains correct, since the attack you describe is from a node that reaches the router at L2. Arguably, that attack is physically much harder to perform than the DOS packet from outer space.

All the best,

Pascal

> -----Original Message-----
> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: mardi 2 juillet 2019 17:38
> To: 6lo@ietf.org; Jen Linkova <furry13@gmail.com>; 6tisch@ietf.org
> Cc: V6 Ops List <v6ops@ietf.org>; 6man <6man@ietf.org>
> Subject: Re: [6lo] ND cache entries creation on first-hop routers
> 
> 
> I think that the discussion here is particularly relevant to constrained
> devices/routers on route-over MESH(RPL,etc.) networks.
> 
> I also think that for L=0 networks, which RPL creates with RPL DIO messages
> rather than (just) RAs, and 6LRs that need to support join operations (like
> draft-ietf-6tisch-minimal-security) this may matter.
> 
> In particular, in the minimal-security case, we need to partition the ND cache
> such that untrusted (unverified) malicious pledge nodes can not attack the ND
> cache.
> 
> The behaviour 2.2.1.  Host Sending Unsolicited NA, should probably never flush
> an old entry out of the ND.  I think that under attack (whether from untrusted
> pledges, or from p0woned devices already on the network), it is better to
> prefer communication from existing nodes rather than new ones.  2.2.1.2
> mentions this.
> 
> {typo:
>       -It's recommended that thsi functionality is configurable and
>       +It's recommended that this functionality is configurable and }
> 
> I didn't really understand 2.2.2: is it exploiting some corner case in the spec, or
> maybe just some part I am not well clued in about.  So maybe an extra
> paragraph to explain things.
> 
> I kinda like the ping all routers trick.
> 
> 
> Jen Linkova <furry13@gmail.com> wrote:
>     > I wrote a short draft to discuss and document an operational issue
>     > related to the ND state machine and packet loss caused by how routers
>     > create ND cache entries for new host addressed:
> 
>     > https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/
> 
>     > (taking into account some vendors have implemented one of the proposed
>     > solution already, I guess it's a well-known problem but it might still
>     > worth documenting)
> 
>     > Comments are appreciated!
> 
>     > --
>     > SY, Jen Linkova aka Furry
> 
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > ipv6@ietf.org
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> 