From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>,
netdev@vger.kernel.org,
Christoph Paasch <christoph.paasch@uclouvain.be>,
Eric Dumazet <eric.dumazet@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Martin Topholm <mph@hoth.dk>
Cc: Florian Westphal <fw@strlen.de>,
Hans Schillstrom <hans.schillstrom@ericsson.com>
Subject: [RFC v2 PATCH 3/3] tcp: SYN retransmits, fallback to slow-locked/no-cookie path
Date: Thu, 31 May 2012 15:40:08 +0200 [thread overview]
Message-ID: <20120531134008.10311.63345.stgit@localhost.localdomain> (raw)
In-Reply-To: <20120531133807.10311.79711.stgit@localhost.localdomain>
Handle retransmitted SYN packets, by falling back to the slow
locked processing path (instead of dropping the reqsk, as
previous patch).
This will handle the case, where the original SYN/ACK didn't get
dropped, but somehow were delayed in the network and the
SYN-retransmission timer on the client-side fires before the
SYN/ACK reaches the client.
Notice, this does introduce a new SYN attack vector. Using this
vector of false retransmits, on big machine in testlab, the performance
is reduced to 251Kpps SYN packets (compared to approx 400Kpps
when early dropping reqsk's. SYN generator speed 750Kpps).
Signed-off-by: Martin Topholm <mph@hoth.dk>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/ipv4/tcp_ipv4.c | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 29e9c4a..d2ff5c3 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1307,24 +1307,22 @@ int tcp_v4_syn_conn_limit(struct sock *sk, struct sk_buff *skb)
/* Check for existing connection request (reqsk) as this might
* be a retransmitted SYN which have gotten into the
- * reqsk_queue. If so, we choose to drop the reqsk, and use
- * SYN cookies to restore the state later, even-though this
- * can cause issues, if the original SYN/ACK didn't get
+ * reqsk_queue. If so, we simple fallback to the slow
+ * locked processing path. Even-though this might introduce
+ * a new SYN attack vector.
+ * This will handle the case, where the original SYN/ACK didn't get
* dropped, but somehow were delayed in the network and the
* SYN-retransmission timer on the client-side fires before
- * the SYN/ACK reaches the client. We choose to neglect
- * this situation as we are under attack, and don't want to
- * open an attack vector, of falling back to the slow locked
- * path.
+ * the SYN/ACK reaches the client.
*/
bh_lock_sock(sk);
exist_req = inet_csk_search_req(sk, &prev, tcp_hdr(skb)->source, saddr, daddr);
- if (exist_req) { /* Drop existing reqsk */
+ if (exist_req) {
if (TCP_SKB_CB(skb)->seq == tcp_rsk(exist_req)->rcv_isn)
net_warn_ratelimited("Retransmitted SYN from %pI4"
- " (orig reqsk dropped)", &saddr);
-
- inet_csk_reqsk_queue_drop(sk, exist_req, prev);
+ " (don't do SYN cookie)", &saddr);
+ bh_unlock_sock(sk);
+ goto no_limit;
}
bh_unlock_sock(sk);
prev parent reply other threads:[~2012-05-31 13:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-31 13:39 [RFC v2 PATCH 0/3] tcp: Parallel SYN brownies patch series to mitigate SYN floods Jesper Dangaard Brouer
2012-05-31 13:39 ` [RFC v2 PATCH 1/3] tcp: extract syncookie part of tcp_v4_conn_request() Jesper Dangaard Brouer
2012-05-31 13:40 ` [RFC v2 PATCH 2/3] tcp: Early SYN limit and SYN cookie handling to mitigate SYN floods Jesper Dangaard Brouer
2012-05-31 13:40 ` Jesper Dangaard Brouer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120531134008.10311.63345.stgit@localhost.localdomain \
--to=brouer@redhat.com \
--cc=christoph.paasch@uclouvain.be \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=hans.schillstrom@ericsson.com \
--cc=mph@hoth.dk \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).