Subject: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-6top-protocol-12: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 03 Jul 2018 19:46:02 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6tisch-6top-protocol-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for resolving my DISCUSS; original COMMENT section preserved below.

The CellList and CellOptions fields can effectively be redefined by the SF, so
the document only gives interpretations for them that are referred to as
"RECOMMENDED", which is a bit jarring since they seem to be expected to be the
default values.  Perhaps it would be better to say that the descriptions in
this document are the "default interpretation unless redefined by the SF in
use".

In several places we see:

   CellList:  A list of 0, 1 or multiple candidate cells.

How about "0 or more"?  Also, the "Its length is [...]" is not
universally present as the next sentence.

As another general note, it might be useful to say a bit more about the fields
in the Response and Confirmation messages, i.e., give a list of fields which
must match the ones in the corresponding Request.

Section 3.3.3

   Upon receiving the request, Node B checks if the length of the
   Candidate CellList is larger or equal to NumCells.  Node B's SF
   verifies that all the cells in the Relocation CellList are indeed
   scheduled with node A, and are associate the options specified in the
   CellOptions field.  If that check fails, node B MUST send a 6P
   Response to node A with return code RC_ERR_CELLLIST.  If that check
   passes,

I think this should be "if either check fails" and "if both checks
pass".

Section 3.3.6

If link-level access message protection is not in use, the ability to inject a
CLEAR message with no SeqNum checking seems a fairly powerful capability to
give to an attacker.  I don't immediately see a way around it, but this would
be a candidate for inclusion in an expanded Security Considerations.

Section 3.3.7

Do we need to explicitly say that the SIGNAL payload's length is determined by
the length of the IE header?

Section 3.4.3 is perhaps a bit underspecified.
In particular, does "consider it never happened" include reusing
that SeqNum for the next transaction?

Section 3.4.6
Is there value in using the term "lollipop counter" when the
behavior needs to be defined here anyway?

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.

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.

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?