Hello Michael Please see below
> > Pascal Thubert (pthubert) <[email protected]> wrote: >> 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. > > There are a few attacks on the ND cache that I can think of. > One of them that we see on the IETF network is the script kiddies who > sequentially scan IP addresses. We have a lot of them, and so we flood the > wifi with ARP queries (v4) and NS (v6). We have mitigations for this. > > In the route-over 6tisch/RPL space, we don't (as you indicate), use NS by the > router, we know who is on our network, and we would just have no /128 routes, > and just drop the packets. Is this the attack that you are speak of as a > remote DOS? Yes, Scanning in v6 can hardly be used to discover addresses but it can be used as a DOS attack against the CPU because the silicon needs to punt on cache miss. It can also be used to DOS the neighbor cache. And it is hard to differentiate from legitimate new traffic. The possibility for such an attack comes from the reactive nature of ND, which was designed when IP routing was in software and the network a happy Woodstock. Times have changed and a modern ND should protect itself and the addresses it manages (think SeND and SAVI) and should be friendly to fabrics, to wireless and to hardware forwarders. We have that on tiny devices but it’s still missing in the big irons. > >> 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. > > When I mentioned attacks on the ND cache, I am referring to those that can > occur from within the 6tisch network from malicious pledge nodes. We have to > limit the NCE usage by untrusted nodes so that we have space for as many > registered nodes. > I think you are agreeing with me above. > Yes I certainly followed you there and agree. We had that discussion for 6TiSCH minimal security. My point was that this local DOS attack requires a physical presence and is much harder to achieve than the remote DOS. > I believe that the issue that Jen is describing would for unaware leaves that > were sleepy. Unaware Leaves that follow the ROLL specs register their addresses and sleep. They can sleep for the whole lifetime of their registration, the router will maintain an ND entry and the network will protect the address ownership. To your point the node must wake up and refresh the registration before it expires. What’s left of Jen’s issue with registration is the asymmetrical routing. In the ROLL specs the router that has the registration injects the route in the MLSN and gets the traffic back so the issue does not exist. In a transit network the router would forward the registration state to a 6LBR that can answer unicast lookups from other routers, still incurring a delay, or may push a state to other routers or to a load balancer so the router with the registration gets the traffic first. All the best, Pascal > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
