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

Tom Herbert <tom@herbertland.com> Fri, 01 February 2019 00:40 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 216AF131184 for <int-area@ietfa.amsl.com>; Thu, 31 Jan 2019 16:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level:
X-Spam-Status: No, score=-2.041 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, URIBL_BLOCKED=0.001] 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 h7sESG8wS1rL for <int-area@ietfa.amsl.com>; Thu, 31 Jan 2019 16:40:09 -0800 (PST)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 C45D3131182 for <int-area@ietf.org>; Thu, 31 Jan 2019 16:40:09 -0800 (PST)
Received: by mail-qk1-x72d.google.com with SMTP id z18so3049879qkj.10 for <int-area@ietf.org>; Thu, 31 Jan 2019 16:40:09 -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=pTVAMAjNs4K/dIJDz+ndkQNhKPfhmXc73yDB78l2vAU=; b=RxNn8ZvwXU5xoVruBS7uffCm5mBVDB3fGYlHQyJFz6pFmRumrS033Fy0Z2P9iLgvvT FKSYErkVim0xbDHB4SeZL8CUo9CmieiL00nfhYt7hipJ+NS14LVhGOkG3og3Y7h0/DaZ hzRLA8Tj+ER6SIpjR3pPh/zDfy89Ip2YkfD45cIF32jWezy6BzZW5ASruuvMtLhLSvTX rqIyKQl/nGcriXrbIz+kVgkQP3jMG5uUMUci7U95WJ0kDiJpuSXkxEVQ+OwdrwR3T27N 4SGu21yfqFWzh4r3gkxYd8O8VK8yEDeZ1M1ZeNav3aVMPaSxirmQeTvdL9KSNBgb2e0l BOGQ==
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=pTVAMAjNs4K/dIJDz+ndkQNhKPfhmXc73yDB78l2vAU=; b=T70NhvKQnN5V789hcZ+EtVWBuGhaS3WNHzWAqh8TjxrwwUuzTOnzK/CI49PxorHv5Z +x20+1KF/hEnvRYb7ywz2flPAHChD4PG43NTIxKFsBSbVaL7wyB5ZdhA8BQm8dxwyATH b9HTJJGeXJSH5Wrtb05tzCDy7ELmL60/pYgEPBJ3KgVnqbmE0srVVmuiuU8KdQtbi0ov Mjs+bY+pip2ASt8s2YFpYQBfUf15xH0NY4K6d2TDQpLLOkui3I0Yoz18VBVlazwdnDzQ A3uImvpwg/3yt6mxTrNkdHvhfGMDA2aPeL1/qP1p0AeM7QqF1VeYwLTYKiH86P0bgWUU N3yQ==
X-Gm-Message-State: AJcUuke86PWj/Mpq1aF/gM1QiNRvmnQHa8uZI4fag8NRHUp1JlaikfBd 67dqkDXrbeXE4o/Vixtg8alliiem6iG1j0h4oSE0fg==
X-Google-Smtp-Source: ALg8bN6RggE8CFkm0mg3UebyVVDF5e7aTwGjuCMAh7WzXkSoBhE8UvK/bM1BZdghISSaE1rDrWL2/cHb5Bne7oa8zvU=
X-Received: by 2002:a37:5bc1:: with SMTP id p184mr34692971qkb.121.1548981608566; Thu, 31 Jan 2019 16:40:08 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <eb0cd9a4bd898310122ea77e0fade3f9@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 31 Jan 2019 16:39:57 -0800
Message-ID: <CALx6S3708uQN2cey8ZDWUKsRR0KUH_uEPk6JwUu4eY4h0Op6xA@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Ron Bonica <rbonica@juniper.net>, int-area <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/T49rAQq1u3L0i87Y9ZaXfUwxE_E>
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:40:12 -0000

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