Inquiry about Security Openthread 1.2

[Khaled Ahmed]

Hi all,

I have some questions related to security processing in radio and in OT code that need some clarifications:

In case of time sync and CSL are supported and Radio doesn't support OT_RADIO_TRANSMIT_SEC:

• Assume secured transmission: My understanding in such a case is that security shall be processed by upper layers (mac or sub-mac) not the radio layer.
  If my understanding is correct, How can the radio layer change some fields in the MHR (CSL and time sync IEs) of an already secured frame? (This requires a MIC(authentication tag) change)
• Assume retransmission of the previously secured packet: 
• if (radio doesn't support retransmission):  Does openthread handle re-securing a frame that has been changed?  (as CSL IE and Time sync shall be updated in retransmission) 
                                                                          Does openthread provide a way to re-secure the packet by only re-generate the MIC?
• if (radio does support retransmission)    : How can the radio re-encrypt the packet even if it doesn't support security?
                                                                         Is there any upper layer function to do so and shall be called in this case?

Now assume Radio supports  OT_RADIO_TRANSMIT_SEC and retransmission:

• Shall radio take care of re-encryption of the packet in case of retransmission due to updating of mentioned IEs?

Thanks on advance,

Khaled Ali

[Jonathan Hui]

If the radio supports OT_RADIO_CAPS_TRANSMIT_SEC, the radio is responsible for securing transmitted frames. Note that the radio platform API includes functions for setting the MAC frame counter and key.

The Thread Group is actually discussing details around retransmission of CSL frames in SPEC-977 (only accessible to Thread Group members). In particular, IEEE 802.15.4 requires retransmissions of a frame to remain unmodified relative to the first transmission. OpenThread does not currently update the CSL IE on a retransmission (see openthread/openthread#6275).

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/CAMAf3rPq%2BABUVixYUPrviz5o_A_2daB%3DT7NVzV8wQbi-VmWw2A%40mail.gmail.com.

[Khaled Ahmed]

Hi Jonathan,

Thanks for your reply.

I still can't understand how CSL will work if Radio doesn't support OT_RADIO_CAPS_TRANSMIT_SEC? I mean the first transmission (not retransmission) which layer will add the CSL IE (if security is handled before calling the radio layer then radio shall not update it)?

And

What about Time Sync IE does openthread add it and radio shall not touch it?

Thanks on advance,

Khaled Ali

[Jonathan Hui]

On Wed, Jun 2, 2021 at 2:10 AM Khaled Ahmed <engkhale...@gmail.com> wrote:

I still can't understand how CSL will work if Radio doesn't support OT_RADIO_CAPS_TRANSMIT_SEC? I mean the first transmission (not retransmission) which layer will add the CSL IE (if security is handled before calling the radio layer then radio shall not update it)?

We currently require OT_RADIO_CAPS_TRANSMIT_SEC to support CSL.

What about Time Sync IE does openthread add it and radio shall not touch it?

OpenThread does not currently support the Time Sync feature with RCP - see openthread/openthread#6028. Note that this is an experimental feature within the OpenThread project and not a part of the Thread specification.

--

Jonathan Hui

[Khaled Ahmed]

Thanks alot Jonathan 

[Khaled Ahmed]

Hi Jonathan,

While revising our conversation and standard:

"In particular, IEEE 802.15.4 requires retransmissions of a frame to remain unmodified relative to the first transmission" i did found that we can't update the DSN. Can you mention the paragraph in the standard please?

If CSL will not be updated i think CSL phase will be shifted with each transmission which may lead to miss estimation of sample window at the leader side (CSL Transmitter).

Thanks

Khaled Ali

[Khaled Ahmed]

[Clear update]

While revising our conversation and standard:

"In particular, IEEE 802.15.4 requires retransmissions of a frame to remain unmodified relative to the first transmission" I did find that we can't update the DSN. Can you mention the paragraph which mentions not updating the whole packet in the standard please?

If CSL IE will not be updated i think CSL phase will be shifted with each re-transmission which may lead to miss estimation of sample window at the leader side (CSL Transmitter).

[Jonathan Hui]

On Mon, Jun 7, 2021 at 2:34 AM Khaled Ahmed <engkhale...@gmail.com> wrote:

[Clear update]

While revising our conversation and standard:

"In particular, IEEE 802.15.4 requires retransmissions of a frame to remain unmodified relative to the first transmission" I did find that we can't update the DSN. Can you mention the paragraph which mentions not updating the whole packet in the standard please?

IEEE 802.15.4-2015 Section 6.7.4.3 states:

When not using TSCH mode and a frame with the Security Enabled field set to one is retransmitted, the

frame shall be retransmitted without changes and without passing through the outgoing frame security

procedure, as defined in 9.2.1.

 

If CSL IE will not be updated i think CSL phase will be shifted with each re-transmission which may lead to miss estimation of sample window at the leader side (CSL Transmitter).

Yes, this reason is why we currently have a workaround with openthread/openthread#6342.

Of course, the workaround is not ideal. This issue is being discussed within the Thread Group in SPEC-977. If you are a Thread Group member, please join in on the discussion.

--

Jonathan Hui