Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Joe Touch <touch@strayalpha.com> Sat, 07 September 2019 17:35 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DC81200EC; Sat, 7 Sep 2019 10:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 cAwugEY1ow2D; Sat, 7 Sep 2019 10:35:45 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DD0541200C7; Sat, 7 Sep 2019 10:35:44 -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: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: 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=TZK9l8USKfMwJZQ7oyyPsKXlNzGNADksNNWyhrNBqzQ=; b=K+SA6alojh0bf0LeXCYRwl5/0 mmT5B9XOCY8rzLwIJsrHTXGZ7Aul7440e7xUqcIhZkXyeIrvhg52/yg7dsxDR8Wurou021eBmCjiz RQ7ogiPiGZGB5nRvzKd1zDYoVst11otL205A2GsvuuC1VQTnTcrIBZVN2i+MHQhSPb1A0EhfUXVIP ln3MXm6u9RUWG4QgKGXul8EEjZqkuEBgwj/nFL3LeSoFptkgfIKyB3ScCejwwDroVzGYayih4zr4Q Hhqu04kSVjf6xr8iBuO8qTkaF6unsklmNgjMBuL2FI3qpZqNWPwwogM4gxxPKnHy/OKhbTQXNarVE HjIGZzggg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59510 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1i6ecd-000RJ0-GR; Sat, 07 Sep 2019 13:35:43 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <5DAA16CC-791E-4042-95F6-65DA58D23EB8@gmail.com>
Date: Sat, 07 Sep 2019 10:35:37 -0700
Cc: Ole Trøan <otroan@employees.org>, "int-area@ietf.org" <int-area@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, Suresh Krishnan <suresh@kaloom.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA3B45A1-FFD2-49A5-B577-602065632F41@strayalpha.com>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com> <163CD364-2975-467A-8925-F114FFD9C422@employees.org> <E00B6159-2771-42D8-B5E8-7750E0B828DE@strayalpha.com> <3764D860-BC6F-441A-86EF-59E1742D7654@employees.org> <939AFA6F-4C75-4532-82DE-77D14ABC41ED@strayalpha.com> <5C51DCDC-4031-47D9-A28E-812D0E66EE35@employees.org> <5DAA16CC-791E-4042-95F6-65DA58D23EB8@gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
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/int-area/5YL8cH8cnTnklmX88BBORVi8N3Y>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Sep 2019 17:35:48 -0000

FWIW, in general:

With all the concern not detecting when frag fails, I’d like to point out that it’s equally impossible to detect when it works, e.g., when it happens on tunnels that start more than one hop away or more than one layer of intermediate headers.

E.g, PLPMTUD turns of frag *on the connected interface*. There’s no way to disable source fragmentation that happens later in the network (as it would at tunnel ingresses) or deeper in the stack (when what you think is your interface is locally tunneled over a layer you don’t even know about).

So *all* systems that try to backoff and use smaller MTUs are actually *already* testing whether fragmentation already works in those cases. Even if your app sends a 1-byte packet you have no idea that some set of layers inflates the headers (e.g., with signatures or key exchanges) beyond the MTU somewhere.

Thus claiming that “fragmentation must be avoided at all costs” is simply not even possible anyway. That’s why it’s reasonable to bring encapsulation up. It works - even when you don’t know.

Joe

> On Sep 7, 2019, at 10:25 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
> 
> Ole,
> 
>> On Sep 6, 2019, at 9:03 AM, Ole Troan <otroan@employees.org> wrote:
>> 
>> 
>> This document should not recommend IP in UDP in IP encapsulation to achieve end to end IP fragmentation for new applications.
> 
> The document doesn’t say that, nor is the document recommending this.  The current text Joe and I proposed to the list was:
> 
>  The risks of IP fragmentation can also be mitigated
>  through the use of encapsulation, e.g., by transmitting IP fragments
>  as payloads.
> 
> If this was recommended it would have included the word “recommended” or SHOULD/MUST terminology.
> 
> It’s only mentioning this, along with other approaches, as a possible approach for mitigating the problems.
> 
> Bob
> 
>