On Wed, Jul 3, 2019 at 1:37 AM Michael Richardson <[email protected]> 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 <[email protected]> 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
> > [email protected]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
--
SY, Jen Linkova aka Furry
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
