On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote: > On Sun, Jul 17, 2011 at 11:42 AM, William Herrin <b...@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