Re: [Spud] New Version Notification for draft-touch-tsvwg-udp-options-01.txt

"C. M. Heard" <heard@pobox.com> Fri, 14 August 2015 18:35 UTC

Return-Path: <heard@pobox.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258591A1ADA; Fri, 14 Aug 2015 11:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 iDlkJh_2pnUN; Fri, 14 Aug 2015 11:35:11 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id E5CA61A1AC1; Fri, 14 Aug 2015 11:35:10 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 68DE36CE5E; Fri, 14 Aug 2015 14:35:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; s=sasl; bh=Rn/ kicWlC4qSnL6vwHFaxHybywQ=; b=OiRzS6rBDeHZpBACkLLgEGWWZxugwtFH3gw W1wXcB2UbMOVgsYUvaku4jtql2AGqEw/ajkK4F0bs7oPXVgPXq5JU6q8OFR6MkxY kPHkMwhxTXjFp8PXs/FgJ1/ZoH+1D4xbHqLfhEav6V1pvDSnxhXVrMS0WOiHhUgO n65oaMoY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; q=dns; s=sasl; b= l76t8VZKbyqBemz8yg7HI9phWkeyieDcCi0KKrQQ9+Bv74qRjvbVwoJUN3mw2TE0 YMCstAmKxeCrC/XcD8UIwQWIEwMpCszthJ1Sv+WJ83mYeJl05vwwsy0Q7cSVTa+p kMHu5dgcQO7X152SRrkbzn7qJpjZ0tbBD0FKPkuAves=
Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6126F6CE5B; Fri, 14 Aug 2015 14:35:09 -0400 (EDT)
Received: from mail-ob0-f182.google.com (unknown [209.85.214.182]) (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 E8CE36CE5A; Fri, 14 Aug 2015 14:35:08 -0400 (EDT)
Received: by obnw1 with SMTP id w1so67893566obn.3; Fri, 14 Aug 2015 11:35:08 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.24.7 with SMTP id q7mr4779917obf.43.1439577308471; Fri, 14 Aug 2015 11:35:08 -0700 (PDT)
Received: by 10.202.77.72 with HTTP; Fri, 14 Aug 2015 11:35:08 -0700 (PDT)
Date: Fri, 14 Aug 2015 11:35:08 -0700
Message-ID: <CACL_3VF5i7FvMR53R8JwRQAW--QJz3a+T9c_Pnwqt9D-baAJ-w@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
To: spud <spud@ietf.org>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset=UTF-8
X-Pobox-Relay-ID: 30C79B4E-42B3-11E5-83E6-63719F42C9D4-06080547!pb-smtp1.pobox.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/EH5Nxj_z5cnIO-WIUJK3E3fGMzY>
Cc: Joe Touch <touch@isi.edu>
Subject: Re: [Spud] New Version Notification for draft-touch-tsvwg-udp-options-01.txt
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2015 18:35:12 -0000

On 7/22/2015 09:52 AM, Joe Touch wrote:
> On 7/21/2015 11:22 PM, Brian Trammell wrote:
> > hi Joe,
> >
> > Thanks for this draft; I appreciate the elegant redundancy-reducing
> > length hack. :)
> >
> > Data in this case is, I know, hard to come by, but would you have
> > any feel for how much stuff out there will just break when they see an
> > inconsistency between IP and UDP length information?
>
> I have students starting this fall who will look into this and do some
> tests. We have no information yet.

In an off-list e-mail exchange with Joe a couple of weeks ago, I noted
that every host stack implementation whose code I have inspected simply
ignores bytes that are past the UDP length but within the IP payload
length.  The BSD-derived stacks trim the excess bytes before the data
is passed to the application via the sockets interface.  However, one
embedded stack I have seen (which does not use a sockets API) makes
all data available to the application, including the UDP header, and
lets the application deal with excess bytes as it sees fit.

I have zero information on the behavior of middleboxes (NAT/NAPT).

Assuming that Joe's tests confirm these observations for both end
systems and middleboxes, then the proposed UDP option trailer should be
incrementally deployable as long as all options therein can be safely
ignored if not understood.  The degree of utility (or, at least, the
length of time needed to make them useful) will of course depend
strongly on whether middleboxes trim the trailer or leave it intact;
if the prevalent middlebox practice is to trim it, then they won't be
useful without updating middleboxes as well as end systems.

Also, Joe, if you and your students have the time and resources to look at
what middleboxes do with UDP packets where the IP header indicates a
shorter length than the UDP header, that would be useful information, as it
could open up a possible means to incorporate fragmentation in the UDP
layer, independent of whether or not an options trailer is present.

Mike Heard