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

Tom Herbert <> Mon, 30 July 2018 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89191130EB2 for <>; Mon, 30 Jul 2018 12:13:11 -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 YFbbK86hEHkl for <>; Mon, 30 Jul 2018 12:13:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1946D130DD6 for <>; Mon, 30 Jul 2018 12:13:08 -0700 (PDT)
Received: by with SMTP id 26-v6so8580891qks.9 for <>; Mon, 30 Jul 2018 12:13:08 -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=8AGp7Gt6rYDFziBFhFW1MCFYaGUrbHNsmR0xSivBkCc=; b=OC9GPWW/Xv4uYmTMHSECm++PgCW7OzKmrH74tVX1b583qqXrkTT9AUnI/P+EUB3xth XdneEWGDv3mntlkJae0ijie7DbKPDRS82VQ7ZeK+3qJlAUHbt52emolMksp76dJL2D5J 1i5nf6Zw0NrANLeJRW4+vNsQazqcZ+OQUjtwpttlKEMEfWoDWWjiglteHD1bMsOZ4nbO ROgbVQ7q+Nubqd4czUs41He7RR2GU/WeElwn5Pssr0nuEAAJ4oNT+ReL6BpSVVc/oUvI RJXfn/a4Ebd3yo1qIpjIp3mETjAy6M+v6okNj5mfX/GPa6d1nxFrJv41yZGFfIjaJhox IDuw==
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=8AGp7Gt6rYDFziBFhFW1MCFYaGUrbHNsmR0xSivBkCc=; b=RCL36WZLiqw6+h/ppjqki/bN90+4rvKEvWvzCHLS90SO/SLJDl5RDNEWRMd9SH6nZa 1I0MXEeHUcx0o74xaS7uLWe5N9zWQk527/lTXTlQIg4gp9m5xVYpyDZXbAb0XunZxwLj XYOVB0jx+I6YwPrCaowA7Yqo6JPtM17SWb9fvdKAqOdNlYdoe7NfbXHhWHuwSJoKeMdH HWgQrDxlZ+ofXzMuOTNMHURIS29iKnz5zLH3Ye3lDROh9Q/b2vMUYqlmJjnXu+TQqCF7 YWnu51Vk3gKEfBZ1NDqqmk8hK0yxojDwGF+5aYNkb3+heD9iYmYT5fQHOe4Zwakcx79n V8AQ==
X-Gm-Message-State: AOUpUlFHMVwpUFZYrmBasDaNmJ3DNMpnAROkEizjOxsK409RNy1yWdhO /5GjkL+/qs9pzpYvs1q2/f0/TQgi5VMGHObXG4nixw==
X-Google-Smtp-Source: AAOMgpevHad+Tqr7U4l7ODgy2BNxW0XcotrthSyBrq8FVgTUsFDhVl9eFL2GXYnOzzyqsAfoxX0OV4D1iLNmqVQ+NdI=
X-Received: by 2002:ae9:c002:: with SMTP id u2-v6mr16736952qkk.391.1532977986987; Mon, 30 Jul 2018 12:13:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Mon, 30 Jul 2018 12:13:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Mon, 30 Jul 2018 12:13:05 -0700
Message-ID: <>
To: Joe Touch <>
Cc: Ole Troan <>, "" <>,
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: Mon, 30 Jul 2018 19:13:11 -0000

On Mon, Jul 30, 2018 at 11:50 AM, Joe Touch <> wrote:
> On 2018-07-30 11:16, Tom Herbert wrote:
> On Mon, Jul 30, 2018 at 10:34 AM, Joe Touch <> wrote:
> On 2018-07-30 08:11, Tom Herbert wrote:
> 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.
> It's not a requirement of the Internet and certainly not a core IETF
> requirement that packets always follow the same path. It's an ad hoc
> requirement imposed by _some_ solutions that have been deployed.
> 1122 requires that devices shouldn't be sourcing IP addresses they don't
> own.
> And any device behind a NAT would have a similar requirement - that the
> private side is setup such that any translation appears as a single device
> -- which means either that each host on the private side forwards all its
> traffic to one egress (as a stub net) or that the multiple egresses
> coordinate state to look like one egress on the private side and one host on
> the public side.
> I.e., the Internet architecture imposes exactly the restrictions you note -
> these aren't ad-hoc, they're derived from the Internet requirements.
> IP is packet switched not circuit switched. Other than the source and
> destination nodes, no two packets sent on a flow are required to
> traverse the same nodes, nor does there need to be any symmetry in the
> path between two directions of communication. If this is an incorrect
> interpretation of the requirements then please reference the RFC that
> states otherwise.
> RFC1122 says that an address belongs to one interface.
> So if you have a system that treats internet addresses as belonging to more
> than one device, that's on you to make sure they ACT like one device.
> You can have a host on the private side use multiple egress NATs for
> different connections, but the reverse traffic has to treat the two as if
> they were one device. If putting those devices in the middle of the network
> means you can't see the traffic to make that happen, then you've deployed
> the devices incorrectly or insufficiently configured them to act as a single
> unit.
> ...
> The mechanism (specifically the requirement that packets traverse
> intermediate nodes that are not addressed) breaks multi-homing. All
> the hacks and hoops we've had to jump through over the years to make
> NAT, stateful firewalls, and L4 load balancers work attest to this
> being a real problem.
> *traversing* intermediate nodes is not an issue. It's changing addresses and
> ports that is.
> Once you do either thing, you're a host - ONE logical host for every IP
> address you do this with. If you deploy a device that intends to act this
> way that can't see all the traffic it should be receiving - or deploy a
> device behind it that isn't represented by exactly one such device - then it
> is your device and/or its deployment that is broken.
> Oh, and I have no debate that people deploying badly designed devices and/or
> doing so in incorrect ways is a real problem. It's just not MY problem, nor
> do I think it should be the IETF's.


I agree, except that a BCP like this is making practical (and current)
recommendations that take into account the protocols have been
commonly implemented regardless of whether they are conformant. From
that perspective, it does seem to be IETF's problem. I think this is
reasonable assuming that it's clear why such recommendations are being
made. If they're being made in order to workaround non-confomant
implementations then that should be highlighted as such. In no way
should such recommendations be interpreted as acceptance of
non-conformance. The need for fragmentation cannot be completely
eliminated and we do need it to work. Devices that do things to
prevent correct operation still need to be fixed, and it would be
productive for the draft to include statements on how some of the
sub-problems problems can be fixed (like using flow label for ECMP
instead of ports).


> Joe