Re: [tcpm] Exceeding value in MSS option?
Steven Sommars <stevesommarsntp@gmail.com> Tue, 27 October 2020 21:51 UTC
Return-Path: <stevesommarsntp@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 02F713A1455 for <tcpm@ietfa.amsl.com>; Tue, 27 Oct 2020 14:51:46 -0700 (PDT)
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 9Qfb92APEwWi for <tcpm@ietfa.amsl.com>; Tue, 27 Oct 2020 14:51:43 -0700 (PDT)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 ACFB73A14CC for <tcpm@ietf.org>; Tue, 27 Oct 2020 14:51:43 -0700 (PDT)
Received: by mail-il1-x135.google.com with SMTP id n5so2898796ile.7 for <tcpm@ietf.org>; Tue, 27 Oct 2020 14:51:43 -0700 (PDT)
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=U8yXjY2ZRi08e41fr7HLNrkEH4R9UO6qRmMFQarwDCU=; b=rp0x3Q3p2TXA9adoX0kuYIbr9xOrw9xnfBVYNd5YLyjzf5I75n0olI0CX5pVM7k7CL fEIPb+P4KEO/oGmEeZi/dwfefoqCCNY1OWk41mNOcCBUfoqUQwRt+KF5NqT5pe/eI1In /yWYI3CuV/zBdcAYwycflQcufqI8x2oMIKx3N0V8tSF/X7eGthoP7yd/o7cmXu7e+XiW gbmpyRxsg7nR1MiBv0zpQXzs4aUXlUOfJoHY8CM5rSJgC7P491llu270WlKVk2SEierV EKMCj3F7skxALwXF0a+GZDh4lOkG5kRbYUI+7Kmn4Ywh3Nxp9ID/YoPMF6+WmnjE2arw E94w==
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=U8yXjY2ZRi08e41fr7HLNrkEH4R9UO6qRmMFQarwDCU=; b=LAxSoh54pp4Pe5J8iXHvsgziYqK7dTdEV4OQEDWedXA4Ih4qv7/FEi0JOvU7pK6oh5 U6JgQ1lOuNDlfLe5y7qQ51FePzgtFyFrpSfc0k9F/Snm9EtaDpewvKiaPUsGZjUw4Hgg rriDZC76FcStaHmV9D4VVQtRFaisPQImf2vlAbtwn/hmziaSKKrtzCGM9kFIgaAOl7sl BeWIq0P/KRq/3eeOxsO7VT0WF/l2T67KnfcbROeVPIgpu7IbjSNOk0pBK5bgdkL5mzFa pQp0Nukdgb7L8zgViDlfFE5/7F6z0mj6u+c7gyWQmHQZvWJyu7LEsfAqUhs6OiossIrj OCFg==
X-Gm-Message-State: AOAM531woqKHYPWBx9SmLHv1giSH3R2QCKlUWQLxh4JPL3H4BcbJii9J Mu5qu4qwjk4EcqM/5BxnIK6XqkblvXOkBRoRc/CWwfCfZuQ=
X-Google-Smtp-Source: ABdhPJxpYGc2SvQC6snW4nIrFhsqDuWcC6e2ikGj5lHZCSADBeKq+g1bJSE9+VwBH5XRNCkJmPMwZ0A54eUWE6dAGdc=
X-Received: by 2002:a05:6e02:786:: with SMTP id q6mr3663457ils.208.1603835502836; Tue, 27 Oct 2020 14:51:42 -0700 (PDT)
MIME-Version: 1.0
References: <4b50b01f-1e39-82c5-1488-1063ef4f0066@tele.no> <8B85DC62-8EB7-45F3-A57A-668D575A0491@strayalpha.com> <77ae4653-ff07-ae23-aba3-e0660791a2f9@tele.no> <EA4F0D4F-C5F6-437C-919B-102AC0231DED@strayalpha.com>
In-Reply-To: <EA4F0D4F-C5F6-437C-919B-102AC0231DED@strayalpha.com>
From: Steven Sommars <stevesommarsntp@gmail.com>
Date: Tue, 27 Oct 2020 16:51:31 -0500
Message-ID: <CAD4huA4ck0TGD6SHa3zw-JnTLnkvM5rHq1EWNNSDaRHsmRpm8A@mail.gmail.com>
To: Joseph Touch <touch@strayalpha.com>
Cc: Frode Kileng <frodek@tele.no>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006cc22c05b2ae0d07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/XAP1OTKwst2SzlJsws_4Bu3swso>
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 21:51:46 -0000
Much of today's mobile traffic IP traffic is GTP (GPRS Tunneling protocol) tunneled within the core network (per the 3GPP specifications). There can be one or two back-to-back bidirectional tunnels between the base station and the PGW/GGSN (gateways to the Internet). The 3GIP IP MTU requirements weren't very clear at the time, but we interpreted the requirement to be a 1500-byte subscriber IP MTU. For those portions of the core network that used IP/ATM (AAL5), transport of a ~1540 byte tunneled packet (IP MTU + about 40 bytes for GTP/IPv4 header) was usually provided. [I'm using 40 bytes for simplicity, could be smaller or larger.] Ethernet was cheaper and more readily available, so transport of 1540 byte packets was needed. [I'll skip other headers that are often used: VLAN, MPLS, etc.] The cellular carriers often leased IP/Ethernet transport and at times only ~1500 byte MTUs were available. If the IP/Ethernet transport network supports sufficiently large IP MTUs, life is simpler. If not, how does one stuff 1540 bytes into a 1500 byte packet? - Avoid core network IP fragmentation. I'll list some of the options & their drawbacks. - Resegment TCP (e.g., proxy). === many drawbacks - Fragment subscriber packet (ignore DF bit) === many drawbacks - Drop packets that would require fragmentation (PMTUD). === PMTU black hole was an issue - Signal to the subscriber device that the IP MTU should be reduced. === This was proposed in 3GPP starting in the late 1990's, but I don't know what happened. - Insert/Alter TCP MSS option during SYN/ACK. === Not strictly legal, but it typically worked well. - Implement core network IP fragmentation/reassembly. Done correctly this is undetectable by the subscriber- or server-side. However, - Transport network bandwidth requirements increased slightly. - IP reassembly can be resource intensive. [I've seen performance drop by over 100x when IP reassembly was needed on some older hardware.] - IP reassembly may fail. - Fragmentation and reassembly may trigger missequencing. Is TCPM the right forum for discussing these end-to-end principle related items? RFC3234 has a somewhat dated (2002) middlebox taxonomy. On Tue, Oct 27, 2020 at 10:25 AM Joseph Touch <touch@strayalpha.com> wrote: > So the real question is why tunneled packets didn’t trigger the same issue > - isn’t it? > > Or are you implying that tunneled traffic shouldn’t be supported? > > There are deeper issues going on here. We should avoid being glib about > how “best” to do things that shouldn’t be done in the first place. > > Joe > > > On Oct 26, 2020, at 11:35 PM, Frode Kileng <frodek@tele.no> wrote: > > > > 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 > >>> > >>> > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >
- [tcpm] Exceeding value in MSS option? Martin Duke
- Re: [tcpm] Exceeding value in MSS option? Joseph Touch
- Re: [tcpm] Exceeding value in MSS option? Joseph Touch
- Re: [tcpm] Exceeding value in MSS option? Michael Tuexen
- Re: [tcpm] Exceeding value in MSS option? Martin Duke
- Re: [tcpm] Exceeding value in MSS option? Joseph Touch
- Re: [tcpm] Exceeding value in MSS option? Joseph Touch
- Re: [tcpm] Exceeding value in MSS option? Gorry Fairhurst
- Re: [tcpm] Exceeding value in MSS option? Mirja Kuehlewind
- Re: [tcpm] Exceeding value in MSS option? Gorry Fairhurst
- Re: [tcpm] Exceeding value in MSS option? Scharf, Michael
- Re: [tcpm] Exceeding value in MSS option? Scharf, Michael
- Re: [tcpm] Exceeding value in MSS option? Michael Tuexen
- Re: [tcpm] Exceeding value in MSS option? Joseph Touch
- Re: [tcpm] Exceeding value in MSS option? Scharf, Michael
- Re: [tcpm] Exceeding value in MSS option? Michael Tuexen
- Re: [tcpm] Exceeding value in MSS option? Gorry Fairhurst
- Re: [tcpm] Exceeding value in MSS option? Markku Kojo
- Re: [tcpm] Exceeding value in MSS option? Michael Tuexen
- Re: [tcpm] Exceeding value in MSS option? Joseph Touch
- Re: [tcpm] Exceeding value in MSS option? Martin Duke
- Re: [tcpm] Exceeding value in MSS option? Joe Touch
- Re: [tcpm] Exceeding value in MSS option? Frode Kileng
- Re: [tcpm] Exceeding value in MSS option? Joseph Touch
- Re: [tcpm] Exceeding value in MSS option? Frode Kileng
- Re: [tcpm] Exceeding value in MSS option? Michael Tuexen
- Re: [tcpm] Exceeding value in MSS option? Joe Touch
- Re: [tcpm] Exceeding value in MSS option? Frode Kileng
- Re: [tcpm] Exceeding value in MSS option? Joe Touch
- Re: [tcpm] Exceeding value in MSS option? Frode Kileng
- Re: [tcpm] Exceeding value in MSS option? Joseph Touch
- Re: [tcpm] Exceeding value in MSS option? Steven Sommars
- Re: [tcpm] Exceeding value in MSS option? Joe Touch