From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neal Cardwell Subject: Re: Why not use all the syn queues? in the function "tcp_conn_request", I have some questions. Date: Tue, 4 Sep 2018 09:06:09 -0400 Message-ID: References: <47NgfBCN4YlW5rstCQGVJicSQ3yqiWFZpYPuBnmE1Jer0vxuBffWYbZzM2VmkeNNdk8gFgnMYo5T1fODpWGiRKnElyAY7bUmS_r-Z-SSaf4=@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Netdev To: ttttabcd@protonmail.com Return-path: Received: from mail-qt0-f169.google.com ([209.85.216.169]:43106 "EHLO mail-qt0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726281AbeIDRbb (ORCPT ); Tue, 4 Sep 2018 13:31:31 -0400 Received: by mail-qt0-f169.google.com with SMTP id g53-v6so3778899qtg.10 for ; Tue, 04 Sep 2018 06:06:27 -0700 (PDT) In-Reply-To: <47NgfBCN4YlW5rstCQGVJicSQ3yqiWFZpYPuBnmE1Jer0vxuBffWYbZzM2VmkeNNdk8gFgnMYo5T1fODpWGiRKnElyAY7bUmS_r-Z-SSaf4=@protonmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Sep 4, 2018 at 1:48 AM Ttttabcd wrote: > > Hello everyone,recently I am looking at the source code for handling TCP three-way handshake(Linux Kernel version 4.18.5). > > I found some strange places in the source code for handling syn messages. > > in the function "tcp_conn_request" > > This code will be executed when we don't enable the syn cookies. > > if (!net->ipv4.sysctl_tcp_syncookies && > (net->ipv4.sysctl_max_syn_backlog - inet_csk_reqsk_queue_len(sk) < > (net->ipv4.sysctl_max_syn_backlog >> 2)) && > !tcp_peer_is_proven(req, dst)) { > /* Without syncookies last quarter of > * backlog is filled with destinations, > * proven to be alive. > * It means that we continue to communicate > * to destinations, already remembered > * to the moment of synflood. > */ > pr_drop_req(req, ntohs(tcp_hdr(skb)->source), > rsk_ops->family); > goto drop_and_release; > } > > But why don't we use all the syn queues? If tcp_peer_is_proven() returns true then we do allow ourselves to use the whole queue. > Why do we need to leave the size of (net->ipv4.sysctl_max_syn_backlog >> 2) in the queue? > > Even if the system is attacked by a syn flood, there is no need to leave a part. Why do we need to leave a part? The comment describes the rationale. If syncookies are disabled, then the last quarter of the backlog is reserved for filling with destinations that were proven to be alive, according to tcp_peer_is_proven() (which uses RTTs measured in previous connections). The idea is that if there is a SYN flood, we do not want to use all of our queue budget on attack traffic but instead want to reserve some queue space for SYNs from real remote machines that we have actually contacted in the past. > The value of sysctl_max_syn_backlog is the maximum length of the queue only if syn cookies are enabled. Even if syncookies are disabled, sysctl_max_syn_backlog is the maximum length of the queue. > This is the first strange place, here is another strange place > > __u32 isn = TCP_SKB_CB(skb)->tcp_tw_isn; > > if ((net->ipv4.sysctl_tcp_syncookies == 2 || > inet_csk_reqsk_queue_is_full(sk)) && !isn) { > > if (!want_cookie && !isn) { > > The value of "isn" comes from TCP_SKB_CB(skb)->tcp_tw_isn, then it is judged twice whether its value is indeed 0. > > But "tcp_tw_isn" is initialized in the function "tcp_v4_fill_cb" > > TCP_SKB_CB(skb)->tcp_tw_isn = 0; > > So it has always been 0, I used printk to test, and the result is always 0. That field is also set in tcp_timewait_state_process(): TCP_SKB_CB(skb)->tcp_tw_isn = isn; So there can be cases where it is not 0. Hope that helps, neal