Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Owen DeLong <owen () delong com>]

On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote:

> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin <bill () 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


_____
NANOG mailing list
NANOG () nanog org
https://mailman.nanog.org/mailman/listinfo/nanog