Re: [Roll] Security threat analysis for applicability draft

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 05 May 2014 13:31 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395EA1A032E for <roll@ietfa.amsl.com>; Mon, 5 May 2014 06:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level:
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=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 UUjGyg0Whc1r for <roll@ietfa.amsl.com>; Mon, 5 May 2014 06:31:18 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 715CD1A032D for <roll@ietf.org>; Mon, 5 May 2014 06:31:18 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id D36CE20011; Mon, 5 May 2014 09:32:40 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id ECD6C63ABD; Mon, 5 May 2014 09:31:12 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CFC7F63AB6; Mon, 5 May 2014 09:31:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
In-Reply-To:
X-Attribution: mcr
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 05 May 2014 09:31:12 -0400
Message-ID: <8543.1399296672@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/H1U5ngnm0qyiDpHPi47F_MiiFSc
Cc: Peter van der Stok <peter.van.der.stok@philips.com>
Subject: Re: [Roll] Security threat analysis for applicability draft
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: 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: <http://www.ietf.org/mail-archive/web/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: Mon, 05 May 2014 13:31:20 -0000

see inline. (no hat. Sorry for 6 week delay in answering)

Peter wrote:
> Thanks for the security threats draft. It certainly provides a large part
> of the text needed in the applicability drafts. However, I am not sure I
> interpreted the text according to your intentions.

> Looking at section 7 in more detail, I tried to establish where the
> applicability draft can be complementary to the text of the security
> draft.

It's a good question.  Not being the author of the original document, I've
tried to make minimal changes to the structure, but perhaps this is no longer
sufficient, and we need to restructure this section...  I admit to being a
bit at my whit's end on this document.

> From section 7.1 I understand that key length, encryption algorithm and key
> life time need to be specified. Unfortunately, much of this is still in
> progress and can change with DICE and ACE recommendations.

I'm not I understand how DICE and ACE relate.
We are primarily talking about security for *RPL*, not for application traffic.

> Complementing section 7.2, link-layer security will probably be used today,
> but in 2 years time?

I can't speculate at what point layer-2 security will prove inadequate for
securing RPL.  I think that it will be sufficient in industrial, metering and
building control systems.  Home control systems are another story in my
opinion.  The biggest risk to only layer-2 security is device compromise.
A monoculture combined with systematic IE6 or Heartbleed-type bugs would be
the biggest risk, I should think.

> Complementing section 7.3. Do I understand that using multiple paths for
> reliability reasons should be mentioned as increasing routing security?

Yes, but we presently have no mechanisms for multi-path.

> Complementing section 7.4. Writing down choices, as already provided by the
> threats draft, will be more realistic than writing down recommendations.

Please, can you explain, ideally in text for the document, what you mean here?

> Complementing section 7.5. Is this the place one should write down physical
> access constraints or recommend to provide filtering edge routers at the
> border of the system?

Yes, I guess that would also belong.

> In conclusion, I am very happy with the threats document and its
> recommendations, but I see little opportunity to improve on it in the
> applicability draft.

I couldn't parse this quite right.
Are you saying you see some small opportunities for improvement, or
are you saying that there are no places for improvement?

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-