[secdir] secdir review of draft-ietf-6lo-btle-13

Chris Lonvick <lonvick.ietf@gmail.com> Wed, 03 June 2015 23:23 UTC

Message-ID: <556F8C89.1020500@gmail.com>
Date: Wed, 03 Jun 2015 18:23:53 -0500
From: Chris Lonvick <lonvick.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-6lo-btle.all@tools.ietf.org
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/H0EdL_9csjhOFJMxNWFjHZnfRdM>
Subject: [secdir] secdir review of draft-ietf-6lo-btle-13
Precedence: list

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

[secdir] secdir review of draft-ietf-6lo-btle-13 Chris Lonvick
Re: [secdir] secdir review of draft-ietf-6lo-btle… Chris Lonvick