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

Tom Herbert <tom@herbertland.com> Fri, 31 August 2018 16:38 UTC

Return-Path: <tom@herbertland.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 32E4E127148 for <int-area@ietfa.amsl.com>; Fri, 31 Aug 2018 09:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 qavbaRd7xleU for <int-area@ietfa.amsl.com>; Fri, 31 Aug 2018 09:38:07 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52576130E20 for <int-area@ietf.org>; Fri, 31 Aug 2018 09:38:07 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id g44-v6so15159403qtb.12 for <int-area@ietf.org>; Fri, 31 Aug 2018 09:38:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0m90BAwf6advxlqaRXW5VFruqZ3QOii/lofQjCRBxcM=; b=aN6kFJuQSsuO7unWyflc0C4C+ctEr8pfXy8wHCgFUxpSAIsIPNSkab6V0CEGNdJEz0 PwV5AgIWTp5yh8+6ofQOaJp2+sC+MlHbyZ5GoNuK5mZEwX9szlBU77hVN9m2/OzLW5AR AXJSHMh44+ghKKqkNCo+jPnn6Cdq/FYxY32xdMVaopZDxoy+x3JT2XALwFml6PWwS85n nDzALiLyxeJnrtknlBDX2zTpwZofRup5ulhUqxXP7+kwiuONQTmmhjmWUMIa5anMDUkE 90tN51QRvY60Xp6x9SZnSOhlwqjFp9AarVaGVR3sOGaDo5Yt8broWlwKszREGI0X4HCe t+vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0m90BAwf6advxlqaRXW5VFruqZ3QOii/lofQjCRBxcM=; b=eedx88tOppCLETUAgJkdyv+zy6nl2BRP4AUMj2f7yOj6vE/3d2nijq9SZqh//gmBqd Eie48DZ98NTaVGOHHVyBXEfwQ+nbIVywQBfMcRx4+bY4IhPWNdWmtoMKel2hZrjofSRR 1h/KJVcI0vlKMw1wftzfcXKOPoMPBP9kRElf6Zxzdxha9u1UGx90SY8dfkv6BGfUR2nd CVRYdjh4ivKZKUsG9AmAOVSCItgK+iIhNW9majhG4EOTUxmWB4yM4Op2XldLrtqOcHP/ llXUbdszkSqX3NyCO2ipm7v2Q5UYS7GVAmjfUHdtV6MHUP4nXCG98qHL1qgZHM9MZQN6 M8fw==
X-Gm-Message-State: APzg51CyAZbAfnL4VD2K+Iht/W13j+j/8Zz17TL0+92ZGnoSOIaoDjUN fUq1zVvqRDKKCXRGTyJUBEl/wAFap90Ax6ibXhVNFg==
X-Google-Smtp-Source: ANB0VdaS1BsDTohbOwUR5Zfwny2WodnLj52iLTjIqveKvvbp+ugA9NEgmmnUeOnhJJ1hQHDjCOc/mb0LX77eTz/hW3w=
X-Received: by 2002:a0c:f685:: with SMTP id p5-v6mr16211058qvn.22.1535733486343; Fri, 31 Aug 2018 09:38:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:2c44:0:0:0:0:0 with HTTP; Fri, 31 Aug 2018 09:38:05 -0700 (PDT)
In-Reply-To: <F23A907A-1930-43FB-B1DB-23855A8A6650@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-d0fb-fb1c0301f07d@huitema.net> <046561A5-8B54-4E8B-B8D6-52E5F2784A9C@strayalpha.com> <CALx6S36P2GheGfV-mpPSY7Fh26LKsic4b-=2V=xkY6BmwtuQww@mail.gmail.com> <F23A907A-1930-43FB-B1DB-23855A8A6650@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 31 Aug 2018 09:38:05 -0700
Message-ID: <CALx6S35CKdPPZ68pPSLETJDAk4T7aV2FtV2H2ZBqiUEmyvGVbA@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Christian Huitema <huitema@huitema.net>, Toerless Eckert <tte@cs.fau.de>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/vy26AS8jqpmkg9WxKFDFFZtGk3U>
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:38:09 -0000

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?

> 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 :-)


> 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? 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.

Tom

> Joe