Thank you for your comments, Mark!
>>> 4.2. SLND Processing >>> ... >>> 4. If the SLND Active Flag is off, the router ignores the neighbor >>>advertisement. >> >> >>Unsolicited neighbor advertisements are integral for >new hosts to join the network or for failover configurations and should not be >disabled by routers by default. > >In traditional stateful neighbor discovery, I don't think unsolicited >(multicast) neighbor advertisements can create new entries in other nodes' >neighbor caches, they can only update existing ones (7.6.2 in RFC4861). There >is no text in that section about unsolicited unicast neighbor advertisements. >Assuming unicast unsolicited neighbor advertisements aren't universally >dropped, I'm sure they still would have to be updating an existing neighbor >cache entry, rather than creating new ones. > > (snip) > >I'll try to make this a bit clearer in the next revision. Thank you. I know of at least one ISP that, as a defense against off-link neighbor solicitation attack, has turned off neighbor solicitations on their router entirely but is accepting unsolicited neighbor advertisements (at least on all-nodes multicast). In any case, a clarification that a router MAY ignore neighbor advertisements _for addresses not already in the neighbor caches_ would be helpful. >>> 4.2 SLND >Processing >>> ... >>> SLDN Activate Threshold. >> >>If the router is implementing the defenses against >on-link neighbor advertisement attack, having a single "SLDN Activate >Threshold" can be harmful due to the possibility of hysteresis around the >threshold value, as pointed out by my co-worker, Deb Banerjee. In that case, >upon entering SLDN mode, the router would send a stateless >neighbor solicitation, only to drop the reply upon leaving SLDN mode. A >high/low watermark approach for "SLDN >Activate Threshold" is preferred in those cases. In cases when a router will >accept an >unsolicited neighbor advertisement, a single threshold is acceptable, though. >> >> > >I've thought in that case, the host that originated the traffic that triggered >neighbor discovery's reliability mechanisms would take care of any loss of >either the stateless neighbor solicitation towards the on-link target host, or >loss off the neighbor advertisements in response (which may in include the >drop you mentioned). As stateless neighbor discovery is really only intended >to be used when there appears to be a neighbor cache DoS attack occurring, >which should hopefully be a fairly rare event, so I'm generally trying to keep >the mechanism simple, and to leverage existing reliability mechanisms to take >care of gaps such as the one Deb identified. An occasional single lost packet is certainly not a problem. The concern here, however, is a possibility of a router entering a state with the neighbor table utilization right at the "SLDN Activate Threshold." A single expiring neighbor table entry would take the router out of SLDN mode, while the next packet requiring a neighbor solicitation will activate SLDN mode right back. Depending on the router's neighbor table expiration policy, it is conceivable that a number of neighbor table entries would expire one-by-one within a relatively short period of time. If that happens, neighbor discovery could be impaired for that period of time. This is admittedly not a likely possibility, and the timing would have to work out "just right". If this is to be addressed, an alternative approach to high/low watermarks could be "SLDN Advertisement Delay" time parameter. When "SLDN Activate Threshold" is no longer met, "SLND Active Flag" would be turned off as in the original proposal (and the router will create new neighbor table entries for sent solicitations). However, the router would still accept all neighbor advertisements for "SLDN Advertisement Delay" time since turning off "SLND Active Flag". Best, - Igor -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
