[6tisch] 802.15.4 "change" that will affect 6TiSCH.

[Tero Kivinen <[e-mail]>]

While I was doing the latest recirculation ballot for 802.15.4rev, I
noticed something that can affect 6tisch, my comment and proposed
resolution is:

My Comment:

	The TSCH pan formation should include not explaining that
	beacons can be secured, but if they are encrypted new devices
	cannot see the IEs and cannot join the network at all.

Proposed Change:

	Add note: “TSCH beacons cannot be encrypted, they can only be
	authenticated. This is because if the beacons are encrypted,
	then the TSCH Synchronization IE used to transmit ASN to
	joining devices will be encrypted. The joining (or devices who
	has lost synchronization with network) need to know the ASN
	before they can decrypt the beacon frame, thus they cannot
	decrypt the beacons and cannot join the network using
	encrypted beacons..”

I.e. this will affect the question whether the beacons can be
encrypted with default key, which was one of the suggestions for the
6tisch drafts.

This is something that is unchanged since 802.15.4-2011 and
802.15.4e-2012, i.e. the TSCH ASN has been carried in the Payload IEs,
and Payload IEs are encrypted if security level >= 4. And to be able
to decrypt the payload, you need to know ASN, which you cannot see as
it is in encrypted part...

The reason for this email is that people pointed me that there has
been discussion about what changes there has been in the revision that
would affect 6tisch and this is the latest one I found (just adding
text stating the fact that has been true already before).

There is also changes that might affect implementations, and those
changes are fixing security issues:

	* Disallow short addresses in Nonce generation
	
	* Removal of encrypt only mode (this caused easy way to attack
	  TSCH mode, i.e. attacker could pick any encrypted and
	  authenticated frame from the air, remove the MIC, change the
	  security level in header to be encrypt only, then modify the
	  packet at will, and then send it to final destination, which
	  would then decrypt and receive the frame without noticing
	  anything, this was not problem for non-TSCH mode, as
	  security level was used to generate Nonce).

	* Adding ability to filter whether MAC acts on information
          elements. The 802.15.4e didn't add any method of saying
          whether we should process information elements we receive in
          the frame. I.e. the implicit default was that they were all
          processed by MAC.

	* Fixes in the inbound security processing to clearly allow
          unsecured and secured frames to be processed at the same
          time.

	* Fixes in the inbound and outbound security processing for
          TSCH saying that we do not keep normal 32-bit FrameCounter
          when using TSCH mode, 802.15.4e didn't modify anything in
          inbound or outbound security porcedures, meaning that
          outbound processing rules still kept incrementing 32-bit
          macFrameCounter for each outgoinf frame, and stopping at
          counter error when it reached max value, even when it is not
          used at all in TSCH mode. Also in the inbound rules it did
          still got the frame counter from frame (not there in TSCH)
          and compared it against previous value etc...

	* Defined how new frames added in 802.15.4e are actually
          encrypted and MACed, the 802.15.4e did not modify the table
          53 listing private and open payloads, thus it was not clear
          how those are encrypted etc.

	* Changed the MAC command identifier to be encrypted for frame
          versions 0b10. MAC command fames with Frame versions 0b10
          can have payload IEs, and those are encrypted. The MAC
          command identifier is after Payload IEs, and it would be in
          clear, then the device would need to first n-bytes of the
          frame (n is unknown, before the frame is decrypted, because
          payload IEs have termination IE at the end), then get next
          byte as is, i.e. without decrypting it, and then decrypt
          rest of the frame. When polled from the 4e implementors they
          said they do nto do that, but they will encrypt and decrypt
          the MAC command identifier too for frame version 0b10. This
          also caused changes to the inbound state machine as now we
          cannot run filters based on the MAC command identifier for
          MAC command frames before we decrypt the frame.

	* Most likely still something more that I have forgotten...
          And of course some changes which do not affect TSCH, or
          which do not affect old devices (like adding new
          secFrameCounterPerKey property for key).

Ps. I have been too busy to really follow the 6tisch mailing list, but
perhaps I need to find time to do it. I did read the "removing the 'e'
thread" in the archives, and I think the correct thing would be to
refer to the 802.15.4 without any year or specific list of amendments. 
-- 
[e-mail]