From nobody Sat May 11 13:32:18 2024 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vc69z0dxvz5K7g5 for ; Sat, 11 May 2024 13:32:23 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from smtp-out.a.misk.com (smtp-out.a.misk.com [199.47.128.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vc69y5TvCz4nXp for ; Sat, 11 May 2024 13:32:22 +0000 (UTC) (envelope-from rrs@lakerest.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rrs@lakerest.net designates 199.47.128.30 as permitted sender) smtp.mailfrom=rrs@lakerest.net X-Authenticated-User: rrs@lakerest.net Received: from 10.1.1.87 (nonat-pool-1510-nbry-162-213-116-120.carolinaconnect.net [162.213.116.120]) by smtp.misk.com (MiskSMTP) with ESMTPSA id 4d05c9fa4e634756871e2fb0ed417ccd for ; Sat, 11 May 2024 13:32:18 +0000 Message-ID: Date: Sat, 11 May 2024 09:32:18 -0400 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: fce03f85c5bf - main - TCP can be subject to Sack Attacks lets fix this issue. To: Alexander Leidinger , Randall Stewart Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202405051310.445DAMEO069675@gitrepo.freebsd.org> <97c2eddd682d7347b0d26c0f042401bb@Leidinger.net> Content-Language: en-US From: rrs In-Reply-To: <97c2eddd682d7347b0d26c0f042401bb@Leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.65 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; NEURAL_SPAM_SHORT(0.74)[0.738]; R_SPF_ALLOW(-0.20)[+ip4:199.47.128.0/23:c]; RCVD_IN_DNSWL_MED(-0.20)[199.47.128.30:from]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:14618, ipnet:199.47.128.0/24, country:US]; RCVD_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[rrs]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[lakerest.net]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-main@freebsd.org]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4Vc69y5TvCz4nXp Alexander: In-line On 5/6/24 3:27 AM, Alexander Leidinger wrote: > Am 2024-05-05 15:10, schrieb Randall Stewart: >> The branch main has been updated by rrs: >> >> URL: >> https://cgit.FreeBSD.org/src/commit/?id=fce03f85c5bfc0d73fb5c43ac1affad73efab11a >> >> commit fce03f85c5bfc0d73fb5c43ac1affad73efab11a >> Author:     Randall Stewart >> AuthorDate: 2024-05-05 13:08:47 +0000 >> Commit:     Randall Stewart >> CommitDate: 2024-05-05 13:08:47 +0000 >> >>     TCP can be subject to Sack Attacks lets fix this issue. >> >>     There is a type of attack that a TCP peer can launch on a >> connection. This is for sure in Rack or BBR and probably even the >> default stack if it uses lists in sack processing. The idea of the >> attack is that the attacker is driving you to look at 100's of sack >> blocks that only update 1 byte. So for example if you have 1 - 10,000 >> bytes outstanding the attacker sends in something like: >> >>     ACK 0 SACK(1-512) SACK(1024 - 1536), SACK(2048-2536), SACK(4096 - >> 4608), SACK(8192-8704) >>     This first sack looks fine but then the attacker sends >> >>     ACK 0 SACK(1-512) SACK(1025 - 1537), SACK(2049-2537), SACK(4097 - >> 4609), SACK(8193-8705) >>     ACK 0 SACK(1-512) SACK(1027 - 1539), SACK(2051-2539), SACK(4099 - >> 4611), SACK(8195-8707) >>     ... >>     These blocks are making you hunt across your linked list and >> split things up so that you have an entry for every other byte. Has >> your list grows you spend more and more CPU running through the >> lists. The idea here is the attacker chooses entries as far apart as >> possible that make you run through the list. This example is small >> but in theory if the window is open to say 1Meg you could end up with >> 100's of thousands link list entries. > > Would it make sense to use a tree list (generic example: > https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/list/TreeList.html) > instead of a linked list additional/independently to what you committed? > We used to use an RBtree but this had CPU consequences that @gallatin and I worked on. Using this customized hash-list which is tuned for TCP sequence numbers saved us about 10% CPU IIRR over the RB tree. With these new fixes I think we are ok and I really don't want to introduce more overhead cpu wise :) R >> diff --git a/sys/netinet/tcp_stacks/sack_filter.c >> b/sys/netinet/tcp_stacks/sack_filter.c >> index e82fcee2ffac..fc9ee8454a1e 100644 >> --- a/sys/netinet/tcp_stacks/sack_filter.c >> +++ b/sys/netinet/tcp_stacks/sack_filter.c > >>  #ifndef _KERNEL >> + >> +static u_int tcp_fixed_maxseg(const struct tcpcb *tp) >> +{ >> +    /* Lets pretend their are timestamps on for user space */ >> +    return (tp->t_maxseg - 12); >> +} > > Typo in the comment? > > Bye, > Alexander. >