Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02

Jen Linkova <furry13@gmail.com> Tue, 13 November 2018 02:32 UTC

Return-Path: <furry13@gmail.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 ED390129C6B for <int-area@ietfa.amsl.com>; Mon, 12 Nov 2018 18:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0532juJS3F59 for <int-area@ietfa.amsl.com>; Mon, 12 Nov 2018 18:32:10 -0800 (PST)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 8A06F1277CC for <int-area@ietf.org>; Mon, 12 Nov 2018 18:32:10 -0800 (PST)
Received: by mail-qk1-x729.google.com with SMTP id w204so17033717qka.2 for <int-area@ietf.org>; Mon, 12 Nov 2018 18:32:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+4BL630t3ndSleQuzJHxn7H4C/2CFKsqznm/B9OvWO8=; b=aha1QFcxUF1C3ADzDnH/aNP4fNKJN2nnl8mhepDEfRB6LliKFnnKnVCXYFps48QE8H I7LW+b4LPle3F5F0qeCijLYEFXIXITb2XqFMLBg2vpv8Y0GegPxljJ+gDCBMaWN4ZAM7 8eM6LXDapFLKY77+qcI/WZFBCMtFAdC3uUGR9u+0WoMc8XjCbLlet+jDOulm48KXW2xc y5jxUb2T9pPnyFoh66IA7A/ZmMthJddpBgbrPQnr0ypVnaod/TOhR+p0Sh1x1+TSE99j 3iPszYD7rV5QmuU9cEd2jOpyci4l7TPLn+FSkdjOF17gezHlv19Evd3ae8VDPELY4A3K Ovgg==
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=+4BL630t3ndSleQuzJHxn7H4C/2CFKsqznm/B9OvWO8=; b=ar+0WuqpY9Ubn6flowIywUCuTfX0XpR2dvCkvri7D6gWhMMvvneLJLBJz/5j/W2Vjy 3NIQRpqLg7+J1Uvx/d02E6WGBCTi+hFWP6TDa1j0FsESDUw6VBaHW7yjWPPPYTrWeKCh ZK4E715GJe9J03YO5lkdjNaKrLHnoo8jPhv30MTzQlxgaYGA83oomME3Sg6dVvH0v9hJ TNw+49kPhq2/itGVOD9lS2IAJws0WGrHEInMqVr0UZpnCTx+2AV6gu9Ik0scfux1ub/W YOVN49K81M7wE0GNusSVDVt8Y8KLWvlDC50L5bQK3b9UKDLjDL16JcxXLs0QnBI7OsXo 05kw==
X-Gm-Message-State: AGRZ1gJGhHBFOE21imAb0PjrvC+kr6i5MCQnssQ26/d20BDEyKbaqxPl 4kjpI+Mf/22QvgsP9ABwlhURKjvyIOWYwfj0JQYdqxT6
X-Google-Smtp-Source: AJdET5dJeH5FbyEw2jvof52quQgHqDEq+Q8FLAIueb0EOcmO0rft5t6KLswFgu4Tnvh8r/x++AJSeHzWb6Mb7hmKZck=
X-Received: by 2002:ac8:7044:: with SMTP id y4-v6mr3189710qtm.325.1542076329484; Mon, 12 Nov 2018 18:32:09 -0800 (PST)
MIME-Version: 1.0
References: <CAFU7BARv90VcSaLsGOkxaSX+epix4Jz6ON2NShTO_fs=utKs0w@mail.gmail.com> <022EB775-2A35-43B9-9981-DEBAFF331370@strayalpha.com> <CAFU7BASZFCZFtHDtt=0x9pkJUpXb1V8fuo--H4bGktjEqmyZyw@mail.gmail.com> <C29D9C45-A6C2-438D-B738-A1455A581B92@strayalpha.com>
In-Reply-To: <C29D9C45-A6C2-438D-B738-A1455A581B92@strayalpha.com>
From: Jen Linkova <furry13@gmail.com>
Date: Tue, 13 Nov 2018 13:31:57 +1100
Message-ID: <CAFU7BAQROruKdAE-K+5MWSzkFDsSGiNUad+huy=Y-QgdeCyqfg@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: 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/9DdfB3XCo-V8tzTOx8GpOtn9EiI>
Subject: Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02
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: Tue, 13 Nov 2018 02:32:12 -0000

On Tue, Nov 13, 2018 at 3:13 AM Joe Touch <touch@strayalpha.com> wrote:
> >> Fragment forwarding is a MUST in our standards.
> >
> > I believe you are talking about routers supporting forwarding
> > fragmented packets, not about policy decisions. While the
> > recommendations in the draft (not to filter ICMP PTB messages) are
> > about policies.
> > So just another policy-related recommendation makes sense, IMHO.
>
> So first, what is the *policy* reason for doing this? The policy of “Rocket” (Guardians of the Galaxy movie)? “Because I really want to”?

Well, usually the security policies are based on "permit only things
you need, drop everything else". Therefore in many cases fragments are
dropped because it's not obvious why they should be permitted. My
understanding is that teh main goal of BCP is document the problem,
explain what would happen if fragments are dropped and provided
recommendations to those who are looking for such recommendations.
That's why I suggested to add one more explicit recommendation on that topic.

> However, let’s just look at fragments - who are you trying to protect by blocking them?
>         - endpoints can already drop whatever they can’t reassemble
>         - an endpoint that lets fragments interfere with complete packets isn’t implementing reassembly correctly

(Just to clarify: you don't need to convince *me* that dropping
fragments is not necessary a good idea)

> Let’s please not dance around the issue - the only policy at play here is “vendors want to make money lying about what they sell”.

My experience is different. It has nothing to do with vendors most of
the time. It's mostly about engineers who has no idea why they should
explicitly permit fragments, so those poor packets hit the default
deny rule. That's why the BCP makes perfect sense. If fragments are
dropped because vendors are lying about what they sell (not sure I
understand what do you mean, actually) then no BCP would change it..

> > If we already have a document which is saying 'operators MUST NOT
> > filter any fragmented packets' then
> > it would be nice to reference it in the draft.
>
> We don’t have a document saying they MAY.

Er...I somehow suspect most operators apply "Everything which is not
forbidden is allowed" principle, not the converse one ;)

Again, when an engineer builds a set of filtering rules, they would
look for reason to allow some traffic ('if I do not allow those
packets a service I need would break") and the BCP provides such a
guidance.

> >> *Additionally*, it’s bad practice to indicate “SHOULD” unless the text also explains why it isn’t a MUST, i.e., under what conditions it is OK to not forward fragments.
> >
> > Sorry, I'm a bit confused. Which standard would need to be updated if
> > the proposed recommendation is made?
>
> If you’re going to systematically drop fragments:

Now I'm totally confused. Nobody suggests to drop fragments. Quite the opposite.

-- 
SY, Jen Linkova aka Furry