Last Call Review of draft-ietf-6lo-btle-13
review-ietf-6lo-btle-13-secdir-lc-lonvick-2015-06-05-00

Request Review of draft-ietf-6lo-btle
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-06-09
Requested 2015-05-28
Authors Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, Carles Gomez
Draft last updated 2015-06-05
Completed reviews Genart Last Call review of -13 by Elwyn Davies (diff)
Genart Telechat review of -14 by Elwyn Davies (diff)
Secdir Last Call review of -13 by Chris Lonvick (diff)
Secdir Telechat review of -14 by Chris Lonvick (diff)
Opsdir Last Call review of -13 by Niclas Comstedt (diff)
Assignment Reviewer Chris Lonvick
State Completed
Review review-ietf-6lo-btle-13-secdir-lc-lonvick-2015-06-05
Reviewed rev. 13 (document currently at 17)
Review result Has Issues
Review completed: 2015-06-05

Review
review-ietf-6lo-btle-13-secdir-lc-lonvick-2015-06-05

Hi,

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.

Overall, the document is well written and explains the concepts well.

I saw that a "test interface" is defined in Section 2.1.  I would like
to see some guidance in the Security Considerations section about this.
Hopefully the guidance will describe how the interface is secured, or
that it can be secured by an operator.

Multicast is mentioned several times throughout the document mostly
saying that the Bluetooth LE link layer does not support it.  I
would like to see this addressed in the Security Considerations section
as well to alert implementers and operators that this may be a point
of attack.  Any guidance on how to prevent an active, malicious denial
of service attack using multicast would be appreciated.

Also, I found a couple of nits that you may want to address.

Current in Section 3:
 This
   functionality comprises of link-local IPv6 addresses and stateless
   IPv6 address autoconfiguration (see Section 3.2.1), Neighbor
   Discovery (see Section 3.2.2) and header compression (see
   Section 3.2.3).  Fragmentation features from 6LoWPAN standards are
   not used due Bluetooth LE's link layer fragmentation support (see
   Section 2.4).

Proposed:
 This
   functionality is comprised of link-local IPv6 addresses and stateless
                 ^^^^^^^^^^^^
   IPv6 address autoconfiguration (see Section 3.2.1), Neighbor
   Discovery (see Section 3.2.2), and header compression (see
                                ^
 Section 3.2.3).  Fragmentation features from 6LoWPAN standards are
   not used due to Bluetooth LE's link layer fragmentation support (see
                ^^
   Section 2.4).


Current also in Section 3:
 In Bluetooth LE a central node is assumed to be less constrained than
Proposed:


   In Bluetooth LE a central node is assumed to be less resource 


constrained than



^^^^^^^^

Current in 3.2.1:
      Effectively duplicate
   address detection for link-local addresses is performed by the 6LBR's
   software responsible of discovery of IP-enabled Bluetooth LE nodes
   and of starting Bluetooth LE connection establishment procedures.
Proposed:


      Detection of duplicate link-local addresses is performed by the 


process


   on the 6LBR responsible for the discovery of IP-enabled Bluetooth LE 


nodes



   and for starting Bluetooth LE connection establishment procedures.

Best regards,
Chris