Re: [v6ops] [tcpm] Flow Label Load Balancing

Erik Kline <ek.ietf@gmail.com> Thu, 03 December 2020 15:44 UTC

Return-Path: <ek.ietf@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935633A0EAA; Thu, 3 Dec 2020 07:44:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 qo-N9eojRrwy; Thu, 3 Dec 2020 07:44:00 -0800 (PST)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 406B43A0EA8; Thu, 3 Dec 2020 07:44:00 -0800 (PST)
Received: by mail-ot1-x32e.google.com with SMTP id 11so2119750oty.9; Thu, 03 Dec 2020 07:44:00 -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; bh=+kFh6OdL+UxMA8YmIOFfjtBDc7L5ECoTMxS3zuGZvCs=; b=YbBL7UoB8stOdenoDlgvmWjmK0F9r/QusBVcjr2uzassJN4QyaRu4YT72i4RtHvahg Cvq57cdtNiqKFXPYXmYs25bVHEvRj0uOM4NNm5kvY40Izri3r36dqAhfWnFee8D7bKd0 n+HTgoBGUP2gMK/YLncMKcetKg/Ptw2wHCQ2na2dZDYoi4wQa6DOrT3TqylVDk/MoIX7 xsIbE7bWM8lkhj+4wSelSPjq3oIMpLa2xN/H/1EluIOGhidqbiAZi9BqcUhYzODdD2Ry TBVLlt/fVOYNMkiO4FNTf37Rz6t5aVEZFNfcsRJd6QHGHARW5CtQc8CzG/tJR2st/wf4 vMnw==
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; bh=+kFh6OdL+UxMA8YmIOFfjtBDc7L5ECoTMxS3zuGZvCs=; b=bVKu1cdZRNcO4oWxP5x6mhBDIKaOBk1zREjKgdD1f/9n0BU7Z9BefrDdug7byTw/AP +Rkdb91nLrmq+6xYRRUWD0esFFjKszx5gZmbIREFmO9BwtIJiVtFHU4AUpOHsnWvmWHT NOBsEO2mDa4ihI/1PMIL1383veBJQ7XclGibzYY1KPKg7d7xW0CwNIHmWWhXowPVtspo S2roF0/wfmrGyYMo8MN2URwokK5TfsiSmF8pi25RHjYzMuwZAdbJD3Q8H2obHrJe+8ey HH8T6sRPks/b9Bq7cUMF04HU9mX6eGPvoZxF9Gaw2aLldRxgogC9QRIae6+faOPmDwfC 9BRA==
X-Gm-Message-State: AOAM532z2hBA0Pd01lT//LXT4oBhfp5Di/MRpu+Hq6AEkDXzOzPPluhH 9G8iWv+xIwiWnGHnTHG+H9WQRCqTuWHnZHJN2lEnlOwL/t4=
X-Google-Smtp-Source: ABdhPJz8I3Inx3vi4c5yjmgSdh3eJCyyi7m44gfgI9Ijar4SI8PQlahAB2F2Lgb9mRVyQ4Vz6QqOkiCrXVPa9efRYNo=
X-Received: by 2002:a9d:62cb:: with SMTP id z11mr2444166otk.191.1607010239448; Thu, 03 Dec 2020 07:43:59 -0800 (PST)
MIME-Version: 1.0
References: <CAEGSd=DY8t8Skor+b6LSopzecoUUzUZhti9s0kdooLZGxPEt+w@mail.gmail.com> <d29042a7-742b-a445-cf60-2773e5515ae5@gont.com.ar> <CALx6S37+1duoNGR3dZWesHsZvx15kX9wCWufPMh=esvMaSMF_g@mail.gmail.com> <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <CALx6S37t4jump6S-R5_xdo5DF+RnHtT4rU5-RuiC-2GQ0PXxkQ@mail.gmail.com> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <CALx6S34uCrA1QdvLV8fpRKaJGLWMgtCmBCnrsBjU3TS+kXUs3Q@mail.gmail.com> <CAO42Z2xn_+7EVpjGyEU3aAdBmt1h=a4MPXFjjoTi_JeM2w9pkg@mail.gmail.com> <f66cbccd-55ed-375b-743b-7fc6c48a50c2@gont.com.ar> <CAO42Z2xqU4gs9iP=u_0Z16Qk+U24_YH0h5vTmJRJ5XZXZ0nweQ@mail.gmail.com> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <CAEGSd=A_e-db8m2VN+2wEuXj9e+GTq7brYfY_fwW7tysUr19Ng@mail.gmail.com> <CALx6S34xQF-PHQRqom_O8=amoRFmVrzHL-qh8765mtr1XnF2Wg@mail.gmail.com> <d59e1785-672d-8cc7-f844-51c64a440a57@gont.com.ar> <CALx6S373yLJwHigv4Yo-xdtRkZ9YsB0J9cwXqy0BWpwXSiHCPg@mail.gmail.com> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com>
In-Reply-To: <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Thu, 3 Dec 2020 07:43:48 -0800
Message-ID: <CAMGpriUb3WQqFhtDULy=Avbf8dWh1LsO=LBfvGUf3ozBAg7myA@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Tom Herbert <tom@herbertland.com>, Fernando Gont <fernando@gont.com.ar>, IPv6 Operations <v6ops@ietf.org>, tcpm <tcpm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OVG68xST2cfKEKA2Yy_6cel8vbM>
Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 15:44:02 -0000

> > Please include requirements for both hosts and network nodes. If there
> > is going to the be a requirement that hosts MUST make a 1:1 mapping to
> > a transport connection and the flow label MUST be consistent for the
> > life of connection, then I would expect there to also be a requirement
> > that the flow label MUST be immutable by all devices in the path-- in
> > particular the requirement of RFC6437 would need to be updated: "A
> > forwarding node MUST either leave a non-zero flow label value
> > unchanged or change it only for compelling operational security
> > reasons..."-- if hosts are not allowed to change a field they are
> > primarily responsible for setting, then the network should not be
> > allowed to modify it either.
>
> I don't recall _(of the top of my head) why we ended up making the field
> mutable ("SHOULD NOT  be modified" rather than "MUST NOT.."). IIRC, it
> had to do with allowing middle-boxes to mitigate FL-based covert
> channels.  If that's the case (Brian CC'ed) then, in retrospective, that
> seems to have been a bad idea.  -- I was part of the discussion, so I
> take my share of blame. :-)

My understanding/recollection is that since there were never any
restrictions on modification of the flow label from the very beginning
it wasn't super meaningful to try to close the barn door after all
these years.