[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: TCP SYN Cookies for NetBSD
On 11/5/2012 11:24 PM, Alan Barrett wrote:
On Mon, 05 Nov 2012, Paul Goyette wrote:
While at the MeetBSD California un-conference over the weekend, I was
approached by the originator of . Looking through the archives, I
don't see any replies or discussion, so I was wondering (along with
John) if there's any merit to the suggested code/patches? Has anyone
with TCP expertise reviewed them at all?
Are these SYN cookies to be used all the time without a SYN cache, or
will there also be a finite sized SYN cache to allow the host to avoid
violating the TCP protocol (as long as the cache is not full)?
If they are to be used all the time without a SYN cache, then I agree
with Mouse that they may cause too much harm. If there is also a SYN
cache and the harmful side-effects of SYN cookies arise only when the
SYN cache is full, then I think that is acceptable. Exhaustion of a
properly-sized SYN cache should be so rare as to occur only when the
host is under attack (or something that looks like an attack), and under
such circumstances it's acceptable for the host's self-defence measures
to inconvenience legitimate clients.
--apb (Alan Barrett)
The current implementation requires a sysctl to be set to enable syn
cookies. When set the host always responds with syn cookies and when
unset only via the syn cache (though a valid cookie will still be
accepted). This is done for testing purposes only.
My intention for the final version is to do as you stated, that is, to
begin sending cookies when the syn cache becomes full (or nearly so),
also for the reasons you stated. A sysctl could be provided to disable
cookies at runtime to meet feature parity with other operating systems,
but I don't know if this is necessary.
I did see a request that I can't find now to add a syn cookie only build
option, to free up the memory that would be used on the cache, which
should be trivially possible assuming I can find the original request.
The opposite would also be easy to add.
Main Index |
Thread Index |