| Internet-Draft | A2G Communications | September 2024 |
| Moskowitz, et al. | Expires 19 March 2025 | [Page] |
This document defines protocols to provide efficient air-ground communications without associated need for aircraft to maintain stateful connection to any tower infrastructure. Instead, a secure source-routed ground infrastructure will not only provide the needed routing intelligence, but also reliable packet delivery through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error Correction (FEC) protocols to address both reliable wireless packet delivery, and assured terrestrial packet delivery.¶
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 March 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 goal of this design approach is to place minimal network intelligence in the aircraft and even the wireless towers. Practically all the networking intelligence is placed within the Ground Station (GS). The target application is uncrewed aircraft communications, but could equally applied to all aircraft.¶
The justification for this approach is intelligence in the aircraft has disproportional costs to that in the GS; there are many factors in this claim. Lower intelligence requirements in the towers will make the technology more attractive to tower owners, provided there is an associated functional payment mechanism for them for the service.¶
The wireless downlink from the aircraft is treated as a broadcast message, with every receiving tower forwarding messages to the GS. The GS, in turns, notes which towers are in contact with the aircraft and sends uplink messages through them to the aircraft. There is no need for complex aircraft/tower connection technologies. At most, for billing purposes, the towers are aware of aircraft and GS that will use their connectivity services via their source IP addresses.¶
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.¶
The following is a list of enabling and enhancing functions.¶
The aircraft:¶
The tower:¶
The GS:¶
The GS should:¶
The aircraft may:¶
The tower may:¶
The GS may:¶
The following considers the possible technologies, some challenges, and final proposed solution.¶
Internet Protocol (IP) transmissions from the aircraft to ground, though unicast in construction (i.e. IP destination/source paired), are really broadcasts, as a practical matter, to all available towers. Such towers can simply send the packets on their way and they will naturally get routed, i.e. relayed, to the GS which correspondingly simply recognizes and processes potential multiple receipts via the many relaying towers. The problem is only the uplink: how to get IP transmissions from the GS to the aircraft.¶
The GS needs to ‘know’ which towers can likely transmit up to the aircraft and how to route packets through them. A simple solution is to use IP-in-IP (IPnIP) tunneling protocol [RFC1853]. Here, each receiving tower wraps the downlink message in IPnIP with the outer source address being the the tower’s address. The aircraft always uses a fixed source address (e.g. their respective DET [RFC9374]). The GS maintains an IPnIP tunneling table for each aircraft DET of the tower addresses. Packets inbound to the GS update this table (stale entries are purged) and the IPnIP service unwraps and forwards the inner content back through the IP kernel for sending up to the application. Packets outbound to the aircraft address get routed internally to the IPnIP process which ends up sending out multiple copies to each of the tower addresses in the table. Each receiving tower then simply unwarps and uplinks the content to the aircraft.¶
Though this approach works, it has security and traffic management challenges. First and foremost, the aircraft must know the GS IP address. It either needs to be fixed or the aircraft needs a separate process to update its knowledge of the GS address. The GS should have the aircraft address prior to operation start or can simply learn them through received messages.¶
There are two security issues associated with the GS processing messages from any random aircraft address:¶
An additional challenge for the GS is determining which set of towers to use to send messages uplinked to the aircraft. Which of the towers last sending messages from the aircraft are still in RF reach of the aircraft and are there now towers better able to message the aircraft? If the GS can trust the towers and know their GPS location and the signal strengths of messages from the aircraft, the GS can use this map along with the map of the planned operation to better select towers for uplinking messages.¶
With all these stated concerns, the IPnIP approach should only be used for PoC and general testing. It presents too good of a DOS attack scenario for production deployments.¶
Trust in tower messaging can be achieved by each tower cryptographically signing the received aircraft messages before forwarding them to the GS. This must be a specific signed object, perhaps in COSE format [RFC8152]. Not only would it contain the aircraft message with the tower’s digital ID and signature, it should also minimally include a timestamp, the tower’s GPS location plus GPS accuracy, and signal strength. With this information, a process on the GS can put the tower on a map with the planned aircraft flight plan. If three or more towers forwarded the message, the GS can also multilaterate the aircraft location for accurate location on the map. This information would allow the GS to predict which towers are still in range, or soon in range (i.e. predicting new towers for communications) of the aircraft for uplink messaging.¶
This signing method is preferable to secure tunnels from the tower to the GS as there will be thousands of GS using a small number of towers. How should tunnels be set up and torn down recognizing the cost to the tower system? It is preferable for the towers to be stateless in their forwarding to the GS. Also, it is questionable whether the GS should sign messages for the uplink. Doing so would potentially place the burden of processing cost on the tower, and analysis would be needed to avoid denial of service (DOS) attacks against towers and their uplink capacity.¶
The inclusion of GPS accuracy supports improved mobile tower multilateration. The timestamp also enables multilateration, in aging towers out of the reachable list of towers against the flight plan.¶
Thus, inbound processing on the GS would first place tower information into the aircraft reachable table mentioned above, then forward the aircraft message up to the application. For outbound, the aircraft address could result in passing the message to an IPnIP service for simple forwarding to the tower as above, but as mentioned above IPnIP has DOS risks.¶
If the air-ground communications are secured with the Host Identity Protocol (HIP, [RFC7401]), the HIP mobility function can update the aircraft with any changes in the GS IP address. DTLS 1.3 [RFC9147] can be used only if the aircraft is the server as DTLS supports client, not server, mobility and the aircraft can learn of new GS addressing as it processes uplinked messages from the new addresses.¶
In any case, the aircraft address should be its DET and be unchanging for the flight duration.¶
If three or more towers provide the uplink, the GS can use Forward Error Correction (FEC) and send the fragments to different towers. The aircraft need only receive the proper set of fragments to reconstruct the full message. This both reduces the packet size on the uplink, conserving uplink capacity and increases both ground and wireless delivery reliability. Static Context Header Compression (SCHC, [RFC8724]) should also be used to reduce the size of the aircraft-ground messages. SCHC Automatic Repeat reQuest (ARQ) may also be used and will soon directly support FEC.¶
The ground communications path reliability can be further improved through use of a subset of Deterministic Networking (DETNET) (tbd) and Bit Indexing Explicit Replication (BIER) multicasting from the GS to the towers.¶
There will be areas where significant traffic exists between a tower (or group of towers) and a GS. An example of such an area is around an aerodrome and its supporting systems. Here it makes performance sense that a secure tunneling technology (e.g ESP, [RFC4303]) be used between the tower(s) and GS(s) rather than digitally signing individual messages. Often, in such cases the ground network can be deployed to ensure reliable delivery.¶
The aircraft and GS MAY have a pre-configured secure connection using technologies like DTLS, IPsec, or HIP. The aircraft SHOULD use its DET as its IPv6 address, and underlying HI for the rawPublicKey to establish the connection. Examples of this type of secure aircraft to GS is discussed in [drip-secure-nrid-c2].¶
There is a bit of chicken-and-egg here if the initial connection setup is not over a single link, as DETs are not easy to route over an IPv6 network. In such a case a tunnel, as discussed later, needs to be in place between the first hop from the aircraft (e.g. WiFi Access Point) and the GS.¶
In some instances, a pre-established aircraft-GS session is not practical (e.g. aircraft to airport traffic control). A variant of Section 3.2 of [drip-a2x-adhoc-session] (Compressed UA Signed Evidence of the A2X message) can be sent to the pre-configured GS IPv6 address:¶
| Bytes | Name | Explanation |
|---|---|---|
| 16 | DET of Aircraft | DRIP Entity Tag of Aircraft |
| 16 | Destination Address | IPv6 address of GS |
| 4 | VNA Timestamp | Timestamp denoting recommended time to trust Evidence |
| 1 | Message ID | A2G Message ID Number |
| n | A2G Message | Actual A2G Message |
| 64 | Signature by Aircraft | Signature over preceding fields using the keypair of the Aircraft DET |
This message is a SCHC compressed IPv6/UDP datagram. The signature is on the whole datagram. The wireless transport will have some mechanism (e.g. SCHC as Ethertype) to trigger the SCHC rule processing to compress the datagram for transmission. Depending on the wireless technology there will be a 1-byte SCHC RuleID after the SCHC Ethertype (or equivalent). If the IP Header is sent without SCHC compression, then SCHC will need to be the Next Header in the IPv6 Header and the SCHC RuleID will immediately follow the IPv6 Header.¶
The full uncompressed message is:¶
| Bytes | Name | Explanation |
|---|---|---|
| 40 | IPv6 Header | IPv6 Header from Aircraft to GS |
| 8 | UDP Header | Full UDP Header |
| 4 | VNA Timestamp | Timestamp denoting recommended time to trust Evidence |
| 1 | Message ID | A2G Message ID Number |
| n | A2G Message | Actual A2G Message |
| 64 | Signature by Aircraft | Signature over preceding fields using the keypair of the Aircraft DET |
Any tower that receives these messages and has a tunnel to the destination IPv6 address uses it to forward the message to the GS. The GS will use the aircraft DET to retrieve, via DNS, the HDA Endorsement of the DET. This will provide the aircraft HI to validate the signature.¶
A tower MAY validate the signature by using the aircraft DET to retrieve via DNS the HDA Endorsement of the aircraft DET. The tower may choose to leave this validation to the GS as it is terrestrial network that may be DOSed from wireless transmissions.¶
It is impractical for most towers to maintain long-lived static tunnels as described in Section 4.5. Too many towers will need to forward messages to too many GS for static tunneling. Rather, per-packet tunneling will be frequently used. These tunnels are the Aircraft-GS packets wrapped in a signed IPv6 datagram from the tower's IPv6 address to the GS's address that is in the A-GS packet:¶
| Bytes | Name | Explanation |
|---|---|---|
| 40 | IPv6 Header | IPv6 Header from Tower to GS |
| 8 | UDP Header | Full UDP Header |
| 16 | DET of Tower | DRIP Entity Tag of Tower |
| 4 | VNA Timestamp | Timestamp from tower denoting recommended time to trust Evidence |
| m | Tower Location | Optional tower location |
| m | A2G Message | Full A2G Message |
| 64 | Signature by Tower | Signature over preceding fields using the keypair of the Tower DET |
The GS will use the tower DET to retrieve, via DNS, the HDA Endorsement of the tower. This will provide the tower HI to validate the signature.¶
The UDP Destination Port can be the indicator of the presence of the Tower Location information. If absent, this information needs to be accessible via DNS using the Tower's DET (or pre-configured in the GS). If the tower is physically mobile, this information SHOULD be included.¶
The GS MUST be able to handle multiple copies of the A2G message. It MUST use the Tower location information to maintain a mapping for routing messages to the aircraft. It MAY use knowledge of the aircraft's planned flight to adjust this routing information as to which tower's are likely to be within reach of the aircraft.¶
In most cases, the GS to aircraft messaging is the mirror of aircraft to GS. The important difference is how the GS selects towers for forwarding G2A messages and how the towers pre-process these messages before using precious wireless bandwidth in sending messages.¶
The GS uses some process to select towers from the list of towers last forwarding aircraft messages to the GS plus knowledge of the aircraft flight and other towers in the area.¶
The GS to tower tunnel is the mirror of Section 5.1 without the location information. The tower SHOULD validate the authenticity of the GS via DNS retrieved HDA Endorsement of the GS DET. It MAY also filter messages based on having recently received aircraft to GS messages.¶
The tower takes the G2A message from within the tunnel, adding any needed wireless heading and transmits the datagram.¶
The aircraft MUST be able to process multiple copies of an G2A message coming from multiple towers.¶
Adam Wiethuechter of AX Enterprize provided review and implementation insights. Michael Baum provided extensive review of the contents in chapters 3 and 4 in a prior white paper.¶