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

Joe Touch <touch@strayalpha.com> Mon, 27 August 2018 03:01 UTC

Return-Path: <touch@strayalpha.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 91238130E4B; Sun, 26 Aug 2018 20:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.779
X-Spam-Level:
X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=strayalpha.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 VQy3d4IOYQDH; Sun, 26 Aug 2018 20:01:14 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9F0130E44; Sun, 26 Aug 2018 20:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zrxv3GiThfweg242L0nWINnrAezT8nPzALAYyLbtl00=; b=pkvSV313Cf8u/ZDvzV8ZP/Wck RU4k4LdsqXt3eOhfqryC2wKtP6pR0BWLXelnjCT/jXY6en84HDkeoGf1qs8Y9r6AB9vSmvjXz9poR SG2KPJGVYLZNleGPB9fRRrfJfYJRmSdAPj10zmQjv41ca2DUG4ACxb35Xh09dy/LKwe9N984igQIG PtQ/c/Tzeu/YX0NHERHKfV69uVvNCNQFylz5kgV7bHhAGYhF5MRbgX9h/SWRwNkYgMBmk8OXhtbG7 McGDTp2kNzD6WL2vCNi/BK9l6dmTLco4YcsG7+PIIN8/csh0Is0uf11ii4XJ+W4gB3PIZYZq14Xbe EOqFkmXLQ==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60908 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1fu7m9-000c5f-5w; Sun, 26 Aug 2018 23:01:11 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_BDEC1A3C-9554-4458-A0CA-9F6D3A035B7D"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <20180827023513.2bxjrk335al2lbvz@faui48f.informatik.uni-erlangen.de>
Date: Sun, 26 Aug 2018 20:01:07 -0700
Cc: Christian Huitema <huitema@huitema.net>, Tom Herbert <tom@herbertland.com>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Message-Id: <E02F3C36-ECE6-419E-A219-08A15AD98D13@strayalpha.com>
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> <20180827023513.2bxjrk335al2lbvz@faui48f.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/YcQj8j_GrHqGmedPsN-XbO2J2Uw>
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 03:01:18 -0000


> On Aug 26, 2018, at 7:35 PM, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> 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.

IPv6.

IP options.

And (perhaps) any new proposed solution.

We have to aim at what network components *need* to do to participate. IP fragmentation is exactly that.

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

What we have are:
	- a (current) standard that works, but isn’t implemented in some places to save money
	- a proposed partial solution that works for only some protocols, and - you guessed it - will still cost money that some will want to save

Making a solution that is partial (won’t support IPsec at least) isn’t evolution; it’s devolution.

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

That’s easy to say, but since any host might be an IPsec tunnel endpoint, you’re back where we are now - needing IP fragmentation support everywhere, ultimately.

My view is simple - if you fix what we KNOW is wrong with NATs and firewalls - in KNOWN ways - then not only don’t we have to solve this problem, we don’t have a lot of other problems either (e.g., lack of state when a flow takes a different path into an enterprise).

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

You’re optimizing a long-term impact solution for a short-term limitation. That’s a bad idea; protocols last a very long time.

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

I am fine with encouraging the *search* for new solutions, as long as *in the meantime* we also call out firewalls and NATs for how they are already broken. Until IP fragmentation is deprecated, that has to be our position as a community. Otherwise, we will be constantly redefining our protocols to how others mis-implement them (yes, I know a few people who write drafts with this very goal in mind, sadly).

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

We are continuing to suffer from cheaply made devices that claim Internet compliance but aren’t. Frankly, until we have a compliance arm, that’s not likely to change. However, we CAN avoid reacting as a community to the least-common denominator of what is implemented for profit.

I.e., a bake-off would catch this and flag it, not bury it as “well, the market decides”. The market cannot be trusted to create a consistent set of capabilities that will support networking.

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

Stop. No. If you can’t use definitions and behaviors that are the underpinning of the Internet architecture, then there’s no point in anything further.

> Lets just figure out
> what we think are the best rules where to apply fragmentation and why.

(see above for “market decides”; your way won’t necessarily get us to a useful network - it may patch one issue, but could easily open three others).

> I think fragmentation is best pushed up on the stack.

Again, please tell me how to do that for IPsec tunnels - which, again, can start/end anywhere in the network.

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

OK, how do you fragment IP without fragmenting IP when it’s IP over IP?

> 
>>> 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" ;-)

Agreed, but that’s exactly where you’re headed when you say “kick the can down the road to the upper layer protocol”.

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

Anything you add will end up being in something that looks and acts like either a firewall or a NAT and you’ll be right back here again, saying some other upper layer protocol should fix things.

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

Provide those terms, define their behavior in a way that is consistent with a full set of protocols, and call us when you’re done. I’ve done so by defining NATs and proxies in terms of existing architectural components, showing an equivalence. the alternative is to design a new, complete architecture.

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

Then your solution works only for those things - which shouldn’t be called hosts (that’s already defined in RFC1122).

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

That can’t work - by the time the traffic gets to you, you don’t have control over whether the source will adjust its size of not (it might even be encrypted). Yet you might have to put a 1280 byte packet inside a new IPv6 payload. How do you do that without fragmenting? The space for the headers has to come from somewhere.

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

You can’t - the packets you receive could be IPv6 and the packet you’re putting them in is IPv6. There’s no way to do this without redefining IPsec tunnel mode.

> 
>>> 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 can be outsourced can be incorporated.

> 
>> Anything that works with two vendors can work with one.
> 
> Like checks and balances, division of power and the like. Don't think so.

If you WANT them implemented separately, you can do that - except that you need to make sure that the firewall and host act as a single endpoint. You can’t delegate part of what a host does to something that fundamentally isn’t responsible for acting like a host (i.e., reassembling).

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

Again, that’s OK as an implementation choice, but with that choice comes responsibility - the firewall is responsible for acting as a host. Not *wanting* to do that doesn’t make it so, nor does it make it possible or useful for us to try to patch the Internet to enable.

Joe