Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02

"C. M. Heard" <heard@pobox.com> Thu, 24 May 2018 18:09 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 0108012EADE for <tsvwg@ietfa.amsl.com>; Thu, 24 May 2018 11:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 bYBRc_xl8kAo for <tsvwg@ietfa.amsl.com>; Thu, 24 May 2018 11:09:39 -0700 (PDT)
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 23AD312EAD6 for <tsvwg@ietf.org>; Thu, 24 May 2018 11:09:39 -0700 (PDT)
Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B8980E7800 for <tsvwg@ietf.org>; Thu, 24 May 2018 14:09:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=oq2 rmzLAdFN+67toRG2zHOnMvYc=; b=kY9gCD5o+uIBb0l53GKAo4t/jjCaUjsqKfA qajbyto9iGd28+GXjYFqBrodsOJaGQcR3ZuQCyqgRUOMGhZPK95H7/D8mkERm7QP b9Hn3271vv204mQmPNeXs/gNftu8VpXRtI5O/YWEGxhqFXRsZbK3oulxjP8jeogv DaoBdf1c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= iqtfU6Qrd6bXVV+KMN2IEB/4N2sw/N4omh+6yDNS2VG7lGw6JT/q6uWt2UGGCxbH sM6HFhl4J3u7ADYcKAaVFiMR1HIRCQxFIb4F5s6CU9iuCGjQlcgBs5pUvBsFLeZU aonGHkZYNRBCNGxRlIhw0xMiLnnwk5Tz0mLb/DMuQ04=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B0568E77FE for <tsvwg@ietf.org>; Thu, 24 May 2018 14:09:36 -0400 (EDT)
Received: from mail-oi0-f41.google.com (unknown [209.85.218.41]) (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 414B0E77FB for <tsvwg@ietf.org>; Thu, 24 May 2018 14:09:36 -0400 (EDT)
Received: by mail-oi0-f41.google.com with SMTP id l1-v6so2302745oii.1 for <tsvwg@ietf.org>; Thu, 24 May 2018 11:09:36 -0700 (PDT)
X-Gm-Message-State: ALKqPwcX3+9zsGNywankcfTRBvoCCnZDVec9n2Myb+iHPGFtXr4XLo+S BBLkx+xuDf1kPC31OCNYryxruwF5LoSayaDR0nY=
X-Google-Smtp-Source: AB8JxZoHSayz4QH9tg2m7AQVrAX8vIe1Wk/fxikhE4gK/YsNbNiOrbclwQPawcqvPUmYwE2OLPzu22oFxkyLvhax7eE=
X-Received: by 2002:aca:917:: with SMTP id 23-v6mr4630277oij.119.1527185375638; Thu, 24 May 2018 11:09:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:88c6:0:0:0:0:0 with HTTP; Thu, 24 May 2018 11:09:15 -0700 (PDT)
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 24 May 2018 11:09:15 -0700
X-Gmail-Original-Message-ID: <CACL_3VGPVYydSEMiU3jkpDSJ6ps7HZC6uDMd86W9D8RNXtVnsg@mail.gmail.com>
Message-ID: <CACL_3VGPVYydSEMiU3jkpDSJ6ps7HZC6uDMd86W9D8RNXtVnsg@mail.gmail.com>
To: Tom Jones <tom@erg.abdn.ac.uk>
Cc: Joe Touch <touch@strayalpha.com>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: 9E1985E2-5F7D-11E8-8776-44CE1968708C-06080547!pb-smtp1.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Zp_SBUe-DVo0oTm2nRqApztwjv0>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 24 May 2018 18:09:41 -0000

On Fri, May 11, 2018 at 3:07 AM, Tom Jones <tom@erg.abdn.ac.uk> wrote:
> On Sun, May 06, 2018 at 10:23:54AM -0700, C. M. Heard wrote:
>> Section 5.5, LITE option: the following instruction
>>
>>    3. Swap all four bytes of the LITE option with the first 4 bytes of
>>       the LITE data area (Figure 11).
>>
>>
>> works only if the LITE data area is at least four bytes long. However, the
>> option will work just fine with 0, 1, 2, or 3 bytes of LITE data if one
>> simply moves the option to the start of the LITE data area and moves the
>> displaced LITE bytes just past the end of the relocated LITE option. This
>> operation is then reversed on the receive side. In effect, one is swapping
>> the locations of the LITE option and the initial segment of the LITE data
>> area of length min(4, LITE offset).
>
> A UDP Lite region greater than 0 must be a minimum of 8 octets.
>
>         A Checksum Coverage of zero indicates that the entire UDP-Lite
>         packet is covered by the checksum.  This means that the value of
>         the Checksum Coverage field MUST be either 0 or at least 8.
>
> So only the 0 coverage case must be considered by this document.

This is a misreading of RFC 3828. In UDP-Lite, if the value of the Checksum
Coverage field is non-zero, then the number of UDP payload bytes covered by
the checksum is 8 less than that value. So UDP-Lite allows for any number of
payload bytes from 0 to (MAXIMUM_UDP_DATAGRAM_SIZE - 8) to be covered by the
UDP checksum. The same range is allowed for the number of payload bytes that
are **not** covered by the UDP checksum. The objective for udp-options should
IMHO be to provide the exact same flexibility (modulo reduction of the upper
bound by the length of the UDP options trailer).

In UDP (protocol 17), even when augmented by UDP options, the minimum value
of UDP Length is 8, full stop; a value from 0 through 7 is simply an error
(see page 6 of the draft). The special meaning of the value 0 defined in RFC
3828 does not apply. But other than that, the meaning of UDP Length field
in the udp-options draft and the Checksum Coverage field in RFC 3828 are
(essentially) the same.

So we do need to deal with LIE data lengths from 0 through 3.

Mike Heard