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 protected]>: > > 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 protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > Internet Interdisciplinary Institute (IN3) > Professor > (+34) 646 633 681 > [email protected] > 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 protected]>: > >> 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 protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 > [email protected] <[email protected]> > 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 > [image: Universitat Oberta de Catalunya] > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
