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

Joe Touch <touch@strayalpha.com> Thu, 17 January 2019 20:48 UTC

Return-Path: <touch@strayalpha.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 95C6912958B; Thu, 17 Jan 2019 12:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Level:
X-Spam-Status: No, score=-1.22 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, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 5ux_s3BTMyl5; Thu, 17 Jan 2019 12:48:32 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2761271FF; Thu, 17 Jan 2019 12:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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=otAxPyO6mMFJQrl53I30oPiASH/crmJyx95ibZRBOA8=; b=eW6xXPW5Jf7tj59tyJdanY032 ywhCyQdEEyiv+1Y4Thy6fg5LuTdG+LyS0Nl9W+2kIpdulYR4Bh6zX9oeF96ecrzHbqXdEOoXD2FLb VNQ+EVq2nQtW/yEgqy7eFHEcQ/F+TcLbSzYwwnJslmX0b1JHpoHLqoVgh1PNKyaSG/pq2DW3xv2u3 dk6G4PZh1Epxumx5/uts0kbQcVyO/bBohblQZxYNNHSkgUYw4YzBgmxgcggxvPwTIYq4qDAoQgxL5 6VMmE34Azt2Zb+vs1DTrj74z8Bn2KD4MCQNaXsuidJ9LRscsn0uexJfo+Gc3bQyQAr4IHyn+5eSph r+9xGeMuQ==;
Received: from [::1] (port=34700 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gkEaU-000maf-QU; Thu, 17 Jan 2019 15:48:31 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_543ec4e2eb2f957c49ea787a815a67d6"
Date: Thu, 17 Jan 2019 12:48:30 -0800
From: Joe Touch <touch@strayalpha.com>
To: Tom Herbert <tom@herbertland.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "internet-area@ietf.org" <int-area@ietf.org>, intarea-chairs@ietf.org
In-Reply-To: <CALx6S373eVDkwfZfbBT7wcOi4H-iV7a7eRA4Oe+WjVw7UDdDtA@mail.gmail.com>
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>
Message-ID: <27de569f15754d1c6844b0a019c7810b@strayalpha.com>
X-Sender: touch@strayalpha.com
User-Agent: Roundcube Webmail/1.3.3
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/DEEpVNl9fPX55kyzaJwu-tUy7eQ>
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 20:48:35 -0000

Hi, Tom,

On 2019-01-17 08:58, Tom Herbert wrote:

> On Thu, Jan 17, 2019 at 8:24 AM Joe Touch <touch@strayalpha.com> wrote: 
> 
>> ...
>> Hint - if a packet arrives on your interface with your IP address, you ARE a host.
>> 
>> Joe,
>> 
>> Conversley, if a packet arrives on your interface that isn't destined
>> to your IP address, you ARE NOT a host.
>> 
>> Correct. Note that the association of host with traffic counts for both transmission and reception, though.
>> 
>> I suspects that
>> implementations of in-network reassembly commonly make two incorrect
>> assumptions:
>> 
>> The first one is above...
>> 
>> 1) All fragments of a packet traverse the network device performing reassembly
>> 2) The first fragment is always received first
>> 
>> Neither of these assumptions are valid for IP.
>> 
>> Agreed, but again, there are three incorrect assumptions. The first is that a NAT isn't a host, and too often that's the one that causes the above two to actually cause pain.
>> 
>> If NAT is a host, then it is only a host in the return path. Packets
>> sent from the client behind a NAT have destinations addresses that are
>> not those of the the NAT device. If a device is performing host
>> procedures on such packets, like reassembly, then it is being done
>> outside the auspices of the standard.
>> 
>> Not quite. The return path is certainly easier to see, but the forward path doesn't *relay* the incoming packets; it consumes them. Which is what a host does.
>> 
>> The outgoing packets are emitted with the source IP of the NAT. So in the forward direction, strictly, only the *content* is relayed.
>> 
>> If that content is modified (i.e., address/port rewriting) or inspected, then that device is acting as a host.
>> If the outgoing HOST packets depend on something of the incoming ones, then that device is also acting as a host.
>> 
>> In any case, this isn't a NAT specific issue. Stateful firewalls
>> regularly process packets for which they aren't the destination.
>> 
>> And they are similarly bound by the rules of being a host *when they do*.
> Joe,
> 
> That's impossible. The first rule is that a host is defined as a node
> to which packets are addressed.

A second rule - per RFC 1812 - is that forwarding devices modify only
the opcount and certain IP options. 

> Intermediate nodes performing host
> processing on packets that don't have their address have already
> violated rule #1.

They consume those packets, they are acting as if they think all
outgoing dest addresses are theirs and assigned to their interface.
I.e., from the outside, they act exactly as if their interface has ALL
those addresses. 

> If they're keeping flow state in the network
> (connection state or reassembly), then that inevitably forces the
> requirement that packets have to be routed through a particular node
> in order for state to be maintained.

Agreed. And because they act as host, they fail badly when they're not
deployed under host assumptions and requirements. 

> This is not a problem hosts have,

It is - that's implicit in the function of their reassembly mechanism
and a reason why it's hard to deploy "virtual" hosts that live in
multipe places on the network (e.g., for single-IP load balancing server
farms, for virtual deployment of copies of a single IP in multiple
places, etc.) 

> and it's not required in IP that packets of a flow have to always take
> the same path to a destination.

Path, no - agreed. But *destination*, yes. Again, the host *is* the
destination. 

> Without additional requirements on
> deployment, stateful devices break multi-path.

Other way around; multipath breaks stateful devices (they don't work as
desired) when they're not deployed *as the hosts they actually are and
always have been* (at least when they perform certain functions we're
talking about there). 

> So if these devices need to *emulate* host behaviors then there really
> should be a specification to that effect.

When you act as a host, you have to follow the rules of being a host. 

> It's not enough to simply
> say they have to follow host requirements. 
> 
> They can't and they clearly
> impose additional requirements.

I agree they don't; it's clear they CAN (it would be costly). 

They don't impose any new requirements beyond being the host they are,
though. 

Joe