[secdir] secdir review of draft-ietf-6lowpan-btle-08

Stephen Hanna <shanna@juniper.net> Thu, 12 July 2012 02:20 UTC

Return-Path: <shanna@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DAB0511E810F; Wed, 11 Jul 2012 19:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xW-RVuNHosO1; Wed, 11 Jul 2012 19:20:42 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2AB7711E809A; Wed, 11 Jul 2012 19:20:33 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([]) (using TLSv1) by exprod7ob118.postini.com ([]) with SMTP ID DSNKT/40kb7m4HH3ifxxQIx3pl9X6T1R8V6z@postini.com; Wed, 11 Jul 2012 19:21:14 PDT
Received: from P-CLDFE02-HQ.jnpr.net ( by P-EMHUB01-HQ.jnpr.net ( with Microsoft SMTP Server (TLS) id; Wed, 11 Jul 2012 19:19:36 -0700
Received: from p-emfe01-wf.jnpr.net ( by p-cldfe02-hq.jnpr.net ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jul 2012 19:19:35 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 11 Jul 2012 22:19:35 -0400
From: Stephen Hanna <shanna@juniper.net>
To: "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-6lowpan-btle.all@tools.ietf.org" <draft-ietf-6lowpan-btle.all@tools.ietf.org>
Date: Wed, 11 Jul 2012 22:19:33 -0400
Thread-Topic: secdir review of draft-ietf-6lowpan-btle-08
Thread-Index: Ac1f1Ma24oacIUSEQV6zGZ0doNIaNw==
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB833166881@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] secdir review of draft-ietf-6lowpan-btle-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2012 02:20:43 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document describes how IPv6 is transported over Bluetooth
Low Energy (BT-LE).

As a proviso, I am not an expert in IPv6, 6LoWPAN, or Bluetooth.
Still, this document seemed to be a clear specification of the
intended subject matter. The Security Considerations section
says that the security concerns are similar to those for IPv6
over 802.15.4. That makes sense, I suppose.

I was happy to see that this document says "IPv6 over BT-LE
SHOULD be protected by using BT-LE Link Layer security", whereas
RFC 4944 (IPv6 over 802.15.4) does not include any normative
language on using link layer security. Also, this document says
that "Key management in BT-LE is provided by the Security Manager
Protocol (SMP)", whereas RFC 4944 says that no key management
is provided by 802.15.4. So this specification is apparently
more secure that RFC 4944. That's good.

So based on my review (admitting little knowledge of BT-LE),
this document seems to be an improvement over the current
state of the art for 6LoWPAN from a security perspective.
And the overall level of security seems reasonable.
I have no objection to the publication of this document.

I did notice two typos:

gateway^1s => gateway's
respectively => respectively