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

Toerless Eckert <tte@cs.fau.de> Sun, 26 August 2018 21:56 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 54B1D130E17; Sun, 26 Aug 2018 14:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 KwVR6mKHf0dw; Sun, 26 Aug 2018 14:56:02 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B758E130E03; Sun, 26 Aug 2018 14:56:02 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0B25658C4BD; Sun, 26 Aug 2018 23:55:59 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id F3BEE440054; Sun, 26 Aug 2018 23:55:58 +0200 (CEST)
Date: Sun, 26 Aug 2018 23:55:58 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Joe Touch <touch@strayalpha.com>
Cc: Christian Huitema <huitema@huitema.net>, Tom Herbert <tom@herbertland.com>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <538A6193-2BD7-4E72-BD28-736B81F97B33@strayalpha.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/HDp0W4Vrcaxd6Aa7TNp88rNqkhc>
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 21:56:04 -0000

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.

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 ?

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