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

Tom Herbert <> Thu, 30 August 2018 01:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61A06130E95 for <>; Wed, 29 Aug 2018 18:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0OhMBBGPsdLN for <>; Wed, 29 Aug 2018 18:34:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03472130EC5 for <>; Wed, 29 Aug 2018 18:34:20 -0700 (PDT)
Received: by with SMTP id g44-v6so8050903qtb.12 for <>; Wed, 29 Aug 2018 18:34:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=daFyHdbhhuL7xsCsvk1FY1cyAUdqacr0yQ4n1u7WTIE=; b=Gq/s1fzZ4VB39ME2sMVG/w6SIMRxFQsFMD5EqTvTSq0nZU4OJ5SzgyBkJUJbQzIt9u aLTySv89B/+6TutGq2NQjVY7T3RXDjEu4AW9rWe1lB/383tlVZ2jaZucBbyQhsltPfJj 5VG3E7IQpLuRd9HW5eWNhLfemhJUel0T+32FNJzSenMJr5i6CLhn5CpwlVDupU4Q+kkF 6fRfLeUYMG17ECFS37TL2gFL2Pen4mEQ1j6irYwxuyT6Z5RB6HNmurC/ORo9DyzIv7iO RV+EPMrI9lAVhXxHwwOrUo2ylQd2Y7VAh5t93AkYShyM2fWH/tbyb/xZJzhvQ3j6wpmz VeWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=daFyHdbhhuL7xsCsvk1FY1cyAUdqacr0yQ4n1u7WTIE=; b=f3FIoAMT0l/cFgbUjYWYIEpW8gzz2imfOQmUL4WmXcflcTcZEIWP4wTvcr5JKSqWY+ mez1HywJXXRlI3F+KrUxT72Uv6Cd08R0XtfummZzBHlJRi3W0bv7k1TG4nMEtG6VmmHQ ZSuAPK8k+QKcLGyJ+5xSMXnBw1tgDtkW9vQgN+EFtVTsKJJZK/EGZEfeDEssmbaTUcmz nv/QsZ3p84fRt0O+M/4L5Jp4lD0IqVcqQkCxTYfaXuo6hrrKL6edoFWfpD3QAWZA2zzc JRsjcQEKbXyf2LNMzviMIY4TBFsuUP3Tl8/R3lzLzPaEC9ot5gTEkRuoCkLGv42Fm4Ev SgiQ==
X-Gm-Message-State: APzg51BK4ijLKfQxSa4uI0Y0bewcnHM50VBFNhcNHgak9rTGW6iLbTxv IC8IMawvKUjCBHfIaBb7NOA83E5wKWUq4aYzGqdMO6YqMcAvbw==
X-Google-Smtp-Source: ANB0Vdagw/rqR3q2nKekDBhLiP27cCi1V7h7fK5w2WTn0QIZBweT6vbCOMA1qwXkcIdXtxle+qkwpPq6FYs0IchlKAw=
X-Received: by 2002:a0c:bd0e:: with SMTP id m14-v6mr9137163qvg.168.1535592858921; Wed, 29 Aug 2018 18:34:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3312:0:0:0:0:0 with HTTP; Wed, 29 Aug 2018 18:34:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Wed, 29 Aug 2018 18:34:18 -0700
Message-ID: <>
To: Joe Touch <>
Cc: Toerless Eckert <>, Christian Huitema <>, int-area <>,
Content-Type: text/plain; charset="UTF-8"
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 01:34:23 -0000

On Wed, Aug 29, 2018 at 5:32 PM, Joe Touch <> wrote:
> On 2018-08-29 10:38, Tom Herbert wrote:
> I don't think you need the part about acting as a host, that would
> have other implications.
> It does, and that's exactly why you do. In particular, this includes ICMP
> processing.
> Also, the reassembly requirement might be
> specific to NAT and not other middlebox functionality. For instance,
> it would be sufficient for a firewall that is dropping UDP packets to
> some port to only drop the first fragment that has UDP port numbers
> and let the other fragments pass. Without the first fragment
> reassembly at the destination will simply timeout and the whole packet
> is dropped.
> And that's a great example of why not reassembling (or equivalent) isn't the
> appropriate behavior.
> Yes, the packet will still not be delivered, but the receiver will end up
> doing a lot of work that isn't necessary. I.e., the middlebox has ignored
> work it was responsible for and caused work elsewhere.


End hosts are already quite capable of dealing with reassembly, I
think you'll find the average middlebox is not prepared to handle it.
In truth, for this case it really doesn't save the hosts much at all.
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

> 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. 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.
Firewalls, never do and don't even need a host address.