Re: tcp hostcache and ip fastforward for review

Mike Silbersack wrote:
> 
> On Sun, 9 Nov 2003, Andre Oppermann wrote:
> 
> > Hello all,
> >
> > this patch contains three things (to be separated for committing):
> 
> I don't have much time free in the next week, so I cannot do a complete
> review.  However, I just did a quick readthrough.
> 
> >  tcp_hostcache
> 
> This looks good to me, I've been waiting for you to finish it for a long
> time.  You actually missed a point:
> 
>     - Ensures that a cached entry isn't added until the 3WHS is completed.
> 
> This should help make synfloods with random source addresses less
> damaging.

The cache will only be updated if the tcp connection is being closed.
All updates are done in tcp_drop. The T/TCP updates have to be done
inline during connection setup. I've converted all places which
updated the T/TCP rtmetrics in routing table with updates to the
hostcache.

> Would it be possible to provide a way for netstat to view the host cache
> table?  I think that it would be useful.

At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list".
Syncache ain't visible via netstat either. So far you had to use
route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm
sure whether netstat is the right place for it. But I can do that
in a second step.

> >  ip_fastforward
> 
> No comment, I didn't read through this part, and I'm not familiar with
> the forwarding code.
> 
> >  tcp bug fixes and MSS DoS attack prevention
> 
> Generally good, but:
> 
> >   - adds tcp_minmssoverload which disconnects a TCP session if
> >     it receives too many (1000) packets per second whose average
> >     segement size is lower than tcp_minmss
> >   - DoS attack 2: make MSS very low on local side of connection
> >     and send maaaany small packet to remote host. For every packet
> >     (eg. 2 bytes payload) a sowakeup is done to the listening
> >     process. Consumes a lot of CPU there.
> 
> I don't think that your patch for this really solves anything.  Anyone who
> would write such a program could just as easily make it use concurrent
> connections, have it auto-reconnect, and/or have it only send 900 packets
> per second.  I think that you should remove this section of the patch, but
> leave a comment about this problem existing so that it will be thought
> more about in the future.

The actually solves the problem. Let me explain in more detail. When
we get so many small packets per second the CPU will become pretty
saturated. Depending on how much data is sent it can go on for minutes
or hours. This code jumps in there and disconnects the within a second.
Of course someone can immediatly reconnect and do it again. But that
needs the 3WHS again and gives some delay. In the end this code is
like the ICMP rate limiter code. It there to migitate a problem to
manageable level, not to make it go away.

> After the rest of the code is in, we can brainstorm on other possible
> solutions... I think that Mini's idea of approaching it as an optimization
> is the correct one.

Ok, for brainstorming. For Mini's idea see my answer to him.

-- 
Andre