Crowd Sourced Remote ID

1.1. Role of Supplemental Data Service Provider (SDSP)

The DRIP Architecture [I-D.ietf-drip-arch] introduces the basic CS-RID entities including CS-RID Finder and CS-RID SDSP. This document has minimal information about the actions of SDSPs. In general the SDSP is out of scope of this document. That said, the SDSPs should not simply proxy B-RID messages to the UTM(s). They should perform some minimal level of filtering and content checking before forwarding those messages that pass these tests in a secure manner to the UTM(s).¶

The SDSPs are also capable of maintaining a monitoring map, based on location of active Finders. UTMs may use this information to notify authorized observers of where there is and there is not monitoring coverage. They may also use this information of where to place pro-active monitoring coverage.¶

An SDSP should only forward Authenticated B-RID messages like those defined in [drip-authentication] to the UTM(s). Further, the SDSP SHOULD validate the Remote ID (RID) and the Authentication signature before forwarding anything from the UA, and flagging those RIDs that were not validated. The SDSP MAY forward all B-RID messages to the UTM, leaving all decision making on B-RID messages veracity to the UTM.¶

When 3 or more Finders are reporting to an SDSP on a specific UA, the SDSP is in a unique position to perform multilateration on these messages and compute the Finder's view of the UA location to compare with the UA Location/Vector messages. This check against the UA's location claims is both a validation on the UA's reliability as well as the trustworthiness of the Finders. Other than providing data to allow for multilateration, this SDSP feature is out of scope of this document. This function is limited by the location accuracy for both the Finders and UA.¶

1.2. Draft Status

This draft is still incomplete. New features are being added as capabilities are researched. The actual message formats also still need work.¶

2.1. Requirements Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terms defined in [RFC9153] and [I-D.ietf-drip-arch].¶

2.2. Definitions

B-RID:

Broadcast Remote ID. A method of sending RID messages as 1-way transmissions from the UA to any Observers within radio range.¶

ECIES:

Elliptic Curve Integrated Encryption Scheme. A hybrid encryption scheme which provides semantic security against an adversary who is allowed to use chosen-plaintext and chosen-ciphertext attacks.¶

Finder:

In Internet connected device that can receive B-RID messages and forward them to a UTM.¶

Multilateration:

Multilateration (more completely, pseudo range multilateration) is a navigation and surveillance technique based on measurement of the times of arrival (TOAs) of energy waves (radio, acoustic, seismic, etc.) having a known propagation speed.¶

Net-RID:

Network Remote ID. A method of sending RID messages via the Internet connection of the UAS directly to the UTM.¶

3.1. Meeting the needs of Network Remote ID

The USA Federal Aviation Authority (FAA), in the January 2021 Remote ID Final rule [FAA-FR], postponed Network Remote ID (Net-RID) and focused on Broadcast Remote ID. This was in response to the UAS vendors comments that Net-RID places considerable demands on then currently used UAS.¶

However, Net-RID, or equivalent, is necessary for UTM and knowing what soon may be in an airspace. A method that proxies B-RID into UTM can function as an interim approach to Net-RID and continue as a adjunct to Net-RID.¶

3.2. Advantages of Broadcast Remote ID

B-RID has its advantages over Net-RID.¶

• B-RID can more readily be implemented directly in the UA. Net-RID will more frequently be provided by the GCS or a pilot's Internet connected device.¶

  • If Command and Control (C2) is bi-directional over a direct radio connection, B-RID could be a straight-forward addition.¶
  • Small IoT devices can be mounted on UA to provide B-RID.¶
• B-RID can also be used by the UA to assist in Detect and Avoid (DAA).¶
• B-RID is available to observers even in situations with no Internet like natural disaster situations.¶

3.3. Trustworthiness of Proxied Data

When a proxy is introduced in any communication protocol, there is a risk of corrupted data and DOS attacks.¶

The Finders, in their role as proxies for B-RID, are authenticated to the SDSP (see Section 4). The SDSP can compare the information from multiple Finders to isolate a Finder sending fraudulent information. SDSPs can additionally verify authenticated messages that follow [drip-authentication].¶

The SPDP can manage the number of Finders in an area (see Section 4.3) to limit DOS attacks from a group of clustered Finders.¶

3.4. Defense against fraudulent RID Messages

The strongest defense against fraudulent RID messages is to focus on [drip-authentication] conforming messages. Unless this behavior is mandated, SPDPs will have to use assorted algorithms to isolate messages of questionable content.¶

4.1. SDSP Heartbeats

If a 1-way messaging approach is used (e.g. not TCP-based), the SDSP SHOULD send a heartbeat at some periodicity to the Finders so that they get confirmation that there is a receiver of their transmissions.¶

A simple (see Section 6.6) message that identifies the SDSP is sent to the Finder per some published policy of the SDSP. For example, at the first reception by the SDSP for the day, then the 1st for the hour. It is NOT recommended for the SDSP to send a heartbeat for every message received, as this is a potential DOS attack against the SDSP.¶

4.2. The Finder Map

The Finders are regularly providing their SDSP with their location. This is through the B-RID Proxy Messages and Finder Location Update Messages. With this information, the SDSP can maintain a monitoring map. That is a map of where there Finder coverage.¶

4.3. Managing Finders

Finder density will vary over time and space. For example, sidewalks outside an urban train station can be packed with pedestrians at rush hour, either coming or going to their commute trains. An SDSP may want to proactively limit the number of active Finders in such situations.¶

Using the Finder mapping feature, the SDSP can instruct Finders to NOT proxy B-RID messages. These Finders will continue to report their location and through that reporting, the SDSP can instruct them to again take on the proxying role. For example a Finder moving slowly along with dozens of other slow-moving Finders may be instructed to suspend proxying. Whereas a fast-moving Finder at the same location (perhaps a connected car or a pedestrian on a bus) would not be asked to suspend proxying as it will soon be out of the congested area.¶

5.1. GPS Inaccuracy

Single-band, consumer grade, GPS on small platforms is not accurate, particularly for altitude. Longitude/latitude measurements can easily be off by 3M based on satellite postion and clock accuracy. Altitude accuracy is reported in product spec sheets and actual tests to be 3x less accurate. Altitude accuracy is hindered by ionosphere activity. In fact, there are studies of ionospheric events (e.g. 2015 St. Patrick's day [gps-ionosphere]) as measured by GPS devices at known locations. Thus where a UA reports it is rarely accurate, but may be accurate enough to map to visual sightings of single UA.¶

Smartphones and particulary smartwatches are plagued with the same challenge, though some of these can combine other information like cell tower data to improve location accuracy. FCC E911 accuracy, by FCC rules is NOT available to non-E911 applications due to privacy concerns, but general higher accuracy is found on some smart devices than reported for consumer UA. The SDSP MAY have information on the Finder location accuracy that it can use in calculating the accuracy of a multilaterated location value. When the Finders are fixed assets, the SDSP may have very high trust in their location for trusting the multilateration calculation over the UA reported location.¶

6.1. CS-RID MESSAGE TYPE

The CS-RID MESSAGE TYPE is defined in Figure 1:¶

  Number   CS-RID Message Type
  ------   -----------------
  0        Reserved
  1        B-RID Forwarding
  2        Finder Registration
  3        SDSP Response
  4        Finder Location
  5        SDSP Heartbeat

CSRID_Object = {
  application-context,
  info                => info_message,
  proxy_message       => broadcast_rid_proxy_message,
  finder_registration => finder_registration_message,
  sdsp_response       => sdsp_response_message,
  location_update     => location_update_message,
  sdsp_heartbeat      => sdsp_heartbeat_message,
}

info_message = {
  common_message_members,
  message_content => tstr,
}

common_message_members = (
  message_type  => message_types,
  mac_address   => #6.37(bstr),
)

message_types = &(
  Reserved            : 0,
  BRD                 : 1,
  Finder-Registration : 2,
  SDSP-Response       : 3,
  Finder-Location     : 4,
)

application-context = (
  application => "DRIP-CSRID",
  ? version => uint .size(1..2),
)

application           = "application"
version               = "version"
info                  = "message_info"
proxy_message         = "proxy_message-type"
finder_registration   = "finder_registration"
sdsp_response         = "sdsp_response"
location_update       = "location_update"
sdsp_heartbeat        = "sdsp_heartbeat"
rid                   = "id"
message_type          = "message_type"
mac_address           = "mac_address"
message_content       = "message_content"
timestamp             = "timestamp"
gps                   = "gps"
radio_type            = "radio_type"
broadcast_mac_address = "broadcast_mac_address"
broadcast_message     = "broadcast_message"
sdsp_id               = "sdsp_id"
proxy_status_type     = "proxy_status_type"
update_interval       = "update_interval"

6.2. The CS-RID B-RID Proxy Message

The Finders add their own information to the B-RID messages, permitting the SDSP(s) to gain additional knowledge about the UA(s). The RID information is the B-RID message content plus the MAC address. The MAC address is critical, as it is the only field that links a UA's B-RID messages together. Only the ASTM Basic ID Message and possibly the Authentication Message contain the UAS ID field.¶

The Finders add an SDSP assigned ID, a 64 bit timestamp, GPS information, and type of B-RID media to the B-RID message. Both the timestamp and GPS information are for when the B-RID message(s) were received, not forwarded to the SDSP. All this content is MACed using a key shared between the Finder and SDSP.¶

The following is a representation of the content in the CS-RID messages.¶

  (
    CS-RID MESSAGE TYPE,
    CS-RID ID,
    RECEIVE TIMESTAMP,
    RECEIVE GPS,
    RECEIVE RADIO TYPE,
    B-RID MAC ADDRESS,
    B-RID MESSAGE,
    CS-RID MAC
  )

broadcast_rid_proxy_message = {
  common_message_members,
  rid                   => tstr,
  timestamp             => tdate,
  gps                   => gps-coordinates,
  radio_type            => radio_types,
  broadcast_mac_address => #6.37(bstr),
  broadcast_message     => #6.37(bstr),
}

radio_types = &(
  EFL : 0,
  VLF : 1,
  LF  : 2,
  MF  : 3,
  HF  : 4,
  HF  : 5,
  VHF : 6,
  UHF : 7,
  SHF : 8,
  EHF : 9,
)

gps-coordinates = [
  latitude : float,
  longitude: float,
  altitude: float,
]

6.3. CS-RID Finder Registration

The CS-RID Finder MAY use [RFC7401] with the SDSP to establish a Security Association and a shared secret to use for the CS-RID MAC generation. In this approach, the HIP mobility functionality and [RFC4303] support are not used.¶

When HIP is used as above, the Finder Registration is a SDSP "wake up". It is sent prior to the Finder sending any proxied B-RID messages to ensure that the SDSP is able to receive and process the messages.¶

In this usage, the CS-RID ID is the Finder HIT. If the SDSP has lost state with the Finder, it initiates the HIP exchange with the Finder to reestablish HIP state and a new shared secret for the CS-RID B-RID Proxy Messages. In this case the Finder Registration Message is:¶

  (
    CS-RID MESSAGE TYPE,
    CS-RID ID,
    CS-RID TIMESTAMP,
    CS-RID GPS,
    CS-RID MAC
  )

finder_registration_message = {
  common_message_members,
  rid       => tstr,
  timestamp => tdate,
  gps       => gps-coordinates,
}

gps-coordinates = [
  latitude : float,
  longitude: float,
  altitude: float,
]

6.4. CS-RID SDSP Response

The SDSP MAY respond to any Finder messages to instruct the Finder on its behavior.¶

  (
    CS-RID MESSAGE TYPE,
    SDSP ID,
    CS-RID ID,
    CS-RID PROXY STATUS,
    CS-RID UPDATE INTERVAL,
    CS-RID MAC
  )

The Proxy Status instructs the Finder if it should actively proxy B-RID messages, or suspend proxying and only report its location.¶

The Update Interval is the frequency that the Finder SHOULD notify the SDSP of its current location using the Location Update message.¶

sdsp_response_message = {
  common_message_members,
  sdsp_id           => tstr,
  rid               => tstr,
  proxy_status_type => proxy_status_types,
  update_interval   => uint,
}

gps-coordinates = [
  latitude : float,
  longitude: float,
  altitude: float,
]

proxy_status_types = &(
  0: "forward",
  1: "reverse",
  2: "bi-directional",
)

6.5. CS-RID Location Update

The Finder SHOULD provide regular location updates to the SDSP. The interval is based on the Update Interval from Section 6.4 plus a random slew less than 1 second. The Location Update message is only sent when no other CS-RID messages, containing the Finder's GPS location, have been sent since the Update Interval.¶

If the Finder has not recieved a SDSP Registration Response, a default of 5 minutes is used for the Update Interval.¶

  (
    CS-RID MESSAGE TYPE,
    CS-RID ID,
    CS-RID TIMESTAMP,
    CS-RID GPS,
    CS-RID MAC
  )

location_update_message = {
  common_message_members,
  rid       => tstr,
  timestamp => tdate,
  gps       => gps-coordinates,
}

gps-coordinates = [
  latitude : float,
  longitude: float,
  altitude: float,
]

6.6. SDSP Heartbeat

The SDSP SHOULD send a heartbeat message at some periodicity to the Finders so that they get confirmation that their is a receiver of their transmissions.¶

  (
    CS-RID MESSAGE TYPE,
    SDSP ID,
    CS-RID TIMESTAMP,
  )

sdsp_heartbeat_messagege = {
  common_message_members,
  sdsp_id   => tstr,
  timestamp => tdate,
}

9.1. Privacy Concerns

TBD¶