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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Jen

The routers that Michael is talking about are real routers, deployed in large volumes in the field, e.g., in Smartgrid networks. 
They are not running ND as RFC 4861/4862 but as RFC 6775/8505, and then operate RPL routing within the ML subnet.
It would be great to have a section that describes that new ND operation and shows how it changes the deal. I'd be happy to help you on that if you need.
There are some hints in https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/.

All the best,

Pascal

> -----Original Message-----
> From: 6lo <[e-mail]> On Behalf Of Jen Linkova
> Sent: mercredi 3 juillet 2019 08:52
> To: Michael Richardson <[e-mail]>
> Cc: [e-mail]; 6man <[e-mail]>; V6 Ops List <[e-mail]>;
> [e-mail]
> Subject: Re: [6lo] ND cache entries creation on first-hop routers
> 
> On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson
> <[e-mail]> wrote:
> > 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.
> 
> Disclaimer: I have very limited knowledge in that area.
> 
> > 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 next version of the draft will have much more details on discussing the
> security considerations indeed.
> 
> > The behaviour 2.2.1.  Host Sending Unsolicited NA, should probably
> > never flush an old entry out of the ND.
> 
> I'd say that the router behaviour for creating a STALE entry upon receiving an
> unsolicited NA should be the same as for creating an entry for any other
> reason (e.g. for receiving an RS with SLLAO).
> The same safety rules shall apply.
> 
> > 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.
> 
> I guess your routers do purge old stale entries?
> 
> > {typo:
> >       -It's recommended that thsi functionality is configurable and
> >       +It's recommended that this functionality is configurable and }
> 
> Thanks, will fix in -01.
> 
> > 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.
> 
> It's just using the standard ND process: when the node B receives an NS from
> node A and that NS contains the node B  address as a target address and
> SLLAO contains node A LLA, the node B would respond with NA and would
> create a STALE entry for the node A -
> https://tools.ietf.org/html/rfc4861#section-7.2.3
> 
> > I kinda like the ping all routers trick.
> 
> I think it's a hack ;( we do have a mechanism for communicating neighbours
> addresses/reachability called ND. It would be nice to utilise its machinery.
> Pinging creates additional overhead on routers and could get filtered.
> But I'd not be surprised if it's the only way we have realistically to mitigate the
> issue..
> 
> >
> > Jen Linkova <[e-mail]> 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
> >     > [e-mail]
> >     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >     >
> > --------------------------------------------------------------------
> >
> >
> > --
> > Michael Richardson <[e-mail]>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo