NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))
Owen DeLong
owen at delong.com
Sun Jul 17 19:40:15 UTC 2011
On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote:
> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin <bill at herrin.us> wrote:
>> My off-the-cuff naive solution to this problem would be to discard the
>> oldest incomplete solicitation to fit the new one and, upon receiving
>> an apparently unsolicited response to a discarded solicitation,
>> restart the process flagging that particular query non-discardable.
>
> Do you mean to write, "flagging that ND entry non-discardable?" Once
> the ND entry is in place, it should not be purged for quite some time
> (configurable is a plus), on the order of minutes or hours. Making
> them "permanent" would, however, cause the ND table to eventually
> become full when foolish things like frequent source address changes
> for "privacy" are in use, many clients are churning in and out of the
> LAN, etc.
>
I believe it was obvious in the context he means flagging the incomplete
ND entry as one that is not to be discarded early for pruning of potentially
DOS-related ND entries.
Basically an ND entry would have the following states and timers:
Flagbits:
I Incomplete (1 = ND entry is not complete)
D Discardable (1 = Incomplete entry is result of incoming packet
for unverified neighbor)
Timers:
A Age -- Counts up from time ND entry was created (most likely
synthetic and calculated by storing T in the ND entry and using
Tnow - Tentry).
The system would have a two timer policies: 1 for Incomplete Timeout
and 1 for Complete Timeout. (TI and TC)
At A=TI, an incomplete entry would be discarded regardless of the D flag.
At A=TC, a complete entry would be discarded regardless of the D flag.
When a packet arrives for a host which does not exist in the ND table,
a new entry with flags I and D would be created. An ND request would
be generated as normal.
When a new ND table entry is required and the table is full, the oldest
entry with both I and D flags (max(A)) would be replaced with the new
entry.
When an ND response is received matching an entry with the I flag set,
the I and D flags would be cleared and the entry would be filled in with
the appropriate data.
When an ND response is received not matching an entry with the I flag set,
a new entry with the I flag and no D flag would be created.
In this way, you cannot overflow the neighbor table in a way that creates
significant disruption unless there are actually too many neighbors,
in which case, it's bad network design and not DOS.
>> Where does this naive approach break down?
>
> It breaks down because the control-plane can't handle the relatively
> small number of punts which must be generated in order to send ND
> solicits, and without the ability to install "incomplete" entries into
> the data-plane, those punts cannot be policed without, by design,
> discarding some "good" punts along with the "bad" punts resulting from
> DoS traffic.
>
I think most of this punting could be handled at the line card level. Is there
any reason that the ND process can't be moved into line-card level silicon
as described above?
Sure, that doesn't solve the problem on current hardware, but, it moves it
from design problem to implementation issue, which IMHO is a step in the
right direction.
Owen
More information about the NANOG
mailing list