Subject: Re: [6tisch] comments to the “Minimal Security Framework for 6TiSCH” document

From: Mališa Vučinić <[email-masked]>
Date: Tue, 17 Jul 2018 17:56:15 +0200

Hi Xavi,

Many thanks for sending this review. See my responses inline.

Mališa

On Fri, Jun 29, 2018 at 5:37 PM Xavi Vilajosana Guillen <[email-masked]>
wrote:

> Hi,
>
> I reviewed the ”Minimal Security Framework for 6TiSCH” document.
>
> Here some comments that have not been mentioned by others.
>
> 1) I miss some section describing how errors are handled at the cbor
> level. This is what if the received Configuration option is wrong, e.g
> there is an element in the map with an unsupported value.
> Or even what if the Join Request contains a wrong role number?. Would be
> good to mention what are the actions taken by the JRC upon receiving a Join
> Request with an incorrect CBOR element. Also from the
> pledge point of view, what if the Join Response contains an unsupported
> parameter. I guess the same will apply for Update Request, from the 6N
> point of view.
>

This makes perfect sense. We focused on error handling in case security
errors are detected on the OSCORE layer, and somehow neglected the
parameter semantics.

My proposal is to add a new CBOR parameter to CoJP objects, e.g.
"error_code" carrying an array of errors codes that were detected.

With that, we'd need to make a table of most common errors on the CoJP
level.

Does that make sense?

>
> 2) The JRC is the origin of Parameter Update Requests which may contain
> for example rekeying material or a new short address. The draft needs to
> describe what happens if the destination 6N is not reachable.
> I understand that there will be a timeout and possibly will retry later or
> do not try anymore (this has to be stated).
> What if the node is no more in the network? when the JRC will stop sending
> the short address updates? When it will remove that node from its
> "database"?
>

I discuss this also during the meeting tomorrow. What you propose is indeed
something that an implementor must consider but I am not sure if we want to
specify any particular behavior in the draft, since this seems to be more
of a policy.

I can add explicit text discussing this issue, but leaving it up to the
implementation of the JRC to decide how transmission errors of CoAP CON
message, that is Parameter Update Request, should be handled. What do you
think?

>
> kind regards
> Xavi
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> [email-masked] <[email-masked]>
> http://xvilajosana.org
> http://wine.rdi.uoc.edu
> Parc Mediterrani de la Tecnologia
> Av Carl Friedrich Gauss 5, B3 Building
> 08860 Castelldefels (Barcelona). Catalonia. Spain
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Wed, 18 Jul 2018 17:35:57 +0200

Dear Malisa,

see my comments inline

Missatge de Mališa Vučinić <[email-masked]> del dia dt., 17 de
jul. 2018 a les 17:57:

> On Fri, Jun 29, 2018 at 5:37 PM Xavi Vilajosana Guillen <
> [email-masked]> wrote:
>
>> Hi,
>>

This makes sense. Maybe a concern is the length of the message which should
be kept small. Maybe we can discuss different options such a single error
byte (e.g., supporting 255 error codes) a bitmap or the proposed array of
errors.

>> I understand that there will be a timeout and possibly will retry later
>> or do not try anymore (this has to be stated).
>> What if the node is no more in the network? when the JRC will stop
>> sending the short address updates? When it will remove that node from its
>> "database"?
>>
>
> I discuss this also during the meeting tomorrow. What you propose is
> indeed something that an implementor must consider but I am not sure if we
> want to specify any particular behavior in the draft, since this seems to
> be more of a policy.
>
> I think that identifying the issue is important so implementers can take
it into account.

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

(+34) 646 633 681