| Internet-Draft | Secure UAS Stateless NRID | October 2024 |
| Moskowitz, et al. | Expires 19 April 2025 | [Page] |
This document defines a stateless transport mechanism and message content between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. It leverages the Broadcast Remote ID (B-RID) messages as constructed by the UA, or constructed by the Ground Control Station (GCS) from the Command-and-Control (C2) messages that are then sent directly over UDP from the UAS. These messages are authenticated by the DRIP Authentication messages if originating from the UA. When originating from the GCS, CBOR Web Tokens (CWT) signed by the GCS's DRIP Entity Tag (DET), are used.¶
Transport privacy is out-of-scope in this approach per the stateless design. Some proposals are offered for data privacy that require some minimal state.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The ASTM Remote ID [F3411-22a] standard in Section 4.5 defines that there may be communications from the Uncrewed Aircraft System's (UAS) to its UAS Service Supplier (USS) Network Service Provider (Net-RID SP) to convey the Remote ID data. However, Section 4.5.4 specifically states the standard does not specify the details of this interface. This document provides the UAS to Net-RID SP interface for DRIP enabled UAS.¶
This document leverages the ASTM F3411 Remote ID broadcast messages to inform the Net-RID SP of the UA flight activity. This is realtime data transmission over a UDP connection between the UAS and USS.¶
Direct UDP with CoAP/CBOR ([RFC7252]/[RFC8949]) was selected for their low communication "cost". This may not be an issue if Net-RID originates from the Ground Control Station (GCS, Section 3.1.2), but it may be an important determinant when originating from the UA (Section 3.1.1). Particularly, very small messages may open Net-RID transmissions over a variety of constrained wireless technologies.¶
If a flight activity originates directly from the Uncrewed Aicraft (UA), the data is protected with DRIP Wrapper Messages Section 4.3 of [RFC9575]. This message may be directly transmitted from the UA to its Net-RID SP over some airborn Internet path, or it may be proxied through the UA's Ground Control Station (GCS). With the GCS in the loop, the GCS handles the Net-RID SP Heartbeat messaging. Other systems MAY act as a proxy for the UA, provided they are configured with a DET.¶
If a flight activity originates directly from the GCS, the GCS constructs the appropriate ASTM F3411 messages based on information it receives from the UA over the Command-and-Control (C2) link (e.g. derived from the MAVLink protocol [MAVLINK]). These messages are sent to the Net-RID SP in an ASTM F3411 Message Pack. The GCS's DET is used for the DRIP authentication in this case. The GCS handles all the USS Heartbeat messages.¶
The flight activity MAY originate from another Operator owned device (e.g. a smartphone). This is a device that is capable of receiving all the UA's transmissions and forward them to the Net-RID SP just as the GCS does. This will require this device to have its own DET known to the USS to be owned by the Operator.¶
Unlike the FAA CONOPS (Need reference and what about EU U-Space?) where they envision a stateful session between the NRID components. The approach here is stateless. The most compelling justification that is missed in the CONOPS is that there will often not be a single Net-RID SP server but a set of them. Thus major design consideration driving a stateless design is to support handoffs between multiple Net-RID SPs. Two major uses of multiple Net-RID SPs are:¶
There really is a very minimal piece of state, in that the UAS is transmitting to a specific Net-RID SP and said Net-RID SP is informing the UAS that it is receiving its messages. If the UAS does not get acknowledgments from its Net-RID SP, this MAY impact its CAA (Civil Aviation Authority) operation rules. Likewise if the Net-RID SP is not receiving the messages, it MAY need to flag the operation as ended.¶
This minimal state can be maintained through through a RESTFUL token included within the UDP messaging in place of a stateful TCP connection. To facilitate this, CBOR Web Tokens (CWTs) [RFC8392] are used.¶
Thus CWTs are used by the UAS to convey the flight activity and other information to the Net-RID SP. They are used by the Net-RID SP for its communication to the UAS.¶
To further reduce the communication cost, SCHC [RFC8724] is defined for both the direct UDP and CoAP layer [RFC8824].¶
UDP SCHC compression is handled separately here from IP header as is currently defined by IP carrier (e.g. LoRaWAN, [RFC9011]). This is to allow for the endpoints to not need to know what constrained carrier is in-path and just design for worst case.¶
Content privacy via a secure transport is out-of-scope for this protocol. Most secure transports are stateful, breaking the stateless approach taken here. It may seem that confidentiality is optional, as most of the information in Net-RID is sent in the clear in Broadcast Remote ID (B-RID), but this is a potentially flawed analysis. Net-RID has eavesdropping risks not in B-RID and may contain more sensitive information than B-RID. The secure transport for Net-RID should also manage IP address changes (IP mobility) for the UAS. Thus for some use cases a way to provide confidentiality is desirable.¶
CBOR Object Signing and Encryption (COSE) [RFC8152] may provide the simplest method to add data encryption to Net-RID. This may be developed at a later time.¶
Another approach that may be investigated later is the Object Security for Constrained RESTful Environments (OSCORE, [RFC8613]) protocol. OSCORE provides a CoAP compliant data encryption, but does not provide the session keys. The Messaging Layer Security (MLS, [RFC9420]) Protocol, may be well suited for the multiple Net-RID model used here and will be discussed further down.¶
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.¶
See Section 2.2 of [RFC9153] for common DRIP terms. The following new terms are used in the document:¶
In UAS Traffic Management (UTM), the purpose of Net-RID is to provide situational awareness of a UA (in the form of flight tracking) in a user specified 4D volume. The data needed for this is already defined in [F3411-22a], but standard message formats, protocols, and secure communications methodologies are missing. F3411, and other UTM based standards going through ASTM and other SDOs, provide JSON objects and some of the messages for passing information between various UTM entities (e.g., Net-RID SP to Net-RID SP and Net-RID SP to Net-RID DP) but does not specify how the data gets into UTM to begin with. This document will provide such an open standard for DRIP enabled UAS.¶
A minimal messaging approach, using the Broadcast Remote ID (B-RID) messages in [F3411-22a], is sufficient to meet the needs of Net-RID. These messages can be sent to the Net-RID SP when their contents change. Further, a UAS supporting B-RID will have minimal development to add Net-RID support. The ASTM Message Pack (Msg Type 0xF) is used in all Net-RID messaging.¶
Other messages (e.g. Heartbeat) are needed in some Net-RID situations. Thus a simple message multiplexer using CWT over CoAP is defined for a richer messaging environment.¶
The US FAA defines the Network Remote ID endpoints as a USS Network Service Provider (Net-RID SP) and the UAS. Both of these are rather nebulous items and what they actually are will impact how communications flow between them.¶
The Net-RID SP may be provided by the same entity serving as the USS. This simplifies a number of aspects of the Net-RID communication flow. The Net-RID SP is likely to be stable in the network, that is its IP address will not change during a mission. This simplifies maintaining the Net-RID communications.¶
In practice, a USS may need multiple Net-RID SP, either for load balancing or geographical diversity. The design here is that the UAS communicates with one Net-RID SP at a time. That SP MAY redirect the UAS to use a different SP via the HEARTBEAT message. It is this multiple Net-RID SP design that mandates the stateless communication model and presents the confidentiality challenge.¶
The UAS component in Net-RID may be either the UA, GCS, or the Operator's Internet connected device (e.g. smartphone or tablet that is not the GCS). In all cases, mobility MUST be assumed. That is the IP address of this end of the Net-RID communication may change during an operation (generally called a flight or mission). The Net-RID mechanism MUST support this.¶
Some UA will be equipped with direct Internet access. These UA will also tend to have multiple radios for their Internet access (e.g., Cellular and WiFi). This protocol is agnostic as to which interface is used when for sending the Net-RID communications. Multi-interface transmissions MAY result in out-of-order packet delivery, thus the SP MUST be prepared to reorder the packets. All B-RID messages contain a timestamp, thus simplifying the reordering process.¶
Multicast (GEN-10 in [RFC9153]) over multiple Internet connection technologies MAY be used improve QOS (GEN-7 in [RFC9153]) for Net-RID.¶
The UA will send DRIP Wrapper messages of the current UA activity. These will be sent in a UA signed CWT that will add the SP DET.¶
Many UA will lack direct Internet access, but their GCS are connected. The GCS is then acting as a gateway for the UA.¶
There are two sources of the RID messages for the GCS, both from the UA. These are UA B-RID messages, or content from C2 messages that the GCS converts to RID message format. The protocol stateless design is such that¶
In a constrained wireless environment for the UA that is not functioning autonomously (i.e., at least C2 traffic to the GCS), this approach may be the most economical. It only uses the wireless to send the UA status once, to the GCS, that then provides the Net-RID functionality.¶
Many UAS will have no Internet connectivity, but the UA is sending B-RID messages and the Operator, when within RF range, can receive these B-RID messages on an Internet Connected device that can act as the proxy for these messages, turning them into Net-RID messages.¶
Net-RID messaging is tied to a UA operation. During the operation, continuous location information is sent by the UA with any needed updates to static operation information.¶
There are four components of the Net-RID protocol:¶
The later two are somewhat asynchronous. Note all participating elements are configured with DETs to participate and they will tend to be in the same Hierarchy ID (HID).¶
There are two steps in setting up a UAS to use the Net-RID protocol:¶
The Gateway queries DNS with the Net-RID SP DET.¶
Net-RID connectivity start can be considered a pre-flight check, so appropriate actions during failures in this phase should be consistent with organization-specific, system-specific, and/or operation-specific pre-flight checklists.¶
All Operational data comes from the UA in a DRIP Wrapper packet. This is transmitted to the SP via the UAS component that has the Internet Connection (the Gateway). It is this element that packs the Wrapper into a CWT.¶
At Operation Start time:¶
The Gateway queries DNS with the Net-RID SP DET.¶
The UA sends its first packet to the Net-RID SP via the Gateway before operation commences.¶
The Net-RID SP ACKs with an Net-RID Heartbeat (defined below).¶
For simplicity, a class of UAS information is called here "Static", though in practice any of it can change during the operation, but will change infrequently. This information is the contents of the B-RID Self-ID (Msg Type 0x3), Operator ID (Msg Type 0x5), and System Messages (Msg Type 0x4). This information can simply be sent in the same format as the B-RID messages. Alternatively the individual data elements may be send as separate CBOR objects.¶
The Basic ID (Msg Type 0x0) Message may be included as a static message if this information was not used for the secure setup. There may be more than one Basic ID Message needed if as in the case where the Japan Civil Aviation Bureau (JCAB) has mandated that the Civil Aviation Authority (CAA) assigned ID (UA ID type 2) and Serial Number (UA ID type 1) be broadcasted.¶
The information in the System Message is most likely to change during an operation. Notably the Operator Location data elements are subject to change if the GCS is physically moving (e.g. hand-held and the operator is walking or driving in a car). The whole System Message may be sent, or only the changing data elements as CBOR objects.¶
The UA sends its operational information in a DRIP Wrapper¶
On receipt of a Net-RID SP Heartbeat¶
If no Net-RID SP Heartbeat was received in the past M seconds.¶
On end of Operation, sends an "End-of-Operation" CWT to the Net-RID SP¶
Many CAAs mandate that the UA Vector/Location information be updated at least once per second. Without careful message design, this messaging volume would overwhelm many wireless technologies. Thus to enable the widest deployment choices, a highly compressed format is recommended.¶
The B-RID Vector/Location Message (Msg Type 0x1) is the simplest small object (24 bytes) for sending this information in a Message Pack (Msg Type 0xF).¶
The Net-RID SP SHOULD send regular "heartbeats" to the UAS. If the UAS does not receive these heartbeats for some policy set time, the UA MUST take the policy set response to loss of Net-RID SP connectivity. For example, this could be a mandated immediate landing. There may be other messages from the Net-RID SP to the UAS (e.g., call the USS operator at this number NOW!). The UAS MUST follow acknowledge policy for these messages.¶
If the Net-RID SP stops receiving messages from the UAS (Section 3.2.3), it should notify the UTM of a non-communicating UA while still in operation.¶
The Net-RID SP process flow is as follows:¶
The CoAP based Net-RID protocol is intended for a rich, bi-directional conversation between the UAS and USS. The USS, through the Net-RID SP, may compare actual UA progress against the filed flight plan and against other UA actual traffic. The USS may then send to the UAS recommended changes to the flight plan to de-conflict traffic or advise the UAS to avoid hazards (1st responder event, avoid space). The UAS may then negotiate changes to the plan, and act on them, as appropriate.¶
Note that this additional USS-to-UAS messaging functionality is not part of the current design and is out of scope for this document. This sort of advanced UAS behavior is envisioned as part of total UTM activities. Discussions now ongoing in UTM will provide the data models and transactional UAS/USS interactions, that will drive UAS communications past the Net-RID defined here toward a more functional CoAP Net-RID protocol.¶
There are three CoAP Net-RID currently defined:¶
Author's Note: This section needs further work. At least (and probably more) uas-update needs the Net-RID SP DET and both need their DET signing.¶
uas-cwt = 6.18([
protected: {
alg: -8
},
unprotected: {
kid: #6.54(bstr) // DET
},
claims: {
sub: "NRID-UAS",
nbf: 0,
exp: 10,
iat: 0,
TBD1: [
det_sp: #6.54,
? encoded: [uint .bits message_types, ? uint .bits auth_pages]
data: bstr ; F3411 Message Pack (Message Type 0xF)
]
}
signature: bstr .size(64)
])
message_types = &(
basic: 0,
location: 1,
auth: 2,
self: 3,
system: 4,
operator: 5,
pack: 15
)
auth_pages = &(
pg0: 0, pg1: 1, pg2: 2, pg3: 3,pg4: 4, pg5: 5, pg6: 6, pg7: 7,
pg8: 8, pg9: 9, pgA: 10, pgB: 11, pgC: 12, pgD: 13, pgE: 14, pgF: 15
)
¶
uss-cwt = 6.18([
protected: {
alg: -8
},
unprotected: {
kid: #6.54(bstr) // DET
},
claims: {
sub: "NRID-USS",
nbf: 0,
exp: 10,
iat: 0,
TBD2: [
det_uas: #6.54,
expected: [uint .bits message_types, ? uint .bits auth_pages],
? move_sp: [
new_sp: #6.54,
new_ip: #6.54 / #6.52 / #6.32,
new_be: bstr .size(136)
]
]
}
signature: bstr .size(64)
])
message_types = &(
basic: 0,
location: 1,
auth: 2,
self: 3,
system: 4,
operator: 5,
pack: 15
)
auth_pages = &(
pg0: 0, pg1: 1, pg2: 2, pg3: 3,pg4: 4, pg5: 5, pg6: 6, pg7: 7,
pg8: 8, pg9: 9, pgA: 10, pgB: 11, pgC: 12, pgD: 13, pgE: 14, pgF: 15
)
¶
eoo-cwt = 6.18([
protected: {
alg: -8
},
unprotected: {
kid: #6.54(bstr) // DET
},
claims: {
sub: "NRID-EOO",
nbf: 0,
exp: 10,
iat: 0,
TBD3: [ TBD ]
}
signature: bstr .size(64)
])
¶
TBD¶
TBD¶
TBD¶