IETF Logo Mail Archive

Re: [tcpm] Exceeding value in MSS option?

Joe Touch <touch@strayalpha.com> Mon, 26 October 2020 14:24 UTC

Return-Path: <touch@strayalpha.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 900BF3A0BB9 for <tcpm@ietfa.amsl.com>; Mon, 26 Oct 2020 07:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 IcJAS_EWfUGK for <tcpm@ietfa.amsl.com>; Mon, 26 Oct 2020 07:24:41 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 106113A0BB6 for <tcpm@ietf.org>; Mon, 26 Oct 2020 07:24:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type: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=r3rkoI7uJG/wfEuJ0qQdhIa8a/PUmOHFSvUwpi/aRwc=; b=wK4RaclrRti8JL3kMsPMCD8PNQ UQOFO9pu5n4cC/xbs+SnIAo+0JkYW4bsNsNxtr364ZKua64h7G7IPf/stbaxS36Cvs7GXK+toXIjk rO+vV0k9GtyTaY2upmYkt19ef0W5fY/2G4uySoCKY8vgDvEFAwF3/yk9X7GDuqpEbK7aNmQGNlwLH RXIXx7ZeiGSwtscOLaIM2Kkk1IJ1nadt4ASKduqo63q4siOMvLeLDnUMP2ppr8lIc04yAMJ/ryTXo +CGrMj7mOzIIXF5CHppnCwgN8iX2CwcOKfr7CPfZLfa/VBF3CI2BCLUOm6LLoGKM127cihcAepGmz xjkmdGuA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55371 helo=[192.168.1.13]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1kX3QH-003iLK-Nx; Mon, 26 Oct 2020 10:24:38 -0400
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <9C8105AE-483B-463F-8EBC-D00199974976@lurchi.franken.de>
Date: Mon, 26 Oct 2020 07:24:32 -0700
Cc: Frode Kileng <frodek@tele.no>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Message-Id: <64E62006-FF20-42E0-83CB-12C622135251@strayalpha.com>
References: <9C8105AE-483B-463F-8EBC-D00199974976@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
X-Mailer: iPad Mail (18A8395)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/KltmzbL5vQ544No8N20slKAdYfs>
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: Mon, 26 Oct 2020 14:24:43 -0000


> 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. 

Joe

v2.23.0 | Report a Bug | By Email