Aviation Data Link - Security, Segmentation, QoS

Beginning in 1978, aircraft data link emerged using a VHF network named ACARS (Aircraft Communication, Addressing and Reporting System).  ACARS is a purpose-built, store-and-forward, character-based, messaging service.  Within just over ten years, ACARS was extended to Inmarsat L-band satcom and HF radio.  Five years later (1995) ACARS was delivering Air Traffic clearances. Today Iridium SBD (short-burst data) and even cellular radios communicate ACARS messages. How is the industry migrating to embrace and secure IP networks, and will ACARS ever go away? How are broadband radios being applied to support airplane health monitoring or EFB?

ATN

While ACARS was originally drafted for AOC (Airline Operational Control), ICAO developed the ATN (Aeronautical Telecommunications Network) for ATS (Air Traffic Services). ATN was built upon the seven-layer OSI stack.

ICAO Doc 9705 ATN Architecture

The underlying network was written at a time when X.25 and ISO 8208 switched virtual circuits were the standard for inter-networking.

ACARS - FANS

Without a compliant OSI network available, most of the industry abandoned the network and lower layers of the ATN, instead using ARINC 622 along with ACARS as an alternative.  This was FANS (now FANS 1/A), which went into service in 1995.  FANS retained the upper layer ATN applications CPDLC (Controller-Pilot Data Link Communications) and ADS-C (Automatic Dependent Surveillance - Contract) by virtue of the ARINC 622 ACARS convergence function (ACF). The ACF translated every four bits into one hex-character.  ARINC 622 substituted the ATS Facilities Notification (AFN) for the ATN Context Management (CM), used to establish data link connections between ATS facilities and airborne applications.

Eurocontrol persevered and has implemented a full ATN/OSI stack using VDLM2 (VHF Data Link, Mode 2) and just recently with Inmarsat L-band (IRIS) to support ATN-B1 CPDLC in Europe.  The rest of the world, including US NextGen, has embraced FANS 1/A CPDLC.  FANS 1/A ADS-C is used for procedural airspace (oceanic/remote); elsewhere aircraft position is determined using transponders - whether secondary surveillance radar (SSR), multi-lateration (MLAT), or ADS-B (Automatic Dependent Surveillance - Broadcast).

You may note that the ATN does not express an intermediate communications service provider (or data link service provider, DSP); rather it expresses an end-end connection.

ACARS relies on a DSP to connect an air-ground network (ARINC 618) to an airplane with  a ground-ground network (ARINC 620) to the airline or air navigation service provider (ANSP).  Every ACARS message lives two lives - one as a 618 message and another as a 620 message - and must be processed in tandem by the DSP, whether uplink (to the airplane) or downlink (from the airplane).  618 uses a block-by-block positive acknowledgement to transfer ACARS messages with an airplane.

End-systems (Flight Management, Central Maintenance, Cabin Terminals, Aircraft Condition Monitoring) communicate with an ACARS Communications Management Unit (CMU) router function using ARINC 619 protocol.  The CMU may host messages, itself as an end-system, or use 619 to communicate messages to/from another end-system.  The CMU-hosted messages may include OOOI (Out-Off-On-In) and free text.  Where 619 is used, an ACARS message is translated a third time (619-618-620).

ACARS has proliferated into the flight deck and has become widely embraced.  This has created a momentum by virtue of cost-to-change.  ACARS avionics use ARINC 429 to communicate 619 and 618 messages.  With plain-old-ACARS (POA), the CMU uses an analog interface with the connected VHF radio, the modem is in the CMU; in all other cases the modem is in the radio and uses 429.

ACARS - Inmarsat SBB

The introduction of IP networking is being accomplished in two steps.  The current approach is to leave ACARS somewhat untouched, and instead bridge the 429 interface into IP, and then use IP to deliver the message to the DSP.  In this case, 618 is running on top of IP.  This method is used by Inmarsat with SwiftBroadBand (SBB) with an ACARS Aircraft Gateway (AAGW+AGGW).

ARINC 781 SBB End-End ACARS network

The 781 ACARS gateway limits any protocol impact to the satellite network, leaving 618 between the CMU and the DSP unchanged.

A key factor in 781 network security is using PDP-context along with a dedicated radio channel to secure and isolate ACARS messaging from any SBB radio channel bearing passenger traffic. 781 trusts that the connection from the AGGW to the DSP (ARINC/SITA), the DSP itself, and the connection to the ANSP is secured by other means.  In summary, there is security protocol control air-ground, but trust end-end (Enterprise level).

Iridium Short Burst Data (SBD) puts each ACARS block into an SBD packet message, with an IP pass-through from the Gateway to the DSP.  Effectively it is 429-SBD-IP, as compared to 429-IP with SBB. In both cases, 618 runs on top of IP.

IPS

Recognizing the benefits of using the Internet Protocol (IP), work is progressing to develop an ATN Internet Protocol Suite (IPS).

ICAO Doc 9896 IPS

IPS promotes an IPv6 end-end network connection, using TCP/UDP to convey ATN connectivity.

AEEC Project Paper 658 is being developed to support IPS development.  658 proposes to move the IP interface into the CMU, similar to SBB AAGW.  This is avoids the 429 to IP gateway, instead the CMU internally converts directly to IP.  The CMU is an LRU (ARINC 724B MU, ARINC 758 CMU), whereas the CMF is just the function itself, usually hosted in a modular avionics rack.

PP658 IPS end-end architecture

A significant point is noting that no end-system is natively IP.

Every message passes to/from the communication service provider (DSP) using 618 over IP.

Where SBB used PDP context to secure air-ground, IPS may propose IPSec to secure between air and DSP.  There is no attempt, I am aware of, to extend the IPSec to the ANSP/AOC and to bypass the DSP - it is a tandem setup as with ACARS.

Project Paper 658 preserves bearer selection as a CMU feature.  In this sense, the CMU may choose to use all bearer systems concurrently, selecting based on performance and cost on a message by message basis.  A CMU normally communicates through a single bearer at any given time.  The time for a CMU to realize a failed communications path may delay sending a message over an alternative path.

ACARS messages are sent using a store-and-forward mentality, a reliable link service.

IP opens a very different dynamic.  Retry methods, varying packet rates and sizes, and managing dropped packets are factors when TCP or UDP are applied.  Authentication can be very powerful.  Data link is migrating away from customized, character-oriented file transfers operating in effectively closed networks, which will require some time to "tune" and optimize for safety applications.

PP848

PP848 is being developed as a generic protocol for securing Broadband Aviation Radio Networks (BARN), initially for non-safety applications only (which includes deferral of ACARS messages).  PP848 has adopted a Software-Defined Wide-Area-Nework (SD-WAN) approach of end-end network security.  An IPSec tunnel is established on the border of the radio interface to the airplane LAN to the border of each connected Enterprise LAN.

PP848 End-End IPSec architecture

PP848 expresses an end-end approach to network security that bypasses any intermediate value-added services, including the DSP.  The DSP may remain a tandem connection to some end-systems, noting that this creates a trusted security vulnerability.

PP848 is part of a defense-in-depth approach to network security. The media access (radio link) layer is secured through proprietary AAA methods, like SIM cards, and may include PDP context, firewalls, intrusion detection, and other features typical with any public Internet service.  848 forms the intermediate layer securing the IP network traffic.  Finally, each application/end-system applies another layer of security including authentication and integrity checks before accepting any data.

Defense-in-Depth Network Security

848 is envisioned to be a modular component that can be applied to any radio generically.  The radio provides a connection to the Internet.  A huge benefit is by leaving the radio untouched, it can remain Commercial-Off-The-Shelf (COTS).  The 848 function may need to be partitioned to support higher levels of design assurance than the radio itself.

PP848 Schematic

A major tenant of 848 is to ensure that only "known" traffic be permitted onto the Airplane LAN.  Pushing the IPSec tunnel up to the router layer leaves the interconnected  LAN unprotected.  There is no difficulty in supporting application layer IPSec on top of PP848 network layer IPSec.

Domain Segmentation

The most volatile feature is the concept of a given radio bearing different levels of traffic, if you will from passenger up to safety-critical.  Today, the approach has been to use dedicated radio channels to segment the traffic, but all forthcoming broadband radios work ideally with a single IP connection.

ARINC 664 part 5 expressed the concept of four isolated Ethernet domains.

ARINC 664 part 5 Ethernet Domains

The Passenger-Owned Devices Domain (PODD) is encompassed by the Passenger Information and Entertainment Services Domain (PIESD) upon connecting to the aircraft network.

The Aircraft Control Domain (ACD) encompasses the "safety applications".  In reality, most modern airplanes are using Time-triggered Protocol (TTP)-based integrated modular avionics subsystems operated as distributed embedded systems with gateways to the backbone Ethernet bus

Time-Triggered Ethernet used for Flight Controls

It is apparent (to me) that data link should be considered as a separate domain from purely flight-controls ACD, but for now they are treated similarly.  I hope to promote a new "data link" domain subset as a future change to ARINC 664.

In addition to ATS, ACARS may bear Airline Operation Control (AOC) and Airline Administrative Communications (AAC) messages.  The industry has consensus that AAC is non-safety data.  There is considerable debate over how AOC should be treated, with the general agreement it is safety - yet there is little to document its requirements as similar to what is done with Air traffic Services (ATS).

In legal vernacular, a "Route" service is licensed to support safety communications.  VHF, HF, L-band satcom, AeroMACS are the four radio bands set aside for Route service.  Cellular, Wi-Fi, Ku/Ka-band satcom, ATG: all are public services with no protection afforded to aviation safety applications.

ICAO embraces a performance-based approach, which implies the possibility of using non-safety networks for safety applications if their performance meets the messaging standards (such as RCP240 or RSP180).  On this basis, it may be possible to use any radio network, regardless, as long as it meets the performance requirements.

However, network security has introduced another consideration that has become a stumbling block.  Methods to share a radio channel including ATS with any passenger traffic (APC) are generally forbidden at this time.

The data loader interface is considered part of the ACD, the only other required data link function on ACD.

Flight Management Systems utilize ACARS today, but in the future could develop a direct IP capability.  Whether the FMS would route IP through the CMU (for bearer selection) or directly to a radio is not known (at least, by me) yet.

Flight controls, themselves, should utilize a high-assurance gateway (HAG) for any connectivity application to ensure an appropriate layer of defense protects the flight controls from malicious acts.  I, personally, do not promote ANY connectivity application with respect to primary or secondary flight controls (which is just the opposite when discussing unmanned aerial vehicles).

Aircraft Information Service Domain (AISD) is the intermediate domain encompassing pretty much every other avionics interface not utilizing ACARS or data loader.

Further complicating the situation is that ACARS, itself, encompasses ATS, AOC, and AAC traffic, yet all resides in the ACD.  All AISD traffic is considered AAC.  PIESD traffic may include AAC and APC.

848 proposes using dedicated IPSec tunnels to federate different domain/traffic types (as well by QoS, as discussed below).  This approach will first be applied to separating AISD (AAC) from PIESD (AAC, APC) traffic.

Future applications are hoped to extend to ACD to offer an alternative for the AAC subset of traffic, and possibly to supplement AOC or even ATS messaging.

A key pre-requisite is having each IP datagram with a means to convey message type and QoS, a change that goes up the protocol stack to routers and end-systems.

There are routing features being promoted that segment the traffic "above the radio" at an intermediate layer.  PP848 operates transparently to support a distributed approach, and further work will explore the best options for network security alternative.

EFB

The Electronic Flight Bag (EFB) is the poster child of AISD.  By definition, only bearing AAC traffic, the EFB is ideally suited to be connected to a broadband non-safety radio (Ku/Ka-band satcom).  PP848 is designed to allow for EFB (AISD) to be segmented from IFE (PIESD) using a single radio connection.

Airplane Health Monitoring

Moving Airplane Health Monitoring (AHM) off of ACARS and onto a native IP broadband radio connection has been held up as the breakthrough relating to the "Internet of Things" (IoT).  AHM is considered AISD (AAC) which is a good candidate for PP848 domain segmentation with PIESD.

Quality of Service

As all traffic falls inside an IPSec tunnel, the radio may have difficulty recognizing the quality of service requirements in order to optimize performance.  Every radio network has unique QoS features.

SBB service types

Iridium Certus Service Types

iDirect Group QoS

ViaSat Flexible Capacity

Hughes CoS (class of service)

PP848 expresses a generic approach to mapping QoS to each radio, to permit optimization whether SBB, Certus, Group QoS, Flexible or COS.  This effort is tied to upper layers in conveying QoS requirements, and thus work is still to be done in areas like ARINC 830, 839, and whatever will be the IP equivalent of 618 and 619.

The primary protocols envisioned include defining DSCP (differentiated services code point) as a connectionless feature along with specific profiles associated with each physical port (connection-oriented).

Next Steps

Interested parties are encouraged to contribute to PP848 development.  Current drafting is focused on translating conceptual concepts to protocols, particularly DSCP, as well contextual aspects relating to authentication.  Those interested in prototyping are particularly encouraged.  Monthly telecons and face-face meetings offer opportunity to submit draft proposals, general commentary, and helpful suggestions.  A first release of PP848 is planned in 2017.



Stay tuned,

Peter Lemme
peter @ satcom.guru

Follow me on twitter: @Satcom_Guru

Copyright 2016 satcom.guru All Rights Reserved


Peter Lemme has been a leader in avionics engineering for 35 years.  He offers independent consulting services largely focused on avionics and L, Ku, and Ka band satellite communications to aircraft. Peter chairs the SAE-ITC AEEC Ku/Ka-band satcom subcommittee developing PP848, ARINC 791, and PP792 standards and characteristics. 

Peter was Boeing avionics supervisor for 767 and 747-400 data link recording, data link reporting, and satellite communications.  He was an FAA designated engineering representative (DER) for ACARS, satellite communications, DFDAU, DFDR, ACMS and printers.  Peter was also lead engineer for Thrust Management System (757, 767, 747-400), supervisor for satellite communications for 777, and manager of terminal-area projects.