Re: [tcpm] Exceeding value in MSS option?

Frode Kileng <frodek@tele.no> Tue, 27 October 2020 06:35 UTC

Return-Path: <frodek@tele.no>
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 CE78D3A15C8 for <tcpm@ietfa.amsl.com>; Mon, 26 Oct 2020 23:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level:
X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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=tele.no
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 BmsTmPrwJak4 for <tcpm@ietfa.amsl.com>; Mon, 26 Oct 2020 23:35:21 -0700 (PDT)
Received: from gorgon.tele.no (gorgon.tele.no [IPv6:2001:700:800::70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2426F3A15EC for <tcpm@ietf.org>; Mon, 26 Oct 2020 23:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tele.no; s=20180731; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4lJvQaIGuSSElGjSJy3RVAvRr/M9DiwMXbuuyhuMQOM=; b=aZ4aZahEQct3eM6vP7NGn3CZtW HEseaYeA5y6FKsnGL+bYonqOR93Vx56LnRj2IEFx30BBTiTtRS/wrFp9laF3pmPyt1cwc9SFV5o4S H5VopNDW7MCuDLUE12F4pKkuJoWh+rWLVnZf1W4P0z7IDOTdM4/H0bk2SyGtV3sls06j+q1XIOL1l xKHRc6gnirE1Ecrppx3VGQNcUXWTCTLdux39cVg2dTRvre4sYi+qNIspbpxOVTJhuQ6KncH2Rr3lO mvKDc7Rx+M20tMpSVJmukTBYJ16wACJhT1LUNEv0LE9MveWZHDx7eTx+t9EE6kHeUdnhk2VMoaJHg AoY4FbfQ==;
Received: from pilt2.tele.no ([2001:700:800::21] helo=[127.0.0.1]) by gorgon.tele.no with esmtp (Exim 4.92) (envelope-from <frodek@tele.no>) id 1kXIZb-0005qc-Of; Tue, 27 Oct 2020 07:35:11 +0100
To: Joe Touch <touch@strayalpha.com>
Cc: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
References: <4b50b01f-1e39-82c5-1488-1063ef4f0066@tele.no> <8B85DC62-8EB7-45F3-A57A-668D575A0491@strayalpha.com>
From: Frode Kileng <frodek@tele.no>
Message-ID: <77ae4653-ff07-ae23-aba3-e0660791a2f9@tele.no>
Date: Tue, 27 Oct 2020 07:35:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <8B85DC62-8EB7-45F3-A57A-668D575A0491@strayalpha.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/C4csXfXZpoZdWRJAqo47eEGfVFQ>
Subject: Re: [tcpm] Exceeding value in MSS option?
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: Tue, 27 Oct 2020 06:35:24 -0000

I do not defending this practice, just trying to communicate their 
rationale and that there may be other more important fights out there. 
But I do understand that operators are cautious as I've seen an example 
of how fragmentation triggered an anti-DDoS feature in a firewall 
causing traffic from a large number of mobiles to halt.

Frode

On 26/10/2020 17:55, Joe Touch wrote:
> Given how many of us are using VPNs, it’s a shame they don’t work without this.  I guess users of those nets have to shut down their Skypes and other services over VPNs, because, according to you, it doesn’t work.
>
> Joe
>
>> On Oct 26, 2020, at 8:46 AM, Frode Kileng <frodek@tele.no> wrote:
>>
>> On 26/10/2020 15:24, Joe Touch wrote:
>>>>> On Oct 26, 2020, at 2:35 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>> On 26. Oct 2020, at 08:52, Frode Kileng <frodek@tele.no> wrote:
>>>>>
>>>>>
>>>>> On 23/10/2020 17:11, Joseph Touch wrote:
>>>>>>>> On Oct 23, 2020, at 1:37 AM, Frode Kileng <frodek@tele.no <mailto:frodek@tele.no>> wrote:
>>>>>>>>
>>>>>>>> Although maybe not  a "general problem",  a study of MSS middlebox manipluation in  23 European and Asian mobile networks did reveal some issues:
>>>>>>>>
>>>>>>>> - 20 of 23 networks always inserts MSS.
>>>>>> That IS a general problem, FWIW.
>>>>>>
>>>>>> Besides being published, it should also be reported to the operators of those networks as violating TCP specs.
>>>>> Do you mean as in "layering violation" or is it explicitly stated in an RFC that MSS clamping is not allowed.
>>>> I think we should differentiate two issues:
>>>> (a) a middlebox which reduces the MSS already in an SYN/SYN-ACK segement.
>>>> (b) a middlebox which adds an MSS option, which wasn't there in the SYN/SYN-ACK segment.
>>> You can if you want; I do not. Both are violations of TCP processing, whose headers aren’t permitted to be altered in flight. Saying it’s for the good of the endpoints doesn’t change the issue that it should be reported and fixed as an error.
>>>
>>> If TCP is given an MSS by the other end of a connection and packets don’t get through, it can always lower the segment sizes it sends - the is what PLPMTUD does.
>> I think there may be other more important fights out there than convincing ~90% of the world mobile network operators and their vendors that a practice solving potential black-holing and typically improves performance should stop because it's a layering violation. For example that 2/3rd of the mobile networks I tested have a TCP Proxy and over 70% of such networks breaks MPTCP, TFO or ECN.
>>
>>
>> Regards
>>
>> Frode Kileng
>>
>>