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

Tom Herbert <> Sun, 29 July 2018 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C24FC130E95 for <>; Sun, 29 Jul 2018 09:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 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] 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 NFyZqEm8uMyR for <>; Sun, 29 Jul 2018 09:43:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36EAD130E90 for <>; Sun, 29 Jul 2018 09:43:41 -0700 (PDT)
Received: by with SMTP id t5-v6so9840028qtn.3 for <>; Sun, 29 Jul 2018 09:43:41 -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:content-transfer-encoding; bh=DcIU4TqjB6bwmsZZCcFBfquOC6nfU3AIp4NX03ECSaE=; b=CaXZRM0Jf19OgRRmPNnqoNQ4svvvMfDm8iKP3OK4ioUsoY8IoP34kW1bUC3C28Suer TVR7t1AdqCgX31+qKHENRVwzuehkI9JxIlZTzLeFu88bbMPgeASeImoqWVXjZdXfEr8h MIR1XjD8aEwhZ4pLZZPwMz5Q0Jezy8VCgT7/lxIMLyCkkWRlBDMt4s+Nu1wxdpL0Kb5M mdcP235xuM6wquY8OyRphtul1EgNoE8mNs6inTdbs8vMawfelUux0pViVKAZLfaUFUmI aYxbKxe0LUQPDqc9M3JAZvGmo/IKYt8lLQSo8JSBRAIzYKp3xbXMI4UnZYA0OYWPMf+B l1vA==
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:content-transfer-encoding; bh=DcIU4TqjB6bwmsZZCcFBfquOC6nfU3AIp4NX03ECSaE=; b=cxnTAkgf8PyX9OOUFTPy/7M6zUHq9ioe2uJwpXhnVpny5R4sg0cUJxbTUHmifaGZhR AaqdHiiIwTbFBFe6YM8rAmZXlF9mC5tafGua71GLvIV2XPAhY/OM3rtBnnIo+5QuqSSg 8MJz0JsvXrBse9jBHCEovNMUcINrbFsdXGz7UE2PLMoA7PcEvtEhnJ/jMEQ5YN6U8Tij EA75Smg54y8QphiKfaaLPVLMhjlTr9dv1o1g4zULPiHBz0DrZZXeuzdmVQhKh5MXlaVO nJQsQ3WmJnf+AMhG2F5+gw7fmwNaSPFxUWQfTFqRSvq5k86Sj7ccggjXPEh/OarPTHtJ ujqQ==
X-Gm-Message-State: AOUpUlH96qMOp1ahSn/Tm/MLg0SP/Mc0GMf8g/RJEy04V3XzMLKu/vh6 6raxFzDSbSgSp15dP2K6OVdReYqqZcxe0KvYZ40Obg==
X-Google-Smtp-Source: AAOMgpeF6d3gdMj3RcdgsT4SrV9gsnNtasgQSs/nv8olRtbm07nO905EaZlJriqwbgwv7KnE1gym6VijnkFAMLA0iMU=
X-Received: by 2002:ac8:6648:: with SMTP id j8-v6mr13709010qtp.254.1532882620106; Sun, 29 Jul 2018 09:43:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Sun, 29 Jul 2018 09:43:39 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Sun, 29 Jul 2018 09:43:39 -0700
Message-ID: <>
To: Joe Touch <>
Cc: Ole Troan <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Sun, 29 Jul 2018 16:43:44 -0000

On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch <> wrote:
> On Jul 29, 2018, at 9:11 AM, Tom Herbert <> wrote:
> ...
> That said, there’s no real problem with a NAT *IF* it acts as a host on the
> Internet
> (see ouch, J: Middlebox Models Compatible with the Internet. USC/ISI
> (ISI-TR-711), 2016.)
> Joe,
> It's still a problem though. A NAT (or any stateful device in the
> network) forces the requirement in network architecture that all
> packets of a flow are routed through the same device.
> I didn’t make that requirement. The Internet does - it’s what it *means* to
> have an IP address.
> A NAT *has* the address of the packets it sources; if it isn’t the sink of
> that address, then it’s being used incorrectly. If it doesn’t reassemble
> those packets before translating them (i.e., by translating only
> unfragmented packets and dropping fragmented ones), then it is broken and
> ought to be returned for a refund.
> This has killed
> our ability to use multi-homing and multi-path.
> No, the Internet supports multi path between two IP endpoints and allows
> multihoming for a single address when managed by a single endpoint (physical
> or virtual).
> The disconnect is a failure to understand that a NAT *is* an IP endpoint.
> The term “middlebox” is wrong in that sense, at least it’s not a middle box
> to the Internet (it is to the device behind the NAT).
> The best way for an
> intermediate devices to deal with transport layer state is to be an L4
> proxy. The intermediate is a host endpoint for the proxy connections,
> but then that has its own problems since it breaks E2E functionality
> (like TCP auth). So the only real solution is to eliminate transport
> state from the network.
> That would work only if the network didn’t look at or modify transport
> information - and it did work when that was the case.
> I'm still holding out hope that IPv6 will
> start to obsolete use of NAT! FAST (draft-herbert-fast-02) is intended
> to provide a viable alternative to stateful firewalls.
> Getting rid of NATs is only part of the problem. Anything that does DPI is a
> problem when it discards messages it can’t parse because they’re fragmented.
Right, that implies that we need to eliminate the motivation to do DPI
by providing a better way to get the same functionality. This is what
FAST proposes. Transport related information of interest to a firewall
is in Hop-by-Hop options. So middleboxes will look at HBH options
which come before fragment EH. No DPI needed, no issues with
fragmentation at middleboxes, and, as a bonus, HBH options are the
only mechanism defined in IP protocol that allows data to be changed
in flight (this will be important property as in-situ OAM starts to
get traction).


> Joe