Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-13.txt

Joseph Touch <touch@strayalpha.com> Fri, 09 July 2021 15:06 UTC

Return-Path: <touch@strayalpha.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 62AF23A243C for <tsvwg@ietfa.amsl.com>; Fri, 9 Jul 2021 08:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 5FVeR8W1C7qg for <tsvwg@ietfa.amsl.com>; Fri, 9 Jul 2021 08:06:34 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A953A243F for <tsvwg@ietf.org>; Fri, 9 Jul 2021 08:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kBau7F0yJBQVHzdPhU+x2fzXMxVk8TZp/OCSjX9yzW4=; b=bbeslnzAVA5omAb0mfVCdo3cHz DXWHZSg2teCJoKz6CxDi6XfsstrRNfmvRe4vpIJRG2bR1TcfN5DMiPTQn2trxM+/oCvgxY55h9LEk 7UnLXsbJRrH4bP/ge8WVPErMsO1F04dRitDBi9sA5HAc4bzs33ptuCr/vt4SbF1+xpHpdWuR913Gr LHdw39wTYymd66sslT67A9a2nJ9LjAYCrVoxr7ofnSwqoh3iTj28X4EtxCZuKp4oS3yW5rUKztSkz UCUhmg8gJjJntnYMAzVHaBFCEI/E6C5leVovVenN44yd65TVHCNPjHzy9OA5ZRJJtLP6FXPtSJ601 OvBBVF0w==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:62224 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1m1s5E-000LVb-FY; Fri, 09 Jul 2021 11:06:33 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CALx6S373DmsGAncT8j2rGdpSfQ8q6pZi7iTVw4geZuxQdbA-sA@mail.gmail.com>
Date: Fri, 09 Jul 2021 08:06:27 -0700
Cc: TSVWG <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E26E6BD-9AC0-46FF-8BA5-EDA016F840CE@strayalpha.com>
References: <162408795080.21706.5548660195641640175@ietfa.amsl.com> <C2C396E7-B728-496E-841B-D9F64004D3E3@strayalpha.com> <CACL_3VHC55cdu96=5OuNKmaaXrvDY5wkYid9a+j6=VtQrvJhZg@mail.gmail.com> <5086F1C2-55C9-4BD4-BB80-9C247E379204@strayalpha.com> <CALx6S373DmsGAncT8j2rGdpSfQ8q6pZi7iTVw4geZuxQdbA-sA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uJCGgRuOvhplFlXvIuOucBiE76Q>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-13.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 09 Jul 2021 15:06:39 -0000

Hi, Tom,

> On Jul 8, 2021, at 10:13 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Wed, Jul 7, 2021 at 10:25 PM Joseph Touch <touch@strayalpha.com> wrote:
>> 
>> Hi, Mike,
>> 
>> On Jun 26, 2021, at 10:13 PM, C. M. Heard <heard@pobox.com> wrote:
>> …
>>   OK on most points, but I strongly object to the following when OCS is mandatory (as is the case when UDP CS <> 0):
>> 
>>      Note that a receiver can compute the OCS checksum before processing
>>      any UDP options, but that computation would assume OCS is used and
>>      would not be verified until the OCS option is interpreted.
>> 
>>   If I perform the computation before processing any options, and OCS is mandatory, it would be foolish of me to waste any more effort seeking the
>>   OCS option in the TLV chain. I already know that the option area is invalid,
>> 
>> How exactly do you know this? If OCS is mandatory, you need to find it (seek it in the TLV chain) in order to know whether the value you compute differs from the value in the option.
>> 
>> Performing the computation early just allows offloading if desired; the value computed still needs to be checked.
>> 
>>   and I should not try to parse potentially invalid TLVs. It is both unsafe and a waste of cycles.
> 
> If the OCS is in a TLV in an arbitrary position in the list, how is
> wasting cycles avoided?

Everything we’re doing wastes cycles by some metric, e.g., if the checksum fails or if the TLV needs to be parsed and there’s no OCS.

This issue isn’t whether it’s wasted cycles; it’s WHEN. If we force a fixed header in a fixed location, then parsing it is a waste to everyone who isn’t using OCS on every packet - which is bad design, because those are the users whose performance we should be conserving.

The approach in the doc does potentially waste cycles - but only when OCS is either far into the TLV or required and not in the TLV at all - e.g., because of corruption. Both are intended to be very rare events, so given we’re going to waste cycles one way or the other, IMO this is the better place to potentially waste them.

> It seems like we need to either parse the list
> fishing for the OCS, or start processing TLVs and throw out any work
> that was done if an invalid checksum is found.

If OCS is needed, you need to process *it* first - so even if you walk the TLVs, you aren’t doing any work on them except that walk until OCS is checked. 

Note that we say OCS *SHOULD* come first, likely only after NOPs, but we don’t need to force this. If someone wants to put the OCS later, then that’s their choice.

>> 
>> You can’t know when OCS is wrong until you find it in the TLV.
> 
> That presumes that the corruption causing the checksum to be invalid
> doesn't affect the ability to find the OCS TLV.

No; it’s a statement of fact. If you don’t find it in the TLV at all and it’s not required, it’s not wrong. If it is required (because UDP CS<>0) *AND* it’s not in the TLV, then you have an invalid packet (not an invalid checksum). Both will be detected. Again, the chance that corruption happens that destroys the TLV chain is possible but of low probability.

> However, if a data
> corruption is in the kind field of the OCS or if a length field of a
> previous TLV then the OCS TLV might no longer be identifiable in a
> packet. In these cases, the OCS is wrong

It would be missing. You can’t say something that isn’t there is incorrect except for being missing.

> however, unless the OCS is
> mandatory for this packet, we don't know the OCS is wrong and we
> incorrectly accept the packet.

Yes - that’s what happens.

> I have brought up this issue several
> times that a checksum in a TLV, like OCS, cannot protect itself from
> corruption; it would be great to see some discussion of this problem
> in the draft.

An error in the TLVs is likely to cause the chain to have a parse error too, at which point we would drop the options anyway.

Do you really think we need to discuss the case where:
	- the TLV chain has an error that hides use of OCS when it is optional
	AND
	- that TLV chain does not have a parsing inconsistency 
	(e.g., a length that is nonsense either in relation to its kind or jumps past the end of the packet)

We can discuss that, but IMO that’s a reasonable risk given it’s likelihood.

>> Additionally, the following paragraph, while an improvement over the -12 version, is still not good enough when OCS is optional:
>> 
>>>> When present, the OCS SHOULD occur as early as possible, preceded
>>   by only NOP options for alignment.
>> 
>> When UDP CS == 0, either that SHOULD needs to be changed to a MUST, or the receiver needs to be excused from bothering to check OCS.

It’s the sender’s perogative to use OCS even when UDP CS==0.

If the sender adds it, the receiver should process it if found. If the lack of a UDP CS causes undetected errors elsewhere, that’s a choice the sender made.

>> I must once again question the wisdom of ever parsing a list of TLVs that are not covered by a checksum (and I think IPv6 made quite a big mistake to do so with its options).

Doesn’t this viewpoint contradict the request to excuse the receiver you just made above?

>> I don’t see why SHOULD isn’t sufficient. First, it’s obvious that there could be utility in NOPs preceding OCS. Second, we don’t know what other options a user or implementer might want to occur first. You have to parse the TLV one way or the other to find OCS - even if it’s first. If it’s not, you still either find it or you don’t. Yes, earlier is better - but not MUST better. I see nothing that will not work if OCS is not first so no rationale for forcing this.
>> 
>>   I'd like to bring up another point that came to my attention during an off-list discussion with Tom Herbert, namely that optional checksums save no
>>   work for an implementation that has generic checksum offload; in fact, they create more work by creating more special cases. He makes the point 
>>  
>>   -- convincingly, as far as I am concerned -- that optional checksums are largely a relic of the past. My preference would be to see support for UDP 
>>   CS == 0 be an option that consenting endpoints may use but that are not required to be implemented.
>> 
>> I don’t understand what that would mean, but this argument appears to ignore the most important current use case - tunnels. Tunnel systems do not necessarily rely on offloading hardware because the packet processing occurs after the packet has already passed the interface, in many cases.
>> 
> A very common use case of tunneling is network virtualization where VM
> guests are sending TCP/UDP packets that are encapsulated by a
> hypervisor in VXLAN, nvgre, etc. In this case checksum offload of the
> transport checksum in the guests packets is important for performance.

Encapsulation by a hypervisor that uses checksum offload. Hmm. I’ll need to think about how that works - are you sending packets between processes of a CPU by sending them out to the network card and back?

Yes, hardware integration will require changes to make UDP options work. Some may be able to do this with just reprogramming, some will require new hardware. We can’t design solutions for only the hardware optimizations that exist today.

Joe