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

Mirja Kuehlewind <> Thu, 05 December 2019 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB8591200B3; Thu, 5 Dec 2019 04:05:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X4Bdk8yF_9UL; Thu, 5 Dec 2019 04:05:49 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E33E12004A; Thu, 5 Dec 2019 04:05:49 -0800 (PST)
Received: from ([2001:16b8:2cc7:ef00:3499:6fbf:b45d:c371]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1icptB-000139-PV; Thu, 05 Dec 2019 13:05:45 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <14289.1572642938@localhost>
Date: Thu, 5 Dec 2019 13:05:45 +0100
Cc:,,,, The IESG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <14289.1572642938@localhost>
To: Michael Richardson <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1icptB-000139-PV
Archived-At: <>
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-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, 05 Dec 2019 12:05:51 -0000

Hi Michael,

Sorry for my late reply (but I guess you could have just went ahead and push a new version anyway…). Please see below.

> On 1. Nov 2019, at 22:15, Michael Richardson <> wrote:
> <#secure method=pgpmime mode=sign>
> Mirja Kühlewind via Datatracker <> wrote:
>> 1) I hope this point can be resolved quickly as it seems to only need a
>> bit more specifics but I think this part is not sufficient:
>> Sec 6.1: "The Join Proxy implements a data cap on outgoing join traffic
>> through CoAP's congestion control mechanism."
>> I think this needs an normative requirement here. Congestion control is
>> supposed to avoid network overload but also to make use available
>> resources.  The congestion control as currently defined for CoAP would
>> probably limit the join traffic appropriately (to something like one
>> packet per RTT likely) but CoAP could in theory use any time a
>> different more aggrieve congestion and therefore just relying on
>> congestion control generically doesn't seem to be sufficient.
>> I
>> recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per
>> 3 seconds if RTT is unknown (as recommended in RFC8085) and say that
>> this can be achieved by congestion control as specified in the base
>> CoAP spec.
> okay, how about:
> + The Join Proxy implements a data cap on outgoing join traffic by implementing
> + the <xref target="RFC8085" /> section 3.1.3 recommendation of 1 packet per 3
> + seconds.
> + This can be achieved with the congestion control mechanism specified
> + in <xref target="RFC7252" /> section 4.7.

Great! Thanks!

>> Further on there seems to be an implicit requirement that
>> the JP MUST implement rate limit using the PROBING_RATE parameter,
>> however, that is never explicitly spelled out as a normative
>> requirement. However, if this rate is not provided by the JRC, it
>> doesn't seem that any rate limiting has to be enforced. So maybe it
>> would be good to be more strict here.
> I think you are saying that we should have a default PROBING_RATE, if the JRC
> does not specify one.  I think that we assumed that the RFC7257 section 4.8
> value of 1 byte/second would apply. please confirm?

Yes, stating this explicitly would be good!

>> 2) Also, not sure if this editorial or a real issue but I'm not sure I
>> fully understand this sentence:
>> Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic
>> forwarded should set it to zero so that it is compressed out."  If the
>> proxy does NOT SET DSCP, why should it SET it to zero?
> Because RFC6282 (and friends) has specific encoding to omit DSCP if it is zero.

I understand what you want to do but saying “does not set” but “should set” seems to be contracting. I think this is only a wording issue though. I guess it could be something like this:

"A Join Proxy that does not require a specific DSCP value on traffic
forwarded should set it to zero so that it is compressed out.”

>> 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) :-)

>> 3) This may also be mostly editorial but just to be sure: Section 7.2
>> provides default values for some of the CoAP transport parameter (where
>> 2 of 3 are the same as defined in RFC7252) but not for all. Why is
>> that?
> We got pushback about relying on 7252 defaults, because what if they changed.

That’s fine but the you need to add all values!

>> 4 ) And then finally on references (again): Given that use of
>> I-D.ietf-core-stateless is recommend, I believe it should be normative
>> (and wait for publication of that doc).
> I guess since it's a MUST for the JRC, we need to do that.

Good. Thanks!

>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> I'm putting this one question in the comments section because there is
>> no concern that it does not work as specified but I wonder about the
>> design of the Parameter Update Response Message. Given the Parameter
>> Update Message is a confirmable CoAP message that is transmitted
>> reliable and the content of the Parameter Update Response Message is
>> empty, why do you need to send the Parameter Update Response Message at
>> all?
>> And some minor comments (mostly editorial proposals):
>> 0) I'd recommend to "Constrained Join Protocol (CoJP)" in the document
>> title to make clear that this is a protocol spec and not "only" and
>> abstract framework or something...
> so like:
>   title: Constrained Join Protocol for 6TiSCH

Do you propose to get rid of the “Minimal Security Framework” part and only call the document "Constrained Join Protocol (CoJP) for 6TiSCH”. I think this would be a more appropriate title, but maybe confirm with the rest of the group.


>> 1) Sec 3: Maybe I'm missing something but this seems contradictory:
>> "Provisioning the network identifier is RECOMMENDED."  And then at the
>> end of that paragraph: "This parameter MUST be provisioned to the 6LBR
>> pledge."+
> You are right. The last sentence does not belong.
> During the join process, the network identifer, returned in the CoJP response
> is a MUST (8.4.1)
>> 2) Sec 4.3.2: Not sure I fully understand the context of this sentence:
>> "The JP operates as the application-layer proxy."  Maybe "... operates
>> as an application-layer proxy" or probably even better "operates as
>> application-layer proxy" ? Also at this part of the document it is not
>> clear that the proxy actually interprets the CoAP message. I recommend
>> to mention this earlier in the doc and maybe add a forward reference to
>> section 7.
> reference added.
>> 3) Sec 5: Maybe just to be absolutely clear: OLD: "When sending frames
>> during the join process, the pledge sends unencrypted and
>> unauthenticated frames."  NEW: "When sending frames during the join
>> process, the pledge sends unencrypted and unauthenticated frames at the
>> link layer."
> done.
>> 4) Sec 6: "As a special case, the 6LBR pledge is expected to have an
>> additional network interface ..."  MAYBE: "As a special case, the 6LBR
>> pledge may have an additional network interface ..." ?
> done.
> --
> Michael Richardson <>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-