Last Call Review of draft-ietf-6lowpan-btle-

Request Review of draft-ietf-6lowpan-btle
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-07-17
Requested 2012-06-28
Authors Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, Carles Gomez
Draft last updated 2012-07-13
Completed reviews Genart Last Call review of -?? by Brian Carpenter
Genart Telechat review of -?? by Brian Carpenter
Secdir Last Call review of -?? by Steve Hanna
Assignment Reviewer Steve Hanna 
State Completed
Review review-ietf-6lowpan-btle-secdir-lc-hanna-2012-07-13
Review result Ready
Review completed: 2012-07-13


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