Subject: [6lo] Stephen Farrell's No Objection on draft-ietf-6lo-btle-14: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Jul 2015 05:40:24 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-6lo-btle-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I strongly support Alissa's DISCUSS and would argue that we
ought really try hard to minimise any privacy leakage being
contributed to by this specification. We basically have one
chance to do this well, after which any leakage becomes yet
another reason to not do the job well in future in other places.
(Based on dodgy but often heard arguments like: "but IPv6/BTLE
already dos this badly, so there's no additional harm in
foo/IPv6/BTLE being just as bad.")

I also note that the fact that some of that leakage relates to
link local addresses doesn't really reduce the damage so much
with a radio based link layer. (Yes, good l2 crypto could help
there, but only if always used everywhere for all packets and I
don't know if BTLE requires that, I suspect it does not.)

- The secdir review in early June made a couple of points that
are worth addressing. [1] I have not seen any response to that
review. (Apologies if I missed it.) 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05744.html

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Thu, 9 Jul 2015 05:33:36 +0000

Thank you Stephen for your review.

>- I strongly support Alissa's DISCUSS and would argue that we ought really try hard to minimise any privacy leakage being contributed to by this specification. We basically have one chance to do this well, after which any leakage becomes yet another reason to not do the job well in future in other places.
(Based on dodgy but often heard arguments like: "but IPv6/BTLE already dos this badly, so there's no additional harm in foo/IPv6/BTLE being just as bad.")

I replied in length to Alissa already, so most of my comments are there. Few more comments below.

The key I'm trying to communicate here is that by mapping LE device address to IID of IPv6 link-local address we obtain header compression benefits, and as far as I can tell, we don't weaken privacy. This is because the Bluetooth LE device is anyway broadcasting it's LE device address to everybody in few 10s of meters of radius for service discovery purposes, and I don't see what harm it does to use this LE device address also in constructing IPv6 link-local address for 6LN-6LBR communication link. Yes, everybody in vicinity will know what IPv6 link-local address the device will be using in its communications with 6LBR even when encryption is used, but the device cannot be tracked on the internet (because the link-local address is only used between 6LN and 6LBR).

The random device addresses are there in specifications and implementations exactly to counter unwanted tracking purposes (sometimes tracking of static addresses is an important feature, and hence supported as well).

If the IID would not be constructed from LE device address all the 64-bits of IID would have to transmitted inline, and that is quite a lot (8 bytes of IID is one third of 23 bytes that fit into a single LE frame, and hence this many additional bytes likely increases number of LE frames needed to transmit an IPv6 packet - especially if both source and destination IIDs need to be transmitted inline). So I'm not sure at all that hiding the IID used between 6LN and 6LBR justifies the cost of this many extra bytes being sent. I would like to at least better understand what is the real privacy leakage that justifies this cost.

>I also note that the fact that some of that leakage relates to link local addresses doesn't really reduce the damage so much with a radio based link layer. (Yes, good l2 crypto could help there, but only if always used everywhere for all packets and I don't know if BTLE requires that, I suspect it does not.)

The BLE implementation can choose whether they use link-layer security or not. The brand new BT SIG IPSP document says:
--
7.1 Node Security Considerations
This section describes the security requirements for the Node.
The Node may use the SM Slave Security Request procedure to request an LE Security Mode other than LE Security Mode 1 Level 1 if required by the use case.

7.2 Router Security Considerations
This section describes the security requirements for the Router.
The Router should accept any request by the Node for LE Security Mode 1 Level 2.
The Router should accept a request by the Node for LE Security Mode 1 Level 3, if the Router’s IO capabilities are sufficient to support Level 3.
--
And from BT core specification 4.1  we can see what these modes and levels mean:
--
10.2.1 LE Security Mode 1
LE security mode 1 has three security levels:
1. No security (No authentication and no encryption)
2. Unauthenticated pairing with encryption
3. Authenticated pairing with encryption

A connection operating in LE security mode 1 level 2 shall also satisfy the
security requirements for LE security mode 1 level 1.

A connection operating in LE security mode 1 level 3 shall also satisfy the
security requirements for LE security mode 1 level 2 or LE security mode 1
level 1.

A connection operating in LE security mode 1 level 3 shall also satisfy the
security requirements for LE security mode 2.
--

So for more serious use of IPv6, the level 2 and 3 security would have to be used, and then the link layer is encrypted as defined in BT SIG Core spec (see page 2613):
--
The Link Layer provides encryption and authentication using Counter with
Cipher Block Chaining-Message Authentication Code (CCM) Mode, which
shall be implemented consistent with the algorithm as defined in IETF RFC
3610 (http://www.ietf.org/rfc/rfc3610.txt) in conjunction with the AES-128 block
cipher as defined in NIST Publication FIPS-197 (http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf). A description of the CCM algorithm can also be
found in the NIST Special Publication 800-38C
(http://csrc.nist.gov/publications/PubsSPs.html).
--

>- The secdir review in early June made a couple of points that are worth addressing. [1] I have not seen any response to that review. (Apologies if I missed it.) 

We have followed that path, please find attached the latest email from Chris.

Best regards,

Teemu

Subject: Re: secdir review of draft-ietf-6lo-btle-13
From: ext Chris Lonvick <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 8 Jul 2015 14:34:19 +0000

Hi,

I have re-reviewed this document. Overall, a lot of very good changes
have been made.
I appreciate the additions to the Security Considerations section. Both
of those are well
written and give appropriate guidance.

I went back and re-read what I had asked about discussing multicast as a
malicious
attack vector. My apologies, but I didn't make myself clear. I was
asking about what
would happen if a device on the Internet were to start sending multicast
packets to
the 6LBR attempting to get it to forward them to the 6LNs. I'm thinking
that would
cause a great deal of overhead processing on the 6LBR and perhaps
overwhelm the
Bluetooth network. Is there a way to prevent or mitigate that?

Best regards,
Chris

On 6/3/15 6:23 PM, Chris Lonvick wrote:
> 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.
>
<remainder elided for brevity>