Re: [Spud] SPUD's open/close are unconvincing

Jana Iyengar <jri@google.com> Fri, 10 April 2015 22:24 UTC

Return-Path: <jri@google.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 73E511B2DCB for <spud@ietfa.amsl.com>; Fri, 10 Apr 2015 15:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7EMgn-DReE-L for <spud@ietfa.amsl.com>; Fri, 10 Apr 2015 15:24:11 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 81AA51B2DC9 for <spud@ietf.org>; Fri, 10 Apr 2015 15:24:11 -0700 (PDT)
Received: by iggg4 with SMTP id g4so9365217igg.0 for <spud@ietf.org>; Fri, 10 Apr 2015 15:24:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vl/mulvnqNWO6ZwSJUU/INjxlzZumgZmC9i2UQySuJU=; b=lcgvREseV9sJfQVXwwQD2m2k1FWGYTi3+u6c0FVpOLz46jR7e5tHT/tMH+gHhbGJHT +dZURM5YLdVW3GxGgD9hoVtIchtlOskblNLLMTj1/lJ2QMhuFVUH0y7qetqu6shNsPa+ lfbXvjMc0b9vctJQ/PX1lz4q32PO5kOM/KV8psFIhVVWR8EKTgokpqziFiKQbCsI2gEu I9FybAcV+u2N1rHy8oU24ZZ8scvw70606TqDnO0C0m98SNyIxCq+mEyse1N7WGFhO2LL LGvU9+1MGHV/jVwo2drIDPTKXueeMNB9rfVprZrPYax6cZEcK9A5pyu9bW9/52N8ufh6 wuNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vl/mulvnqNWO6ZwSJUU/INjxlzZumgZmC9i2UQySuJU=; b=iu/xQmvOYRZuHUBQlJqxss+yN3RyhYkKIoKeTTgqky1B8l3B3RcYmQrhh04ecEikg3 igdEWt79/yFS5X+DdEfgXpuwx1i3qr3JZRlaFCOQykMNQx14kuBK04jdP+HccQVNqIDP vwWkjcsxzshVf3j1Wyptu6xustIZneoh12bB8ir4AXfudQjPL6I1VjtbpllxoACubpB+ SSXGCp1LE2CKcXLl/+HBAngHKTNipgc7t2DXb/9wUJPlAaV7o9TgXc5XxsKqVIPQEJQO okLAM9DE9KLq5x7NxzZz8HaTPNGjT2btMrcKxChefol0sUu8Nu75PG/nuoUnZseGCIHp vGmA==
X-Gm-Message-State: ALoCoQm+xaLZEpLBh4iH3zGCbkIth5UfSphFadKImzT6qIZadSqrgrqSoruZV8RLXXu7PPorHKBl
MIME-Version: 1.0
X-Received: by 10.42.216.145 with SMTP id hi17mr6430626icb.63.1428704650991; Fri, 10 Apr 2015 15:24:10 -0700 (PDT)
Received: by 10.50.45.41 with HTTP; Fri, 10 Apr 2015 15:24:10 -0700 (PDT)
In-Reply-To: <D27BFEA4-11F7-4BA7-995F-7540C27C2E9C@gmail.com>
References: <87iod631nv.fsf@alice.fifthhorseman.net> <DM2PR0301MB06555C7D7F32A69214405D44A8FC0@DM2PR0301MB0655.namprd03.prod.outlook.com> <20150408193920.GD24286@cisco.com> <871tju2rdq.fsf@alice.fifthhorseman.net> <20150409012229.GG24286@cisco.com> <CALx6S35NH9yPZxeARTic10b0jFEi8aC4Gmt79cxuzF_VpYYqLA@mail.gmail.com> <20150409041507.GJ24286@cisco.com> <CAMm+LwgD8Foe=JdJvZ4oeuhGkJJvUaNOsCJATGDsRmBwN4en_w@mail.gmail.com> <CALx6S37PO+1_iqv44-QtNT_=ThMBbffOa-vNtG8wLSyFoGYU4A@mail.gmail.com> <20150409174603.GX24286@cisco.com> <CALx6S35ihypT_QGAaf08bmk3_P7XGLVbss0sgASkTuv+_e9NSg@mail.gmail.com> <D27BFEA4-11F7-4BA7-995F-7540C27C2E9C@gmail.com>
Date: Fri, 10 Apr 2015 15:24:10 -0700
Message-ID: <CAGD1bZYc2kNU+Hx-9p2DwQ+pmeyAgmN1yZabKSfVeLE7YUwwtg@mail.gmail.com>
From: Jana Iyengar <jri@google.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=20cf301cc73c36486c05136639ff
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/5Nvdcwid_vIBfWEAXEYVSWCEMdo>
Cc: Tom Herbert <tom@herbertland.com>, Toerless Eckert <eckert@cisco.com>, Phillip Hallam-Baker <phill@hallambaker.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] SPUD's open/close are unconvincing
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: <http://www.ietf.org/mail-archive/web/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 Apr 2015 22:24:13 -0000

This thread seems to gone far afield. To the original question, I still
don't see clear value in SPUD open/close bits, but it is clear to me how
these can both turn into trivial DoS vectors. Specifically, as I see it
even now,
- An OPEN bit carries redundant information.
- An ACK to the OPEN is a thing apps are likely to do, and we can expect
this to be normal behavior. But we don't yet know why a middlebox may need
this information to be explicitly present on the wire, or what it may do
with it.
- A CLOSE bit is unreliable from the middlebox's point of view, since apps
may not send it, and unauthenticated CLOSE bits are DoS vectors.

If these bits are not authenticated, they are all trivially spoof-able, and
they will be exploited for various sorts of DoS attacks.

On Thu, Apr 9, 2015 at 1:36 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

>
> > On Apr 9, 2015, at 9:40 PM, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Thu, Apr 9, 2015 at 10:46 AM, Toerless Eckert <eckert@cisco.com>
> wrote:
> >> Glad you didn't ask how SPUD can solve world peace, because i am
> >> still researching that aspect.
> >>
> >> There is a lot of work going on wit security models of device
> deployment,
> >> you may want to look at 6LO, 6TISCH, ACE, DICE, ANIMA and there is a
> >> lot more outside the IETF. I would see that work as prerequisites
> >> to move forward.
> >>
> >> IN general, i think there is one good and sane device operations method,
> >> in IoT which is to NOT upgrade the OS after initial device deployment,
> >> but just upgrade/modify applications. And with SPUD, that means you
> >> now can upgrade/fix/improve transport layer.
> >>
> > Well, there's already over a billion smartphones in the world which
> > are already regularly updating their OS and this hasn't yet led to
> > mass anarchy. You can certainly make avoiding OS updates and avoiding
> > OS in general a design point for your products, but this is not a
> > relevant design point or requirement for a networking protocol. As I
> > said, it's a red herring wrt SPUD.
>
> There are also over a billion smartphones stuck in an old version of the
> OS. Android 2.6 is very popular as is the latest iOS version your phone
> supports (lots of iPhone 4 out there, and they’re not getting iOS 8).
>
> And don’t get me started on desktop operating systems. By NetApp’s numbers
> just under 17% of desktop and laptop systems are running Windows XP. The
> majority are running the already outdated Windows 7.
>
> And those phones and desktops are things people are always looking at.
> Lots of people do upgrade the OS on their phones and computers when given a
> choice. How many people are going to want to upgrade the OS on their
> refrigerator, car fuel-injection system, air conditioner, or industrial
> sensor? Those things are deep into “if it works - don’t fix it” territory.
>
> Yoav
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>