Re: [Drip] Martin Duke's Discuss on draft-ietf-drip-auth-46: (with DISCUSS and COMMENT)

[Adam Wiethuechter <[e-mail]>]

Hi Martin,

It is unfortunate that F3411 is not free. We are sorry that this makes doing a full review of the specification difficult. Section 3.2 is our attempt to fill in as much as possible for background on the framing for the Authentication Message.

The thing to remember is that for Broadcast RID is a one-way RF broadcast and no two-way communication occurs between the Observer and the UA. The message rate is at a minimum of one message set [1] per second. The idea, foolish or otherwise, is to blast out as much as possible and quickly as possible. If you miss the Location message (giving latitude/longitude of UA) in one second, the hope is that you get it in the next second or two. Data from one second in the past over Broadcast RID is considered "out of date" anyways so if you missed it no big deal.

F3411 makes no explicit mention of congestion control, thus leaving it to lower layers. IMO Broadcast RID itself (excluding the use of Authentication) can easily overwhelm the spectrum once a dozen UA are in the same area. We are sadly no matter what we do in a RF congested regime. All the selected transports are in the 2.4GHz shared spectrum. The only exception is if Wi-Fi and Beacon are selected to go over 5GHz, I believe no jurisdiction allows this at this time, which reduces range anyway.

As we show in Appendix B.2 there is a schedule that in one second can transmit two full sets of messages, a Manifest authenticating all of them and single page of either a Wrapper or Link (which bleeds out of the course of 8 seconds). If you lose more than 1 page in a Manifest in that schedule there is no "loss"; just wait for the next second to come around and hopefully get at least N-1 pages for that set.

For Wrapper and Link you must wait for the next Link/Wrapper running over the 8 second window, which itself is cycling in a pattern shown in the appendix below Figure 13. You will notice in that pattern that the most important Link message (BE: HDA on UA) is sent a total of 8 times followed by 4x for BE: RAA on HDA, 2x for BE: Apex on RAA and Wrapper and a single BE: IANA on UAS RID Apex.

The loss of a page can only occur over Bluetooth 4 (Legacy Transport).  Bluetooth 5, Wi-Fi NAN and 802.11 Beacon (Extended Transport) all have some form of Error Correction built into their transport layers protecting them. And the way those are sent over F3411 (via Message Pack) means that there can be no lost page in Authentication.

Per F3411 (and at least FAA via F3586) when performing Bluetooth 5 you MUST also send Bluetooth 4 concurrently. This is due to Apple devices not supporting the required Bluetooth 5 extensions or any of the Wi-Fi options. Most UA either do only Wi-Fi/Beacon (most common) or only Bluetooth. There are a few that can support all but usually have configuration for user to select which to run. As such, most Observer devices will typically see an Extended Transport over a Legacy one anyways.

If an Observer can see multiple transports, they will most likely take the latest complete data from whatever transport it came from and use that.

I hope this answers your questions, it felt like rambling a little bit at the end.

[1] One set varies between different Civil Aviation Authority (CAA) jurisdiction. In the US a set consists of 1x Basic ID, 1x Location and 1x System message. In the EU the set is identical with the inclusion of 1x Operator ID. Japan is 2x Basic ID, 1x Location, 1x Authentication, 1x System.
--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Martin Duke via Datatracker <[e-mail]>
Sent: Wednesday, January 31, 2024 5:06 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Martin Duke's Discuss on draft-ietf-drip-auth-46: (with DISCUSS and COMMENT)

Martin Duke has entered the following ballot position for
draft-ietf-drip-auth-46: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-drip-auth/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm not able to access [F3411] and therefore am unable to assess if this design
creates excessive load on the network.

In particular, I'm somewhat concerned about two pages being lost, overpowering
the FEC and resulting in loss of the entire authentication message (and the
other message types it is wrapping!) and retransmission of the whole suite,
depending on how sophisticated the loss recovery is. In some edge cases, this
might never converge.

No doubt the authors can provide a high-level view of how congestion control
and loss recovery work?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Gorry for the TSVART review.