Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

Tom Herbert <tom@herbertland.com> Thu, 17 January 2019 23:46 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86AC130F8B for <int-area@ietfa.amsl.com>; Thu, 17 Jan 2019 15:46:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHQygZ3ka2gw for <int-area@ietfa.amsl.com>; Thu, 17 Jan 2019 15:46:28 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC75E130FD1 for <int-area@ietf.org>; Thu, 17 Jan 2019 15:46:27 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id c21so7092375qkl.6 for <int-area@ietf.org>; Thu, 17 Jan 2019 15:46:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ki1f7GobU0LAkkh38Hd1StBuHFUMn1FFCTik2e6FXjc=; b=KrkRwImw2atMkfz+8ClYm9TXcHl4QXS8gQS949ZUr1JDVCemFHC8O+zg6jaKjA78BM ioxuCpYeGrZvJB2/lKoMr9NXqOZPI2H8ekXlCeVKtCXc4N1RH3fBDfj3gjEhQWVBCUWg w/0k7GDArXBGlvZfvJhnCJXUk8rOBkh1T6w5AC/VWnczxABfQNKFNmkrbWocGmlHyTyU 1tRJ6kGBkroyRIRxD3Ptw8zNEA4/vcCelnezF2jKmk4m9IFMk5w6OVA7jnoG4NNb4sr6 /pfqDUQSfy2Vs6Co+n1dbA66d5xZ32/2xmKq63k3b5TBVlV37T2i3m/DTfYFuhi52keM Uqvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ki1f7GobU0LAkkh38Hd1StBuHFUMn1FFCTik2e6FXjc=; b=GElddm0GCmx9MDo2IZc6wgumElr/oei76HwmDi7S8grTb6A6gS/sYlQe03rOuVJ5Ce 8VyKA4qrEBPg6r/m2JRnedz1bvlDYQsel6YLwrC5QJInuXnE3pn9TbBe3I0flOGTfyv/ fydlrj/xgMehgT634hUtakzXWW85htrcVzWC1nt0Dk4vntWvBL2UxGX+zedxp4RvNn4K Jol87IvKwCWEU7czuQtbTl6Tr7YobTIoef53ep4B1x/Xb6Qj5hVh15FZzBF+wmsSPe5F FjOozTWfRBTmm85CNVmqQLchOWa/3QaV2pnmzJHd/z5QghG8DFeSk/7tm1VrrjMkWqAL uOPQ==
X-Gm-Message-State: AJcUuke5WNOoqGPVID6sAvuI1gRPeWdfP33cSuLKUz0tICyjG5/KYUUj mG4zQeojclNgzNZn3jW77Kw3tf7RSwvcxrDOg7eSmvxt
X-Google-Smtp-Source: ALg8bN5Q2HcqagtgRbDHfOuRR/7dyfqBSx6IY1YE4tiyw9kYizBjY8M1zTJ7G7rvtO514sWj4XXHvbwqY/ZgRMnIPrI=
X-Received: by 2002:a37:b482:: with SMTP id d124mr13177734qkf.168.1547768786518; Thu, 17 Jan 2019 15:46:26 -0800 (PST)
MIME-Version: 1.0
References: <D060DC26-15C7-4D3F-A3C5-641072C75CC5@ericsson.com> <4a283194-98f5-8f38-211a-29cfbc4c9c3e@joelhalpern.com> <CALx6S36btHxs0UTjahSMXEmOgfnQMAD+xYVFam=vKvQQfvOVdQ@mail.gmail.com> <984bfc0f-8e48-ca87-8f5c-064ae290bb0e@strayalpha.com> <CALx6S36bvohww=X8T_Yc7MmVWnD04hFmgvfW2VEEa-F-kTPERQ@mail.gmail.com> <31109D45-3F4A-45A5-99B9-386B045CF81B@strayalpha.com> <CALx6S35jigE3YapYN8uPg7bP_FPfA71iyDApF8D_AJZK_jAu_w@mail.gmail.com> <90788fb5f4ab20c1c262a40baf1db11d@strayalpha.com> <CALx6S373eVDkwfZfbBT7wcOi4H-iV7a7eRA4Oe+WjVw7UDdDtA@mail.gmail.com> <27de569f15754d1c6844b0a019c7810b@strayalpha.com> <CALx6S37LMrUPZC8sdWkQmZivQ=19WTEQEUWKSDgdeKnqhtCO=g@mail.gmail.com> <D9585D2D-BC2C-4C79-AD9C-8FE69231A976@strayalpha.com>
In-Reply-To: <D9585D2D-BC2C-4C79-AD9C-8FE69231A976@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 17 Jan 2019 15:46:15 -0800
Message-ID: <CALx6S35CNVya=f1mpP0SqKoLonHGvOGx7ZYMUaF_qcFybbJSzg@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "internet-area@ietf.org" <int-area@ietf.org>, intarea-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/gf59QITgYOA8WOyu6Mr-7vUwKrk>
Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jan 2019 23:46:30 -0000

On Thu, Jan 17, 2019 at 3:17 PM Joe Touch <touch@strayalpha.com> wrote:
>
>
>
> On Jan 17, 2019, at 1:09 PM, Tom Herbert <tom@herbertland.com> wrote:
>
> Joe,
>
> When they attempt to do host processing on packets that don't belong
> to them they're not hosts.
>
>
> They are every host for whose packets they process.
>
> And when they do this, they impose a new
> requirement that hosts do not have which is that packets for some flow
> must consistently the traverse the same intermediate node.
>
>
> It’s not an intermediate node - it’s a host. It’s the same requirement as any host - that a host has one point of attachment to a network for a given IP address.
>
> In any case, as I said previously, reassembly is only specified as an
> operations at destination hosts.
>
>
> And these are destination hosts because of how they behave, which means they need to reassemble (either actually or logically).
>
> It seems like there might be a need
> for in-network reassmbly, or some nodes might be doing it already.
>
>
> It’s not in-network - it’s at a host, but yes, some do reassemble (or its equivalent).
>
> But, in that case we really need the specification of the protocol to
> have a meaning discussion about it.
>
>
> RFC 791 and 1122 provide everything that is needed.
>
> It’s not new, it’s just not an “intermediate” node. Never was.
>
Joe,

You can try this experiment. Provision two stateful firewalls as
egress points of a network. From an internal network network host
connect to an external host of the network. Now changing routing. If
packets to the external network were being routed through firewall A,
changing routing so they go through firewall B. Now take a look at
what happens to packets on the connection. They are dropped at
firewall B because it does not have the connection state that firewall
A has. The connection is no longer viable. You can call these devices
whatever you want, but that doesn't change the fact that stateful
devices in the network, including those that attempt reassembly, break
multi-path.

Tom

> Joe