Re: [Spud] Putting Network-Layer Information in the Network Layer

Joe Touch <touch@isi.edu> Mon, 20 July 2015 16:53 UTC

Return-Path: <touch@isi.edu>
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 2F34D1ACEAF for <spud@ietfa.amsl.com>; Mon, 20 Jul 2015 09:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Vc2OrZUa69XK for <spud@ietfa.amsl.com>; Mon, 20 Jul 2015 09:53:28 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C428A1ACECF for <spud@ietf.org>; Mon, 20 Jul 2015 09:53:27 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6KGr7cU007957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 09:53:07 -0700 (PDT)
Message-ID: <55AD2772.7040809@isi.edu>
Date: Mon, 20 Jul 2015 09:53:06 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Toerless Eckert <eckert@cisco.com>
References: <7158BF85-8731-40A0-9920-36D21D73D7F2@trammell.ch> <CALx6S37w1J=v48gFCH18E-3UZyfC28_d_LTuKjC5VHtXC0eu2Q@mail.gmail.com> <5A64B99E-89C5-4D5C-BFF2-C5F0C25EC35D@trammell.ch> <559D8301.2020604@isi.edu> <006C9182-7352-4086-AF18-785AEFD44979@trammell.ch> <559EB134.2090905@isi.edu> <CB3FEFD0-1FE0-49D4-A650-349218ABD00A@trammell.ch> <CALx6S37Xy1gg0O-OmkMMdxbJoQmHDS79Z9ZoU92-kAsDfUbTrQ@mail.gmail.com> <AB3E8022-C3F3-4966-9EAF-193971D26F26@trammell.ch> <55AD204E.5080908@isi.edu> <20150720164609.GP1667@cisco.com>
In-Reply-To: <20150720164609.GP1667@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/URJHmWpT5efFDYw7LZzX_Ludbrk>
Cc: Brian Trammell <ietf@trammell.ch>, spud@ietf.org, =?windows-1252?Q?Mirja_K=FChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Tom Herbert <tom@herbertland.com>, touch@isi.edu
Subject: Re: [Spud] Putting Network-Layer Information in the Network Layer
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: Mon, 20 Jul 2015 16:53:29 -0000


On 7/20/2015 9:46 AM, Toerless Eckert wrote:
> On Mon, Jul 20, 2015 at 09:22:38AM -0700, Joe Touch wrote:
>> Yes and no. UDP has a length field, which means it's actually possible
>> to use space in an IP payload that isn't part of the UDP frame without
>> compliant UDP implementations breaking.
> 
> It's a nice possible trick, but it would break the ability to build an
> app purely on top of unmodified UDP APIs.

An unmodified UDP API, by definition, would not be able to do anything
except use vanilla UDP.

> Those APIs do not provide you
> with the ability to create a UDP packet with UDP payload + "metadata"
> payload after the UDP length. So you'd need to get support for this API extensions
> again in all OSs and programming language SDKs. 8 years minimum. 

It didn't take that long for MPTCP.

> Worse yet,
> there are likely  a good set of firewalls that would drop these packets.

Firewalls typically either look at UDP ports or part of the UDP content.
It might complicate firewalls that try to parse the entire IP payload as
if it were UDP, i.e., a device that didn't process the UDP length field
correctly. But that's a bug - we really can't build protocols to operate
over devices that do such things.

Joe