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

["Pascal Thubert (pthubert)" <[e-mail]>]

Regards,

Pascal

> Le 5 déc. 2019 à 04:06, Mirja Kuehlewind <[e-mail]> a écrit :
> 
> 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
> 


I’m happy with the renaming. We had a trend to call everything minimal just like there was a trend to call thing simple. That’s fine to remember what we are after during the development phase of the protocol but useless and hard to prove afterwards.

The Minimal fragments draft  was already renamed by the way...


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