Re: [Spud] related draft in TSVWG

Joe Touch <touch@isi.edu> Tue, 28 June 2016 21:49 UTC

Return-Path: <touch@isi.edu>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3E912D539 for <spud@ietfa.amsl.com>; Tue, 28 Jun 2016 14:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.325
X-Spam-Level:
X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham 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 GNSP_4uAaupO for <spud@ietfa.amsl.com>; Tue, 28 Jun 2016 14:49:27 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B1F12D537 for <spud@ietf.org>; Tue, 28 Jun 2016 14:49:25 -0700 (PDT)
Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5SLmZaj003806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jun 2016 14:48:36 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>
References: <57719746.6030304@isi.edu> <CALx6S34KiyVHs74TWhM=meypbB7BWkeJD-t_P76ZtkRY3Y+LXg@mail.gmail.com> <5771B2E9.6030304@isi.edu> <CALx6S37Y4U7ueDaZDdXyrSWvMF=TR6qZK18qS_XWGQ6caD3A=w@mail.gmail.com> <5771B940.50003@isi.edu>
From: Joe Touch <touch@isi.edu>
Message-ID: <5772F0B2.9090106@isi.edu>
Date: Tue, 28 Jun 2016 14:48:34 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5771B940.50003@isi.edu>
Content-Type: multipart/alternative; boundary="------------050601000604050507000903"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/t75EJ8b9wkNyUPsi177a9Jn2GBs>
Cc: Aaron Falk <aaron.falk@gmail.com>, Natasha Rooney <nrooney@gsma.com>, spud <spud@ietf.org>
Subject: Re: [Spud] related draft in TSVWG
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 28 Jun 2016 21:49:29 -0000


On 6/27/2016 4:39 PM, Joe Touch wrote:
>> Probably should also expressly forbid the network to modify options in
>> > flight, that is where things get really scary in the above ambiguous
>> > identification problem.
> Oh, yes. FYI, the OCS is just over the option space, not over the UDP
> payload, UDP header, or IP pseudoheader.
Thinking further on this, I have the following language in the update:

>> UDP options are intended for use only by the transport endpoints.
They are no more (or less) appropriate to be modified in-transit than
any other portion of the transport datagram.

UDP options are are transport options. Generally, transport datagrams
are not intended to be modified in-transit. However, the UDP option
mechanism provides no specific protection against in-transit
modification of the UDP header, UDP payload, or UDP option area.


I.e., I agree that these shouldn't be modified, but IMO neither should
UDP ports. The only way that such mods make sense is when they are
carried out "on behalf of" the transport endpoints, but again they key
is that "this is no different than any other portion of the UDP
datagram" IMO.

Joe