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

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Thu, 21 Jun 2018 12:41:27 +0200

Dear Benjamin,

today we published a new version of the draft including the changes
mentioned in the answers provided so far.

thanks again for your valuable reviews.
Xavi

2018-04-05 10:35 GMT+02:00 Xavi Vilajosana Guillen <[email-masked]>:

>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
> Internet Interdisciplinary Institute (IN3)
> Professor
> (+34) 646 633 681
> [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
> Universitat Oberta de Catalunya
>
> 2018-04-03 0:45 GMT+02:00 Benjamin Kaduk <[email-masked]>:
>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681
> [email-masked] <usuari@uoc..edu>
> http://xvilajosana.org
> http://wine.rdi.uoc..edu <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
>
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[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