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

Joe Touch <> Thu, 30 August 2018 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13D291294D0; Thu, 30 Aug 2018 09:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.778
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: (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vbIFi2Bix8WV; Thu, 30 Aug 2018 09:31:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (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;; 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 [] (port=20790 helo=[IPv6:2607:fb90:6c90:696e:25f7:f14c:d717:9171]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) 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 <>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <>
Date: Thu, 30 Aug 2018 10:31:03 -0600
Cc: Toerless Eckert <>, Christian Huitema <>, int-area <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <CALx6S34WW4tj=UV> <> <>
To: Tom Herbert <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Aug 2018 16:31:10 -0000

> On Aug 30, 2018, at 8:56 AM, Tom Herbert <> wrote:
>> On Wed, Aug 29, 2018 at 7:58 PM, Joe Touch <> 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. 


> Tom
>> Joe