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

Tom Herbert <tom@herbertland.com> Fri, 31 August 2018 15:44 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 6A9E5130E21 for <int-area@ietfa.amsl.com>; Fri, 31 Aug 2018 08:44:32 -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=unavailable 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 7wvrljMGl702 for <int-area@ietfa.amsl.com>; Fri, 31 Aug 2018 08:44:28 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 DFE89130DD1 for <int-area@ietf.org>; Fri, 31 Aug 2018 08:44:27 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id j7-v6so15034878qtp.2 for <int-area@ietf.org>; Fri, 31 Aug 2018 08:44:27 -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=WzCu4H5yH9D98+G0IvJAoq7ZR/sqg+FwHQ87s8WDvMc=; b=JGRpCD4+ENGq24T1/MFtZ4aPcdZFioXjPlw4xN4aLcJklWpzvkX4GiwjJe7VbbYFiI SYvo7fC5oZk8NilD8/r1Hzdmu9in3l0F5iUFdu3vcNHNnPocq2+4prf01ZNx7FHdBwUa MoigUqtbJ/20AvJFEMC3IOzXw4LMsDKcPDKctze9IrKMeYplIlYHj9Tul6kvzKSmzdZF bulQMAEKEXJAFJlql59PIUxMoZETaBbvxgUcd39OwInIx05PPDRgaa2oSG6BcRy7Kosf yV/89AF90983qovNc+DtYAoXZ1ysmtNOoVxaiLXOe+RkCnXJY0eWQwwW5hyWIEvtuPtZ vf1Q==
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=WzCu4H5yH9D98+G0IvJAoq7ZR/sqg+FwHQ87s8WDvMc=; b=eO4GaEG35iqvzhDAgbcUyVkzJ4ReScAhi5dQpxg8Jbgxey62+vKonofEpNRALm/la7 9pZy9ZSpkLE/8cNQOnBC5U+Uk1B7u6ZrMEx+K8zZef9HqElVs/spJkTetj9Hf1YC8OC3 7gYcrBaJ6f2qf1btI6OZG4K3XomtizV+f03I3MMtN7gWHueVwOe980NDrSIAxGD8m0Cp bpkjBnimdtCWSY/D6cDym2f+5b0eyZC0Em2boqKvUO9a2aEoa2f8G393zB8vr1g8++Fd 6Y41N3jbEALXqrriTTWRYHc/14uI4ZR65AgKe6sdpe/X/H+q0Avc0qGXLVax1f8KbsKC e+Mw==
X-Gm-Message-State: APzg51BKMdN23RcoGhPSPWJi6erJDb2+vPgIuktUGV8L4ZVf1HZPNg80 9Va1La/x5KVf12qUtLVWgLcDbEAr1NQV4PGvLp7E6Phajdg=
X-Google-Smtp-Source: ANB0VdaS6op4dQ4qFsO2IwCFOqNN6jKElNVn6brNoNBwpCNEWUrj2jUMki0DVgQyPqkAfqioJNmIwUI5XQxqeg879to=
X-Received: by 2002:a0c:f685:: with SMTP id p5-v6mr16012000qvn.22.1535730266574; Fri, 31 Aug 2018 08:44:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:2c44:0:0:0:0:0 with HTTP; Fri, 31 Aug 2018 08:44:25 -0700 (PDT)
In-Reply-To: <046561A5-8B54-4E8B-B8D6-52E5F2784A9C@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>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 31 Aug 2018 08:44:25 -0700
Message-ID: <CALx6S36P2GheGfV-mpPSY7Fh26LKsic4b-=2V=xkY6BmwtuQww@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/7-_1Qm82kGG0sfplcZCNTKYL4AE>
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 15:44:33 -0000

On Thu, Aug 30, 2018 at 5:26 PM, Joe Touch <touch@strayalpha.com> wrote:
>
>
> On Aug 29, 2018, at 11:19 PM, Christian Huitema <huitema@huitema.net> wrote:
>
> Regardless, middleboxes shouldn't be avoiding their own effort by creating
> work for others. A corollary to the Postal Principle should be "you make the
> mess, you clean it up".
>
>
> Joe's stubborn adherence to the letter of the RFC would be very nice if the
> protocol police could somehow punish the merchants of NATs…
>
>
> My concerns are pragmatic - merely not supporting something does not make it
> unnecessary.
>
> There was a time when Internet service in hotels would regularly block all
> except basically DNS and HTTP/HTTPS; that’s becoming much less the case.
> There was a time when devices didn’t support IPv6 at all because it was
> considered merely an unnecessary expense; that’s becoming much less the case
> too.
>
> In this case, we have two problems
> 1) NATs/firewalls as currently implemented do not support fragments
> 2) our current protocols, in many cases, require fragments (IPsec tunnel
> mode) and in other cases (tunnels in general) would benefit from IP
> fragmentation support
> 3) we DO NOT HAVE an alternative (there are some piece-wise proposals for
> various aspects, but none support IPsec tunnel mode and none are otherwise
> universal
>
Joe,

There is an alternative: don't use NAT! In a draft that is
recommending against using a core IP protocol feature like
fragmentation, I think it is entirely appropriate to recommend against
using the very features that are breaking it in the first place. IMO,
this draft should recommend people use of IPv6 without NAT to resolve
the problems with fragmentation caused by NAT.

> 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. 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.
The fact that this might forward fragments that are never reassembled
is at best an optimization with unproven benefit.

There is another case where in-network reassembly could be required
which is load balancing to a virtual IP address. This is handled in
the Maglev load balancer
(https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44824.pdf)
without employing a synchronization protocol. It is rather complex
though and not a solution easily generalized for simple environments.
Like NAT though, in the long run I believe IPv6 offers a better
solution that would eliminate the need for VIPs.

Tom

>
> The whole discussion reminds me of Martin Thomson's draft, "use it or lose
> it" (draft-thomson-use-it-or-lose-it-02). Martin is describing how extension
> mechanisms that are not actually used get ossified away by the deployment of
> middle-boxes. The same happened long ago with IP segmentation. With NATs,
> applications cannot assume that reassembly will work. With Firewalls,
> transports cannot assume that ICMP will work.
>
>
> Yes, that’s the tension:
> a) identify bugs and fix them
> b) accept bugs as de-facto protocol evolution
>
> The problem with (b) is that it is not guided by what Internet users need;
> it’s guided by what is profitable for individual vendors. That path is
> hazardous - there’s no reason to believe that the result will be a useful
> Internet. So until we know it’s safe to do (b), we need to stick with (a).
>
> Joe