HTT Consulting

Oak Park MI 48237 USA rgm@labs.htt-consult.com

AX Enterprize

4947 Commercial Drive Yorkville NY 13495 USA stu.card@axenterprize.com

Linköping University

IDA Linköping 58183 Sweden gurtov@acm.org

Internet DRIP RFC Request for Comments I-D Internet-Draft DRIP 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.

Introduction 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.

Terms and Definitions

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 when, and only when, they appear in all capitals, as shown here.

Definitions

A2G

Communications from an aircraft to some ground equipment. Also somethings GS.

Enabling and Enhancing Functions The following is a list of enabling and enhancing functions.

Enabling Requirements The aircraft:

• Support end-to-end secure communications with the GS and start the operation with the pre-configured GS IP address. The aircraft sends the first message, to the GS, to establish the routing knowledge in the GS,
• Use a fixed IP address for itself for the duration of the operation, and
• be able to process multiple copies of messages from the GS, received potentially from multiple towers.

The tower:

• Support digital signing of messages from the aircraft, and the tower’s IP address, and forward these objects to the GS.

The GS:

• Support end-to-end secure communications with the aircraft,
• support processing multiple copies of messages from the aircraft,
• support digital signing by the tower, and
• maintain a list/map of towers forwarding aircraft messages from the aircraft for messaging to the aircraft. The list of trusted tower IP addresses is constructed from within the tower signed objects.

Enhancing Security Requirement The GS should:

• Support digital signing for the tower to trust messages from the GS.

Enhancing Performance Requirements The aircraft may:

• Support uplink usage optimizations like FEC and ARQ (e.g., NORM ), and
• support GS IP address mobility (e.g. via HIP, ).

The tower may:

• Include information like timestamp and its GPS-derived location (and accuracy of same) in the signed object delivered to the GS,
• may be IP address mobile, if so, then MUST provide its IP address within the signed object,
• support multicast and DETNET for efficient and reliable communications with the GS, and
• use a subscription model to filter messages supported for forwarding. If done with a list of registered IP addresses it MUST support GS IP address mobility.

The GS may:

• Support intelligent operation routing and tower contact information to select towers to use to send messages to the aircraft,
• support tower subscription for tower communication filtering,
• support multicast and DETNET for efficient communications with the towers,and
• support FEC and ARQ for efficient use of uplinks to the aircraft.

Background Discussion The following considers the possible technologies, some challenges, and final proposed solution.

The problem and simple solution using IPnIP 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 . 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 ). 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:

• either these addresses are preset (e.g. registered DET), or there is some process for the GS to dynamically learn which to trust.
• a larger security challenge is why should the GS trust the address for the towers as a route to the aircraft. A malicious source could provide bad tower addresses resulting in loss of aircraft contact at worst, or consumption, through DOS attacks, of both GS processing resources and tower uplink bandwidth.

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.

Improved tower trust through digital signing 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 . 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.

Inclusion of mobile ground systems If the air-ground communications are secured with the Host Identity Protocol (HIP, ), the HIP mobility function can update the aircraft with any changes in the GS IP address. DTLS 1.3 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.

Improved uplink reliability 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, ) 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.

Alternative dedicated Tower-GS tunneling 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, ) 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.

Aircraft to GS Messaging 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 . 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 (Compressed UA Signed Evidence of the A2X message) can be sent to the pre-configured GS IPv6 address: 101+n Byte Aircraft Signed A2G message

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: IPv6 117+m+n Byte Aircraft Signed A2G message

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.

The Tower to GS tunnel It is impractical for most towers to maintain long-lived static tunnels as described in . 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: IPv6 117+n Byte Aircraft Signed tunnel message

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.

GS to Aircraft Messaging 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 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.

IANA Considerations TBD

Security Considerations TBD

References

Acknowledgments 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.