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

Joe Touch <touch@strayalpha.com> Mon, 27 August 2018 00:10 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 453DD130DD5; Sun, 26 Aug 2018 17:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) 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 D-9uBiJ3uNfa; Sun, 26 Aug 2018 17:10:07 -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 BA2261277C8; Sun, 26 Aug 2018 17:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=GbB5qx4L6H1uoUgNeqoqDfysHoTowvDEiCWklRkcDRQ=; b=s8qwS9+Ut/746ZRTWz8rFKqCvI xdH4+xRnqw6bK4387/yWyDAXM9/nI9fi5Q2rwlSEyexGk6ycqn6XefMvCAZTtbMe3kFlRAQqFcqwe DrwgCh3SbW6BIRakEqUGVBdohqLgSOEdzKnQKhMLBTuEAbYNBWJkNx65itJo0anTD0yRf+Py8R7XV UatySkB88pssqsFMHkSm4hkVEgNyioC16x5oZJDWV0/B8QNynOP7UVdOont9aqQOw6XIQCDRyB149 YrcSEWStlwxy/mfwgc/qOkS2lOonsaeUoRcQk1ie/FBHIuUPHJ6LcS1jdXlRrouyutmrfTXIax0Zk ec7iLfWg==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50986 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1fu56a-003PPk-R6; Sun, 26 Aug 2018 20:10:05 -0400
To: Toerless Eckert <tte@cs.fau.de>
Cc: Christian Huitema <huitema@huitema.net>, Tom Herbert <tom@herbertland.com>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
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> <20180826233350.kz3q6gzqbq36nn4r@faui48f.informatik.uni-erlangen.de>
From: Joe Touch <touch@strayalpha.com>
Message-ID: <810cea0d-809f-040d-bc79-7c7413cd99f2@strayalpha.com>
Date: Sun, 26 Aug 2018 17:10:00 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180826233350.kz3q6gzqbq36nn4r@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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/Et1ifeetOZSF87o3EntS_mw9YJM>
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 00:10:11 -0000


On 8/26/2018 4:33 PM, Toerless Eckert wrote:
> 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.

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?

>>>> 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.
A function whose basic existence defies our current 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'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 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).

It currently does.

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

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

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

>
>> Hosts receiving packets reassemble. Period. Or they won???t work. Period. And those that don???t, don???t work.
> Hosts must have transport layer.
Sure, and a transport layer that has no associations is vacuous. A host
is something that emits packets with their own addresses; minimally,
hosts MUST terminate/originate IP (a host that doesn't
terminate/originate IP does nothing). A host that doesn't
terminate/originate UDP or TCP is simply a host with no
associations/connections - which remains valid.

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

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

Anything that works with two vendors can work with one.

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

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