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

Hi Pascal,

On Wed, Jul 3, 2019 at 6:18 PM Pascal Thubert (pthubert)
<pthubert@cisco.com> wrote:
> 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/.

Oh, that's an interesting plot twist ;) Migrating from 4861/4862 to 6775/8505?
Sounds like smth we might want to explore as a strategy (while the
tactical fixes my draft mostly talks about might be still needed too).
I'll re-read RFCs  6775/8505 and will be back to you with some
questions later..Thanks for the suggestion!

> > -----Original Message-----
> > From: 6lo <6lo-bounces@ietf.org> On Behalf Of Jen Linkova
> > Sent: mercredi 3 juillet 2019 08:52
> > To: Michael Richardson <mcr+ietf@sandelman.ca>
> > Cc: 6tisch@ietf.org; 6man <6man@ietf.org>; V6 Ops List <v6ops@ietf.org>;
> > 6lo@ietf.org
> > Subject: Re: [6lo] ND cache entries creation on first-hop routers
> >
> > On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson
> > <mcr+ietf@sandelman.ca> 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 <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 =-
> > >
> > >
> > >
> >
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > _______________________________________________
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lo

-- 
SY, Jen Linkova aka Furry