Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

Joe Touch <touch@strayalpha.com> Fri, 01 February 2019 00:43 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 0D3E4131183 for <int-area@ietfa.amsl.com>; Thu, 31 Jan 2019 16:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level:
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" 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 bTDo39dhtLuB for <int-area@ietfa.amsl.com>; Thu, 31 Jan 2019 16:43:34 -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 BEA7E131182 for <int-area@ietf.org>; Thu, 31 Jan 2019 16:43:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=eKxc/uU9CXCO0O4W4GQBhuCh5DnZsMqOYneM9e0WOUM=; b=ZpE3PKvlBqReSUvb5c46tR2Tn PlbgGcfU/FoaU8I19BvycgG8C/7go1Omps+gmClf9NcnpRqAPrhZUg1d5sVSYkFL3ww4yyZrgdNL7 QEIvVwh/rSok4C+GlIaAVsvMWF7ayLjYMSZi+vM/H5Oy/PMTpCkdZeOPTs4z4olhUgJFzo02mI4yL TpUaFhQEFx8Hfu2tAUZjs/Q432FedMicmXQhIwgTgkKVjL2rZq0p2nlqtOrWMtEL7nt8yVZUtQeew t4lvgBs6gEuGvyhsWCzaVJy0W8h2z1qOQYfbCfUUuTsfXH32N8JQ5hbUdZ5N/E1vuUWTevXYMbN+v FK/Lew7HQ==;
Received: from [204.140.240.55] (port=62870 helo=[172.26.61.232]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gpMvc-002h5z-4I; Thu, 31 Jan 2019 19:43:33 -0500
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
X-Mailer: iPhone Mail (16C101)
In-Reply-To: <CALx6S3708uQN2cey8ZDWUKsRR0KUH_uEPk6JwUu4eY4h0Op6xA@mail.gmail.com>
Date: Thu, 31 Jan 2019 16:43:31 -0800
Cc: Ron Bonica <rbonica@juniper.net>, int-area <int-area@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C15D9D6B-4E88-4293-8B0F-C35580F4727C@strayalpha.com>
References: <BYAPR05MB424584AA4D0D11D7D0098B81AE900@BYAPR05MB4245.namprd05.prod.outlook.com> <CALx6S35-F_8L+QCcwN6--3TrrRdE5OG3vUACTEH03AmKYerLSw@mail.gmail.com> <BYAPR05MB4245604C8E234D72F42E0D8CAE910@BYAPR05MB4245.namprd05.prod.outlook.com> <10861CAC-3650-4B69-A8B0-437C2A3494CA@strayalpha.com> <CALx6S35XMV+7uXoGatsFEg7Bh+ueuHGVDZrXa8o4cSQKdON7iA@mail.gmail.com> <eb0cd9a4bd898310122ea77e0fade3f9@strayalpha.com> <CALx6S3708uQN2cey8ZDWUKsRR0KUH_uEPk6JwUu4eY4h0Op6xA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-OutGoing-Spam-Status: No, score=-1.0
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/TxRd-tUDAE2QyadsKgCMaWv_Orw>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt
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: Fri, 01 Feb 2019 00:43:36 -0000

Reassembly is described in detail in RFC 791. 

Joe

> On Jan 31, 2019, at 4:39 PM, Tom Herbert <tom@herbertland.com> wrote:
> 
>> On Thu, Jan 31, 2019 at 3:10 PM Joe Touch <touch@strayalpha.com> wrote:
>> 
>> 
>> 
>> 
>> 
>> On 2019-01-31 13:56, Tom Herbert wrote:
>> 
>> On Thu, Jan 31, 2019 at 7:59 AM Joe Touch <touch@strayalpha.com> wrote:
>> 
>> 
>> The problem with dropping the entire paragraph is the section title - talking about stateless firewalls begs the question of stateful ones. This is reinforced later in the recommendations. The sentences you remove were the only thing that tied the two together, which IMO is important.
>> 
>> 
>> Joe,
>> 
>> The term "Stateless firewalls" is unambiguous in this context. In a
>> stateless firewall, each packet is inspected and judge based solely on
>> it's content.
>> 
>> 
>> My statement above has no relation to any potential ambiguity in the term.
>> 
>> ---
>> 
>> However, the term stateless is inaccurate in a few places:
>> 
>> (Sec 4.6) NAT is a stateful procedure for an otherwise stateless protocol as well. The same could be argued for load balancers that retain similar state through a connection for a flow (i.e., not just hashing the flow or tuple, but doing round-robin per-flow/tuple 'sticky' routing)
>> 
>> (Sec 7.3) The problem is not just stateless middle boxes, but also certain stateful ones (e.g., NATs, some load balancers, etc.)
>> 
>> ---
>> 
>> Thus "stateful" actually is both ambiguous and inaccurate here.
>> 
>> You appear to want to distinguish between the state needed for virtual reassembly and the state needed to maintain NAT translations or sticky round-robin load balancing, but there's no simple term that differentiates them. They're both content-dependent, context-dependent, and stateful.
>> 
>> 
>> Further, as you note there are no *specified* algorithms for virtual reassembly, nor are there any *specified* for NAT translation table maintenance or sticky load balancing. Everyone comes up with their own and the basic concept is well enough defined as to not need a specification.
>> 
> In that case, if it's so obvious and well defined then there shouldn't
> be any issue in either providing a reference to a description or
> specifying it in the draft (if authors do choose discuss virtual
> reassembly in the draft).
> 
> Tom
> 
>> Joe