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

Ted Hardie <ted.ietf@gmail.com> Fri, 10 July 2015 16:25 UTC

Return-Path: <ted.ietf@gmail.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 9177B1A0127 for <spud@ietfa.amsl.com>; Fri, 10 Jul 2015 09:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 mYn-2BcTe5Qr for <spud@ietfa.amsl.com>; Fri, 10 Jul 2015 09:25:11 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 E9D331A00BE for <spud@ietf.org>; Fri, 10 Jul 2015 09:25:10 -0700 (PDT)
Received: by wicmz13 with SMTP id mz13so17842561wic.0 for <spud@ietf.org>; Fri, 10 Jul 2015 09:25:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yn4HaAPtbJmc8FbTnXwFuJI/oDFRa1mTCXT/hcnQvco=; b=IxbhjSCAGpmvRvbYUUUDloIpnc2sSoZrdWOZHQQMiZRfTNN53LRR3QvysRxitf+7cq iDmHeN4O83z6+H1FPerB1mSFrj+sJJtf2yf/UA3PIMynQOkpnFyMnJAc72MGQdUZM9PQ muAC1LlPaGuStp/bhJ2EIsDeVcbeVrV+pyjGNA2ytmvA351b0iR6E8RW5cwi9vcyQ5RU hRrDv5CdP1sqO+SgCrvEx1FZ+wSis6wiiOy6n+7YeV+efNlpLhAbM4fNd9G2KvbOfC9n 7/C0rbRDfr5VzTeWVqfTN0zaLkn9NmurjzuirucJvBpgurVkDoEQU0UnExqNEy0psV3f D/aQ==
MIME-Version: 1.0
X-Received: by 10.194.85.116 with SMTP id g20mr41509411wjz.154.1436545509699; Fri, 10 Jul 2015 09:25:09 -0700 (PDT)
Received: by 10.194.17.68 with HTTP; Fri, 10 Jul 2015 09:25:09 -0700 (PDT)
In-Reply-To: <CB3FEFD0-1FE0-49D4-A650-349218ABD00A@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>
Date: Fri, 10 Jul 2015 09:25:09 -0700
Message-ID: <CA+9kkMDUQJ7bnW2Njea4Ws0j=JrbXFAmJAcs906_hH+hs7jA+g@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary=047d7bfcfd50cf36bf051a87d03e
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/Bq_WLt4dfDlpCXPZlhnbi8RnZHk>
Cc: Tom Herbert <tom@herbertland.com>, "spud@ietf.org" <spud@ietf.org>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Joe Touch <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 16:25:12 -0000

On Fri, Jul 10, 2015 at 3:44 AM, Brian Trammell <ietf@trammell.ch> wrote:

>
> I've been thinking about whether it would be worth the effort to do an
> updated IP options transparency study.
>
> We revisited the safety of ECN in part because there were plausible
> processes for the situation to have changed -- the biggest problems that
> caused the Internet to be ECN-unsafe involved what were basically
> single-packet exploits against routers, and needed to be fixed for reasons
> *other* than making the feature work. (ECN *support* is another question,
> the answer to which is less cheerful.)
>
> I can't think of a comparable process making new/experimental options
> support less linked to connectivity risk in edge networks -- if nobody uses
> them (because they don't work) then if you try to use them and they don't
> work, it's your fault. That would unfortunately seem to be a rather stable
> state.
>
>

​From a research design point of view, I think you could construct such a
study so that your test nodes tried both IP options​ and SPUD, so I think
it is worth thinking about quite seriously.  While it is not the main point
of them, you might be able to talk the RIPE and MLAB folks into adding code
to their test devices to enable these checks.

More data is always good,

Ted