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

raffaele <> Sat, 29 February 2020 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5F7C3A0FEA for <>; Sat, 29 Feb 2020 09:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cg4Qdpr-Me08 for <>; Sat, 29 Feb 2020 09:48:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 932E73A0FE8 for <>; Sat, 29 Feb 2020 09:48:03 -0800 (PST)
Received: from ( [IPv6:2001:630:42:150::5]) by (Postfix) with ESMTPSA id 47A0C1B001C0; Sat, 29 Feb 2020 17:47:59 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 29 Feb 2020 17:47:57 +0000
From: raffaele <>
To: Joe Touch <>
Cc: "C. M. Heard" <>, TSVWG <>
In-Reply-To: <>
References: <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.3.8
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Feb 2020 17:48:06 -0000

On 2019-12-31 15:11, Joe Touch wrote:
> Hi, Mike,
> Many thanks for these detailed comments. They’ll be incorporated in
> the next rev.
> Joe
>> On Dec 28, 2019, at 2:53 PM, C. M. Heard <> wrote:
>>> - fix the figure and description of OCS to use a 16-bit checksum
>> The work on this section is incomplete, as it does not specify
>> that a two-byte pseudo header containing the length of the surplus
>> area be conceptually prefixed to the surplus area data. As noted in
>> that pseudo-header is necessary to fix the most common middlebox
>> traversal issue that has been found (i.e., calculating the UDP
>> checksum based in the IP payload length instead of the UDP length).
>> Since the result will not be an overall ones-complement sum of
>> zero, that language needs to be dropped from the draft.

Hello everyone,

I wanted to add one thing about how the pseudo-header (the Options 
length) is added to the checksum, just in case it hasn't been already 

In the current OCS design the potential misalignment between the start 
of the Options area and the OCS field is taken into account through a 
byte swap.

However, the misalignment between the start of UDP header and the OCS 
field should be also taken into account, when adding the Options length.
If OCS field is aligned with UDP header (and thus with UDP Length), the 
Options length should be added as-is.
If OCS is not aligned with UDP header, the Options length should be 
byte-swapped and then added.

Sorry for unnecessary caveat if you have already considered this.

Best regards,
Raffaele Zullo

>> I would also recommend that the next version of the draft
>> explicitly mention that for the purpose of the checksum
>> calculation the surplus area needs to be conceptually
>> padded by zero bytes that are not actually transmitted
>> if its start and/or end are on odd boundaries relative
>> to the start of the UDP data area.
>>> - define OCS as required when UDP CS != 0
>> Changes look good.
>>> - change ACS from a 16-bit CRC to CRC32c
>> Changes look good, but it should be explicitly stated whether it is
>> REQUIRED that an option-aware receiver discard a packet with
>> an incorrect ACS (which I believe is the intent of the draft) or
>> whether it is at the receiver's discretion (presumably not, since
>> ACS is listed as one of the options that an options-aware
>> implementation is required to support).
>>> There are more than a few other changes underway based on feedback
>>> from
>>> the last meeting. The concept behind those changes will be posted
>>> for
>>> feedback when developed further for WG feedback before being
>>> included in
>>> the next update.
>>> I.e., please don't treat the fact that the rest hasn't changed as
>>> anything beyond "TBD".
>>> Comments on *these changes* welcome, of course.
>> Editorial: section numbers for Echo (6.) and Experimental (6.1) are
>> incorrect.
>> Substantive comments later on the proposed path forward presented at
>> IETF 106.
>> Mike Heard