rfc9434v4.txt   rfc9434.txt 
skipping to change at line 820 skipping to change at line 820
RID or Network RID. The EASA initially specified Broadcast RID for RID or Network RID. The EASA initially specified Broadcast RID for
essentially all UAS and is now also considering Network RID. The FAA essentially all UAS and is now also considering Network RID. The FAA
UAS RID Final Rules [FAA_RID] permit only Broadcast RID for rule UAS RID Final Rules [FAA_RID] permit only Broadcast RID for rule
compliance but still encourage Network RID for complementary compliance but still encourage Network RID for complementary
functionality, especially in support of UTM. functionality, especially in support of UTM.
One opportunity is to enhance the architecture with gateways from One opportunity is to enhance the architecture with gateways from
Broadcast RID to Network RID. This provides the best of both and Broadcast RID to Network RID. This provides the best of both and
gives regulators and operators flexibility. It offers advantages gives regulators and operators flexibility. It offers advantages
over either form of UAS RID alone, i.e., greater fidelity than over either form of UAS RID alone, i.e., greater fidelity than
Network RID reporting of planned area operations, surveillance of Network RID reporting of [FAA_RID] planned area operations, together
areas too large for local direct visual observation, and direct Radio with surveillance of areas too large for local direct visual
Frequency Line Of Sight (RF-LOS) link-based Broadcast RID (e.g., a observation and direct Radio Frequency Line Of Sight (RF-LOS) link-
city or a national forest). based Broadcast RID (e.g., a city or a national forest).
These gateways could be pre-positioned (e.g., around airports, public These gateways could be pre-positioned (e.g., around airports, public
gatherings, and other sensitive areas) and/or crowdsourced (as gatherings, and other sensitive areas) and/or crowdsourced (as
nothing more than a smartphone with a suitable app is needed). nothing more than a smartphone with a suitable app is needed).
Crowdsourcing can be encouraged by quid pro quo, providing CS-RID Crowdsourcing can be encouraged by quid pro quo, providing CS-RID
Surveillance Supplemental Data Service Provider (SDSP) outputs only Surveillance Supplemental Data Service Provider (SDSP) outputs only
to CS-RID Finders. As Broadcast RID media have a limited range, to CS-RID Finders. As Broadcast RID media have a limited range,
gateways receiving messages claiming locations far from the gateway messages claiming sender (typically UA) locations far from a physical
can alert authorities or a Surveillance SDSP to the failed sanity layer receiver thereof ("Finder" below, typically Observer device)
check possibly indicating intent to deceive. CS-RID SDSPs can use should arouse suspicion of possible intent to deceive; a fast and
messages with precise date/time/position stamps from the gateways to computationally inexpensive consistency check can be performed (by
multilaterate UA locations, independent of the locations claimed in the Finder or the Surveillance SDSP) on application layer data
the messages, which are entirely self-reported by the operator in UAS present in the gateway (claimed UA location vs physical receiver
RID and UTM, and thus are subject not only to natural time lag and location), and authorities can be alerted to failed checks. CS-RID
error but also operator misconfiguration or intentional deception. SDSPs can use messages with precise date/time/position stamps from
the gateways to multilaterate UA locations, independent of the
locations claimed in the messages, which are entirely self-reported
by the operator in UAS RID and UTM, and thus are subject not only to
natural time lag and error but also operator misconfiguration or
intentional deception.
Multilateration technologies use physical layer information, such as Multilateration technologies use physical layer information, such as
precise Time Of Arrival (TOA) of transmissions from mobile precise Time Of Arrival (TOA) of transmissions from mobile
transmitters at receivers with a priori precisely known locations, to transmitters at receivers with a priori precisely known locations, to
estimate the locations of the mobile transmitters. estimate the locations of the mobile transmitters.
Further, gateways with additional sensors (e.g., smartphones with Further, gateways with additional sensors (e.g., smartphones with
cameras) can provide independent information on the UA type and size, cameras) can provide independent information on the UA type and size,
confirming or refuting those claims made in the UAS RID messages. confirming or refuting those claims made in the UAS RID messages.
skipping to change at line 1000 skipping to change at line 1005
receiver. Thus, it is pointless to attempt to provide relief from receiver. Thus, it is pointless to attempt to provide relief from
DoS attacks, as there is always the ultimate RF jamming attack. DoS attacks, as there is always the ultimate RF jamming attack.
Also, DoS may be attempted with spoofing/replay attacks; for which, Also, DoS may be attempted with spoofing/replay attacks; for which,
see Section 9.4. see Section 9.4.
9.4. Spoofing & Replay Protection 9.4. Spoofing & Replay Protection
As noted in Section 5, spoofing is combatted by the intrinsic self- As noted in Section 5, spoofing is combatted by the intrinsic self-
attesting properties of HHITs, plus their registration. Also, as attesting properties of HHITs, plus their registration. Also, as
noted in Section 5, to combat replay attacks, a receiver MUST NOT noted in Section 5, to combat replay attacks, a receiver MUST NOT
trust an observed UA that is identified in the Basic ID message trust any claims nominally received from an observed UA (not even the
(i.e., possesses the corresponding private key) until it receives a Basic ID message purportedly identifying that UA) until the receiver
verifies that the private key used to sign those claims is trusted,
that the sender actually possesses that key, and that the sender
appears indeed to be that observed UA. This requires receiving a
complete chain of endorsement links from a root of trust to the UA's complete chain of endorsement links from a root of trust to the UA's
leaf DET, plus a signed message containing frequently changing and leaf DET, plus a message containing suitable nonce-like data signed
unpredictable but sanity-checkable data (e.g., a Location/Vector with the private key corresponding to that DET, and verifying all the
message), and verifies all the foregoing. foregoing. The term "nonce-like" describes data that is readily
available to the prover and the verifier, changes frequently, is not
predictable by the prover, and can be checked quickly at low
computational cost by the verifier; a Location/Vector message is an
obvious choice.
9.5. Timestamps & Time Sources 9.5. Timestamps & Time Sources
Section 6 and, more fundamentally, Section 3.3 both require Section 6 and, more fundamentally, Section 3.3 both require
timestamps. In Broadcast RID messages, [F3411-22a] specifies both timestamps. In Broadcast RID messages, [F3411-22a] specifies both
32-bit Unix-style UTC timestamps (seconds since midnight going into 32-bit Unix-style UTC timestamps (seconds since midnight going into
the 1st day of 2019, rather than 1970) and 16-bit relative timestamps the 1st day of 2019, rather than 1970) and 16-bit relative timestamps
(tenths of seconds since the start of the most recent hour or other (tenths of seconds since the start of the most recent hour or other
specified event). [F3411-22a] requires that 16-bit timestamp specified event). [F3411-22a] requires that 16-bit timestamp
accuracy, relative to the time of applicability of the data being accuracy, relative to the time of applicability of the data being
skipping to change at line 1117 skipping to change at line 1129
Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
Entity Tag Authentication Formats & Protocols for Entity Tag Authentication Formats & Protocols for
Broadcast Remote ID", Work in Progress, Internet-Draft, Broadcast Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-auth-30, 28 March 2023, draft-ietf-drip-auth-30, 28 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip- <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
auth-30>. auth-30>.
[DRIP-REGISTRIES] [DRIP-REGISTRIES]
Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET) Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET)
Identity Management Architecture", Work in Progress, Identity Management Architecture", Work in Progress,
Internet-Draft, draft-ietf-drip-registries-11, 30 June Internet-Draft, draft-ietf-drip-registries-12, 10 July
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
drip-registries-11>. drip-registries-12>.
[F3411-19] ASTM International, "Standard Specification for Remote ID [F3411-19] ASTM International, "Standard Specification for Remote ID
and Tracking", ASTM F3411-19, DOI 10.1520/F3411-19, May and Tracking", ASTM F3411-19, DOI 10.1520/F3411-19, May
2022, <https://www.astm.org/f3411-19.html>. 2022, <https://www.astm.org/f3411-19.html>.
[F3586-22] ASTM International, "Standard Practice for Remote ID Means [F3586-22] ASTM International, "Standard Practice for Remote ID Means
of Compliance to Federal Aviation Administration of Compliance to Federal Aviation Administration
Regulation 14 CFR Part 89", ASTM F3586-22, Regulation 14 CFR Part 89", ASTM F3586-22,
DOI 10.1520/F3586-22, July 2022, DOI 10.1520/F3586-22, July 2022,
<https://www.astm.org/f3586-22.html>. <https://www.astm.org/f3586-22.html>.
 End of changes. 6 change blocks. 
19 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.48.