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

Tom Herbert <tom@herbertland.com> Sun, 26 August 2018 18:13 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 946C2130DEF for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 11:13:22 -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=unavailable 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 pl3pHjCHRcJR for <int-area@ietfa.amsl.com>; Sun, 26 Aug 2018 11:13:19 -0700 (PDT)
Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 B50A2130DEA for <int-area@ietf.org>; Sun, 26 Aug 2018 11:13:19 -0700 (PDT)
Received: by mail-qk0-x243.google.com with SMTP id z78-v6so9101350qka.0 for <int-area@ietf.org>; Sun, 26 Aug 2018 11:13:19 -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=tR6h5Vq5ZpD5IVMnepSfDHVDKVL4vcsg6WlR0KFu35g=; b=LU9zePDlEOxC7qsUfa/g1TaqbHi8MCBiigEWVBwI04kAL0QCuc8dri9yy6KYMgVPC4 3DDytyr/POwpsHN55CBhhPsuU04EmglabJFOWK7jLO7xpOfO3DfIqAd9A8t/LhueM6qY hqLjjFLvU0fNLhGkVA3nDhNZp8sSJxBtSbEN+/u7FU597DpKouBUVcAj+tlqkAFvq+6g xFsiWkR3gWHcXXzUxbHOnn4jEbuhyKzkHlObc6y2KK+Wq5kZmUKK2XnFnN2Fm+ae6uw8 bhOBFAARjq4mzvvQ5FClNds8sIB1beWjHmZtxIagrXRx02ntB2aksquAiQwDiICxSgzE L+Lg==
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=tR6h5Vq5ZpD5IVMnepSfDHVDKVL4vcsg6WlR0KFu35g=; b=sXN9J5Nn5R4AApvKF7r0/LptUKlKeY0IZAig7P1EZaaOYxJXJ0f+MEVfpsC6CdUm4Y UBt5SpbAk3bk5dDcK7QNbyhEqBQl99Wshb3f55IW7ftUCwHge/SL/h5+RAiyu0RnbH3f UaDUxzpc3OLJ1KsYaBWS6lUsOcbdTP8kUmJ92vwl6rAZedyUsGuw0fyVPjBw8Zx2s9FO Q9ACYfTGgaMdMWe2hDYyGveuEzm81ulrxqXFA69KXFbXXrvvrMMHWIyCpwXc1KcV8Or/ GGe1zfzXsnHGu6epFMIutN8ZhNPsBkzREgM5UU5EecaHWGk+zYwskDqJm8ObsNi+KnhT 1aBg==
X-Gm-Message-State: APzg51AP1frP1RRSnHvoJ4mdlvY3hljNY5jjTiQ4i6fzc578NW1Rvzs4 rfW9IaEFcf+APlv5dmWsfFYkUkFi30x1aIdXNFgkCA==
X-Google-Smtp-Source: ANB0Vdba8/oUZ+1yb41gtEYVEHi4S4JE92A4ZTxvkeuIMGiHwCy6IQcjZ/xijaVDJ46tXsN/weEOkHeevHiBdcBDUk4=
X-Received: by 2002:a37:4fcd:: with SMTP id d196-v6mr10379479qkb.323.1535307198655; Sun, 26 Aug 2018 11:13:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3312:0:0:0:0:0 with HTTP; Sun, 26 Aug 2018 11:13:18 -0700 (PDT)
In-Reply-To: <CAF493D3-37A2-4A89-BA88-81567E5B88F1@huitema.net>
References: <CALx6S36Ef3t7Axmx9hg994DHpVM=NdW-7ygf89E==gL4XKrkQg@mail.gmail.com> <5E21B3C1-0420-404C-9824-9B7E5A850BC5@employees.org> <CALx6S34qmKngi3hK_PVrJA1DMa5kfaLww3jfqRKN=up5v0Y0Ww@mail.gmail.com> <8D23C8B1-C2DA-4A8B-A2BE-8CCF6233B3A5@strayalpha.com> <D1D5EDCE-7C43-4CD8-947C-AA43CDB18892@employees.org> <1B04E207-08FA-400F-BBED-67379FEFD64E@strayalpha.com> <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>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 26 Aug 2018 11:13:18 -0700
Message-ID: <CALx6S34FzAjyV0DLRhBkg-ZdXgx+U2vGEGACWT-aXY60OFvukA@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Toerless Eckert <tte@cs.fau.de>, 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/6-EUMuVVNF1bv9pZ3S9FRPtMaFI>
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 18:13:23 -0000

On Sun, Aug 26, 2018 at 10:31 AM, Christian Huitema <huitema@huitema.net> wrote:
> It seems that the biggest obstacle to fragmentation are NAT and Firewall. They need the port numbers in order to find and enforce context. NAT might be going away with IPv6, maybe, but firewalls are not.
>
> Have considered strategies that move the port number inside the IP header? For example, have an UDP replacement for IPv6 that does not have any port number in the new UDP header, and relies instead on unique IPv6 addresses per context?

Christian,

That's sort of along the lines for what Firewall and Service Tickets
(FAST) does. But instead of just putting a port number in the IP
header, FAST employs a generic ticket containing the state information
needed by the firewall. Tickets are encoded in Hop-by-Hop options, so
the firewall only needs to inspect the Hop-by-Hop options to do its
work eliminating the need for DPI at the middlebox (protocol compliant
with RFC8200). This works on any packet regardless of whether it's a
fragment (no reassembly at firewall is ever necessary), any
combination of extension headers, and any transport protocol even
those that don't have a concept of ports.

Tom


>
> -- Christian Huitema
>
>> On Aug 26, 2018, at 10:08 AM, Tom Herbert <tom@herbertland.com> wrote:
>>
>>> On Fri, Aug 24, 2018 at 8:24 PM, Toerless Eckert <tte@cs.fau.de> wrote:
>>>> On Fri, Aug 03, 2018 at 09:48:25AM +0200, Mikael Abrahamsson wrote:
>>>> I've kept saying "Networks must support ip fragmentation properly.
>>>
>>> Why ? Wheren't you also saying that you've got (like probably many
>>> else on this thread) all the experience that only TCP MSS gets you
>>> working connectivity in many case (like hotels) ?
>>>
>>> IMHO, we (network layer) should accept defeat on network layer
>>> fragmentation and agree that we should make it easier for the
>>> transport layer to resolve the problem.
>>>
>>> Aka: I would lvoe to see a new ICMPv4/ICMPv6 reply and/or PTB reply option
>>> indicating "Fragmented Packets Not Permitted". Any network device which
>>> for whatever reason does not like Fragemnts would simply drop
>>> fragmented packets and send this as a reply. Allows then the
>>> transport layer to automatically use packetization  (such as TCP MSS)
>>> to get packets through.
>>>
>>> Of course. Will take a decade to get ubiquitously deployed, but
>>> neither IPv4 nor IPv6 will go away, only the problems with fragmentation
>>> will become worse and work if we do not have an exit strategy like this.
>>>
>> Toeless,
>>
>> I'm curious why you think the problems with fragmentation will become
>> worse. The draft and much of this thread has already highlighted the
>> problems with fragmentation that happen because of non-conformant
>> implementation. While there's a lot of legacy implementation that
>> might hard to fix completely, I don't think we've seen a good argument
>> that these problems are infeasible to fix in new deployments and
>> products. I think this draft is an opportunity not only highlight the
>> problems, but to suggest some practical fixes to improve the situation
>> as a way forward.
>>
>> Tom
>>
>>> If we don't try an exit strategy like this, we will just get what
>>> Joe said, the complete segmentation of the Internet with more and
>>> more L4 or even higher layer proxies.
>>>
>>> Btw: +1 for adopting the doc as a WG item, but primarily because everything
>>> before section 7 is on a way to become a good read of reality. Section
>>> 7 recommendations is only a faith based exercise (praying) as long as it tries to
>>> get the job done primarily by appealing to application developers.
>>>
>>> Cheers
>>>    Toerless
>>>
>>>
>>>
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>