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

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

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


XV: We propose to change RECOMMENDED to default as indicated.

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.

XV: Thanks, this has also been changed. "0 or more ..."

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.

XV: We propose to add at the end of Section 3.2.2 Generic 6P Message Format

  " 6P Requests, 6P Response and 6P Confirmation messages for a same
   transaction MUST share the same Version, SFID and SeqNum values."


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

XV: thanks again. We corrected that as well.

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.

XV: We clarified that l2 security is mandated as per previous comment.
Payload IEs must be encrypted.

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?

XV: thanks, that is a good clarification to add. We will just say that.


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.)"


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.

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:






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.



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.


kind regards
Xavi
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



-- 
Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
xvilajos...@uoc.edu
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
Universitat Oberta de Catalunya

2018-04-03 0:45 GMT+02:00 Benjamin Kaduk <ka...@mit.edu>:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-6tisch-6top-protocol-11: Discuss
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> 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.
>
> 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).
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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?
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>



-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
xvilajos...@uoc.edu <usu...@uoc.edu>
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
[image: Universitat Oberta de Catalunya]
­
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to