IETF Logo Mail Archive

Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt

Yoshifumi Nishida <nsd.ietf@gmail.com> Wed, 24 February 2021 10:00 UTC

Return-Path: <nsd.ietf@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1159C3A130E for <tcpm@ietfa.amsl.com>; Wed, 24 Feb 2021 02:00:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haq1d4jCBsd4 for <tcpm@ietfa.amsl.com>; Wed, 24 Feb 2021 02:00:41 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35E03A130D for <tcpm@ietf.org>; Wed, 24 Feb 2021 02:00:40 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id w19so1513591qki.13 for <tcpm@ietf.org>; Wed, 24 Feb 2021 02:00:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1sv90p1Bbdmxoo2bqqFoLaYEfkXAMb7gy0rrSLMhVBg=; b=dpX0yc+A3ZuAxUl8ehoQnGGbzryHfCyEyzFCG6LwcT1qu9jj9KKmyjQQICiFYFIIz9 FY4c84alVhNvaFdjK+mbOYEDsUqL145WHUVrLu2CIr0RT6bAa+nf24EXSYF+yyuSHoi8 kH2iQ6lmLJ1cicaJUZ13txeUN12d3Bfv9O+h9Tbx0bOhw22VxdGrC/ulW1pTJSe7wJG4 OW22lWt8pHgAEKB7MR9mCsueArw/6Dd22SQoEsvNEQUeHidGJcoy4n5r3cqWY7g6sP4C Tt5JITjfIHNwclycGXjmZHxI2wQCY5JpkL5wXvWzEaezMLkjFm4uZNVEwK/Cu9d0L1IL tEVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1sv90p1Bbdmxoo2bqqFoLaYEfkXAMb7gy0rrSLMhVBg=; b=BL8pH+uKiWRciFVl6ZV16YXcBKnKEoAg9TeFeQgxckrRH5kUW2aDJZcP26/Fmlw1Th Sx5ZnJuJMxaNwRMeGbQw8e6p3rrn2ydxBMU1AgFbTqWiCV3HzqDxLF+ZwBhxb9py/+r7 yC1oHwfku6CCBpETA0FWSDhn0JTkLvINNfOI+k8tXSJQn+pv4l5H0smnUD4XBmqICKM8 VhIErxWTz2/lb6n9b6AZvTw+NM8aVQlrVlG//eNtZ8AqQElD24BpEXPPAJL+MPUuVSDV inNECVhrqcJzOXdZ8JgqJZIaTOcJDn/92PSH9/t3V0gPwYXF6lBsecvmn1H0AHW7eNeN BQJA==
X-Gm-Message-State: AOAM531bOJRQGxVWEOkxJKKnzp9rAR87g/AJwHwXrQaLZ4Ru+09oiIqx YYz1+/MgFT26TojN7gZ26s+Qyf23tVb39V69V2ygyS3y
X-Google-Smtp-Source: ABdhPJyQHhTwrC6A+FEExhS98YxbKrZRUGmCo2+Ze/ah7EVpvgsP8Bhh0UAQKHXnzyc/3BmY5oOfYtxmqc6u/z400Aw=
X-Received: by 2002:a05:620a:941:: with SMTP id w1mr765940qkw.484.1614160839801; Wed, 24 Feb 2021 02:00:39 -0800 (PST)
MIME-Version: 1.0
References: <161233469809.31214.294457730576935197@ietfa.amsl.com> <CAAK044QYBiGXKm+D+=edc8TWhjzAadBxER5VRFmJOdW8hdXFKg@mail.gmail.com> <244FE3E7-7B83-4884-B11B-028F7167B549@strayalpha.com> <CAAK044RKtJ_PpDXH9pmS90wqUZNK9unDggiDjVLUBK00cxhYnA@mail.gmail.com> <8C6762C8-2A22-4CC7-AF53-1D13FC3DC268@strayalpha.com> <C591EED6-210A-4AEB-94D6-D3B77130596E@strayalpha.com> <CAAK044SxMF1p-BzyOYWYkhYYrToLg+8Ybx8ZB-GeADGkayexGQ@mail.gmail.com> <274785c8-004e-71bb-828b-8d8d0ee95af8@gmx.at> <YCG4EQ9BCAvucdN1@sorcerer.cms.waikato.ac.nz> <04723570-93E7-4BB8-821E-BC3672A42F15@comsys.rwth-aachen.de>
In-Reply-To: <04723570-93E7-4BB8-821E-BC3672A42F15@comsys.rwth-aachen.de>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Wed, 24 Feb 2021 02:00:28 -0800
Message-ID: <CAAK044Ti_M=KaqVcq8d_=AHZsQuWRZcoGtF8gFo+m-DKW+LJFA@mail.gmail.com>
To: Jan Rüth <Jan.Rueth@comsys.rwth-aachen.de>
Cc: Matthew Luckie <mjl@caida.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000777c6305bc121b51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/VPYJOaHgvZ4xTNiY_jWei7U4Dak>
Subject: Re: [tcpm] I-D Action: draft-nishida-tcpm-agg-syn-ext-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2021 10:00:43 -0000

Hi Jan,

Thanks for providing very interesting information.
I am guessing the ratio is not very high, but it's a good proof that we've
still seen such nodes. (probably connection split middleboxes as you
mentioned)
Thanks for sharing!
--
Yoshi

On Mon, Feb 22, 2021 at 2:46 AM Jan Rüth <Jan.Rueth@comsys.rwth-aachen.de>
wrote:

> Hi everyone,
>
> maybe I can add to the measurements that Matthew cited.
> We performed these only once. But we are doing other measurements that we
> do more frequently.
>
> From these I can report further numbers that we never got around to
> actually publish.
>
> We look for TFO support on port 80 and we send TFO cookie requests to all
> of IPv4.
> We get roughly 3.2M valid replies with TFO cookies (as of late 2019),
> which rose from 500k (mid 2017).
>
> Regarding the mirrored options, we see around 70k - 80k empty cookie
> replies (essentially, we get our cookie request back) that have the same
> behavior as outlined in Olivier’s blogpost, this number is rather stable,
> sometimes 10k more or less.
> This behavior is focussed on IPs residing in Chinese autonomous systems.
> Our assumption has always been that this mirroring is performed by some
> middlebox and not an end-host.
>
> If there is interest, I can perform these measurements with an unassigned
> TCP option number.
>
> Best
>  Jan
>
>
> > On 8. Feb 2021, at 23:15, Matthew Luckie <mjl@caida.org> wrote:
> >
> > Hi Richard,
> >
> > On Mon, Feb 08, 2021 at 10:46:45PM +0100, Scheffenegger, Richard wrote:
> >> Hi Yoshi,
> >>
> >> Sorry to nitpick - in your draft, you mention that some hosts reflect
> >> back unknown tcp options, which is why you are using different GID
> >> mappings between SYN and SYN,ACK.
> >>
> >> I did read about this behavior concerning TCP header flags / reserved
> >> bits - but have not come across a paper where this behavior is described
> >> for unknown TCP options (or I may have missed that aspect in the various
> >> studies around TCP option investigations done by MPTCP and other
> groups).
> >
> > There is some discussion of systems that seem to reflect TCP options
> here:
> >
> >
> http://blog.multipath-tcp.org/blog/html/2018/12/19/which_servers_use_multipath_tcp.html
> >
> > Matthew_______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

v2.23.0 | Report a Bug | By Email