diff options
author | Gerrit Renker <gerrit@erg.abdn.ac.uk> | 2007-09-26 11:31:49 -0300 |
---|---|---|
committer | David S. Miller <davem@sunset.davemloft.net> | 2007-10-10 16:52:43 -0700 |
commit | a94f0f970549e63e54c80c4509db299c514d8c11 (patch) | |
tree | 3b9421fc70e00c16ed57ef4330b24504b04ae309 /README | |
parent | ee1a15922d356aff0e31bf9bb9088ab346b8033a (diff) | |
download | linux-stable-a94f0f970549e63e54c80c4509db299c514d8c11.tar.gz linux-stable-a94f0f970549e63e54c80c4509db299c514d8c11.tar.bz2 linux-stable-a94f0f970549e63e54c80c4509db299c514d8c11.zip |
[DCCP]: Rate-limit DCCP-Syncs
This implements a SHOULD from RFC 4340, 7.5.4:
"To protect against denial-of-service attacks, DCCP implementations SHOULD
impose a rate limit on DCCP-Syncs sent in response to sequence-invalid packets,
such as not more than eight DCCP-Syncs per second."
The rate-limit is maintained on a per-socket basis. This is a more stringent
policy than enforcing the rate-limit on a per-source-address basis and
protects against attacks with forged source addresses.
Moreover, the mechanism is deliberately kept simple. In contrast to
xrlim_allow(), bursts of Sync packets in reply to sequence-invalid packets
are not supported. This foils such attacks where the receipt of a Sync
triggers further sequence-invalid packets. (I have tested this mechanism against
xrlim_allow algorithm for Syncs, permitting bursts just increases the problems.)
In order to keep flexibility, the timeout parameter can be set via sysctl; and
the whole mechanism can even be disabled (which is however not recommended).
The algorithm in this patch has been improved with regard to wrapping issues
thanks to a suggestion by Arnaldo.
Commiter note: Rate limited the step 6 DCCP_WARN too, as it says we're
sending a sync.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions