Re: git: fce03f85c5bf - main - TCP can be subject to Sack Attacks lets fix this issue.
- Reply: Gary Jennejohn : "Re: git: fce03f85c5bf - main - TCP can be subject to Sack Attacks lets fix this issue."
- Reply: rrs : "Re: git: fce03f85c5bf - main - TCP can be subject to Sack Attacks lets fix this issue."
- In reply to: Randall Stewart : "git: fce03f85c5bf - main - TCP can be subject to Sack Attacks lets fix this issue."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 06 May 2024 07:27:31 UTC
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 <rrs@FreeBSD.org>
> AuthorDate: 2024-05-05 13:08:47 +0000
> Commit: Randall Stewart <rrs@FreeBSD.org>
> 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?
> 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.
--
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF