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

Mikael Abrahamsson <swmike@swm.pp.se> Sat, 04 August 2018 07:36 UTC

Return-Path: <swmike@swm.pp.se>
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 39817130DCB; Sat, 4 Aug 2018 00:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 N9qSMKrHX_tj; Sat, 4 Aug 2018 00:36:04 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 9C408130DC3; Sat, 4 Aug 2018 00:36:03 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E1FABAF; Sat, 4 Aug 2018 09:35:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1533368158; bh=tzYWZf8WTdfNh/QHJEl1wb+CSAE0/1FKrWP2kG+e2P8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bylciT2KHFRKuiSO8Uf7KT6naGYwic9cnsuImxILWOARkVEvZwDl9eiAbOiX7q08r wz1E6SCHZruUsI/5ofwULCVhXBX1mJowYN9p3EvxhGfbCDySzXbDwihWnvDmy7iiTp u4/sa0NuSO0ge7+rEZmPIrI7qxvPmO6UOHs2R3ww=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DD9F39F; Sat, 4 Aug 2018 09:35:58 +0200 (CEST)
Date: Sat, 4 Aug 2018 09:35:58 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Tom Herbert <tom@herbertland.com>
cc: Joe Touch <touch@strayalpha.com>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
In-Reply-To: <CALx6S35P=iKC8bJ+3cbNGu7ctyFMqngkOD7PGLgqN2u7jUEFQQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1808040928530.19688@uplift.swm.pp.se>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <CALx6S348jLsnHG3gp-mh9d4KJ1bROT3OcVz=XjwVgpv1aSsi_w@mail.gmail.com> <c271e9501b381c9be6ac1f3a0095a1d9@strayalpha.com> <CALx6S35DRCEjS5qaVkj2_FJzNumrkSfCZmoSJLueqqZs+pm9gw@mail.gmail.com> <240E40E2-81F9-4FAB-A271-825BD7AC6073@strayalpha.com> <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> <CALx6S35P=iKC8bJ+3cbNGu7ctyFMqngkOD7PGLgqN2u7jUEFQQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/nW-NSNF7L3xyz_bwyYF-td2BxEQ>
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: Sat, 04 Aug 2018 07:36:10 -0000

On Fri, 3 Aug 2018, Tom Herbert wrote:

> You could say the same the thing about extension headers, SCTP and DCCP, 
> and even IPv6 itself since it still doesn't work everywhere. The only 
> protocols an application can _rely_ on working is TCP over plain IPv4. 
> That is current LCD. If the advice is that applications only use 
> protocols they can rely on, then Internet is stuck in time.

I know plenty places where the only thing that works is TCP/80 and 
TCP/443. I know other places where the only thing usable is a SOCKS proxy. 
There are exactly zero protocols/ip version that an application can rely 
on. There are now operators which do not provide native IPv4 access, you 
have to use NAT64.

There is no such thing as a "sure thing".

> IMO, there should be a way for applications to use "alternative"
> features and protocols with a fallback mechanism if necessary. For
> instance, if the application had a priori knowledge that all nodes in
> a path supported fragmentation, then there should be no issue with it
> using fragmentation when sending on that path. Applying the car
> analogy, if I look at a map and don't see any unpaved roads on the
> route to my destination, then I can leave my four wheel drive all
> terrain vehicle at home and take my Ferrari instead. I think that a
> generalization of "Happy Eyeballs" might be a solution that discovers
> and maps what features and protocols work on what paths.

This is exactly what I am saying.

> Per the draft at hand, I think the advice to try to avoid fragmentation 
> is practical under the current circumstances. However, I think that 
> recommendation needs to be heavily qualified and scoped appropriately. A 
> general statement that applications shouldn't rely on fragmentation 
> cannot be interpreted as acceptance of non-conformant implementation or 
> as a free pass that middleboxes don't need to fix there stuff.

I would encourage everybody who wants the Internet to improve (and I 
support this), so get "someone" to fund work in freely available Internet 
access validation and testing. The best tool I know of is ICSI Netalyzr. I 
use this all the time to validate that what we come up with works for 
"everything". Yet, that tool is not complete and source code is not 
available. The CAIDA Spoofer project is also of interest.

So get someone with resources to allocate them to that work, that might 
actually improve things. Lots of people have no idea that their new 
fangled design of access solution doesn't work properly. I see this all 
the time "oh, we just turn on MSS adjust and everything works." "Err, what 
about fragmented IP packets and PMTUD?" "The what and the what???"

So this is not just about vendors and ISPs being evil and cheap, this is 
also largely of ignorance on all sides as well.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se