netdev
[Top] [All Lists]

Re: [PATCH] Increased DoS protection.

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [PATCH] Increased DoS protection.
From: Rusty Russell <rusty@xxxxxxxxxxxxxxxx>
Date: Fri, 28 Apr 2000 11:38:28 +0930
Cc: netdev@xxxxxxxxxxx, netfilter@xxxxxxxxxxxxxxx
In-reply-to: Your message of "Thu, 27 Apr 2000 09:44:42 -0400." <Pine.GSO.4.20.0004270918170.26852-100000@shell.cyberus.ca>
Sender: owner-netdev@xxxxxxxxxxx
In message <Pine.GSO.4.20.0004270918170.26852-100000@xxxxxxxxxxxxxxxx> you writ
e:
> 
> 
> On Thu, 27 Apr 2000, Rusty Russell wrote:
> 
> >     3) Do randomish/LRU drop on unreplied connections when we're
> >        under stress.
> > 
> 
> My 2 cents CDN:
> I just gleaned at the code and must have missed the "randomness"
> in the drops.
...
> Would you please explain your algorithm (in english)?

This is why I said `randomish': I sweep through the hash table.  If
that hash chain doesn't have a likely candidate, I try the hash chain
the new entry is trying to go into (in case they're trying to bomb one
hash chain).

I traverse the hash chain backwards (meaning oldest-creation first),
looking for connections which have only had one-way traffic (this
means no established TCP connections).  This approximates LRU (only
approximate because retransmits do not reorder the hash chain).

I never touch connections with traffic both ways (TCP RST packets
don't count: handled specially in the tcp protocol tracking).

This leaves it vulnerable to SYN floods (as is the old masquerading
code, so we didn't get *worse* here): long term I will implement
window tracking as per ipfilter, and then I can be more confident that
a real three-way handshake has occurred, and set a high-confidence bit
for that connection.

Hope that helps,
Rusty.
--
Hacking time.

<Prev in Thread] Current Thread [Next in Thread>