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

Joseph Touch <touch@strayalpha.com> Tue, 03 March 2020 01:47 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 1451A3A15C9 for <tsvwg@ietfa.amsl.com>; Mon, 2 Mar 2020 17:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 YCZjWNYeYskB for <tsvwg@ietfa.amsl.com>; Mon, 2 Mar 2020 17:47:45 -0800 (PST)
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 E91F93A15C7 for <tsvwg@ietf.org>; Mon, 2 Mar 2020 17:47:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=X/AjlL/D/QZsEZBmIGrD3QA7U6jceOb8IjsI+t84BsQ=; b=ZKyjIJHrAMJF57AqsfKzIHRl/ xAh5fFev6EO7SXMUvIkbBbdX8gLp6hoSKzevVywYKP2Te3SKJTPWBAgIBZxHkawfakWmTk1tbY8bv MHAnfhwN7T7AkC7mlTrSE5Vf6n3GGUAJ/E1fOK1JZlK/rgdGYEyBbSgB+2HrSIVYzpaO/H/rScXBf I+lrCxT7qnMiSkxq1ipCSIkIi3kiXxCpZE51w5QntiAl1IpGVLcvflK2GyGLvGjfDcufVhKmWpa69 KHhbZGLiPErp4xhjJ2Hwbx2UI1myb83puvkgfAvo82Qnlwc4uFd6YGtzXwf6hMXUODelMlq7isnDt vnp/SJJZg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50885 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1j8wen-001sD9-0D; Mon, 02 Mar 2020 20:47:41 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_4914D211-5AAF-4E70-85B3-AB7834FF6359"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <334042733f98a0ea044d77cc86b638c4@erg.abdn.ac.uk>
Date: Mon, 2 Mar 2020 17:47:36 -0800
Cc: "C. M. Heard" <heard@pobox.com>, TSVWG <tsvwg@ietf.org>
Message-Id: <E28554F8-E1BE-4EB6-A759-354ED583E3D3@strayalpha.com>
References: <156834756193.16526.1693311602903610372@ietfa.amsl.com> <3834716c-78ad-2272-d3cc-dfaf86c2cd68@strayalpha.com> <CACL_3VEdX-0kDNWXoUyOZAX21ucnBme1NE3U9EF5MGsS3JQF2g@mail.gmail.com> <F31E4A04-97E7-4514-B77B-4A6A3EA0CED7@strayalpha.com> <334042733f98a0ea044d77cc86b638c4@erg.abdn.ac.uk>
To: raffaele <raffaele@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3445.9.1)
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/S_r4U9TbzL2vAs7O_XzW7X2Onbw>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-08.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: Tue, 03 Mar 2020 01:47:50 -0000

I’ll check that - thanks for the pointer.

> On Feb 29, 2020, at 9:47 AM, raffaele <raffaele@erg.abdn.ac.uk> wrote:
> 
> 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 <heard@pobox.com> 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
>>> https://tools.ietf.org/html/draft-fairhurst-udp-options-cco-00,
>>> 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 considered.
> 
> 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