Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Joe Touch <touch@strayalpha.com> Fri, 01 June 2018 19:04 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 06A0C12DA4E for <int-area@ietfa.amsl.com>; Fri, 1 Jun 2018 12:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 quicbApKjWUs for <int-area@ietfa.amsl.com>; Fri, 1 Jun 2018 12:04:47 -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 9906D12DA4B for <int-area@ietf.org>; Fri, 1 Jun 2018 12:04:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding: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=IuWq1TPc6QPTHeSJSFLQQAjv2sazl/KH6MFhIEQn7uw=; b=XsKyS6ok/UoTwXxsnP76OyzWL JwvYwz0JBzniqmUlp/UPnY5eUhCYjhiK3p22jVkFAf9R0X/6gC55DVqFxSaz2H5okhmJ2T4q3PdKI nkCq3zjy++UOBWXsdQNohpQQUfI3ZMXERI/3qQPErBP+070r4ur8Pdj6cNPO4+onqTuVIm4zsuPiw YJpmYNUd18+GE3XNmu6KzXbdW1oiv45SpQuRHiGtmm2CypzU4kxWtdbqSRcxI0qJc8q5OV5JdgSDa vqZ0eyGxFvDHiesDexyUS3NEYSLLRvIJSaY52q/4Olj9+P5VviQZ/e2KecQrKsY6rT6tKBYbrKvtY wBeV+5ZXg==;
Received: from [::1] (port=58086 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1fOpLx-000Xss-VD; Fri, 01 Jun 2018 15:04:46 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_e8795e3ca0c0579a321233068a22bb35"
Date: Fri, 01 Jun 2018 12:04:45 -0700
From: Joe Touch <touch@strayalpha.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Ron Bonica <rbonica@juniper.net>, int-area@ietf.org
In-Reply-To: <alpine.DEB.2.20.1806011150370.17103@uplift.swm.pp.se>
References: <BLUPR0501MB2051C0DCCE28384FCD08F7C4AEDA0@BLUPR0501MB2051.namprd05.prod.outlook.com> <57DFBADC-9064-4DF8-AAC1-8C0DBB41D8A6@strayalpha.com> <76F3B3E5-6FA8-4A27-815C-32415E0D7CB6@gmail.com> <FCE8FC77-3A30-4EE3-B6A1-35969E7DD1E2@strayalpha.com> <SN6PR05MB424048AD14382C38788DE158AE630@SN6PR05MB4240.namprd05.prod.outlook.com> <855AFF4E-F2B7-4C35-ABA5-EFC571AF90F9@strayalpha.com> <alpine.DEB.2.20.1806011150370.17103@uplift.swm.pp.se>
Message-ID: <15571055d14a388c9c77abc845e95e87@strayalpha.com>
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.3
X-OutGoing-Spam-Status: No, score=-0.5
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/4GY5CDj9cLM9C2AEcAhp-dHY9hI>
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Jun 2018 19:05:04 -0000

On 2018-06-01 02:54, Mikael Abrahamsson wrote:

> On Thu, 31 May 2018, Joe Touch wrote:
> 
>> I disagree.
>> 
>> UDP fragmentation has its benefits and uses, but should not be required when a transport layer isn't needed - e.g., for IP tunneling.
>> 
>> Fundamentally, IP fragmentation is fragile for only a few reasons:
>> 1) the ID space is small (which shouldn't matter unless there is a very large amount of reordering)
>> 2) loss of fragments creates inefficiencies (true, but routers can fate-share fragments they drop sometimes, just as was eventually done for ATM AAL5)
>> 3) in-network devices can't find transport ports in some fragments, causing problems for NATs, policy filters and firewalls, etc.
>> 
>> Of these, my view is that #3 is the only reason actually driving a claim of fragility - and all it tells me is that "the Internet is fragile when devices don't follow the rules".
>> 
>> I do not think it is appropriate to validate that conclusion.
> 
> You're fundamentally right, unfortunately operational reality adds lots of more points to your list, meaning the end outcome is that IP fragmentation doesn't work well in real life.
> 
> I am as opposed to letting bad practices win as you probably are, but I also don't think this is fixable. This means applications need to have a mode where they do not rely on IP fragments for basic operation.

I am OK if the conclusion says: 

1) this is a bug/incorrect implementation that needs to be fixed 
2) in the meantime, users (not just apps) should consider using other
ways, esp. if their system cannot detect whether the use of IP fragments
fails 
3) #2 should not be interpreted to let implementers off the hook for #1 

I.e., IP fragmentation should not be deprecated; its avoidance should
not imply that deprecation, and vendors are responsible for the bug that
not supporting fragmentation represents. 

Joe