[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
- [6tisch] Updates for minimal-security-09 Mališa Vučinić
- Re: [6tisch] Updates for minimal-security-09 Thomas Watteyne