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

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

Return-Path: <lonvick.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559A41A8908; Wed, 3 Jun 2015 16:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 MDWpcyii7pyQ; Wed, 3 Jun 2015 16:23:45 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B446D1A0120; Wed, 3 Jun 2015 16:23:45 -0700 (PDT)
Received: by oiww2 with SMTP id w2so19446032oiw.0; Wed, 03 Jun 2015 16:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=02jIrLydkoZSil4iG+ngG52SvKSy0CfivP/olGWsCJ4=; b=wxqwJislpGBD4JdEXv7ukR7vS0oJ8lCYckgYplbEoxqV9FSOSNtBuQI5dJ+alUizZQ hgD6YuCFzfM3pdRWOEOcS7VaAMMZLvt5/2Lpm2+l50zjFbDkGMRkFcGNrDCY7R2fLjLm O6v1QoOVDZ4BWhuJqghagtmzqxGGmmapoTMBZw+xlXsonpX5nEkBAG4sWlmWzvfiqqyQ 8sY2POaPdVNy6Prd5R8tLBMY0/l+is0DvWJhIwcWLBulcAEhl1rnrHrw5YWWxnLsEklj D3pisVe6iMgvwOTKdRDkAiLp8s/CufuGaEFl7Qf1vtdI/Phkk1ZXBs3S1seNxBKOjWxd o22w==
X-Received: by 10.202.239.138 with SMTP id n132mr15744924oih.99.1433373825214; Wed, 03 Jun 2015 16:23:45 -0700 (PDT)
Received: from Chriss-MacBook-Air.local (c-50-171-51-221.hsd1.tx.comcast.net. [50.171.51.221]) by mx.google.com with ESMTPSA id x3sm215531obm.8.2015.06.03.16.23.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 16:23:44 -0700 (PDT)
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
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 03 Jun 2015 23:23:47 -0000

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