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

Tom Herbert <tom@herbertland.com> Mon, 27 August 2018 03:19 UTC

Return-Path: <tom@herbertland.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 BF642128CF3 for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 20:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 lJduK0DFMakP for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 20:19:43 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568F1126F72 for <int-area@ietf.org>; Sun, 26 Aug 2018 20:19:43 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id h138-v6so9585049qke.8 for <int-area@ietf.org>; Sun, 26 Aug 2018 20:19:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OXsg1XSefp732xeaVylP3QUMZiwC/yM31T5lH1SgiIc=; b=BoOLtq2dZNU5xXP4tSUwRlQJsAGuYJZUAjSdUBIDEoEuX4G28MUEkIEysMs4oqhs0f +w/jOcD1PRFrKlW2zc8/8GORngi2QIOrZsVTP+SkCvSkb/OMX0oe5yOnokSF4Favb7QY fwyEn3kwmMWUdv39dmgljalB5Gk9POL6jaTUH9ffMcweF44U/W8NoiqnCZ+6vCmxl0mU frr+PoRJD32JumkOhi/LhJhBnRAAKD08wkTgCAJPiYYreSflpkEYw76tjvqQGS6CzCp0 MbXwLj2GqcDQzLuCTnN9ky4xrOmccbPkHD9SUQCu24tMAHg2YKT09dCG32NV1tGZvb6V VZsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OXsg1XSefp732xeaVylP3QUMZiwC/yM31T5lH1SgiIc=; b=HF3WV55CBkaIFsS+6sV3hHsqL6iWmhyeW0bo6hLjzjEjC1i9zcVaTudktXyQbdw94O LfZrKdwA9zT6XHIOgNnZMThmdFQt+bTMbT2yJ0WQmRwDDIDijBkM1FTImrbTAvVYB/1Z al7ovSHrjwM66BbJjkktw28ruG/xxIdxZJ86lbWmeH9oShOqxqX1LH3FPEz3cRdTvcVy lZlrNOr03K6mNPCOrEKFmn6RkRplWgKuGnI8oNmqzWwE3/sLrbbmsUpj9UNbfCoWAGjC VfIf/NlFFrgUWWc+y1E6gW/SY4zrln6mbzQoBOEp25TkLa3WgMRexfz3hAlAN9Aa12lz c+Dg==
X-Gm-Message-State: APzg51B2Lbotw7EqO85KAobQSkc6TOM3LKRbYvbv2slyMQr3Ngvoc5xJ uiG/SOwVLxxJ2eJvAWeSG6tHsIqnVVv0cBxRF2wtpw==
X-Google-Smtp-Source: ANB0VdYiQbq39dL58mpD1T+e2r+gjeFDvyljPSuThmCPTqW8EDMN73dtjpyjlkdUhS6rTUNJ5MQLNEyQL4RP/iiFr4g=
X-Received: by 2002:a37:d44c:: with SMTP id l73-v6mr11573691qki.190.1535339982116; Sun, 26 Aug 2018 20:19:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3312:0:0:0:0:0 with HTTP; Sun, 26 Aug 2018 20:19:41 -0700 (PDT)
In-Reply-To: <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> <20180827023513.2bxjrk335al2lbvz@faui48f.informatik.uni-erlangen.de>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 26 Aug 2018 20:19:41 -0700
Message-ID: <CALx6S35MbKF+b8n6Tps1-4NsOA=i_cUD5-mhYt-hSkiQXikx-Q@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Joe Touch <touch@strayalpha.com>, Christian Huitema <huitema@huitema.net>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/pE4_BYzH0C02-iQQjOk7nlL9nBc>
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:19:47 -0000

On Sun, 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.
>
>> > 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.

Toerless,

I'm not sure what "outsourced into a common network component" means.
I've done a lot of app and OS development and have NEVER once
"outsourced" security to the network. OSes and apps need to work
across all networks, in any possible environment, so having one
network provide a strict firewall, and in the next one no firewall
doesn't help really help things. Least common denominator for security
is no firewall, and that's what we assume in host development.
However, we do have to jump through a number of hoops to satisfy some
of the implicit requirements created by firewalls.

> Not really a difficult concept, just something that the single vendors
> of endpoint OS never wanted to make work because of business reasons.
>
Or perhaps they don't want to make it work since there is no standard
protocol for hosts to communicate characteristics of traffic with the
network. I think https://datatracker.ietf.org/doc/draft-herbert-fast/
could be that.

Tom

> 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