Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Joe Touch <touch@strayalpha.com> Sun, 26 August 2018 18:39 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 AC360130DEA; Sun, 26 Aug 2018 11:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 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, T_SPF_PERMERROR=0.01] autolearn=ham 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 SokIflkc4XRH; Sun, 26 Aug 2018 11:39:02 -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 EA9F9130DD3; Sun, 26 Aug 2018 11:39:01 -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=t3ocFqRH03CGoNnVkEW5FzOyJj0cXfZq8lGIRP00JQU=; b=0bCGzIYFmOl3u80X/dDHFOC55 4fb66DDONsbT4bmgNRCMkXKmuIaQGcvbu8pDrwV2EsZqUuXIvfleeqJXzOC/SLp6C0vb9ilq3iWiM iVe00a+c4ZSqZDyNnZRj9ogkYyrG+ON7RY6DhW8odSw+NINn6Bydsa2jivJO51+r61y8fD+DOZPVy gfSKmzlf/om4edHshS3yHJLGrvTPlVvgb53CoaqgAaAK5naFnJnfilx/wNfhovyxe16/NKXe1SaA1 n0HVMyXorh4PyFtD+dcDhYn+0gCPk6+1m2vpFyJAM441jRiaHGwfB/y5Qr12FZ01si5Graorjj1wZ tPC/AI7Bw==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60729 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1ftzwA-0009E2-Rz; Sun, 26 Aug 2018 14:38:59 -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: <CAF493D3-37A2-4A89-BA88-81567E5B88F1@huitema.net>
Date: Sun, 26 Aug 2018 11:38:57 -0700
Cc: Tom Herbert <tom@herbertland.com>, Toerless Eckert <tte@cs.fau.de>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <538A6193-2BD7-4E72-BD28-736B81F97B33@strayalpha.com>
References: <CALx6S36Ef3t7Axmx9hg994DHpVM=NdW-7ygf89E==gL4XKrkQg@mail.gmail.com> <5E21B3C1-0420-404C-9824-9B7E5A850BC5@employees.org> <CALx6S34qmKngi3hK_PVrJA1DMa5kfaLww3jfqRKN=up5v0Y0Ww@mail.gmail.com> <8D23C8B1-C2DA-4A8B-A2BE-8CCF6233B3A5@strayalpha.com> <D1D5EDCE-7C43-4CD8-947C-AA43CDB18892@employees.org> <1B04E207-08FA-400F-BBED-67379FEFD64E@strayalpha.com> <137751A3-7C52-4CCF-AE9C-B99C4A85EFC1@strayalpha.com> <alpine.DEB.2.20.1808021749020.19688@uplift.swm.pp.se> <CALx6S35kw2dodgG2L3LE3A5y8RYEXy6izQWgrQTwg7-yPqpzOg@mail.gmail.com> <alpine.DEB.2.20.1808030857370.19688@uplift.swm.pp.se> <20180825032457.ol5rlrr7h2kqi6px@faui48f.informatik.uni-erlangen.de> <CALx6S35-n_ROEZv0NReVEWTUhnyc25SNJb5DaeqtnxPAPk6QjQ@mail.gmail.com> <CAF493D3-37A2-4A89-BA88-81567E5B88F1@huitema.net>
To: Christian Huitema <huitema@huitema.net>
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/-l0Y78AkW1fn8vOHq_j7A-GUAu4>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
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: Sun, 26 Aug 2018 18:39:04 -0000


> On Aug 26, 2018, at 10:31 AM, Christian Huitema <huitema@huitema.net> wrote:
> 
> It seems that the biggest obstacle to fragmentation are NAT and Firewall. They need the port numbers in order to find and enforce context. NAT might be going away with IPv6, maybe, but firewalls are not.
> 
> Have considered strategies that move the port number inside the IP header? For example, have an UDP replacement for IPv6 that does not have any port number in the new UDP header, and relies instead on unique IPv6 addresses per context?

NATs already have what they need to do the proper job - they need to reassemble and defragment using unique IDs (or cache the first fragment when it arrives and use it as context for later - or earlier cached - fragments). There’s no rule that IP packets that are fragmented MUST have a transport header both visible (not encrypted) and immediately following the IP header. 

Firewalls are just delusions; the context they think they’re enforcing has no meaning except at the endpoints; it never did.

Using part of the IPv6 space for this solution would then break per-address network management (different UDP ports would use different IPv6 addresses, presumably).

The “disease" is that NATs don’t reassemble (or emulate it). It’s not useful to try to address the symptoms of that disease individually.

Joe