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

Tom Herbert <tom@herbertland.com> Fri, 01 February 2019 01:03 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 06AC5131196 for <int-area@ietfa.amsl.com>; Thu, 31 Jan 2019 17:03:11 -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 w07Y6NBE21pm for <int-area@ietfa.amsl.com>; Thu, 31 Jan 2019 17:03:08 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 73724131195 for <int-area@ietf.org>; Thu, 31 Jan 2019 17:03:08 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id n32so5677668qte.11 for <int-area@ietf.org>; Thu, 31 Jan 2019 17:03:08 -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=rCr3bS9EV+FCmqPHsCpD/spHHcTE1KzqMFuJSP6zRZE=; b=H8I5zs8fYbWXmnYrHQ1smIF77alCvFpboxnwtz7r9UDYZfaTzQ6DJwAfseljoL3eIi 520ZdkgeyYY61b9DxAj0Ty4xtjRIY3J4i3TTzYjTLSXZTPIy4Z7RTziZ2uHKnjzaBEnB TDbPDuGtlyCY9iy+eU7+NgnrLr4KvmJnyyyqaQ+Urw2jC7tgjDZ5gNONartJgAx5JCnv yhM/M6eoNMuunG9LqaGp3MVegaFFvwgkJ1pVm9C/7ElsDKWu8K059Xypo4WP/a+qqh24 7n+LK546pcOWieDUnvq7s/2R01QjN+NJcsyNRjc/3m2dKE8dVbuaCgWOUcF2mpwejWQs wZ1Q==
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=rCr3bS9EV+FCmqPHsCpD/spHHcTE1KzqMFuJSP6zRZE=; b=TinG4HUE1RSh40ukkWN25vNFbDVRPn1IKsiTu/PbZUrtZO41csQGEBgfGsLMA564uQ KBfT7ciuUtdUaq8jWnhX9Zkhnbx6pPIlxkrAJ5cbLzPc3fi+M8r/nEGVKIzWemsT0POC fF9fS9iJiflPiQaFZxHUvz31uS26JENhYRq6nU2kMdJK4j+5KeBc6788O0KtP/IMrSJX uhJAKRpJuyFKBMgIHO57YC/RJR9j/El6vm/LEv9aWnJ3Z4ZpbPHSsgnNheKrpVzCI55y L3Hi7xLa7EU5lvQqIPnEqydp/hpb1AXLLu1rr0WVdxl4OCSZ1+fdvXhRG3Lm9D+aTjMK b5VA==
X-Gm-Message-State: AJcUukfbMSlQXpv2Fr+r5FkhknQpYBxhFFcGonRGgPWCjmicXBD8VY3C RIAfRIrlD+5KpBUdpvIuXVDH+FcyKPO1Gz4Ff9oprA==
X-Google-Smtp-Source: ALg8bN4pnwqfxKIclPb3S3wU3ZeOzPJjTFkjes8Lfx+eoNpQ80mIpNT6DQfKetgoKP1n86sp9/HKfyUnjzYM44nWuT0=
X-Received: by 2002:a0c:b407:: with SMTP id u7mr33233859qve.179.1548982987336; Thu, 31 Jan 2019 17:03:07 -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> <CALx6S3708uQN2cey8ZDWUKsRR0KUH_uEPk6JwUu4eY4h0Op6xA@mail.gmail.com> <C15D9D6B-4E88-4293-8B0F-C35580F4727C@strayalpha.com>
In-Reply-To: <C15D9D6B-4E88-4293-8B0F-C35580F4727C@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 31 Jan 2019 17:02:56 -0800
Message-ID: <CALx6S34EYFtCY6HiYsWO7-70kM=nhqd8MUDAQXhRfaWf7abnfA@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/tG3_uAdW_6B4ne3CrS3YNDXYw8M>
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 01:03:11 -0000

On Thu, Jan 31, 2019 at 4:43 PM Joe Touch <touch@strayalpha.com> wrote:
>
> Reassembly is described in detail in RFC 791.
>
That describes "reassembly" not "virtual reassembly". I cannot find
any IETF publication that refers to virtual reassembly in the context
of IP fragmentation. If it  is exactly the same thing, then why is it
different terminology? What makes virtual reassembly "virtual"? All
this may seem obvious to you, but for those of us that are uninitiated
it would be very nice if terminology is clearly defined before using
it in a standards specification.

Tom

> 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
>