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

Joe Touch <touch@strayalpha.com> Fri, 31 August 2018 16:49 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 CD750130E51; Fri, 31 Aug 2018 09:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.779
X-Spam-Level:
X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 hox9OApUDkCs; Fri, 31 Aug 2018 09:49:10 -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 3345D127148; Fri, 31 Aug 2018 09:49:10 -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=SvQxbdvJuSWORX1nb0ySMbgtMjmZNuLdddgSyipLKaE=; b=hl396hyvHcZ6QAUTQXlrmdvyH aLaxT0kBpGromkd1CI1TQ0Kv0Q8VvhPJ6Y81mUV9IKYL77+AKkxMbBu5rLyqSv6sGVVFfLucTNLDt w5eg7r7Mm8IYX2jDwkURifCZoobOqs6jcZgwNyMmBX9Y43ewYUmVCcgw4by2iehhktP1RBeKtbCfm afkwtq8GS/MS0+1so/22syJNsVRYgCiuk5pNVpEYzsgk2TtOxFEA2Ol0mCbfoejs6tcuhTwX8QXm3 uOkTnI4sUyONUw0eafk2Nq4j+WMLFWPBUBJr9L059pOmuz3E3MouQV5gXIGGOs4gc70t7q+KaSl+5 RxmHMO1Kw==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54037 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1fvmbb-002nBu-I3; Fri, 31 Aug 2018 12:49:08 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <CALx6S35CKdPPZ68pPSLETJDAk4T7aV2FtV2H2ZBqiUEmyvGVbA@mail.gmail.com>
Date: Fri, 31 Aug 2018 09:49:06 -0700
Cc: Christian Huitema <huitema@huitema.net>, Toerless Eckert <tte@cs.fau.de>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4FA09FEB-9EA0-4338-AD9B-6E6051D9D328@strayalpha.com>
References: <CAF493D3-37A2-4A89-BA88-81567E5B88F1@huitema.net> <0A065EE6-463C-4C71-BF12-C0E5A1C51680@strayalpha.com> <20180826233350.kz3q6gzqbq36nn4r@faui48f.informatik.uni-erlangen.de> <810cea0d-809f-040d-bc79-7c7413cd99f2@strayalpha.com> <20180827023513.2bxjrk335al2lbvz@faui48f.informatik.uni-erlangen.de> <E02F3C36-ECE6-419E-A219-08A15AD98D13@strayalpha.com> <20180828220915.fpx5hi7nhl46ou6r@faui48f.informatik.uni-erlangen.de> <CALx6S35vbtYOiEx2opqSh1uq9rfgG5QHEQcb+ccWLMcwWZA-uQ@mail.gmail.com> <20180829002430.fojlqonvnqdrhw4z@faui48f.informatik.uni-erlangen.de> <af424b4b449c4a1459b69ed01a984e48@strayalpha.com> <CALx6S3563g___ZP03dD5+sV++ZH7U5yudqRX0Bf2744BbBxGgQ@mail.gmail.com> <2b6dd7006cca65525ac6240a8edffabb@strayalpha.com> <CALx6S37EiFo8C4K7fO=O0hNpStoaS6wBvM8jVowmJTQHW2=DHw@mail.gmail.com> <b40ed6c3fc32909e2df677cd999550dd@strayalpha.com> <CALx6S34WW4tj=UVmUBpREdeQ9Wshv=ZdTs3RLQLG9+nOr6ArjQ@mail.gmail.com> <11b0cc8e660ae288b283b6fb82f45b3b@strayalpha.com> <472d83e1-ea8f-2ac5-d 0fb-fb1c0301f07d@huitema.net> <046561A5-8B54-4E8B-B8D6-52E5F2784A9C@strayalpha.com> <CALx6S36P2GheGfV-mpPSY7Fh26LKsic4b-=2V=xkY6BmwtuQww@mail.gmail.com> <F23A907A-1930-43FB-B1DB-23855A8A6650@strayalpha.com> <CALx6S35CKdPPZ68pPSLETJDAk4T7aV2FtV2H2ZBqiUEmyvGVbA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
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/PAVlGWYIp8_bz8oU828TZ-PXKgI>
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, 31 Aug 2018 16:49:12 -0000


> On Aug 31, 2018, at 9:38 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
>> On Fri, Aug 31, 2018 at 8:56 AM, Joe Touch <touch@strayalpha.com> wrote:
>> 
>> 
>> On Aug 31, 2018, at 8:44 AM, Tom Herbert <tom@herbertland.com> wrote:
>> 
>> 
>> Joe,
>> 
>> There is an alternative: don't use NAT!
>> 
>> 
>> Agreed - that should also be part of the observations of this doc.
>> 
>> Yes, something needs to be done, but I argue that *until we have a worked
>> alternative*, we need to keep restating the fact - NATs/firewalls MUST
>> reassemble to work properly; where they don’t, the error is on them - not
>> the rest of the Internet for using fragments.
>> 
>> 
>> Reassembly could only be a MUST for NAT, not firewalls.
>> 
>> 
>> “or its equivalent"
>> 
>> NAT might be
>> required because of the identifier space issue, however we already
>> shown how a firewall can achieve proper functionality without
>> reassembly and to be stateless by forwarding fragments and potentially
>> dropping the first one that contains port information being filtered.
>> 
>> 
>> First, firewalls that port-filter need to do the same thing as a NAT in
>> terms of keeping state.
>> 
>> The fact that this might forward fragments that are never reassembled
>> is at best an optimization with unproven benefit.
>> 
>> 
>> ATM proved otherwise in numerous published studies in the late 1980s. Those
>> fragments compete for bandwidth further along the path; anytime they “win”,
>> that decision is not work-conserving.
>> 
> ATM from the 1980s? Is there any evidence that this is a real problem
> impacting users in this century?

Not until we instrument and measure these boxes. But that doesn’t mean a 30yr old KNOWN problem won’t repeat. 

> 
>> Note that keeping some state is already needed (if port-filtering) and that
>> - as you note - the state filtering need not be “perfect”. However, it
>> really ought to be SHOULD at least.
>> 
>> 
>> There is another case where in-network reassembly could be required
>> which is load balancing to a virtual IP address.
>> 
>> 
>> Any middlebox that uses state not available in all fragments MUST reassemble
>> or keep equivalent storage/state to process fragments appropriately.
>> 
> That requirement would include pretty much be applicable to every
> router on the planet that does ECMP based on hashing transport ports.
> Good luck fixing all of those to do reassembly :-)

They need to either reassemble or keep state that equivalently let’s fragments share paths - or the don’t do their job as advertised. Fortunately if they’re just picking among paths that all work it won’t blackhole the traffic. 

> 
> 
>> Like NAT though, in the long run I believe IPv6 offers a better
>> solution that would eliminate the need for VIPs.
>> 
>> 
>> That’s true right up until we end up in a world where (mostly) nobody
>> correctly uses flow IDs. Oh, wait - we’re already there…
>> 
> Huh? Who is not correctly flow labels?

Lots of endpoints don’t bother using them. 

> Besides, in IPv6 there's plenty
> of address space to that address sharing should be not needed and
> routing is sufficient without looking beyond IP header.

Address sharing is one reason NATs are used. Others are stateful firewalls (which also exist without NAT) and stateful forwarding (also exists without NAT). All require some level of work beyond the ‘cheap and dirty’ to actually get things correct. 

Joe

> 
> Tom
> 
>> Joe