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

Tom Herbert <tom@herbertland.com> Thu, 30 August 2018 14:56 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 4B858130EBA for <int-area@ietfa.amsl.com>; Thu, 30 Aug 2018 07:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 eRuds5rXCHoS for <int-area@ietfa.amsl.com>; Thu, 30 Aug 2018 07:56:26 -0700 (PDT)
Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 968B4130E4B for <int-area@ietf.org>; Thu, 30 Aug 2018 07:56:26 -0700 (PDT)
Received: by mail-qt0-x242.google.com with SMTP id j7-v6so10307491qtp.2 for <int-area@ietf.org>; Thu, 30 Aug 2018 07:56:26 -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=TJxca0s/cZPHO+24DGsi1FL5c4AiJuzSMeWsBtBRzmg=; b=SHEoiSrC/JcnAEYK/zG/rYSy77vVLcSARMfwxADaPVzhTiyOXo082eGn9nuLM8TC64 jaNzg6nFe20MSgOJEpEerb6BNjAvpIK74Wti9JaDn7gJaN/8QZaZ4KNiQskTEEQPKhDW SpHBgppwkAxbSwYue8x7pDKlNaSAPDXvwnrKPLPfDZyjNeyZpJiQQXJKid65NiM+AVyR oNoYlG7nI8J+g9iAEixYrE1+Pj/5fytHbzTmREUnDvmuMtSCTqionllmAiwehCI9Y0X1 vu7TAyFYpwga2pQpadIRiv866MLvo531/JVafrMWznBNtkfIXlHtRXj2g0sX7EuFZWqt 6O8A==
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=TJxca0s/cZPHO+24DGsi1FL5c4AiJuzSMeWsBtBRzmg=; b=kyd1Ka3/38cs3lwr8I9jPgPypfhOA80AEROotm2DI5MlcOVonU2RXT5iXkiP8Slp8K KHY6fvMZ9K1G0VOemET/q6dS/SZ5rCaWircb146tDYgvuWLNSjlmu+iUQelVo2yrMC07 bIR8J2ExL5cH6JNBfRHo6ZPxUBhHfij6jMqKyho21ZcK0Qen7Rcz4KPvQcRgyB/CKlR3 4M8EAs9o/TwR3Sj4OQdK88hC6E5oXCMN6rVMP5JY9fGei5if8QueiU8V49U98ehWABMc stoTUYcFagIEe7kPPzm1tfvm+tAz4mYIs63PuiVHTLAfiW/BK3WXHlrAmSmDuvCpC3oU IwFA==
X-Gm-Message-State: APzg51DNIjzBRmBwOQptZxtY1wnk7sNWgfAbSO1K6TZNQ7YMA0IMQOkD XP46rI3mNjH3fsD2JW4CByB20+fjvWAxQEAXjb8Jsbgx
X-Google-Smtp-Source: ANB0VdbFvLkN6iRCeykg/2zxiqDoB0ll5gVnKC4j0EdZKZoaPiNhtq97A/BN//AmTUEaD68iV6NIVAoJsLCphGjZGro=
X-Received: by 2002:a0c:bd0e:: with SMTP id m14-v6mr11666308qvg.168.1535640985390; Thu, 30 Aug 2018 07:56:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3312:0:0:0:0:0 with HTTP; Thu, 30 Aug 2018 07:56:24 -0700 (PDT)
In-Reply-To: <11b0cc8e660ae288b283b6fb82f45b3b@strayalpha.com>
References: <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> <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>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 30 Aug 2018 07:56:24 -0700
Message-ID: <CALx6S34uvov_DT9ux93uo9YDj5yBAC9rqHApEuFQm-NC6ot0Tg@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Toerless Eckert <tte@cs.fau.de>, 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/qUq7xN7w-ihoEoszPbTOBl2zDp4>
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: Thu, 30 Aug 2018 14:56:29 -0000

On Wed, Aug 29, 2018 at 7:58 PM, Joe Touch <touch@strayalpha.com> wrote:
>
>
>
>
> On 2018-08-29 18:34, Tom Herbert wrote:
>
>
> Joe,
>
> End hosts are already quite capable of dealing with reassembly,
>
>
> Regardless, middleboxes shouldn't be avoiding their own effort by creating
> work for others. A corollary to the Postal Principle should be "you make the
> mess, you clean it up".
>
> FWIW, the idea of dumping just the first fragment and letting the receiver
> clean it up was tried in ATM in the late 1980s and it failed badly. It turns
> out that congestion isn't always a point problem - when multiple routers in
> a path are overloaded (which can and does happen), not dropping the rest of
> the fragments can cause downstream congestion that wouldn't have happened
> otherwise and then drops to other "real" packets.
>
>
> I
> think you'll find the average middlebox is not prepared to handle it.
>
>
> Sure, but that's a problem I'm hoping we can fix rather than encourage
> continued bad behavior.
>
>
> In truth, for this case it really doesn't save the hosts much at all.
>
>
> It won't prevent endpoint attacks, but it does mitigate the effect of
> useless fragment processing. And, as per above, it avoids drops to other
> packets that could/should have made it through.
>
>
> A DOS attack on fragmentation is still possible by the attacker
> sending all but the last fragment to a port that is allowed by the
> firewall. Also, a destination host will receive all the fragments for
> reassembly by virtue of it being the having destination address in the
> packets. As discussed previously, there's no guarantee that a firewall
> will see all the packets in a fragment train in a mulithomed
> environment-- routing may take packets along different paths so they
> hit hit different firewalls for a site. The answer to that seems to be
> to somehow coordinate across all the firewalls for a site to act as
> single host-- I suppose that's possible, but it would be nice to see
> the interoperable protocol that makes that generally feasible at any
> scale.
>
>
> Compared to other solutions proposed in this thread, that one is nearly
> trivial to design. The issue is having operators - who deploy these devices
> in ways that they should know need this feature - enable it properly (i.e.,
> point them all at each other).
>
Joe,

I would be amazed if firewall vendors consider this "nearly trivial to
design". Reassembly requires memory to hold packets, a non-work
conserving datapath, requires state to be maintained, and the
aforementioned problems of consistent routing of fragments needs to be
resolved. A middlebox would be performing reassembly on behalf of some
number of backend hosts, so the memory requirement for reassembly is
some multiplier of that needed by an individual host. Non-work
conserving means packets need to be queued at the device which
requires cache management and introduces delay. Requiring state in
_stateless_ devices is a problem, it's likely they have neither the
mechanisms nor the memory to support reassembly. And then there's the
Denial Of Service considerations... the middlebox is now an obvious
target for DOS attack on reassembly. We need to deal with this on
hosts, but the attacks are going to be worse on middleboxes. Consider
that a middlebox wouldn't normally know all possible hosts in the
network, so it may very well end up reassembling packets for
destinations that don't even exist! And on top of all of this,
applications are still motivated to avoid fragmentation for other
reasons, so I suspect vendors will view as a lot of work for very
little benefit.

>
> Further, acting as a host is always the right thing for any node that
> sources packets with its own IP address -- that includes NATs and regular
> proxies. The behavior of transparent proxies is more complex, but can be
> similarly reasoned from the appropriate equivalence model.
>
>
> Proxies aren't quite the same though.
>
>
> They are three different things, as noted in the paper I posted earlier, but
> they all are variants of requiring host behavior of some sort.
>
>
>
> An explicit proxy at least is
> both receiving and sourcing packet based on it's own address. NAT only
> sources or receive packets with their own address half the time.
>
>
> Sure, but there's more to it than just using the address...(see next note)
>
>
>
> Firewalls, never do and don't even need a host address.
>
>
> Transport protocols are endpoint demultiplexers and state managers; anything
> that uses that info and/or state is also acting as a host and needs to
> follow at least some host requirements too (all that apply to transports,
> including translation of signaling related to transport protocols and
> ports).

Maybe so, but at best middleboxes can only approximate host behavior.
Requiring them to perform reassembly is only addressing one symptom of
the disease. The real disease is intermediate devices that try to
insert themselves into transport layer protocols by DPI or trying to
infer transport layer state. Calling them "hosts" doesn't change the
fact that such devices will break the end-to-end model and ossify the
Internet. As they say, "You can put lipstick on a pig, but it's still
a pig!" :-).

Tom

>
> Joe