Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

Mališa Vučinić <> Wed, 25 March 2020 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D60913A0CC3; Wed, 25 Mar 2020 14:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EVGkYy01CkL2; Wed, 25 Mar 2020 14:38:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 823523A0C3C; Wed, 25 Mar 2020 14:38:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.72,305,1580770800"; d="scan'208,217";a="442278113"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2020 22:37:57 +0100
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9C544B50-F197-4980-943E-46794C0F7CF5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 25 Mar 2020 22:37:57 +0100
In-Reply-To: <>
Cc: Tengfei Chang <>, The IESG <>,, 6tisch <>, 6tisch-chairs <>, "Pascal Thubert (pthubert)" <>
To: Benjamin Kaduk <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Mar 2020 21:38:30 -0000

Hi Ben,

There has been an extensive discussion on this issue in the WG. As Tengfei stated, since MSF operates exclusively at L2, reading DSCP values from the IPv6 header would constitute a layer violation. It was decided that MSF would implement the recommendation from draft-ietf-6tisch-minimal-security by recommending the rate limit on DSCP-tagged traffic, at IPv6 layer as outlined in Security Considerations. That said, other scheduling functions that may operate higher up in the stack, e.g. to establish end-to-end tracks between nodes in a mesh, may adhere to this requirement from minimal-security. Therefore, for the sake of future scheduling functions that may get standardized, it was deemed appropriate to leave the recommendation in minimal-security as-is.

Hope that clarifies.


> On 24 Mar 2020, at 20:25, Benjamin Kaduk <> wrote:
>>     There seems to be some "passing the buck" going on with respect to
>>     rate-limiting unauthenticated (join) traffic:
>>     draft-ietf-6tisch-minimal-security (Section 6.1.1) says that the SF
>>     "SHOULD NOT allocate additional cells as a result of traffic with code
>>     point AF43"; this document is implementing a SF, and yet we try to avoid
>>     the issue, saying that "[t]he at IPv6 layer SHOULD ensure that this join
>>     traffic is rate-limited before it is passed to 6top sublayer where MSF
>>     can observe it".  I think we need a clear and consistent story about
>>     where this rate-limiting is supposed to happen.
>>> Thanks for the comments! This has been discussed in some  previous
>>   revision of MSF.
>>> It is not "passing the buck" but a decision based on the scheduling
>>   function and security context.
>>> In the point of avoiding layer violation, the upper layer information
>>   suppose NOT see-able for linker layer where 6P and MSF are.
> If we assume strict layiner so that IP information is not visible to the
> link layer where the scheduling function lives, then isn't that a flaw in
> draft-ietf-6tisch-minimal-security to say that the scheduling function
> should do [something relying on IP-layer information]?
>>> But regarding to security, it seems it is not avoidable.
>>> IMO, the scheduling function is aiming to provide algorithm to
>>   add/remove cell according to traffic.
>>> The traffic could contains unauthenticated  join request from both
>>   normal devices and malicious devices.
>>> The function does NOT have enough information to differentiate them.
>>> We are assuming some other entity out side of MSF needs to resolve this
>>   issue.
> Nonetheless, we're currently not fulfilling a requirement that a SF should
> meet.  If that requirement is unattainable, the requirement should be
> modified or removed; if not, we should attain the requirement.