Re: [Roll] Stephen Farrell's No Objection on charter-ietf-roll-04-06: (with COMMENT)

peter van der Stok <stokcons@xs4all.nl> Thu, 15 December 2016 10:02 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908EA1297EE for <roll@ietfa.amsl.com>; Thu, 15 Dec 2016 02:02:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HILD9po0g5sz for <roll@ietfa.amsl.com>; Thu, 15 Dec 2016 02:02:14 -0800 (PST)
Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD835129561 for <roll@ietf.org>; Thu, 15 Dec 2016 02:02:13 -0800 (PST)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud6.xs4all.net with ESMTP id LA2B1u00A25pRQy01A2Bms; Thu, 15 Dec 2016 11:02:11 +0100
Received: from 2001:983:a264:1:466:a346:51ef:6889 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 15 Dec 2016 11:02:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 15 Dec 2016 11:02:11 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <148179406008.27562.6173114911411840518.idtracker@ietfa.amsl.com>
References: <148179406008.27562.6173114911411840518.idtracker@ietfa.amsl.com>
Message-ID: <4e50b80843eaef06922d45fe48af766d@xs4all.nl>
X-Sender: stokcons@xs4all.nl (C2Um/KFrl3Cfuy8WOMUaHQaFb+JPO7VT)
User-Agent: XS4ALL Webmail
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/xStipM_a-NSISYuAuuaEF-PJJ3A>
Cc: roll-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [Roll] Stephen Farrell's No Objection on charter-ietf-roll-04-06: (with COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 10:02:15 -0000

Hi Stephen,

Indeed, formulating security attacks, analysing their consequences, and 
findig adequate remedies for a routing protocol is a challenging task.
It starts with formulating the attacks, which in my understanding evolve 
over time.

In the 6lo WG a draft has been written to handle privacy issues in a 
coherent way; which proves extremely useful during the IP-over-foo draft 
discussions.
In Roll Michael has written a template for the applicabiity statements, 
including security issues.

In my opinion a draft which helps identifying the threats and their 
(existing) remedies could be a proper way forward.
For Roll such a draft together with Manet, which faces similar wireless 
issues, might be a good starting point.

Any other suggestions, or showing this one to be inadequate, are 
welcome.

peter,
> 
> The charter continues to say "The Working Group will pay
> particular attention to routing security..."
> 
> How do we think that's going? I'm not sure that it's going
> that well - we seem to have a history where ROLL documents
> arrive at the IESG lacking security analysis. I don't think
> that's because folks are bad or lazy, but it's maybe more
> down to people assuming that security is someone else's
> problem (e.g. will be handled by layer 2, or will be part
> of some applicability statement, or will be handled by
> some RPL security document etc...)
> 
> Anyway, now that we're re-chartering, maybe it's a good
> time to review how we've been doing on this, given the
> history and see if there's anything we could do to avoid
> problems arising for future ROLL documents. (I don't have
> any specific suggestion for what to do, I just wanted to
> see if a discussion of this might be useful.)
>