From heard@pobox.com Wed Mar 6 10:05:17 2024 Return-Path: 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 18C73C14F5FD for ; Wed, 6 Mar 2024 10:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 bDWkuhHgXRNS for ; Wed, 6 Mar 2024 10:05:13 -0800 (PST) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11091C14F5FE for ; Wed, 6 Mar 2024 10:05:12 -0800 (PST) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id CD0B81E4761 for ; Wed, 6 Mar 2024 13:05:06 -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=967IrFrhoR1Z7AjnLpE9k4vNuAM/E458 uhRsyesRE44=; b=QH70KEvf/nJpQ9s7NjzNpo4zzOEmdFUOHZjFfon/NTo8MYxz G/8hsJ1rznsRu+MIrMe1i3KhgTlXg0Bk3VMr5nwouBsMIW+a8XW+1xN73uDVGvtK uqp9Sij96NHOACXmKMPAVCGiqLc50h7poK16Tw8gAMbP8VxlgDujEZSHpqA= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 9BB001E4760 for ; Wed, 6 Mar 2024 13:05:06 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-ej1-f46.google.com (unknown [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 988621E475D for ; Wed, 6 Mar 2024 13:05:04 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-a293f2280c7so11392866b.1 for ; Wed, 06 Mar 2024 10:05:04 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCU/l0EDaUWnOAnvWuU+4Hu3QVJ09JFDLvIwVP5mwQGr7kaJH1m0YbSPnHwaajx0fze8PzU06PFeZP3+Vga96Q== X-Gm-Message-State: AOJu0YxvvIxVZJwvLzrNqmx6Lvttc8oZZtnllRbU3ACQ1V+QUO550lhp 96v9lDsuMZEyvB1ZDbpoc52ZOCKNor9Ovk9HbJwjv9kv5v9IUJVjDJPU4wwps9dM36BwpMAhCZG iOf6rPGlRNoB+mpT6YigILGbQCZg= X-Google-Smtp-Source: AGHT+IG6eXrJk4iXivV91Udoh3XN5ofVhLzGxurBqoP+cWdh3ItFPkKHwad2TSvfWINYCxzTtRFKnXiOXZTi3pUx9kE= X-Received: by 2002:a17:906:4e95:b0:a45:c01e:600c with SMTP id v21-20020a1709064e9500b00a45c01e600cmr1537976eju.33.1709748303477; Wed, 06 Mar 2024 10:05:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "C. M. Heard" Date: Wed, 6 Mar 2024 10:04:51 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Tom Herbert Cc: "Gorry (erg)" , TSVWG Content-Type: multipart/alternative; boundary="00000000000048cea3061301cc8e" X-Pobox-Relay-ID: 0F0A1512-DBE4-11EE-9975-78DCEB2EC81B-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-31.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2024 18:05:17 -0000 --00000000000048cea3061301cc8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2024 at 8:18=E2=80=AFAM Tom Herbert wrote: > The implication is that we can use an alternate CRC when the UDP > checksum is either not used or considered too weak. I think it's also > implied that any alternate to UDP checksum would need meet the same > salient requirements as UDP checksum which are: > > 1) Use of the checksum or CRC is optional only by the sender not the > receiver. From RFC1122: "Unlike the TCP checksum, the UDP checksum is > optional; the value zero is transmitted in the checksum field of a UDP > header to indicate the absence of a checksum." > 2) If a checksum or CRC is received then the receiver MUST either > validate that it is correct or drop the packet: From RFC1122 "If a UDP > datagram is received with a checksum that is non-zero and invalid, UDP > MUST silently discard the datagram." The requirements that you cite certainly apply to the UDP checksum, but where does 1122 or any other IETF standard say "or CRC"? Admittedly, the way that we have traditionally written our specifications creates that expectation. But an expectation is not necessarily a requirement. As currently specified, APC (and AUTH, when it is completed) will allow mutually consenting endpoints to use a stronger integrity check (or authentication). That makes them useful building blocks. And there is something to be said for having them be incrementally deployable. I recall a long-ago comment of Michael Richardson's that it was a historic mistake for the IP AH specification to require mandatory drop for authentication failures because doing so inhibited incremental deployment. Mike Heard --00000000000048cea3061301cc8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 6, 2024 at 8:18=E2=80=AFAM Tom Herbert =C2=A0w= rote:
> The implication is that we can use an alternate CRC when the = UDP
> checksum is either not used or considered too weak. I think it&= #39;s also
> implied that any alternate to UDP checksum would need me= et the same
> salient requirements as UDP checksum which are:
>=
> 1) Use of the checksum or CRC is optional only by the sender not t= he
> receiver. From RFC1122: "Unlike the TCP checksum, the UDP c= hecksum is
> optional; the value zero is transmitted in the checksum = field of a UDP
> header to indicate the absence of a checksum."<= br>> 2) If a checksum or CRC is received then the receiver MUST either> validate that it is correct or drop the packet: From RFC1122 "I= f a UDP
> datagram is received with a checksum that is non-zero and i= nvalid, UDP
> MUST silently discard the datagram."

The re= quirements that you cite certainly apply to the UDP checksum, but
where = does 1122 or any other IETF standard say "or CRC"?

Admitte= dly, the way that we have traditionally written our
specifications creat= es that expectation. But an expectation is not
necessarily a requirement= . As currently specified, APC (and AUTH,
when it is completed) will all= ow mutually consenting endpoints to
use a stronger integrity check (or a= uthentication). That makes them
useful building blocks. And there is som= ething to be said for having
them be incrementally deployable. I recall = a long-ago comment of Michael
Richardson's that it was a historic mi= stake for the IP AH specification
to require mandatory drop for authenti= cation failures because doing so
inhibited incremental deployment.
Mike Heard
--00000000000048cea3061301cc8e--