IETF Logo Mail Archive

Re: [tsvwg] Intdir early review of draft-ietf-tsvwg-udp-options-19

"C. M. Heard" <heard@pobox.com> Mon, 13 February 2023 23:08 UTC

Return-Path: <heard@pobox.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69CDC14EB17; Mon, 13 Feb 2023 15:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph2jbkedZ4cl; Mon, 13 Feb 2023 15:08:16 -0800 (PST)
Received: from pb-smtp21.pobox.com (pb-smtp21.pobox.com [173.228.157.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10931C14E511; Mon, 13 Feb 2023 15:08:09 -0800 (PST)
Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id D0B141DC739; Mon, 13 Feb 2023 18:08:05 -0500 (EST) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=AY3c336JFyj4kiftJI4MzRMMaz8JtWPZ yFDGjqZ/n0M=; b=OK7s+QBQMSAx3tznvFL2FSFhTsoROR0dXJAp8BlJJbQn5OUW 5obVmdKzXBZGDqOzpvB1CSWXASEX5O66BikUPzutgNPNfxfDjoWjAV6TW44ikm7N mLgEYsWvgaM3udWsKCQFTnYNuKG97oIKFGDqZ2Fph/ReLiFk9h/uz7FzFAs=
Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id C99EE1DC738; Mon, 13 Feb 2023 18:08:05 -0500 (EST) (envelope-from heard@pobox.com)
Received: from mail-ej1-f48.google.com (unknown [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id F1D4B1DC737; Mon, 13 Feb 2023 18:08:02 -0500 (EST) (envelope-from heard@pobox.com)
Received: by mail-ej1-f48.google.com with SMTP id p26so35693597ejx.13; Mon, 13 Feb 2023 15:08:02 -0800 (PST)
X-Gm-Message-State: AO0yUKU+DM2r7y0xvdYm87wju87hlGrVHb+OTtKaCcJ3V8jsrfAaR7pq pHKWwxgkFhCC/BuugTm9TrFoUPi7hkxMs/R1ll8=
X-Google-Smtp-Source: AK7set8Ay5QF2FU7/tPB2CCuN9QqW+HVjzOd90WdBjl/7/B/w9Jb86SlPbfJJuT5mc9JVFAfObW22X4gOBwRkiiGl0k=
X-Received: by 2002:a17:906:7693:b0:888:3594:6d5c with SMTP id o19-20020a170906769300b0088835946d5cmr316814ejm.6.1676329680889; Mon, 13 Feb 2023 15:08:00 -0800 (PST)
MIME-Version: 1.0
References: <167599146728.42049.10916891372133731811@ietfa.amsl.com> <CBCA1F49-73BC-4242-B162-2B743F23FAAF@strayalpha.com> <0E3756C7-E473-4B3A-9D6D-C43DA3C89C91@cisco.com> <CACL_3VHcMe87XnETGAzwpdPZK_HnY4KLKyHyyj-EXBo=WWNcMA@mail.gmail.com> <B743425D-38C0-49B8-B391-7AC6E51D9B1A@cisco.com> <CACL_3VFDHhmJL2_WXV60d-tyyfE8tkW8P6rwtcBOox4mxsHRzQ@mail.gmail.com> <CALx6S35T+H5ETDJVEawbOSs7EeBO7wbvmRSvH0+TfZiTXhK5cQ@mail.gmail.com> <CACL_3VFrtuDS4FW1xWzzdB4LGibrUWSvTgWi1ashh=D1hvFaNQ@mail.gmail.com> <CALx6S34qG0uv4tj1gzZxL7LZUeX6V1vEwYJ9A9Ybtszh074ovA@mail.gmail.com> <BB7783E3-273A-4D83-B4BF-BCE3DA00E609@strayalpha.com> <CALx6S36QovfwXjFmspVP4CgEOwmJzBLGX59c=zsvSGap8sX1gQ@mail.gmail.com> <CACL_3VFDQUjp5ez70RpyptZSOYvso2-QZsRvLhRNyU9p0iMayw@mail.gmail.com> <CALx6S34y6XttaEz_Uod4bSK50F-KArrv-V=HjKAb8v-9oWoM5Q@mail.gmail.com> <CACL_3VGKuk2HU1Hy4bZymUgPJqvhtzS_xSvZ987m58=fZAAXDw@mail.gmail.com> <CALx6S34dEdPgUvTQZda0qb-H3dERzo-3rjsnZ1MyscbJwJwvoQ@mail.gmail.com>
In-Reply-To: <CALx6S34dEdPgUvTQZda0qb-H3dERzo-3rjsnZ1MyscbJwJwvoQ@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Mon, 13 Feb 2023 15:07:49 -0800
X-Gmail-Original-Message-ID: <CACL_3VEhA-Jc_GH2isrJjYsheEp0phHdh71ZgRnvBW5tCKYR5A@mail.gmail.com>
Message-ID: <CACL_3VEhA-Jc_GH2isrJjYsheEp0phHdh71ZgRnvBW5tCKYR5A@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Joe Touch <touch@strayalpha.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-tsvwg-udp-options.all@ietf.org" <draft-ietf-tsvwg-udp-options.all@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: 4452C24A-ABF3-11ED-91DD-B31D44D1D7AA-06080547!pb-smtp21.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UeM5okcPdu_933XMT1CfduCyGNw>
Subject: Re: [tsvwg] Intdir early review of draft-ietf-tsvwg-udp-options-19
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2023 23:08:20 -0000

On Mon, Feb 13, 2023 at 11:07 AM Tom Herbert wrote:
> On Mon, Feb 13, 2023 at 10:28 AM C. M. Heard wrote:
> > Those servers can (and probably should) be configured to reject UDP
> > options with OCS=0, if they are not already configured to reject UDP
> > packets with CS=0.
>
> I agree, but that suggests that there are conditions when it's
> acceptable to not use OCS=0. What guidance is given for that? Just
> saying the user needs to figure this out themselves seems like a
> disservice; this is not the same risk as enabling a CS=0 for UDP. How
> can a user determine what is safe and what is not in their network?
> Note that it took two RFCs to describe the necessary conditions in
> detail to enable CS=0 for UDPv6. Do we need an equivalent discussion
> on when it's safe not to have the checksum in surplus space?

Section 7 of the draft currently says:

   Like the UDP checksum, the OCS is optional under certain
   circumstances and contains zero when not used. UDP checksums can be
   zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload
   already covered by another checksum, as might occur for tunnels
   [RFC6935]. The same exceptions apply to the OCS when used to detect
   bit errors; an additional exception occurs for its use in the UDP
   datagram prior to fragmentation or after reassembly (see Section
   9.4).

If this guidance is too slender, how should it be improved?

Mike Heard

v2.23.0 | Report a Bug | By Email