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

Joe Touch <touch@isi.edu> Fri, 10 July 2015 17:31 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 CD3061A037C for <spud@ietfa.amsl.com>; Fri, 10 Jul 2015 10:31:32 -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 BzwrJIHzLZ7k for <spud@ietfa.amsl.com>; Fri, 10 Jul 2015 10:31:31 -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 004101A0275 for <spud@ietf.org>; Fri, 10 Jul 2015 10:31:30 -0700 (PDT)
Received: from [128.9.184.209] ([128.9.184.209]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6AHVEGY002223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2015 10:31:15 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, Brian Trammell <ietf@trammell.ch>
References: <20150703151910.417.20312.idtracker@ietfa.amsl.com> <176C39DB-16F3-4E46-9A1D-22290A38FBA6@tik.ee.ethz.ch> <CALx6S37Eo6eAE4GTkAWGe+w0ZhDHyuMym7+txgjai5GRw+pgiQ@mail.gmail.com> <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>
From: Joe Touch <touch@isi.edu>
X-Enigmail-Draft-Status: N1110
Message-ID: <55A0015F.2090502@isi.edu>
Date: Fri, 10 Jul 2015 10:31:11 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CALx6S37Xy1gg0O-OmkMMdxbJoQmHDS79Z9ZoU92-kAsDfUbTrQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
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/uKEklVQAvGnS6yFWmsqmt7WqGPQ>
Cc: spud@ietf.org, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, 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: Fri, 10 Jul 2015 17:31:33 -0000

Hi, Tom,

On 7/10/2015 9:19 AM, Tom Herbert wrote:
> This "new network layer" breaks down at fragmentation. Only the first
> fragment carries port numbers and the embedded network layer
> information in the payload. Other fragments will carry neither, but
> still can carry IP options, DSCP, TTL, ECN marking, flow labels in
> IPv6.

Right. Which goes to the point that port numbers are NOT part of the
network layer.

Those who want to filter on port numbers are operating network devices
that act on behalf of endpoints - which is fine, but also means they
really ought to be reassembling the network-layer fragments.

I.e., the benefit of port filtering needs to come with the work of
reassembly. Or, "with great (filtering) power, comes great (don't break
the Internet) responsibility".

> An alternate possibility would be to embed IP options within UDP.

That would be a tunnel, and you might look at GUE.

However, you'd have the problem of the relationship of the inner and
outer options and how to maintain them as consistent if they're related.

Joe