All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Paasch <christoph.paasch@uclouvain.be>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: netdev@vger.kernel.org, Eric Dumazet <eric.dumazet@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Martin Topholm <mph@hoth.dk>, Florian Westphal <fw@strlen.de>,
	opurdila@ixiacom.com,
	Hans Schillstrom <hans.schillstrom@ericsson.com>
Subject: Re: [RFC PATCH 0/2] Faster/parallel SYN handling to mitigate SYN floods
Date: Mon, 28 May 2012 18:14:29 +0200	[thread overview]
Message-ID: <4FC3A465.4030203@uclouvain.be> (raw)
In-Reply-To: <20120528115102.12068.79994.stgit@localhost.localdomain>

Hello,

On 05/28/2012 01:52 PM, Jesper Dangaard Brouer wrote:
> The following series is a RFC (Request For Comments) for implementing
> a faster and parallel handling of TCP SYN connections, to mitigate SYN
> flood attacks.  This is against DaveM's net (f0d1b3c2bc), as net-next
> is closed, as DaveM has mentioned numerous times ;-)
> 
> Only IPv4 TCP is handled here. The IPv6 TCP code also need to be
> updated, but I'll deal with that part after we have agreed on a
> solution for IPv4 TCP.
> 
>  Patch 1/2: Is a cleanup, where I split out the SYN cookie handling
>   from tcp_v4_conn_request() into tcp_v4_syn_conn_limit().
> 
>  Patch 2/2: Move tcp_v4_syn_conn_limit() outside bh_lock_sock() in
>   tcp_v4_rcv().  I would like some input on, (1) if this safe without
>   the lock, (2) if we need to do some sock lookup, before calling
>   tcp_v4_syn_conn_limit() (Christoph Paasch
>   <christoph.paasch@uclouvain.be> mentioned something about SYN
>   retransmissions)

Concerning (1):
I think, there are places where you may have troube because you don't
hold the lock.
E.g., in tcp_make_synack (called by tcp_v4_send_synack from your
tcp_v4_syn_conn_limit) there is:

if (sk->sk_userlocks & SOCK_RCVBUF_LOCK &&
	(req->window_clamp > tcp_full_space(sk) ||
	 req->window_clamp == 0))
	req->window_clamp = tcp_full_space(sk);

Thus, tcp_full_space(sk) may have different values between the check and
setting req->window_clamp.


Concerning (2):

Imagine, a SYN coming in, when the reqsk-queue is not yet full. A
request-sock will be added to the reqsk-queue. Then, a retransmission of
this SYN comes in and the queue got full by the time. This time
tcp_v4_syn_conn_limit will do syn-cookies and thus generate a different
seq-number for the SYN/ACK.


But I don't see how you could fix these issues in your proposed framework.

Cheers,
Christoph

> 
> ---
> 
> Jesper Dangaard Brouer (2):
>       tcp: Early SYN limit and SYN cookie handling to mitigate SYN floods
>       tcp: extract syncookie part of tcp_v4_conn_request()
> 
> 
>  net/ipv4/tcp_ipv4.c |  131 ++++++++++++++++++++++++++++++++++++++++++---------
>  1 files changed, 107 insertions(+), 24 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
Université Catholique de Louvain
-- 

  parent reply	other threads:[~2012-05-28 16:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-28 11:52 [RFC PATCH 0/2] Faster/parallel SYN handling to mitigate SYN floods Jesper Dangaard Brouer
2012-05-28 11:52 ` [RFC PATCH 1/2] tcp: extract syncookie part of tcp_v4_conn_request() Jesper Dangaard Brouer
2012-05-28 11:52 ` [RFC PATCH 2/2] tcp: Early SYN limit and SYN cookie handling to mitigate SYN floods Jesper Dangaard Brouer
2012-05-29 19:37   ` Andi Kleen
2012-05-29 20:18     ` David Miller
2012-05-30  6:41     ` Eric Dumazet
2012-05-30  7:45       ` Jesper Dangaard Brouer
2012-05-30  8:15         ` Eric Dumazet
2012-05-30  9:24           ` Jesper Dangaard Brouer
2012-05-30  9:46             ` Eric Dumazet
2012-05-30  8:03       ` Hans Schillstrom
2012-05-30  8:24         ` Eric Dumazet
2012-05-30 11:14           ` Hans Schillstrom
2012-05-30 21:20           ` Rick Jones
2012-05-31  8:28             ` Eric Dumazet
2012-05-31  8:45               ` Hans Schillstrom
2012-05-31 14:09                 ` Eric Dumazet
2012-05-31 15:31                   ` Hans Schillstrom
2012-05-31 17:16                     ` Eric Dumazet
2012-05-28 16:14 ` Christoph Paasch [this message]
2012-05-29 20:17   ` [RFC PATCH 0/2] Faster/parallel SYN " Jesper Dangaard Brouer
2012-05-29 20:36     ` Christoph Paasch
2012-05-30  8:44       ` Jesper Dangaard Brouer
2012-05-30  8:50         ` Eric Dumazet
2012-05-30  8:53         ` Christoph Paasch
2012-05-30 22:40           ` Jesper Dangaard Brouer
2012-05-31 12:51             ` Jesper Dangaard Brouer
2012-05-31 12:58               ` Eric Dumazet
2012-05-31 13:04                 ` Jesper Dangaard Brouer
2012-05-31 13:10                 ` Eric Dumazet
2012-05-31 13:24                   ` Jesper Dangaard Brouer
2012-05-30  4:45     ` Eric Dumazet

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=4FC3A465.4030203@uclouvain.be \
    --to=christoph.paasch@uclouvain.be \
    --cc=brouer@redhat.com \
    --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 \
    --cc=opurdila@ixiacom.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.