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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 01 November 2019 21:15 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 1E94C120826; Fri, 1 Nov 2019 14:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rZkvBGEv5-pi; Fri, 1 Nov 2019 14:15:40 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D031112024E; Fri, 1 Nov 2019 14:15:39 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 59BCB3818F; Fri, 1 Nov 2019 17:12:50 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 73726612; Fri, 1 Nov 2019 17:15:38 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?us-ascii?Q?=3D=3Futf-8=3Fq=3FMirja=5FK=3DC3=3DBChlewind=3F=3D?= <ietf@kuehlewind.net>
cc: "The IESG" <iesg@ietf.org>, 6tisch-chairs@ietf.org, pthubert@cisco.com, draft-ietf-6tisch-minimal-security@ietf.org, 6tisch@ietf.org
In-Reply-To: <157244462862.32472.6918190621522301464.idtracker@ietfa.amsl.com>
References: <157244462862.32472.6918190621522301464.idtracker@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 01 Nov 2019 17:15:38 -0400
Message-ID: <14289.1572642938@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/WiifRuIqZhjRJKI3MgiVueMLCOI>
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: Fri, 01 Nov 2019 21:15:42 -0000

<#secure method=pgpmime mode=sign>

Mirja Kühlewind via Datatracker <noreply@ietf.org> 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.


    > 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?

    > 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 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.

    > 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.

    > 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.

    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------

    > 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

    > 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-