Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

Tengfei Chang <> Thu, 21 March 2019 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73E88129A4B for <>; Thu, 21 Mar 2019 09:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TpOXREI09cvV for <>; Thu, 21 Mar 2019 09:23:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B12E6129619 for <>; Thu, 21 Mar 2019 09:23:36 -0700 (PDT)
Received: by with SMTP id d25so4606211pfn.8 for <>; Thu, 21 Mar 2019 09:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0OnWL2hyLYDS7k3yHeAoL5/eeAIDyuVeq3nJ0oTuthE=; b=IuZ9llWpinpKBWLIpJTJ5RrFun13dJpabc1+je55CBvxpkc9/58CnxMJfp2McFzKHq RR2ECsdiSQTXRFyk/0ejtD30j2gLIUntfqjkpNRCl1QIl2oooKPoDuuS55UKY+yaOqbT iKhmdJIs5tBI2RJprx2EKAW0zFUmysdiBDRJWlLGg/mROPJx8b1pGoLk7/EgP9qm+AEF X1KoVsBA/QfLg9FkaCMfBfqnICtHtCwxGzlgwzUPSY75JM2iZB5cUHe/bxCKsK0R4ZfM ij7A1HRBM+oXwp43CAk1yDHztkknxqaQzbczMZETxeiqleNNz5FNerMbhnj8aMfZVFoa oxlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0OnWL2hyLYDS7k3yHeAoL5/eeAIDyuVeq3nJ0oTuthE=; b=bXyOTaiZZvgETMdcw238kGHJ7AUhfrz9mpzEfQGlHAM/7Uluy3gEX3PT+x+2FW0I9X fVQa5Q5h5b0Jt2nkjeUk1kJNqknsDv5p8siZt388Rerz2zRC9yGn5m6FU2/tG6IHleHC Mc6Fq/rp3Gj1DqEWejQBq/rKi50FjfxBviORw2yRGUzFK2k07Sm0+UbUcvOJmk9hXBp6 Dc7xYNSR9I4ISaw+whDimp2ggGaPOTtIYij98j7B+HAmXhl1A41pDCJQoAFHy8aTUXf2 axEn6/ECKdAggGFM4ckEPOLFI39FHcX46ps97he61dC1lLaieu6fkTIj+ruB8lkU/eDt ksVQ==
X-Gm-Message-State: APjAAAWlHSIi/LLneVRtAQr4PnFZAO63801tkSOr+4qIM0mwCeqiVjny ESO6ojDNIl1y15/46RVdTG9hcRXTKr+uiq6K3SU=
X-Google-Smtp-Source: APXvYqxaliSnp+3ENWeMAbX4ocxCrK10zIDdqpwG6MJ4P0AnEryOXhgsplq/XokCS1r6Ezw2DoqvMfzcWIbmsC3WCbI=
X-Received: by 2002:a17:902:e48f:: with SMTP id cj15mr2543485plb.256.1553185415978; Thu, 21 Mar 2019 09:23:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Tengfei Chang <>
Date: Thu, 21 Mar 2019 17:23:24 +0100
Message-ID: <>
To: Yasuyuki Tanaka <>
Content-Type: multipart/alternative; boundary="000000000000fd629405849d2843"
Archived-At: <>
Subject: Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published
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, 21 Mar 2019 16:23:39 -0000

Hi Yatch,

Thanks for the following-up comments! I replied inline below.

On Thu, Mar 21, 2019 at 4:25 PM Yasuyuki Tanaka <>

> Thank you, Tengfei.
> Additional and following-up comments:
> [Section 5.1, what to do after timeout of a 6P transaction]
> The draft does not say anything about how to handle timeout of a 6P
> transaction. I know, the initiator of the timed out transaction will
> resend a 6P request to the same peer ;-) But, it's better to mention
> that as well as the maximum number of retries if we have.
Comment accepted!

> [Section 9, 6P Timeout Value]
> A couple of questions:
> - "C" includes the autonomous cell to the neighbor or it is the number
>    of the managed cells?
> - How can the timeout value be calculated while PDR is not available?
I agree that those questions are not clear for the current version.
As the current version allows 6P to send on the autonomous SHARED cell
mentioned in the draft (MAY send on the Managed Cell as well, as mentioned
in the draft.), the PDR value is not realistic.
The calculation of TIMEOUT in the draft MAY not apply anymore.

Instead of a complex calculation, I propose to use a fixed value.
The value is the worst case to have a 6P response received on the
autonomous SAHRED cell after maxmium re-tries.
The worse case means each time when 6P response is failed to send out, it
back-off with the largest number of cells (autonomous SHARED cell).
Since there is only one autonomous SHARED cell each node, the node will
wait for the same number of slotframes.

The calculation is like:

for maxmium 3 retries:

backoff exponent start from 2 and increase each re-transmission

6P Timeout = slotframeDuration * (1 +  (2^2-1)+(2^3-1)+(2^4-1)  )

> [Section 4.5, Step 4 of the bootstrap process]
> tengfei> I don't know whether there is a specification for how the
> tengfei> neighbor table should be managed. If no, I think PERSONALLY
> tengfei> it's better not keeping the address from pledge in neighbor
> tengfei> table.
> Although the actual way to manage neighbor information is
> implementation-dependent, the minimal security framework draft
> suggests to have separate memory for joined nodes and for pledges
> respectively:

I see. I am not sure using a neighbor cache is able to avoid the DoS attack.
My intuitive thinking is the neighbor cache still has a fixed size.
If an attacker sends multiple join requests with fake eui64 address in the
packet, it can still fill up the neighbor cache, which blocks other pledges
to join.

This maybe need to discuss with minimal security scope as well.

> Again, my comment on Section 4.5 is just that, I think we need some
> text in "Security Considerations" section for this operation described
> in Step 4. And, it seems the term of "the neighbor table" in the Step
> 4 is ambiguous. Some may think it's IPv6 neighbor cache, some may
> think L2 neighbor table.

I agree!

> [Appendix-B, SAX configuration]
> tengfei> This is a pre-configured (offline) for interoperability
> tengfei> purpose only.
> It's better to mention how a pledge gets the SAX parameters used in
> the network where it is trying to join. There are always two options:
> - pre-configured
> - advertised in EBs


> Best,
> Yatch

Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria