[6tisch] Security review of draft-ietf-6tisch-minimal-security-12

Mališa Vučinić <malisa.vucinic@inria.fr> Wed, 23 October 2019 14:26 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0CFC5120822; Wed, 23 Oct 2019 07:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DHB_Or-NJ74b; Wed, 23 Oct 2019 07:26:41 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893B0120255; Wed, 23 Oct 2019 07:26:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.68,221,1569276000"; d="scan'208,217";a="407797669"
Received: from wifi-pro-83-058.paris.inria.fr ([]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2019 16:26:38 +0200
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0456494B-32A5-4885-AB93-7E62D708C2E0"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <D025931C-6CEF-40DF-851A-EC538B55556F@inria.fr>
Date: Wed, 23 Oct 2019 16:26:38 +0200
Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-6tisch-minimal-security.all@tools.ietf.org, 6tisch <6tisch@ietf.org>
To: hilarie@purplestreak.com
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/tMUUmVdx8CK9yFj1OVLHuV_hx3Y>
Subject: [6tisch] Security review of draft-ietf-6tisch-minimal-security-12
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2019 14:26:44 -0000

Dear Hilarie,
Thank you for going over the document. Please see the responses inline. Proposed changes to the working version of the document following your review can be found at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8d77145e63531b604a7d4df4197515ffebde0927 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8d77145e63531b604a7d4df4197515ffebde0927>
Kind regards,

>        Security review of Minimal Security Framework for 6TiSCH
> 		draft-ietf-6tisch-minimal-security-12
> Do not be alarmed.  I generated this review of 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
> with the intent of improving security requirements and considerations
> in IETF drafts.  Comments not addressed in last call may be included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> Nodes can join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e)
> network) by issuing a request that is validated using pre-shared
> keys.  The document defines the Constrained Join Protocol and its
> data structures.
> The security considerations section has been done well.
> The "short identifier" space consideration on page 34 might be
> problematic under extreme conditions.  If almost all values have
> been used, a set of nodes might cause trouble by constantly
> sending join requests.  The JRC(s) would have to time out their
> previous information, and there might be long delays before a
> short identifier could be freed up.  Perhaps there should be a rate
> limit on join requests from any single node.  (If there is such
> a limit I didn't see it).

On page 26, we define a parameter called “join rate” which sets the rate at which a Join Proxy (JP) forwards the requests on behalf of different pledges into the network. We discuss the use of join rate also in the Security Considerations section where I made the following change to stress the applicability of the parameter to the scenario you consider:
OLD: A data cap on the JP prevents it from forwarding more traffic than the network can handle.
NEW: A data cap on the JP prevents it from forwarding more traffic than the network can handle and enables throttling in case of an attack.
Please let me know if the existing and the amended text sufficiently clarifies the use of the join rate parameter.

> Page 20 and page 23 mention "the user", but it is unclear what "user"
> means in this framework.

OLD: ...the (6LBR) pledge SHOULD signal to the user the presence of an error condition,...
NEW: ...the (6LBR) pledge SHOULD signal the presence of an error condition,...

> Page 34 says that "the loss of security properties is eminent".  That
> intended word was probably "imminent".  I suggest rephrasing.


> Page 37 asks the reader to recall a "well-known" Bluetooth problem, but
> there is no citation for it.  Either document it or remove it.

Thanks, I removed this sentence as it wasn’t critical for the comprehension of the rest of the paragraph.

> Hilarie Orman