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

Toerless Eckert <tte@cs.fau.de> Mon, 27 August 2018 02:35 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 D19F81277C8; Sun, 26 Aug 2018 19:35:19 -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 OKO1WMB6S-Jh; Sun, 26 Aug 2018 19:35:17 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 49EDA12008A; Sun, 26 Aug 2018 19:35:17 -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 45949548326; Mon, 27 Aug 2018 04:35:13 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3AC67440054; Mon, 27 Aug 2018 04:35:13 +0200 (CEST)
Date: Mon, 27 Aug 2018 04:35:13 +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: <20180827023513.2bxjrk335al2lbvz@faui48f.informatik.uni-erlangen.de>
References: <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> <20180826233350.kz3q6gzqbq36nn4r@faui48f.informatik.uni-erlangen.de> <810cea0d-809f-040d-bc79-7c7413cd99f2@strayalpha.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <810cea0d-809f-040d-bc79-7c7413cd99f2@strayalpha.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/DtKD9O0ktFloU9GdVPfRTUYTJtE>
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: Mon, 27 Aug 2018 02:35:20 -0000

On Sun, Aug 26, 2018 at 05:10:00PM -0700, Joe Touch wrote:
> Agreed, but reassembly is clearly possible (hosts do it). The issue is cost.
> 
> We are not in the business of defending a vendor's idea of profit margin
> WHEN it gets in the way of a required mechanism. I've described why it's
> required; you've indicated that it's expensive. So?

Cost that is too high translates into "not going to happen". Else
we'd all be commuting in helicopters.

> > 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.

> A function whose basic existence defies our current standards?

I thought we where discussing evolution of our standards. 

> You admitted that devices that NAT in the middle of the net wouldn't
> work because of a requirement of IP routing. So why aren't you trying to
> change IP routing to fix the path and not vary - if you want to defend
> the existence of mid-net NATs, then you have to change that requirement too.

I think we're jumping a bit across various cases. Not that they are not
interesting. My main point was that we should separarte out
fragementation as something useful purely in device types without
necessary a full highler layer transport stack (like routers doing
tunneling at IP layer), and host stacks that should rather do
fragementation at transport stack or higher.  And yes, that would enable
me to make NAT and firewalls (for the firewall functions i think make sense)
for host stack traffic something that does not require to bother about
fragmentation and could therefore be done easier at higher speed
and architecturally as something only in the network layer. 

> I'm describing the rules for working within the existing requirements.
> Changing fragmentation alone will not fix what's wrong with NATs or
> firewalls in those cases.

The draft in question argues to limit what future work should do
within the existing requirements, which is fine. I was merely
pointing out that we could move more into what i think would be 
a useful evolution if we also went beyond our current arch
and evolved it. 

It's not really as if IPv6 itself did do a good job in trying to
figure out what network devices can and can not do within sellable
costs. And we're continuing to suffer from it.

> > If we think fragmentation is only something that needs to happen
> > for tunneling within the network stack then maybe not so much.
> Because you think tunneling happens somewhere else? Tunneling happens at
> host - BY DEFINITION. A device that adds a header with addresses *IS A
> HOST* on the side where it emits those packets.

Sure. But lets not get stuck on current terminology of "host". Lets just figure out
what we think are the best rules where to apply fragmentation and why.
I think fragmentation is best pushed up on the stack. Packetization
fragmentation in the "higher layer" is IMHO better than fragments in
the lower layer. Even if the higher layer is a network layer
protocol itself.  

> > 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.
> When you find a complete model better than the Internet, propose it.
> Until then...

HTTPs over DWDM with application layer proxies on every hop.
You didn't define how to measure "better" ;-)

The example of SOCKS should have shown that i wasn't trying to replace
the internet architecture, but rather seeing what could be added on the
edge that is both as (IMHO) as useful as SOCKS but more lightweight.

> No. NATs are hosts because the emit packets with new headers with
> addresses they own. That's the very definition of a host on the side
> where those packets are emitted.

The architecture misses good terms to better characterize better the
type of nodes sitting in betweenwhat users would perceive to be hosts
(HTTPs/TCP stack and the like) and pure routers.

> > Aka: yes, logically today, NAT need to go up to
> > transport layer, which is bad. See Christians suggestion.
> His suggestion is to make IP the one header where everything happens -
> but then we don't have layering flexibility.

Please explain what you think you would loose ? 
I see only benefits of moving demux identifiers one layer down.

> >  Transport layer can do PLMTUD/transport layer
> > segmentation. No need for hosts to do IP layer fragementation.
> Please describe how to implement IPsec tunnel mode in that case. 

See terminology discuss. In my text you question, i was referring
to host' as something that can effficiently run TCP/HTTPs stacks,
not as hosts per TCP/IPv6 architecture terms. My hosts' would use 
transport mode.

If you're talkin about network devices using IPsec tunnel mode,
i would equally just pass the effective MTU up to avoid
fragmentation.

If i could build a network device doing fast fragmentation with
IPsec tunnel mode, i would probably look for how to most
easily extend IPsec to do such packet layer fragementation so as
to not bother the undelying layer.

> > 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.
>
> Hmm. But there's a model to outsource it to a separate vendor and it
> still works?

Sure, why not ?
Before Microsoft after 25 years finally got some useful firewall
into windows 10, most firewalls where outsourced to separate vendors.

> Anything that works with two vendors can work with one.

Like checks and balances, division of power and the like. Don't think so.

> > 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.
> The "best we can do", yes. To lie about what we can do, no.

IMHO, logically the firewall is part of endpoint OS, but its impossible
to standardize that well especially with all that embedded/IoT crowd.
So its outsourced into a common network comonent, and the question
is what a reasonable amount of information about the apps is
that the OS should share with the outsources firewall to do the job.
Not really a difficult concept, just something that the single vendors
of endpoint OS never wanted to make work because of business reasons.

Cheers
   Toerless

> >>> 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.
> They're also called hosts.
> 
> Joe

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