Re: [Spud] OS updates on embedded devices

Tom Herbert <tom@herbertland.com> Fri, 10 April 2015 00:07 UTC

Return-Path: <tom@herbertland.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 16A631B37AF for <spud@ietfa.amsl.com>; Thu, 9 Apr 2015 17:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 OE7gcewD8FTt for <spud@ietfa.amsl.com>; Thu, 9 Apr 2015 17:06:57 -0700 (PDT)
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (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 437A31B37A9 for <spud@ietf.org>; Thu, 9 Apr 2015 17:06:51 -0700 (PDT)
Received: by igbqf9 with SMTP id qf9so5450619igb.1 for <spud@ietf.org>; Thu, 09 Apr 2015 17:06:50 -0700 (PDT)
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 :content-transfer-encoding; bh=Q941hPLU8m3L9yyJRhQg/WWK0Hdq2eyFOReLs+K1PaE=; b=RosEy5Of6VMUWvPHS3Un4SkPbo+T0Iz1598a8vNcJySu0ovGapVWcpqNdj09S+cVZX IpnHzuCYUwgWtRf+FaKyWdwyBwpDraPFMXsNwpkSTPveVo1OxcPPYbbUwIRjsNQ70QAb dD6rBt9ykQmHfqkoLyKlmSqL0Mv83gQPOsspCp0o95vQPQGCotWxFq3IJRnaYCCqz26l rb0dHzM5mNXgqxe4GHea+j1nXQUurwNYKFoKDatloDsO61Moyf8tQK+W5sf1yUHQ/pU8 k7V0Pke1eA/u73wQpiTIo1F8ADZvi8DCj2tYlmsVL9L2WAdfoKMaXvIVagaS5gpQMdd2 Xj0w==
X-Gm-Message-State: ALoCoQlazmHNtmwEurN1Tsb39CLJZPHQrnpS2SFnbCfVes4uuK4ZelGWd7DtBGBEH+UPWn1TVkjn
MIME-Version: 1.0
X-Received: by 10.50.97.41 with SMTP id dx9mr23981378igb.1.1428624410671; Thu, 09 Apr 2015 17:06:50 -0700 (PDT)
Received: by 10.107.149.15 with HTTP; Thu, 9 Apr 2015 17:06:50 -0700 (PDT)
In-Reply-To: <DM2PR0301MB0655F7760BBA44E5807F15BEA8FB0@DM2PR0301MB0655.namprd03.prod.outlook.com>
References: <CAMm+LwgQ30qRyQufBTqFvyjTZ0GT6_jvgf0Z0yOPF8SD-N=ujg@mail.gmail.com> <CALx6S35n6VXOm4WN_efG9e0DQvTZGYpCS+VZ=MZ6BdxoaZrFcw@mail.gmail.com> <EEFC75DA-31EF-4AB7-8B1B-6CF3E67FDA10@trammell.ch> <DM2PR0301MB0655F7760BBA44E5807F15BEA8FB0@DM2PR0301MB0655.namprd03.prod.outlook.com>
Date: Thu, 9 Apr 2015 17:06:50 -0700
Message-ID: <CALx6S36Qc1E8_8NkE+VArS2eTt_d3cHGCOMmxFnOD25x=O6_UQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
To: Christian Huitema <huitema@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/Cw_LgbYtNiA4fXC-umJswm1XZHA>
Cc: Toerless Eckert <eckert@cisco.com>, Phillip Hallam-Baker <phill@hallambaker.com>, Yoav Nir <ynir.ietf@gmail.com>, "spud@ietf.org" <spud@ietf.org>, Brian Trammell <ietf@trammell.ch>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: Re: [Spud] OS updates on embedded devices
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 00:07:02 -0000

On Thu, Apr 9, 2015 at 2:52 PM, Christian Huitema <huitema@microsoft.com> wrote:
> On Thursday, April 9, 2015, at 2:45 PM, Brian Trammell wrote
>>
>> What I take away from this tangent: avoiding certain types of badness is
>> probably a necessary function of any minimal common transport such as SPUD.
>> Which types of badness those are is a point for detailed discussion, but it
>> probably includes avoiding anything that looks like reflection or amplification,
>> and anything that looks like trivial state exhaustion, which we need to consider
>> very carefully in a protocol designed to make state establishment on path
>> explicit.
>>
>
> Agreed. In particular, "no worse than TCP" is a bit of a low bar. We need to be robust against packet injection attacks.
>
That is a good requirement which is directed more at the transport
layer itself rather than the middleboxes-DPI interaction. I don't see
that requirements like this are listed in the SPUD drafts, have they
been enumerated somewhere?

Thanks,
Tom

> As for IoT, did we not have a couple of IoT talks during the last IAB plenary? Most of what I read on this thread was presented here: http://www.ietf.org/proceedings/92/slides/slides-92-iab-techplenary-2.pdf. The discussion should probably move to an IoT specific list.
>
> -- Christian Huitema
>