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

Ole Troan <otroan@employees.org> Fri, 27 July 2018 21:16 UTC

Return-Path: <otroan@employees.org>
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 0B198130E52; Fri, 27 Jul 2018 14:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 EJLPU_exAc2A; Fri, 27 Jul 2018 14:15:59 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D700130E2F; Fri, 27 Jul 2018 14:15:59 -0700 (PDT)
Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 8824E2D4F9B; Fri, 27 Jul 2018 21:15:58 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <48288d35-4f75-21b1-5e4d-67071d5d5c45@gont.com.ar>
Date: Fri, 27 Jul 2018 23:15:55 +0200
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Tom Herbert <tom@herbertland.com>, "internet-area@ietf.org" <int-area@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA84B396-5E7E-42C1-9F95-A7AB6F8C8C3D@employees.org>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <0466770D-C8CA-49BB-AC10-5805CFDFB165@strayalpha.com> <8e5ba0b3-837e-02d1-d9d9-7c5e596c1774@gont.com.ar> <CALx6S34VMeLS7bqL4Zt0xZ+==5hUT7Q2=5m01a14mJ4B3J6G3g@mail.gmail.com> <50a1e177-6b37-b89a-2caf-5caf1cbc955b@gont.com.ar> <7e9260c4-462f-35bc-b962-cc85230058e2@gmail.com> <4D481FC7-BCE4-4F2D-AF16-7EF054D0AAA0@employees.org> <48288d35-4f75-21b1-5e4d-67071d5d5c45@gont.com.ar>
To: Fernando Gont <fernando@gont.com.ar>
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/j0jMHNlEEyIWdiLSql1_psWwBW4>
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: Fri, 27 Jul 2018 21:16:01 -0000


> On 27 Jul 2018, at 22:51, Fernando Gont <fernando@gont.com.ar> wrote:
> 
>> On 07/27/2018 10:28 PM, Ole Troan wrote:
>> 
>> 
>>> On 27 Jul 2018, at 22:12, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> 
>>> Fragmentation, (PL)PMTUD, extension headers, and innovative
>>> L4 protocols are very possibly not viable on the open Internet.
>>> At least, we can't assume that they will work on arbitrary paths.
>>> Sad but apparently true.
>> 
>> Hasn’t this been discussed ad infinitum in the ossification work?
>> If you want to generalize, nothing is guaranteed to work across an arbitrary path in the Internet. 
>> 
>> So what? This is part of a tussle and it would be making a self fulfilling prophecy for us to take all policy based filtering or other brokenness into consideration when designing protocols. 
> 
> I see your point. However, how do you engineer something that "works" if
> you ignore all brokenness etc.?
> 
> We do normally engineer protocols taking this things into account. e.g.
> 
> * PLPMTUD is a response to ICMP filtering
> * ECN had a backup mechanism that would switch to non-ECN for cases
> where e.g. firewalls were complaining about previously-unspecified bits
> * Quic is most likely implemented over UDP to be able to survive NATs
> and firewalls
> 
> 
> Yes, and one hand is not nice to have to account for all types of
> brokenness and filtering. OTOH, it would make any sense to enigneer a
> protocol that only works on paper.

To bring this back to the draft in question. Each type of “brokenness” needs to be considered on its own merits.

E.g brokenness as in network operator blocks all traffic from 1.0.0.0 is different from a poorly designed protocol. 

While fragmentation has issues because of network policy, the combination of PMTUD and fragmentation also exposes weaknesses in the design, which is something we should fix. 

Cheers 
Ole