[6tisch] Updates for minimal-security-09

Mališa Vučinić <malisa.vucinic@inria.fr> Mon, 12 November 2018 17:37 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C95130E57 for <6tisch@ietfa.amsl.com>; Mon, 12 Nov 2018 09:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.92
X-Spam-Level:
X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4HVWQ_yrUh4B for <6tisch@ietfa.amsl.com>; Mon, 12 Nov 2018 09:37:53 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 820FD130E53 for <6tisch@ietf.org>; Mon, 12 Nov 2018 09:37:52 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.54,496,1534802400"; d="scan'208,217";a="355296513"
Received: from mail-qk1-f175.google.com ([209.85.222.175]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 12 Nov 2018 18:37:43 +0100
Received: by mail-qk1-f175.google.com with SMTP id 131so14725164qkd.4 for <6tisch@ietf.org>; Mon, 12 Nov 2018 09:37:43 -0800 (PST)
X-Gm-Message-State: AGRZ1gJVLT4iljSzUK6isJu7L7BUF8fn/vE/+iQxltgjVOMQ3ZsBhZ5d cEZCNtQUxqWJ9v1Re78PeTG1qU6SX0dVx1Pk/qs=
X-Google-Smtp-Source: AJdET5e0GDS4svR15h9S5S4iSfiNNcsqyxOuT9vMc+yYkyAK9gcUIBXYdoqrdHi5Uh9W+aHInneQumTzOSPKLnpp848=
X-Received: by 2002:ac8:6706:: with SMTP id e6mr1877184qtp.62.1542044263082; Mon, 12 Nov 2018 09:37:43 -0800 (PST)
MIME-Version: 1.0
From: Mališa Vučinić <malisa.vucinic@inria.fr>
Date: Tue, 13 Nov 2018 00:37:31 +0700
X-Gmail-Original-Message-ID: <CANDGjycDnUG1W=zhsMVQU_p+uhFhsvZY2DS99Fxnnp6z4vwSJA@mail.gmail.com>
Message-ID: <CANDGjycDnUG1W=zhsMVQU_p+uhFhsvZY2DS99Fxnnp6z4vwSJA@mail.gmail.com>
To: tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008776ba057a7b28d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/Ve2mjuHpnBFV64Y1RDbiz9RyV34>
Subject: [6tisch] Updates for minimal-security-09
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: Mon, 12 Nov 2018 17:37:56 -0000

Hi all,

As discussed during IETF 103, here is a list of proposed changes for
minimal-security-09 that we will use for the second WGLC:

- Add "join rate" parameter in the Configuration structure present in Join
Responses and Parameter Update requests: As discussed during IETF 103,
allowing the JRC to dynamically set the join rate at each individual JP in
the network may prove useful in order to 1) speed up the network formation
by allocating all the available bandwidth to join; 2) throttling join
traffic sent by JPs in case of an attack; 3) switching off the join
process; 4) enabling/disabling a given node to act as a JP. The value of
this parameter will be used to set CoAP's congestion control mechanism at
the JP. As discussed, the text should not prevent the JP to use another
mechanism, e.g.
https://tools.ietf.org/html/draft-ji-roll-traffic-aware-objective-function-03,
and locally decide on a value that it should use, but in case this
parameter is received in the Configuration object, the value set by the JRC
MUST take precedence. Is this fine?

- Remove "network identifier" from the Configuration structure present in
Join Response and Parameter Update requests: During IETF 102, we agreed on
not managing all of the 6LBR parameters with CoJP protocol, so this
parameter when present in a Join Response is a remnant. It used to be there
to allow the JRC to signal to the 6LBR which network identifier (i.e. PAN
ID) to use to advertise the network. With this parameter removed from
Configuration object, there is an expectation that the JRC and 6LBR
exchange this and other necessary parameters (timeslot duration, template,
slotframe length, etc) through another protocol. The proposed text is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/b43a8139052a444e886b3b5a915bc0d545267340?at=minimal-security-09


- Clarification text on handling JRC failures and significant OSCORE
sequence number mismatch, aligning it better with OSCORE. The proposed text
is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/e942995f70b3ded33d9ce5307817ce4a9298b5fe?at=minimal-security-09


If you have any suggestions/recommendations/concerns, please raise them at
the latest a week from now.

Mališa