Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 05 December 2019 15:18 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 2F85112002E for <6tisch@ietfa.amsl.com>; Thu, 5 Dec 2019 07:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 PXHDhYv5LvqF for <6tisch@ietfa.amsl.com>; Thu, 5 Dec 2019 07:18:53 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 1BE59120013 for <6tisch@ietf.org>; Thu, 5 Dec 2019 07:18:52 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,281,1571695200"; d="scan'208";a="331484345"
Received: from wifi-eduroam-85-089.paris.inria.fr ([128.93.85.89]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2019 16:18:51 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
In-Reply-To: <27585.1575557225@localhost>
Date: Thu, 5 Dec 2019 16:18:50 +0100
Cc: Pascal Thubert <pthubert@cisco.com>, 6tisch@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1D7C911-428F-4694-A285-AEEECC9C172A@inria.fr>
References: <157244462862.32472.6918190621522301464.idtracker@ietfa.amsl.com> <14289.1572642938@localhost> <3C7830D8-59C5-4F78-8986-91391EF464D6@kuehlewind.net> <27585.1575557225@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/yYxhzMcJH2n8DpKgfaIHRNeJIQA>
Subject: Re: [6tisch] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-6tisch-minimal-security-13=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Thu, 05 Dec 2019 15:18:55 -0000

This text should end up in the next version of the MSF draft, as it is the scheduling function that triggers 6P to add/delete cells. We added some text on it already for the security considerations, what remains to be done is to align the MSF algorithm with the requirement of not adapting to tagged traffic.

Mališa

> On 5 Dec 2019, at 15:47, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>>>> I would think it
>>>> either sets it to AF43 or it does nothing about it because DSCP is not
>>>> really used in that network.
>>> 
>>> In 6tisch networks, different DSCP points can be used to get different
>>> behaviours, see .... UHM. Let me get back to you on this, because the
>>> reference has evaporated.
> 
>> A reference would be good (in the draft) :-)
> 
> Hi, we had a long discussion about setting DSCP points on upward and downward
> traffic.   We had said that these code point would *not* cause 6P to add bandwidth.
> Where did we say that?   I feel like that the reference has gone away.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>