In your letter dated Tue, 12 Jul 2011 22:34:53 +1000 you wrote: >The router would need to know that it was under attack. That could be >quite a complicated heuristic. It seems to me that it is simpler to >treat ND slot exhaustion as the problem, and not worry too much about >the cause.
First, let me make clear that I was thinking about remote attacks. I think that's the most serious problem. If you have malicious hosts directly attached you have bigger problems, and you have to use either SeND or L2 filtering. Assuming a remote attack, the only thing the attacker can do is cause incomplete entries to be created. So the table consist of a collection of normal (complete) entries for neighbors and a potentially large number of incomplete entries. Ultimately, the limit is not so much the number of incomplete entries in the table, but the number of NS messages you can send per second. So my definition of under attack would be that the router did not send a NS because doing so would exceed the maximum number NS messages per second. Beyond that, scale the table to hold that number of incomplete entries and you are done. >- when slots get scarce, start favouring existing completed entries. > Don't time them out as fast. That is, treat completed entries as more > valuable than incomplete ones. Silly to toss out a probably-good entry > in favour of a definitely-incomplete one. This can be done all the time. If a completed entry is less then 1 minute old, keep it. If you run out of space, then there is a local attack (or the number of neighbors exceeds what the router can handle) >- when slots get very scarce, start timing out incomplete entries > faster, returning the slots to the pool. There will be a useful > minimum time here... You only need incomplete entries for about 3 seconds (default settings). >- store source info with each slot. Have separate slot > space for local (on-router) sources and remote (off-router) sources. > This lets the local network keep working even when under attack from > off-router. Yes. Just one bit to mark an incomplete entry as local. But that should mostly effect the sending of NS messages. >- when slot space reaches a critical level, start ignoring requests from > sources that have no completed entries. Yes, innocent new sources will > suffer, but you are heading into crisis. That would be just the packets that are forwarded. >- when and as long as there are NO slots left: > - don't delete completed entries at all while there are incomplete > entries to delete I would just partition the table: some number of entries for completed and some number for incomplete. > - delete entries with sources with the fewest completed entries > first. After them, delete the oldest entries first. I think that for remote attack this doesn't make much sense. >Do you need a special message? A ping to the all-nodes multicast address >should result in all nodes responding, and the responses would have all >the info in them that you need. No, other nodes have to send a NS (or anything else that contains their link layer addresses). >You'd have to do that on each link, >though. If the bottleneck is not the table size, but number of NS messages you can send per second, then it is per overloaded link. >And you'd have to do it *fast*. In fact, it seems to me that you >would be unlikely to be able to do it fast enough to make a difference - >by the time your nodes had responded, the attacker would have filled the >ND cache. Doing it preemptively would make for a very chatty link. The attacker fills the cache with incomplete entries. NS requests can be used to create complete entries. So you can always add them to the table. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
