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

Tom Herbert <tom@herbertland.com> Sun, 26 August 2018 23:16 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 14671130E03 for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 16:16:42 -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 HHSZUi5BtA_3 for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 16:16:40 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 99A38129385 for <int-area@ietf.org>; Sun, 26 Aug 2018 16:16:40 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id k38-v6so1770022qtk.11 for <int-area@ietf.org>; Sun, 26 Aug 2018 16:16:40 -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=JWaYyo3+xXnq0WiHB7ZgFK5bMAUICnvB3ir+0dGFmfM=; b=XpxsULJ5QnuExi6PmPTxaMPLbIEmvJ8JHxOiOGVMZ0rJOpgpIVIwoX+48yrCYWDqsQ t0ej8LfGQ/D9fk+Tz8LMnQ5rfDOuKG4vfNKWwrcgDa0fK4jQorvcLVhlzOzM8aOy7BYj T00Qhb35zMsFAO8GyjbKsBAqe7c7ZY5AoP5u79+EpREUJfXJRT50mMd9g8Ngo9eDL+WX 6BlgmeAdhbvYGpZSK1XMdajnuD8wXHHTr0NkwkfJ2K4dirf/dUHRttbpsP20ZW4PBP2N VL/rI+UGNmTyuU2X1VjH1e0Y2Ww6Q96OfAnCVlCcJPTiiyp/bKCowX07vbUUmc9wfzaJ ZJsg==
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=JWaYyo3+xXnq0WiHB7ZgFK5bMAUICnvB3ir+0dGFmfM=; b=EahSCxca2uPSRH3H6qfkAl/Pw91h9tE7E9NIZfTlrg1611YHeQfBfEitXmbmq+GbfO OBL9tEmud3mn8fyyPR7hvJT0T58DNzREHfoa8XilQ2nAOsfYe5sUNmOtn/IaXoFMVf7N AxzQnePYLg6Zot1UBcY+Fmk9CNwmJ+3Czb8jrpM3486EPOVXGowbJvTMmkEq19eRQdsC KIHOAC6GXfVbZGBxhxVfL+0K2TNLZ7EPzG+o8BrvpEU63TkhwqsbKjYP0Y9OoIQLnzYc 6jOxgINad9Vlk6yoHgaEjAHfG5o2Avi/6T66P6w6CIf5uNrvQmfNDbuOzLRgsdW+TBnZ w37A==
X-Gm-Message-State: APzg51COmS4vZZ0B20Zni0uRd4zGbtlkT0CdcO7uVqxFku80sAuibs0p WP1RK6jYCsSzjxKfgA2kOgKw/6Y0YcZg+L2kWptZ8Obs
X-Google-Smtp-Source: ANB0VdbnJiFQMgfJRP4JS9SCiKNfZgHEh6wxHMd4Vm1L5slbPH8FBRdlhKUYbCUN46fDArZxAh/jxIFjLoPX6vSaF8s=
X-Received: by 2002:a0c:f685:: with SMTP id p5-v6mr11155045qvn.22.1535325399546; Sun, 26 Aug 2018 16:16:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3312:0:0:0:0:0 with HTTP; Sun, 26 Aug 2018 16:16:39 -0700 (PDT)
In-Reply-To: <20180826215558.6hzff2povrxuis3y@faui48f.informatik.uni-erlangen.de>
References: <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> <20180826215558.6hzff2povrxuis3y@faui48f.informatik.uni-erlangen.de>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 26 Aug 2018 16:16:39 -0700
Message-ID: <CALx6S36sUCoBfh+X_USs-FDQAhdqE7XGP7sY+Df97EW9L8+n5Q@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Joe Touch <touch@strayalpha.com>, Christian Huitema <huitema@huitema.net>, 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/XbfsV-ySf8yNFW8KFZFTEaG3nDs>
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 23:16:42 -0000

On Sun, Aug 26, 2018 at 2:55 PM, Toerless Eckert <tte@cs.fau.de> wrote:
> On Sun, Aug 26, 2018 at 11:38:57AM -0700, Joe Touch wrote:
>> 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.
>
> Reassmbly/refragment and MTU discovery puts NAT out of the realm of many
> cost effective HW acceleration methods. Simple address rewrite does not.
>
>> Firewalls are just delusions; [1]
>> the context they think they???re enforcing has no meaning except at the endpoints; it never did. [2]
>
> I completely agree with [2], but my conclusion is not [1], but
> rathat its highly valuable and necessary.
>
> The ability of firewalls to open 5-tuple bidirectional pinholes because
> of trigger traffic from the inside is IMHO the most important feature
> to keep Internet hosts protected. I wish host stacks would be built securely,
> but after a few decdaces i have given up on that for most hosts. Which is
> why its so irritating when host stack pundits continue telling network device
> stack builders what they should and should not do.
>
When the host stack pundits are asking network device stack builders
to conform to the standard protocols then I believe that is
reasonable. If firewalls were standard and ubiquitous, and standards
were adhered to, then host stacks would have no problem. But alas
they're not, so we're forced to implement the host stack per the least
common denominator functionality of network devices.

> Firewalls inspecting unencrypted higher layer message elements where a fairly
> well working security model based on having a separate security administration
> from the application administration. Now the applications promise to
> provide all the security themselves, but they primarily just prohibit visibility
> of what they do, so its a lot harder to figure out when they are insecure.
>
> Would you ever put all type of in-home "iot" gear thats not a Windows/MacOS
> system with a GUI you can control on the Internet without a firewall ?
>
Conversely, do you allow your smartphone to connect to a network
before you've verified that a firewall is being run in the network,
what vendor provided it, and what the configured rules are?

Tom

> Cheers
>     Toerless
>
>> 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