Re: [6tisch] Intelligent JP / validating the MASA

Mališa Vučinić <> Thu, 22 August 2019 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3ADF3120813 for <>; Thu, 22 Aug 2019 03:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6P3nS0VmHBlg for <>; Thu, 22 Aug 2019 03:12:14 -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 D37851200B2 for <>; Thu, 22 Aug 2019 03:12:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.64,416,1559512800"; d="scan'208,217";a="316931910"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2019 12:12:11 +0200
From: Mališa Vučinić <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1B91C78-4E33-400B-A29E-7A0C88C5FC2E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 22 Aug 2019 12:12:11 +0200
In-Reply-To: <>
Cc: Benjamin Kaduk <>, Tero Kivinen <>, Michael Richardson <>, "" <>
To: "Pascal Thubert (pthubert)" <>
References: <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [6tisch] Intelligent JP / validating the MASA
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: Thu, 22 Aug 2019 10:12:16 -0000

Hello Pascal,

The issue that Ben outlines was solved through two separate mechanisms that are detailed in draft-ietf-6tisch-minimal-security:

1) The traffic that JP redirects into the network on behalf of unauthenticated pledges is tagged using IPv6 DSCP such that it can be distinguished from the legitimate network traffic. This allows e.g. the 6tisch scheduling function to explicitly ignore the unauthenticated traffic when adapting link resources to traffic requirements. This is detailed in Section 6.1 of draft-ietf-6tisch-minimal-security.

2) The use of the CoJP “join_rate” parameter that allows the JRC to set the rate at which each JP in the network forwards the unauthenticated traffic. This mechanism serves as the bandwidth cap for the unauthenticated traffic before it is being forwarded into the network. The details are in Section 8.4.2 of draft-ietf-6tisch-minimal-security, and there is also a paragraph in the Security Considerations detailing the issue.


> On 20 Aug 2019, at 18:20, Pascal Thubert (pthubert) <> wrote:
> Dear all:
> I’m looking for a consensus on how to address the following review comment on the 6TiSCH Architecture by Benjamin:
> > I'd like to see some discussion somewhere that the Join Proxy needs to take care
> > to not be an open redirector by which an unauthenticated pledge can attack
> > arbitrary network elements (whether within the LLN or on the broader
> > network), e.g., by performing some validation on the claimed MASA identifier.
> > Similarly, that the JRC will be exposed to lots of untrusted input and needs to be
> > implemented in an especially robust manner.
> Then again I’d like to discuss the split of what goes in the architecture and what goes in Minimal security or elsewhere.
> What do you think?
> Pascal