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

Tom Herbert <tom@herbertland.com> Sun, 26 August 2018 19:58 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 17C0E130E3B for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 12:58:04 -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 wQZ1NyUQ-W2M for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 12:58:02 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 6E5DA130E37 for <int-area@ietf.org>; Sun, 26 Aug 2018 12:58:02 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id b19-v6so9168540qkc.6 for <int-area@ietf.org>; Sun, 26 Aug 2018 12:58:02 -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=uxIRsEjqJeYxY1aHLq6gt3wT5i5aPSOwoPbw3b7NaHM=; b=1O4TjPu3+uv1NbnQ+KfyL/k51zNXMb67ygWS5Z+l1ABFCWiK2Yi2cGkOKmZ3BrtZzh aCO7Lof+99l5pnIXjEawzLw9aviIgWOMPmPD20ExSTNtiD0ZtGf/t59w1a6HeVbwDLcJ GMOAwm3l4qkEBeV9TkxR/rFg+ShbG6F3ORLJgva77y3hNWaJiQYXlvPAxo+W7MI1TqrA 4Sdi4okugiZ1iEyUba7dX2IqQMuo6ruyBUjwkH9pGzD9VNAKkziiPk08S7bMT91CUm3q IG2Nx2EBTknQ78eRJjsXabgdueCNNClYDKIV88zXcZmlNGU21IU70sWGenM6W3mPgoxh HdRQ==
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=uxIRsEjqJeYxY1aHLq6gt3wT5i5aPSOwoPbw3b7NaHM=; b=Gphwe9thjO+out5mQwuCE7oY5Z8peScH3XohVLv65wz9DAmYOc7WzfWhZOcqm5Yr+P hFXP77nKipv/G+AboFqf181/CBgCtmmFOBlPvppWAPOJpbcgPcr5M9Zw1Bjkj9S2hE2K u3Sup/82X0aOwV3SlVshMz/sQTZOze7JQ8P3dGgbHPz7wxmBKl8frZPGy9Jt7j/rYCOy HC/8CXfEBIgN7Pi+QksWImFhD62CUcQA4uFOM4j3P+VyJj7UcRNn8/LPkChIOH/mKkgB TlSL6IdCu1BADQFs42jRppQQZvuVndEHOJJ8bBnoS1/TDl6UAp5x6ICx+6p2o+RK1P9T NBFg==
X-Gm-Message-State: APzg51CajK5FNC4UG3+rJ1IFwueu0lss4eH0DIgDl3v3+S+EcSZOn8TA c5xdeDnCzyPCxNe/ThbJyYXMPI/5zWLiblLyoUdw4s1PPB4=
X-Google-Smtp-Source: ANB0VdZbChZEkxrPfm2/LLgfXxx90PSqCeWRltRNSTccBS+BgduR2bw7yTUmAFfgWDEkNWZVVsE4hbrRde/qT8l5bFE=
X-Received: by 2002:a37:a357:: with SMTP id m84-v6mr5246371qke.121.1535313481264; Sun, 26 Aug 2018 12:58:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3312:0:0:0:0:0 with HTTP; Sun, 26 Aug 2018 12:58:00 -0700 (PDT)
In-Reply-To: <538A6193-2BD7-4E72-BD28-736B81F97B33@strayalpha.com>
References: <CALx6S36Ef3t7Axmx9hg994DHpVM=NdW-7ygf89E==gL4XKrkQg@mail.gmail.com> <5E21B3C1-0420-404C-9824-9B7E5A850BC5@employees.org> <CALx6S34qmKngi3hK_PVrJA1DMa5kfaLww3jfqRKN=up5v0Y0Ww@mail.gmail.com> <8D23C8B1-C2DA-4A8B-A2BE-8CCF6233B3A5@strayalpha.com> <D1D5EDCE-7C43-4CD8-947C-AA43CDB18892@employees.org> <1B04E207-08FA-400F-BBED-67379FEFD64E@strayalpha.com> <137751A3-7C52-4CCF-AE9C-B99C4A85EFC1@strayalpha.com> <alpine.DEB.2.20.1808021749020.19688@uplift.swm.pp.se> <CALx6S35kw2dodgG2L3LE3A5y8RYEXy6izQWgrQTwg7-yPqpzOg@mail.gmail.com> <alpine.DEB.2.20.1808030857370.19688@uplift.swm.pp.se> <20180825032457.ol5rlrr7h2kqi6px@faui48f.informatik.uni-erlangen.de> <CALx6S35-n_ROEZv0NReVEWTUhnyc25SNJb5DaeqtnxPAPk6QjQ@mail.gmail.com> <CAF493D3-37A2-4A89-BA88-81567E5B88F1@huitema.net> <538A6193-2BD7-4E72-BD28-736B81F97B33@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 26 Aug 2018 12:58:00 -0700
Message-ID: <CALx6S34uKA9XYP8Mguw1bf+nby_NXWA1GQk88C+Dmtw56ZxF8g@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/AFWrHBOboBkIO5xgk8ixlOntMtE>
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: Sun, 26 Aug 2018 19:58:04 -0000

On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch <touch@strayalpha.com> wrote:
>
>
>> On Aug 26, 2018, at 10:31 AM, Christian Huitema <huitema@huitema.net> wrote:
>>
>> It seems that the biggest obstacle to fragmentation are NAT and Firewall. They need the port numbers in order to find and enforce context. NAT might be going away with IPv6, maybe, but firewalls are not.
>>
>> Have considered strategies that move the port number inside the IP header? For example, have an UDP replacement for IPv6 that does not have any port number in the new UDP header, and relies instead on unique IPv6 addresses per context?
>
> NATs already have what they need to do the proper job - they need to reassemble and defragment using unique IDs (or cache the first fragment when it arrives and use it as context for later - or earlier cached - fragments). There’s no rule that IP packets that are fragmented MUST have a transport header both visible (not encrypted) and immediately following the IP header.
>
> Firewalls are just delusions; the context they think they’re enforcing has no meaning except at the endpoints; it never did.
>
> Using part of the IPv6 space for this solution would then break per-address network management (different UDP ports would use different IPv6 addresses, presumably).
>
> The “disease" is that NATs don’t reassemble (or emulate it). It’s not useful to try to address the symptoms of that disease individually.
>
Joe,

That is only a better solution, not a complete or robust one. For
reassembly to work all fragments of a packet must traverse the same
NAT device. There is no rule that IP packets going to the same
destination (fragments or not) ever MUST follow the same path. So in a
multi-homed environment this will eventually break someone. For IPv6,
this is also a clear violation of RFC8200 since intermediate nodes are
processing a non-HBH extension header in a packet not addressed to the
them. The only robust solution to NAT and its fragmentation problems,
as well as a bunch of other problems NAT brings, is to not use NAT!
(i.e. switch to IPv6)

Tom

> Joe