[secdir] Secdir last call review of draft-ietf-6lo-blemesh-08

Catherine Meadows via Datatracker <noreply@ietf.org> Wed, 18 November 2020 22:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 113D03A0DEE; Wed, 18 Nov 2020 14:24:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Catherine Meadows via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: 6lo@ietf.org, draft-ietf-6lo-blemesh.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160573826402.16462.7124606612381130154@ietfa.amsl.com>
Reply-To: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Date: Wed, 18 Nov 2020 14:24:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SfxASLhZzfL4xm_iZNkJMgw9q4Q>
Subject: [secdir] Secdir last call review of draft-ietf-6lo-blemesh-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Nov 2020 22:24:24 -0000

Reviewer: Catherine Meadows
Review result: Ready

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. This document specifies mechanisms that are needed to
enable IPv6 mesh topologies over Bluetooth Low Energy Links established using
the Bluetooth Internet Protocol Support Profile.  It does not specify the
routing protocol to be used in an IPv6, and it does not specify security
mechanisms.

In the Security Considerations Section the document directs the reader to the
relevant documents. For most security issues, it points the reader to RFC 7668,
“IPv6 over BLUETOOTH(R) Low Energy.”  For security issues produced by the
routing protocol, the reader is directed to RFC 7416, “ A Security Threat
Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)”, and
it is noted that the issues addressed in that RFC are useful for other low
energy routing protocols as well.  Finally it is noted that the Registration
Ownership Verifier (ROVR) field can be derived from the Bluetooth address, and
that this field is also subject to impersonation and spoofing.  For this the
document refers the reader the Internet Draft on "Address Protected Neighbor
Discovery for Low-power and Lossy Networks.”

I think that this document does an excellent job of identifying the relevant
security issues to related to its topic, and of directing the reader to the
relevant documents.

I consider this document Ready.