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

Joe Touch <> Thu, 30 August 2018 02:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D03FE130E95; Wed, 29 Aug 2018 19:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PTjvrKn_sdp8; Wed, 29 Aug 2018 19:58:10 -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 AC63C12426A; Wed, 29 Aug 2018 19:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding: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=/rTKgiDf1/DjNB34JFfj71RWPXezdZEr7dvHXAeiA4c=; b=5Z9hbx3poQsK42OwtSduqHsI+ 24SI2FKWjfRNTM1vOgi9pgX2kviJu99n2Rwyx0Tn2OOiQbS8XDjffhFNxlwpfgnJNrqLJORq5nS3a 6HtO5e5ow/DGa9vLDoTjSPi2HgYnA+Twij0QDBLzbycukYzOm//jM8pK40iZy4+A69KAMyk7sh2jL IeeSXvSPQHbLDPu7/QhseidKk7Ol2gkr3M6AoiLvFwApbp4j3SIYvDg6LjuG/oZpHWFe9SgUlHF8Z UMUk+D826F8Fuqan8JPQYlWGpzHMtN3tGmvCK10mYf4xGMxGLT6CAmxN+bbLHKuRFlMABKdnQrL5T aBM9AZVyA==;
Received: from [::1] (port=34592 by with esmtpa (Exim 4.91) (envelope-from <>) id 1fvD9r-0012cO-6K; Wed, 29 Aug 2018 22:58:07 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_c5aef8c698d91f0e82813cc1c4a6081c"
Date: Wed, 29 Aug 2018 19:58:06 -0700
From: Joe Touch <>
To: Tom Herbert <>
Cc: Toerless Eckert <>, Christian Huitema <>, int-area <>,
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.3.3
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 02:58:14 -0000

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"

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

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

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