Subject: Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-6top-protocol-11: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Jul 2018 22:45:31 -0500

Hi Xavi,

My sincere apologies for the delayed response.  I guess this email slipped
through the cracks somehow, so thank you for the more recent reminder.

As you hopefully saw, I did clear the DISCUSS position already; a few more
notes inline (with some portions trimmed).

On Thu, Apr 05, 2018 at 10:35:36AM +0200, Xavi Vilajosana Guillen wrote:
> Dear Benjamin,
> 
> thanks so much for your detailed review. We will proceed to update the
> draft following your comments as discussed inline with your remarks (our
> responses prepended with XV:). The next published version will include the
> changes proposed here after we close this discussion.
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 3.5 states:
> 
>    [...] When link-layer
>    security is enabled, the 6P messages MUST be secured.
> 
> but Section 5 (the Security Considerations) says:
> 
>    6P messages are carried inside 802.15.4 Payload Information Elements
>    (IEs).  Those Payload IEs are encrypted and authenticated at the link
>    layer through CCM* [CCM-Star].
> 
> implying that this message protection is always enabled.  So, which is it --
> always-on, or (application)-controlled? If use of link-layer security is
> optional, then the security considerations for the case without link-layer
> security should be documented.
> 
> XV: Payload IEs are encrypted. 6TiSCH should mandate the use of security
> and hence the
> sentence in Section 3.5 should be removed. The whole section 3.5 should
> read as:
> 
>  "6P messages MUST be secured through link-layer security.  This is
>    possible because 6P messages are carried as Payload IEs."

Excellent; that was the answer I was hoping it was going to be :)

> Separately, Section 3.2.2 describes the generic message format, but only for
> version 0. Some indication should be given as to which aspects of the format
> are required to be invariant across all versions of 6P (and thus which
> aspects
> are potentially specific to version 0). Some readers might assume that only
> the
> version nybble is invariant (though there also seems to be a requirement in
> Section 3.4.1 that the RC_ERR_VERSION response remain invariant to some
> extent).
> 
> XV: Interesting comment. We added a sentence indicating that:
> 
> "Future versions of 6P Message SHOULD maintain the format of the 6P
> Version, Type and Code fields for backward compatibility."
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 3.4.3 is perhaps a bit underspecified.
> In particular, does "consider it never happened" include reusing
> that SeqNum for the next transaction?
> 
> XV: Yes, the SeqNum won´t be updated as the transaction is not committed.
> we propose to update the text with this sentence:
> "(i.e., reverting changes to the schedule or SeqNum done by this
> transaction.)"

Ah, thanks.  (I myself was not entirely sure from reading the document, so
it's good to have that confirmed.)

> 
> Section 3.4.6
> Is there value in using the term "lollipop counter" when the
> behavior needs to be defined here anyway?
> 
> XV: for us is a term that illustrates the type of counter used. We do not
> see any problem on keeping it but if there is strong opposition we can
> remove it. We are open to further advise on this.

I don't see a problem to keep it, either; it can be useful as a shortcut
for people who do know the term to pull in their previous experience with
the technique.

> Section 3.4.6.2
> 
> I'd be interested to see an example where the node that has
> power-cycled is the one sending the request that triggers
> inconsistency detection.
> 
> XV: Thanks for the proposal. We added such example:

Thank you!

> 
> 
> 
> 
> 
> Section 5
> 
>    [...] These cases
>    SHOULD be handled by an appropriate policy, such as blacklisting the
>    attacker after several attempts.
> 
> It's not clear that pure blacklisting is always an appropriate
> policy.  Rate-limiting or time-limited blacklisting might be a more
> appropriate example.
> 
> Though key management is out of scope, it may be worth explicitly mentioning
> that forgery and misattribution attacks become more damaging when a single
> key is shared amongst a group of more than 2 participants.
> 
> XV: Security considerations section has been extended as follows:
> 
>  6P messages are carried inside 802.15.4 Payload Information Elements
>    (IEs).  Those Payload IEs are encrypted and authenticated at the link
>    layer through CCM* [CCM-Star].  6P benefits from the same level of
>    security as any other Payload IE.  The 6P protocol does not define
>    its own security mechanisms.  In particular, although a key
>    management solution is out of scope of this document, the 6P protocol
>    will benefit for the key management solution used in the network.
>    This is relevant as security attacks such as forgery and
>    misattribution attacks become more damaging when a single key is
>    shared amongst a group of more than 2 participants.
> 
>    The 6P protocol does not provide protection against DOS attacks.
>    Example attacks include, not sending confirmation messages in 3-step
>    transaction, sending wrongly formatted requests, etc.  These cases
>    SHOULD be handled by an appropriate policy, such as rate-limiting or
>    time-limited blacklisting the attacker after several attempts.  The
>    effect on the overall network is mostly localized to those two nodes,
>    as communication happens in dedicated cells.

That's perfect; thanks!

> 
> 
> In the IANA considerations, should the new subregistries (e.g., message
> types
> and CellOptions bitmap) be scoped down to just 6P version 0 or are they
> intended to be version-agnostic?
> 
> XV: We think they should be version-agnostic.

Okay, I just wanted to check.

-Benjamin