svn commit: r191259 - head/sys/netinet

[Robert Watson]

On Mon, 20 Apr 2009, Marko Zec wrote:

>>> ... which makes a flow cache a perfect DoS target in any environment, be 
>>> it a DFZ or enterprise router or an end host or whatever.
>>
>> Uhm, assuming that you don't put a limit on the number of flows allocated - 
>> which I do. When you hit the zone limit for flows you simply stop caching 
>> new flows.
>
> ... which means you fall back to the ordinary routing lookups, but only 
> after you have wasted cycles to compute a hash and found out that it doesn't 
> match anything in your cache -> in this case I would expect only a 
> degradation in performance, not an improvement.

The most recent example I'm aware of in our tree along those lines was from 
the 4.x time range, I believe.  My memory is a bit hazy, but it goes something 
like this: in an initial analysis, we believed that the pain associated with a 
synflood was from connection state and hash lookups of that state.  Actually, 
it turned out that much of it was from the creation of cloned routes for every 
remote IP address from which we received a SYN, as we would clone the route 
and cache it very early.  Features like the syncache and syncookies were very 
important for mitigating SYN flood overhead, but in part because avoiding 
allocating routing-related state was actually just as, if not more, important 
as the "ordinary" connection state.

Many of the concerns brought up in the discussion so far are reasons that I 
asked Kip to do the following with the flowcache:

(1) Make this a kernel option
(2) Disable it by default

I would also agree with the view that if/when our routing table is more 
up-to-snuff, we might well want to lose the flowcache again, as arguably a 
revised routing table implementation, (combined with connection-oriented 
route/llentry caching) should not require or benefit from a flowcache. 
However, there's quite a bit of work required to get us there.  Happily Kip 
already has a patch for route/llentry caching, but the historic opacity of the 
routing code is still hurting us in seeing optimization of the base routing 
table.

Robert N M Watson
Computer Laboratory
University of Cambridge