On Fri, 7 Jan 2011 09:38:32 +0000 "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Jan 7, 2011, at 4:14 PM, Mark Smith wrote:
Doesn't this risk already exist in IPv4?
There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work,
I was commenting on the mentality the OP seemed to be expressing, about *both* onlink and off link sources triggering address resolution for lots of non-existent destinations, and that this was a new and unacceptable threat. I think the offlink risk is a far more significant one. I think the onlink risk pretty much no worse than any of the other things that LAN attached devices can do if they choose to.
and as you mention, the ND stuff is layer-3-routable.
The issue isn't that ND is layer 3 routable - it isn't unless a router implementation is broken. The problem is that somebody on the Internet could send 1000s of UDP packets (i.e. an offlink traffic source) towards destinations that don't exist on the target subnet. The upstream router will then perform address resolution, sending ND NSes for those unknown destinations, and while waiting to see if ND NAs are returned, will maintain state for each outstanding ND NS. This state is what is exploitable remotely, unless the state table size is large enough to hold all possible outstanding ND NA entries for all possible addresses on the target subnet. I think this problem can be avoided by getting rid of this offlink traffic triggered address resolution state. The purpose of the state (from the Neighbor Discovery RFC) is two fold - - to allow the ND NS to be resent up to two times if no ND NA response is received to ND NSes. A number of triggering packets (e.g. UDP ones or TCP SYNs) are queued as well so that they can be resent if and when ND NS/NA completes. - to allow ICMP destination unreachables to be generated if the ND NS/NA transaction fails, even after resending. I think it is acceptable to compromise on these requirements. ND NS/NA transactions are going to be successful most of the time, so the ND NS/NA retransmit mechanism is going to be rarely used. Original traffic sources have to be prepared for it to fail anyway - the Internet is a best effort network, so if a source node wants to be sure a packet gets to the original destination it needs to be prepared to retransmit it. This has actually proved not to be a problem in IPv4 as Cisco routers have for many years dumped the data packet that triggers ARP, which I'm pretty sure is the reason why the ARP timeout is 4 hours, rather than the more common 5 minutes. Time outs are pretty much moot anyway, because active Neighbor Unreachability Detection is usually performed these days instead of using simple timeouts for existing ARP entries and is required to be performed by IPv6. If you don't maintain state for outstanding ND NS transactions, then that means that the ND NS issuing device will have to just blindly accept any ND NAs it receives at any time, and put them in the neighbor cache, assuming they are correct. That is an vulnerability, as a local node could fill up the neighbor cache with bogus entries, but one that is far less of a risk than the Internet sourced one we're talking about, as it is only onlink devices that can exploit it. As a LAN is already a trusted environment for basic protocol operations, and devices have a vested interest not disabling other devices that provide them with services e.g. default routers, I think it is a reasonable and acceptable risk given those we already accept in LANs, such as the IPv4 ones I mentioned. If it isn't, implement static address resolution entries, PPPoE, per-device VLANs, SEND etc. I doubt I need to go into much detail about whether ICMP destination unreachables need to be reliably received, the reality is that they aren't in IPv4 and I doubt that will change much in IPv6. I think they're a "nice to have" not a "need to have". Regards, Mark.