Telechat Review of draft-ietf-6lo-btle-14

Request Review of draft-ietf-6lo-btle
Requested rev. no specific revision (document currently at 17)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2015-07-07
Requested 2015-07-02
Authors Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, Carles Gomez
Draft last updated 2015-07-16
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-14-secdir-telechat-lonvick-2015-07-16
Reviewed rev. 14 (document currently at 17)
Review result Ready
Review completed: 2015-07-16



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 


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,

On 6/3/15 6:23 PM, Chris Lonvick wrote:


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>