Draft 1 of ARINC Project Paper 848: Secure Broadband IP Air-Ground Interface (SBAGI) has been released by the AEEC Network Infrastructure and Security (NIS) Subcommittee for industry comments.
DRAFT 1 PP848
ARINC Project Paper 848 is intended to define a method for a secure communications interface between Internet Protocol (IP) networks contained within an aircraft and a ground network hosted within the aircraft OEM, airline, or 3rd party.
A Secure Broadband IP Air-Ground Interface (SBAGI) instance abstracts the Wide-Area Network (WAN) such that the airplane and ground LAN can operate as if connected locally.
SBAGIs may convey the Commercial Off- The-Shelf (COTS) radio network capabilities to upper network layers to assist with least-cost routing decisions.
SBAGI instances may convey end-system performance requirements to the COTS routers and intermediate networks (both public or private) to support the most capable QoS.
SBAGIs provide network traffic segmentation such that only authorized network traffic is injected into each channel.
ARINC Project Paper 848 would standardize the SBAGI only at the network level while taking into account the overall security context.
AEEC is an aviation industry activity organized by ARINC Industry Activities, an industry program of SAE Industry Technologies Consortia (ITC), to establish consensus technical standards, known globally as ARINC Standards, and develop shared technical solutions that no one organization could accomplish independently.
Project Paper 848 originated in the AEEC Ku/Ka Satcom Subcommittee as a follow-on effort from ARINC 791 Part 2.
The document ARINC 791 Part 2:
- characterizes the networking interface in a Ku/Ka satcom installation.
- utilizes ARINC 664 IP address conventions while assigning specific subnetworks and VLANs to segregate Passenger, Entertainment, and Avionics network domains.
- defines a methodology for managing Quality of Service (QoS) based on connection-oriented and connectionless signaling.
- methodologies focused mostly on the air-ground wireless data link, levying networking expectations upon the teleport, or ground-station.
- was originally published in 2013, following a five year effort.
After ARINC 791 Part 2 supplement 1 was published in 2014, attention was directed to conveying the requirements in a generic fashion that could be applied to any Broadband Aviation Radio Network (BARN.)
Originally conceived as ARINC 791 Part 2 supplement 2, instead a project was created to develop a new specification, Project Paper 848.
Originally conceived as ARINC 791 Part 2 supplement 2, instead a project was created to develop a new specification, Project Paper 848.
Over the course of the intervening three years (making this now a nine year development), the work focused on two objectives:
- Secure the inter-network between LAN interfaces that connect an airborne end-system to the BARN radio and the network access point to any Enterprise hosting a peer end-system.
- Ensure QoS is optimized over the BARN, taking best advantage of each network's features.
Traditionally securing wireless networks relies on a trusted-tandem relationship that spans across the airborne network to the point it leaves/enters the airplane itself.
Inherently, there is a deep divide between the highly regulated avionics and "all that stuff on the ground".
The most intrusive characteristics levy a reference design from one service provider that leverages a routing technique to segregate traffic and embraces the use of dedicating radios to specific services (passenger up to ACARS), such as may be found in ARINC 781.
All Ku/Ka broadband radios operate on a single-carrier basis, using link-layer techniques to operate logical channels that are managed for QoS and access. These radios must be shared across multiple domains (passenger, entertainment, avionics.)
ARINC 791 Part 1 and Part 2 define independent Ethernet interfaces to each domain such that traffic between the domains is barred.
ARINC 791 Part 2 VLAN layer 2 methods offer a means to segregate the traffic, by domain, across the BARN.
ARINC 791 Part 1 and Part 2 define independent Ethernet interfaces to each domain such that traffic between the domains is barred.
ARINC 791 Part 2 VLAN layer 2 methods offer a means to segregate the traffic, by domain, across the BARN.
Project Paper 848 applies an end-end VPN spanning the border of the BARN radio to the Enterprise entry point. IPsec offers a means to authenticate, apply integrity checks, provide confidentiality and extend a local IP address schema.
QoS methods are still a matter of discussion. The issue is complex, with the concept of least cost routing heavily debated and dwelling on proprietary features.
The protocol to convey QoS between the BARN, any intermediate routers, and the end-systems requires a degree of abstraction that remains elusive. High/Low, Fast/Slow, Big/Small are all relevant.
Differentiated Services Code Point (DSCP) and VLAN remain the probable QoS signaling tools, each embraced by PP848.
PP848 instances were reduced to a single bearer, a serial interface, to avoid any routing mandates.
The protocol to convey QoS between the BARN, any intermediate routers, and the end-systems requires a degree of abstraction that remains elusive. High/Low, Fast/Slow, Big/Small are all relevant.
Differentiated Services Code Point (DSCP) and VLAN remain the probable QoS signaling tools, each embraced by PP848.
PP848 instances were reduced to a single bearer, a serial interface, to avoid any routing mandates.
Most contested was whether PP848 affords a means to interconnect the BARN radio to the "safety" (ATC, AOC) Ethernet network domains (ACD) alongside connections to the non-safety (AAC, APC) network domains avionics (AISD), entertainment (PIESD), and passenger (PODD) domains.
In order to proceed, PP848 is currently does not address safety networks.
The PP848 methodologies are extensible to complete the connections to safety networks, but other considerations must be factored in that the subcommittee agreed to defer for now, in order to hasten the release for non-safety application.
It should be noted that the ATN-IPS methods, and those to secure IRIS satellite links, all rely on similar VPN technologies as PP848; each is applied across different network spans.
The PP848 methodologies are extensible to complete the connections to safety networks, but other considerations must be factored in that the subcommittee agreed to defer for now, in order to hasten the release for non-safety application.
It should be noted that the ATN-IPS methods, and those to secure IRIS satellite links, all rely on similar VPN technologies as PP848; each is applied across different network spans.
The lower, link layer relies on Commercial-off-the-Shelf (COTS) radio network that provides a firewall-connection to the Internet.
The second, network layer connects the local area network of the airplane to the local area network of the Enterprise (848).
The upper layer is reserved for end systems to apply another means to authenticate and ensure integrity of any data presented. This upper layer, and the means to convey QoS, remains under analysis.
While PP848 will offer guidance for QoS, upper layer requirements are the purview of many subcommittees, some beyond AEEC.
While PP848 will offer guidance for QoS, upper layer requirements are the purview of many subcommittees, some beyond AEEC.
In light of the desire to extend PP848 to any radio, not just Ku/Ka satcom and in light of the fact that the majority of individuals participating were also members of NIS; a decision was agreed to move the project from the Ku/Ka satcom subcommittee to the NIS subcommittee in Oct. 2016.
NIS renamed PP848, "Secure Broadband IP Air/Ground Interface" or SBAGI.
NIS renamed PP848, "Secure Broadband IP Air/Ground Interface" or SBAGI.
I prepared appendix B (please refer to for more detailed discussion) of PP848 draft 1 to provide examples of how to apply PP848 to both a Ku/Ka satcom and to a cellular radio.
In the appendix B examples 848S (satcom), 848C (cellular), 848T (teleport), and 848E (enterprise) are secure end-points of SBAGI IPsec tunnels.
In the appendix B examples 848S (satcom), 848C (cellular), 848T (teleport), and 848E (enterprise) are secure end-points of SBAGI IPsec tunnels.
Ku/Ka satcom networks have the option to extend a second IPsec to secure the connection to the teleports, such that access to the airborne radio interface is fully authorized.
While a cellular provider can use a private APN to accomplish the same, any use of a public SIM will bring the Internet directly to the airplane interfaces with the commercial firewall as a first barrier.
While a cellular provider can use a private APN to accomplish the same, any use of a public SIM will bring the Internet directly to the airplane interfaces with the commercial firewall as a first barrier.
In the figure below, Passenger (blue), Entertainment (black), and Avionics (red) network services are provided for Internet access, and to connect to two different Enterprise ends-systems.
The passenger traffic is segregated by VLAN E and terminated directly into the WWW at the teleport.
The teleport extends a fixed IPsec 848T (IPsec T1, T2) to each Enterprise. These teleport IPsedc tunnels restrict all traffic (uplink or downlink) to authorized links.
The cellular network connection is shown providing a commercial firewall, Internet connection to the airborne 848C instance.
The satellite network connection 848S builds upon the 848T connection, extending a second IPsec tunnel, but now extending from the airplane to the Enterprise. This traffic is managed through different VLANs, based on priority and QoS.
The 848 IPsec are organized by destination, priority and QoS. It is this mix of IPsec and VLAN that enables optimized QoS around traffic obscured by IPsec.
Life-cycle aspects including certificate-based authentication, tunnel provisioning, remote management, reference profile are under discussion.
The airborne 848E instances standby ready to establish VLAN specific IPsec sessions from either 848T, 848S, or 848C instances.
The airborne 848 instances establish the IPsec tunnels under programmable conditions either in real-time response or upon network availability.
The IPsec tunnels are persistent to allow for unsolicited or unscheduled uplink traffic.
The PP848 methods are designed to segregate uplink and downlink traffic equally.
The 848 IPsec are organized by destination, priority and QoS. It is this mix of IPsec and VLAN that enables optimized QoS around traffic obscured by IPsec.
Life-cycle aspects including certificate-based authentication, tunnel provisioning, remote management, reference profile are under discussion.
The airborne 848E instances standby ready to establish VLAN specific IPsec sessions from either 848T, 848S, or 848C instances.
The airborne 848 instances establish the IPsec tunnels under programmable conditions either in real-time response or upon network availability.
The IPsec tunnels are persistent to allow for unsolicited or unscheduled uplink traffic.
The PP848 methods are designed to segregate uplink and downlink traffic equally.
The examples in PP848 draft 1 show a cross-link (AISD to PIESD) between routers to deliver an AISD interface to the Ku/Ka satcom radio.
The existence of this cross-link is a feature within Airbus networks, and reflects their unwillingness to physically connect the Ku/Ka radio to the AISD router (while noting they are promoting the connection of cellular to it). Their objection/concern stems from Ku/Ka offering passenger owned devices access.
As mentioned earlier, the first supplement of PP848 will address the means for using 848 instances to allow the Ku/Ka, or any BARN to serve all domains on the airplane.
The existence of this cross-link is a feature within Airbus networks, and reflects their unwillingness to physically connect the Ku/Ka radio to the AISD router (while noting they are promoting the connection of cellular to it). Their objection/concern stems from Ku/Ka offering passenger owned devices access.
As mentioned earlier, the first supplement of PP848 will address the means for using 848 instances to allow the Ku/Ka, or any BARN to serve all domains on the airplane.
PP848 is planned for approval in October 2018.
The next NIS meeting is scheduled for June 5-7 in Renton, Washington.
Anyone interested should consider participating in the activity.
The next NIS meeting is scheduled for June 5-7 in Renton, Washington.
Anyone interested should consider participating in the activity.
Stay tuned!
Peter Lemme
peter @ satcom.guru
Follow me on twitter: @Satcom_Guru
Copyright 2017 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 ARINC 791 and 792 characteristics and contributes to the Network Infrastructure and Interfaces (NIS) subcommittee developing Project Paper 848, standard for Secure Broadband IP Air/Ground Interface.
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 lead engineer for Thrust Management System (757, 767, 747-400), also supervisor for satellite communications for 777, and was manager of terminal-area projects (GLS, MLS, enhanced vision).
An instrument-rated private pilot, single engine land and sea, Peter has enjoyed perspectives from both operating and designing airplanes. Hundreds of hours of flight test analysis and thousands of hours in simulators have given him an appreciation for the many aspects that drive aviation; whether tandem complexity, policy, human, or technical; and the difficulties and challenges to achieving success.
An instrument-rated private pilot, single engine land and sea, Peter has enjoyed perspectives from both operating and designing airplanes. Hundreds of hours of flight test analysis and thousands of hours in simulators have given him an appreciation for the many aspects that drive aviation; whether tandem complexity, policy, human, or technical; and the difficulties and challenges to achieving success.
No comments:
Post a Comment