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

Toerless Eckert <tte@cs.fau.de> Sun, 26 August 2018 23:33 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 171E5130DD5; Sun, 26 Aug 2018 16:33:57 -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 cUaIdxutdIuw; Sun, 26 Aug 2018 16:33:54 -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 536931277C8; Sun, 26 Aug 2018 16:33:54 -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 5B035548326; Mon, 27 Aug 2018 01:33:50 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 48076440054; Mon, 27 Aug 2018 01:33:50 +0200 (CEST)
Date: Mon, 27 Aug 2018 01:33:50 +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: <20180826233350.kz3q6gzqbq36nn4r@faui48f.informatik.uni-erlangen.de>
References: <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> <0A065EE6-463C-4C71-BF12-C0E5A1C51680@strayalpha.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0A065EE6-463C-4C71-BF12-C0E5A1C51680@strayalpha.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/VJrzuGf3JJbj5_L0UM9oQVqdgB0>
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:33:57 -0000

On Sun, Aug 26, 2018 at 03:50:18PM -0700, Joe Touch wrote:
> > Reassmbly/refragment and MTU discovery puts NAT out of the realm of many
> > cost effective HW acceleration methods. Simple address rewrite does not.
> 
> And crumple zones and airbags get in the way of cars running fast and being inexpensive.
> I.e., you???re right - doing NATs properly is more expensive than lying that you have a functioning NAT that doesn???t.

Sometimes it helps designing solutions against what can actually be
achieved instead of wishfull thinking. The way we operate
against expectations on network devices today just creates a lot
of half-baked solutions.

> >> 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.
> 
> Good. Continue to run them and tell your customers that they actually stop email when they block ports 23 and 110, etc.
> The rest of us then will tunnel one port over another (VPN) and walk right through that device (like we all dll all the time in hotels).

You can always prove the existance of wishfull thinking by
assuming all type of stupid advertisements or misunderstanding of
achievable functionality. But that does not disprove the
existance of useful or necessary functions.

> > 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.
> 
> A firewall hsa to be close enough to the endpoint to act as its proxy; at that point, provided it does act as its proxy, then that sort of 5-tuple filtering works fine. You???re offloading work of the host elsewhere - but that firewall needs to act as a true host proxy, which includes reassembly, or it won???t work properly (nor can it ever).

If a host stack should do fragementation (as IPv6 mandates now).
If we think fragmentation is only something that needs to happen
for tunneling within the network stack then maybe not so much.

If i wouldn't have to worry about such proxy forwarding plane capabilities,
i definitely would prefer models like SOCKS. If i have to think about them
it becomes certainly difficult to even model this well.

> > 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.
> 
> No argument there - but again, pushing the work of that host to another device MAKES THAT DEVICE A HOST.

Can i re-apply your argument about fragmentation: 

You said something like IP can not be self-sufficient enough if
it wouldn't support fragmentation because then you would have
to rely too much on the higher layers.

Your claim of requiring NAT to be hosts is because we do not permit
IP to be self-sufficient for address translation between different
domains. Aka: yes, logically today, NAT need to go up to
transport layer, which is bad. See Christians suggestion.

> Hosts receiving packets reassemble. Period. Or they won???t work. Period. And those that don???t, don???t work.

Hosts must have transport layer. Transport layer can do PLMTUD/transport layer
segmentation. No need for hosts to do IP layer fragementation.

> > 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.
> 
> No better, FWIW, than would be managed software inside the end system. There???s no strict rule these need to be separate devices, but - as per above - they work fine when they act as they actually need to.

Microsoft provides some good enterprise system management to
separate application security management from application management
itself, but i am pretty sure there is no chance in hell to expand
that model across all type of hosts in a standardized fashion.
Hence its certainly very viable to figure out what the best is we
can do with firewall and other seucurity techniques on
"proxy" devices. See also MUD and the like.

> > 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 ?
> 
> Without firewall functions somewhere? No - I agree. But I also wouldn???t put that firewall inside the network where it couldn???t see the fragments to reassemble - because it will never work properly.

Which circles us back to me questioning the need for fragement at
the IP layer (as opposed transport layer) in hosts that MUST have transport stack. vs. some
other type of devices that do e.g. not have transport stacks but want
to do tunneling IP in IP tunneling.

> I.e., I agree that ???it hurts when we do that???, but not that we have to do it the wrong way (even though it???s cheaper).

Cheers
    Toerless

> 
> Joe

-- 
---
tte@cs.fau.de