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

[Mirja Kuehlewind <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> <#secure method=pgpmime mode=sign>
> 
> Mirja Kühlewind via Datatracker <[e-mail]> 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!


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

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.

Thanks!
Mirja


> 
>> 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 <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
>