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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 31 August 2018 16:12 UTC

Return-Path: <Fred.L.Templin@boeing.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 36B7B130E51; Fri, 31 Aug 2018 09:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 3tTvsFG80VWk; Fri, 31 Aug 2018 09:12:42 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 435BD130E20; Fri, 31 Aug 2018 09:12:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w7VGCflY007203; Fri, 31 Aug 2018 09:12:41 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w7VGCdQI006824 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 31 Aug 2018 09:12:39 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 31 Aug 2018 09:12:38 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1367.000; Fri, 31 Aug 2018 09:12:38 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@strayalpha.com>, Tom Herbert <tom@herbertland.com>
CC: int-area <int-area@ietf.org>, Toerless Eckert <tte@cs.fau.de>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Thread-Topic: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
Thread-Index: AQHUQUNTdkxN0DHlqk+wgRWsO7c3L6TaBoYw
Date: Fri, 31 Aug 2018 16:12:38 +0000
Message-ID: <283a2682b98442a085f27781c85a8476@XCH15-06-08.nw.nos.boeing.com>
References: <CAF493D3-37A2-4A89-BA88-81567E5B88F1@huitema.net> <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> <E02F3C36-ECE6-419E-A219-08A15AD98D13@strayalpha.com> <20180828220915.fpx5hi7nhl46ou6r@faui48f.informatik.uni-erlangen.de> <CALx6S35vbtYOiEx2opqSh1uq9rfgG5QHEQcb+ccWLMcwWZA-uQ@mail.gmail.com> <20180829002430.fojlqonvnqdrhw4z@faui48f.informatik.uni-erlangen.de> <af424b4b449c4a1459b69ed01a984e48@strayalpha.com> <CALx6S3563g___ZP03dD5+sV++ZH7U5yudqRX0Bf2744BbBxGgQ@mail.gmail.com> <2b6dd7006cca65525ac6240a8edffabb@strayalpha.com> <CALx6S37EiFo8C4K7fO=O0hNpStoaS6wBvM8jVowmJTQHW2=DHw@mail.gmail.com> <b40ed6c3fc32909e2df677cd999550dd@strayalpha.com> <CALx6S34WW4tj=UVmUBpREdeQ9Wshv=ZdTs3RLQLG9+nOr6ArjQ@mail.gmail.com> <11b0cc8e660ae288b283b6fb82f45b3b@strayalpha.com> <472d83e1-ea8f-2ac5-d0fb-fb1c0301f07d@huitema.net> <046561A5-8B54-4E8B-B8D6-52E5F2784A9C@strayalpha.com> <CALx6S36P2GheGfV-mpPSY7Fh26LKsic4b-=2V=xkY6BmwtuQww@mail.gmail.com> <F23A907A-1930-43FB-B1DB-23855A8A6650@strayalpha.com>
In-Reply-To: <F23A907A-1930-43FB-B1DB-23855A8A6650@strayalpha.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 12E83EB1BBA2B78953F385338C4DFFE1AC99A0940FCB523B92C24B04C8BB4C6B2000:8
Content-Type: multipart/alternative; boundary="_000_283a2682b98442a085f27781c85a8476XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/BxS6WlY3Z7q2I4l34PLhZpzY-aM>
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: Fri, 31 Aug 2018 16:12:44 -0000

>> Any middlebox that uses state not available in all fragments MUST reassemble or keep equivalent storage/state to process fragments appropriately.

This statement is true without question, so the only question is what applications
would produce IP fragments that need to be forwarded by a middlebox. We have
already seen that ‘iperf3’ produces IP fragments by default on some systems. And,
intarea-tunnels makes the case for tunnels.

I will also make the case for NAT66. With RFC4193 ULAs, NAT66 will be inevitable,
but a middlebox may be able to translate based only on the IPv6 addresses and
not transport-layer port numbers. Such a middlebox could forward fragments
without having to reassemble or otherwise hold them until all fragments have
arrived.

Thanks - Fred

From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch
Sent: Friday, August 31, 2018 8:57 AM
To: Tom Herbert <tom@herbertland.com>
Cc: int-area <int-area@ietf.org>rg>; Toerless Eckert <tte@cs.fau.de>de>; intarea-chairs@ietf.org
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile




On Aug 31, 2018, at 8:44 AM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote:

Joe,

There is an alternative: don't use NAT!

Agreed - that should also be part of the observations of this doc.

Yes, something needs to be done, but I argue that *until we have a worked
alternative*, we need to keep restating the fact - NATs/firewalls MUST
reassemble to work properly; where they don’t, the error is on them - not
the rest of the Internet for using fragments.

Reassembly could only be a MUST for NAT, not firewalls.

“or its equivalent"


NAT might be
required because of the identifier space issue, however we already
shown how a firewall can achieve proper functionality without
reassembly and to be stateless by forwarding fragments and potentially
dropping the first one that contains port information being filtered.

First, firewalls that port-filter need to do the same thing as a NAT in terms of keeping state.


The fact that this might forward fragments that are never reassembled
is at best an optimization with unproven benefit.

ATM proved otherwise in numerous published studies in the late 1980s. Those fragments compete for bandwidth further along the path; anytime they “win”, that decision is not work-conserving.

Note that keeping some state is already needed (if port-filtering) and that - as you note - the state filtering need not be “perfect”. However, it really ought to be SHOULD at least.



There is another case where in-network reassembly could be required
which is load balancing to a virtual IP address.

Any middlebox that uses state not available in all fragments MUST reassemble or keep equivalent storage/state to process fragments appropriately.

Like NAT though, in the long run I believe IPv6 offers a better
solution that would eliminate the need for VIPs.

That’s true right up until we end up in a world where (mostly) nobody correctly uses flow IDs. Oh, wait - we’re already there…

Joe