odid_message_build_pack and ODID_PACK_MAX_MESSAGES limitations

[madatr]

Hi All,

Firstly, thank you for your great and helpful work.

I am currently tinkering with Authentication part of opendroneid and I am trying to push it to its limits. I have assembled an entire ODID_UAS_Data structure and I am trying to build an ODID message pack. However it obviously fails due to the fact that I am filling ODID_Auth_data to almost its limits.

From the your code, ODID_PACK_MAX_MESSAGES is defined to be 9, therefore if a user wants to build an ODID_MessagePack they can have:

1 x ODID_BasicID_data BasicID 1 x ODID_Location_data Location; 1 x ODID_SelfID_data SelfID; 1 x ODID_System_data System; 1 x ODID_OperatorID_data OperatorID;

which only leaves only 4 pages of the ODID_Auth_data object before the limit of ODID_PACK_MAX_MESSAGES is reached:

4 x ODID_Auth_data Auth;

Deciding to only send pages of the ODID_Auth_data object then a user can only pack 9 pages of that, it allows up to 16 and a user can use 255 bytes for authentication purposes due to the uint8_t "length" field limit.

How would you advice someone wanting to pack and send 16 full pages of ODID_Auth_data or at least take advantage of the allowed 255 bytes of authentication data (12 pages of ODID_Auth_data), hopefully also packing other data such as location and basic Id.

Have you set this limit arbitrarily or is it for some reasons that I have not come across in any documentation? if it is changeable then would it be still ok to transmit this over WiFi/Bluetooth then receive it and decode it without any issue or breaking standards?

I have thought of splitting up the data; send basic id and what not in a transmission then if length permits send ODID_Auth_data in a single pack or in worst case divide it as well into separate transmissions.

Any advice or pointers would be very helpful as I am currently stuck at it for some time, I have seen a few implementations/examples of mock data being sent but no one has gone over 4 pages of ODID_Auth_data. I plan to continue working on this aspect and would gladly contribute any useful outputs to this project.

Sorry for the long explanation but I wanted to be clear.

Thanks for your time and help.

[kc2rxo]

In regards to the specification:

Authentication data is limited in Table 8 to 255 bytes but in practice to 201 bytes (equivalent to 9x Bluetooth 4 authentication pages). This is due to the limit found by @friissoren with regards to Bluetooth 5 implementations he was working on at the time. Table 8 is therefore wrong as it states the Length field has a maximum of 255 when it should really be 201.

I have done a search of both F3411-22a and F3586-22 to find the requirement is present (limit of 9 for Message Pack as stated in Section 5.4.7.7) but nowhere the explanation as to why. Perhaps this should be rectified in a revision of F3411.

Beyond the limit of the Length field additional data can be added but as stated in 5.4.5.15 of F3411-22a:

The Length field shall specify the exact length in bytes of the authentication payload data. Additional data may be sent (for example: additional Forward Error Correction (FEC) data) after the authentication payload data.

Additional Data is NOT part of the authentication payload. This implies it should not be used for signatures. This was our original intent but did not clearly get into the document.

Nowhere in F3411, F3586 or Part 89 (the FAA rule) does it state that data over different transport media need to be the same an interesting omission from our F38 text as this drove some of the considerations above.

In regards to implementation:

I have also run into the same limitation you have while attempting to implement DRIP Authentication (https://datatracker.ietf.org/doc/draft-ietf-drip-auth/). This is a great example of using the Additional Data in practice to use FEC only over Bluetooth 4 and not Bluetooth 5 (shameless plug as I am one of the primary author of said work).

The limitation of having to send the entire UAS_data structure into the Message Pack builder function can cause a perfectly valid Authentication Message that requires all the "slots" of the Message Pack to fail to be built. One could systematically blank and refill the data structure as needed to meet the Message Pack requirements, but at what cost to code performance and flow?

Your idea of breaking the Authentication Pages over multiple Message Packs may not work. I have always been in the former camp of an Authentication Message sent in a Message Pack is complete in that Message Pack.

The Message Counter byte MUST be the same for all the Authentication Pages for a decoder to properly re-interleave them into a single message. This is stated in Section 5.4.4.2 of F3411-22a.

A potential work around would be to send as many Message Packs are needed swapping out remaining "slots" with Authentication Pages until all pages are sent and choosing not to increment the Message Counter of the Message Packs as "the data hasn't changed". One could argue of layer violations when changing the Message Counter for arbitrary application data reasons this could cause decode failures.

Regardless the flexibility needed to build a Message Pack is currently lacking when using the UAS_data structure and have it run through in Message Type order explicitly. In my Python implementation of F3411 I can take a list of Messages in and just perform a sort of the list to ensure the requirement to be in Message Type order as stated in Table 13 of F3411-22a (oddly not in the main text body) is fulfilled.

Strong authentication, even with compact modern crypto (as in DRIP), requires pagination that ODID doesn't seem to support right now.

[friissoren]

This is an interesting question. I assume you have read this, but it probably doesn't help, since that is mainly about adding forward error correction data.

The limit of max 9 messages in a message pack comes from Bluetooth 5. The long range transmission mode only allows storing something close to 255 bytes in an advertising message and due to the various header overhead etc. there is only room for 9 messages. I found some further clarification of this in an old mail discussion on the DRIP mail list:

• About the max page count. I personally don’t see any problem in increasing that in the next version of the ASTM standard. However, the maximum number of messages that can fit for Bluetooth Extended Advertising is 9. With 9 messages, the total size is 1 + 5 + 3 + 9 ODID_MESSAGE_SIZE = 234 bytes. Adding a 10th message would bring that to 259 bytes. (See Figure 9 in the ASTM spec: Length + type + 16-bit UUID + code + counter + ProtoVersion:MessageType + SingleMessageSize + MsgPackSize + 9ODID_Messages_encoded).
• As a side-note, the two Bluetooth chipsets I have worked with, impose some additional size limits for the extended advertising data in their Bluetooth SW stack. The TI CC2640 seems to have a limit somewhere around 241 bytes and the nRF52840 a limit somewhere around 245 bytes. When I increase the buffer size larger than those values, the extended advertising messages on the S8 Coded PHY are never visible on the receiver phone. The transmitter SW stacks must be filling some of the fields in the extended header (Bluetooth Core spec 5.1, vol 6, B, 2.3.4 fig 2.14), which reduces the possible size of the advertising data. This still allows 9 messages, fortunately.
• I tried to read through the WiFi-NaN spec to see if there are similar restrictions in there but didn’t find any. However, I don’t have any practical experience with implementing a WiFi-NaN transmitter. It is possible that some restriction applies.

\<atw> This lines up a bit with what I have experiences working with some Laird modules (they use the nRF52840). I couldn't fit the 10 pages and dropped to 9 for the extended payload. I figured it was an implementation restriction...very insightful and changes a lot of text/sizes in the document going forward. \</atw> \<sf> It wasn’t until last week that I realized that it will never be possible to fit more than 9 messages for BT5. Some text in the ASTM standard should probably be added to clarify this. I have a personal list of things to look at when the discussion starts up again (next year?). I will add it there. \</sf>

It seems that we reduce the max message amount to 9 in the standard but never added an explanation of why. There are unfortunately a fair amount of design decisions that were made during the standardization that are reflected in the standard but never explained anywhere, why we ended up with a particular solution.

The above comment was before Wi-Fi Beacon was added as a viable transmission option. I don't know the details, but it is possible that both Wi-Fi NaN and Beacon will allow you to stuff in more data than 255 bytes in a single transmission. But for the sake of transmission compatibility, those transmission options were limited also to max 9 messages in length.

[gabrielcox]

To close this item out., the short answer to the question is that the 9 page limit is driven by the (BT5 AE) max payload size and 10 messages will go over (as both Soren and Adam said). If you include other messages in the payload, then the max page count will be reduced my the number of additional messages in the payload. The DRIP folks (Adam in this thread being one of them) have done a lot of activity in this space including standardization of this authentication payload. If you really get into payload authentication, I would encourage coordinating with the DRIP folks.