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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
