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

Joe Touch <touch@strayalpha.com> Thu, 30 August 2018 16:31 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 13D291294D0; Thu, 30 Aug 2018 09:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Level:
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" 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 vbIFi2Bix8WV; Thu, 30 Aug 2018 09:31: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 E4C65128CFD; Thu, 30 Aug 2018 09:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type: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=+LxcJQBrybyYyEFUWSh80Q9iu8L3NS7dzcyMiYWeEI8=; b=NhggNc4TXZskySwr1jpkwnD2k vb9i/MaLP8MCtDptW0dHBB7jPsa7H3q5f2ONqXTldJAW6k6MQtfoGscs6z56/9EJKPvQzktxruYBw XOEyIO05oIBtCcXJ1eGpMm+CFBj5vDO8gog13Ph8pUo3HGS1dVPw/Un4Xh4qaBZ/ThF95fbWIfX/u V3rMeFn/4tTR3UvSOwqY8ELsJmc12DOjkC+jjCi2Id34xLIICWz7M8MZHGv3K7Kw33xesWdTI0Jqu FDRUXh9013rWCgZkDu/yerNx4zVUHS4rNdc0W3Qiz5cBJte0cubEgbYSxWeZegwAEJZivetTxfCVI dS1+p9zcQ==;
Received: from [172.58.56.35] (port=20790 helo=[IPv6:2607:fb90:6c90:696e:25f7:f14c:d717:9171]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1fvPqa-000pfY-Rj; Thu, 30 Aug 2018 12:31:05 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <CALx6S34uvov_DT9ux93uo9YDj5yBAC9rqHApEuFQm-NC6ot0Tg@mail.gmail.com>
Date: Thu, 30 Aug 2018 10:31:03 -0600
Cc: Toerless Eckert <tte@cs.fau.de>, Christian Huitema <huitema@huitema.net>, int-area <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <17F03402-0E69-4723-9ABF-5BDCFD7E8FE0@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=UV mUBpREdeQ9Wshv=ZdTs3RLQLG9+nOr6ArjQ@mail.gmail.com> <11b0cc8e660ae288b283b6fb82f45b3b@strayalpha.com> <CALx6S34uvov_DT9ux93uo9YDj5yBAC9rqHApEuFQm-NC6ot0Tg@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
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/REGm7b5WHXY0MKNFh1sUCTauQ-E>
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 16:31:10 -0000


> On Aug 30, 2018, at 8:56 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
>> 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".

The coordination protocol is, and that’s all I claimed. 

> 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 would if they were, but they’re not. So I’m suggesting these devices need to add more state and work to clean up the mess they make. 

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

As they did for devices that don’t support v6. 

> 
>> 
>> 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!" :-).

That’s their problem and will increasingly render them less useful over time. 

Joe

> 
> Tom
> 
>> 
>> Joe