Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

Derek Fawcus <dfawcus+lists-tsvwg@employees.org> Sat, 13 July 2019 18:02 UTC

Return-Path: <dfawcus@employees.org>
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 506C11200F9 for <tsvwg@ietfa.amsl.com>; Sat, 13 Jul 2019 11:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.274
X-Spam-Level: *
X-Spam-Status: No, score=1.274 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=1.274, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 7VWLEjBoNB0l for <tsvwg@ietfa.amsl.com>; Sat, 13 Jul 2019 11:02:48 -0700 (PDT)
Received: from clarinet.employees.org (unknown [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1FF1200D6 for <tsvwg@ietf.org>; Sat, 13 Jul 2019 11:02:48 -0700 (PDT)
Received: by clarinet.employees.org (Postfix, from userid 1736) id C260A4E12933; Sat, 13 Jul 2019 18:02:47 +0000 (UTC)
Date: Sat, 13 Jul 2019 19:02:47 +0100
From: Derek Fawcus <dfawcus+lists-tsvwg@employees.org>
To: tsvwg <tsvwg@ietf.org>
Message-ID: <20190713180247.GA39770@clarinet.employees.org>
References: <CAPDqMeq9GjEQKukH1pZOTdE50e_rc3U6gpdxT-5qrS5phD0RGw@mail.gmail.com> <646D45AD-D79B-4BD2-A084-7DA97CE2C415@strayalpha.com> <CALx6S35grMA4uLYRGs4ioLfXBbS8zYN5ygprr=RKQ0hDk=Q1CQ@mail.gmail.com> <7EC37B50-45D5-4CF1-B113-205E55BF244E@strayalpha.com> <CALx6S34s7L7xo+26bt5Cdaqi4Es5Aci42GHk1WNKzugr5st-Gw@mail.gmail.com> <B525BF50-EFCC-44A5-A604-6CDDA914A1CB@strayalpha.com> <CAPDqMep3R6z9PRKkHyOvrh6sV9n5Sc0B++-zVz0FYJCwE6swrQ@mail.gmail.com> <E42A2AE2-F499-465E-BDE6-5EFC0AB20042@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936306138E9@MX307CL04.corp.emc.com> <f9f1701c2196c5db520d025294202353@strayalpha.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <f9f1701c2196c5db520d025294202353@strayalpha.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/yBMAJpqLdk3vwCA_9v04P-RhTyw>
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
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: Sat, 13 Jul 2019 18:02:50 -0000

On Thu, Jul 11, 2019 at 01:45:07PM -0700, Joe Touch wrote:
> On 2019-07-11 13:01, Black, David wrote:
> > Commenting as an individual, **not** as a WG chair.
> > 
> > -- Option Checksum (OCS)
> > 
> > The IETF 104 tsvwg minutes match my impression that the topic of whether the offsetting option checksum (OCS) should be optional vs. mandatory remains an open issue for UDP options.
> 
> Tom has kept this issue open for over a year; there hasn't exactly been
> a groundswell behind the issue.

Well strictly it is not just Tom, I also have expressed concerns about OCS,
and preferring to have a checksum field at some fixed offset.  I don't recall
what position Mike Heard took.

So I'd prefer the checksum as a fixed field, at either the start or end of
the surplus area, and probably optionally set to zero indicating not used.
The latter could then be of use in the LITE case.

Apart from the reasons already rehearsed in this thread, part of my concern
is simply the implementation robustness.

Having coding up the logic to efficiently parse and check an earlier version
of the OCS option scheme, the code becomes complex and fragile.

The alternate scheme of a fixed field was simpler, and also has the advantage
of allowing for a naive approach where the surplus is first validated,
then subsequently parsed (thus avoiding TLV parsing and verification until
after checksum validation).

DF