Saturday, September 2, 2017

Managing Network Security and QoS: PP848

Air Transport Airplanes are faced with a monumental challenge to upgrade and embrace modern IP radio networks.  Network security has risen mightily to challenge designers, mire down operations, and yet struggles to achieve its goal.  Bandwidth management - Quality of Service - is done piece-meal, blind to real priority and performance goals.  What will bring this all together?

Aeronautical Wireless Data Networking

Airplane data networking has been based around ACARS for nearly 40 years.  ACARS is a private packet-switched data network that uses an arcane character-oriented protocol over three distributed interfaces:

ARINC 619: Airborne End System Server (AESS) to Communication Management Unit (CMU)
ARINC 618: CMU Air-Ground to Data Link Service Provider (DSP)
ARINC 620: DSP to Ground End System Server (GESS) (not discussed further, herein)

ARINC 619 is based upon ARINC 429, a low-speed serial data network.

The CMU connects to radios, using ARINC 429, following ARINC 750 for VHF Data Radio, ARINC 741 for Satellite Data Radio, and ARINC 753 for HF Data Radio.

The Aeronautical Telecommunications Network (ATN) was originally envisioned to work over X.25/8208 switched virtual circuits (SVC).  ARINC 750 VDR natively support this protocol. Inmarsat recently brought forth the same capability (IRIS precursor) to augment SESAR service.

Inmarsat SVC (data level 3) has been a packet-switched service since about 1994, but for non-safety applications. Tenzing, for example, used this feature to power cellular SMS messaging from seat-back IFE (Virgin Atlantic, Panasonic, ARINC) starting in 2002.

IP quickly out-paced SVC broadly by the end of the twentieth century.  Inmarsat and Iridium offered dial-up circuit-switched, public-switched telephone network (PSTN) interfaces to an ISP modem that operated along v.22bis (2400 bps) speeds, that could deliver the Internet.  Inmarsat Swift64 Mobile Packet Data Service (MPDS) finally brought native, packet-switched IP to the airplane by 2003. Inmarsat continued that with SwiftBroadband.  

Inmarsat Aero Timeline
Inmarsat Aero Timeline
https://www.inmarsat.com/wp-content/uploads/2013/10/Inmarsat_Introduction_to_SwiftBroadband.pdf


Tenzing, ARINC/Viasat, and Connexion-by-Boeing developed native IP aero Ku satcom networks starting in 2002.   Gogo brought IP natively with their passenger line-of-site (LOS) ATG network in 2008. Notably the Ku-band and Ka-band satcom systems have proliferated, with heaps of low-cost bandwidth.  Iridium will bring native IP with Iridium Certus, by 2019.

End-End Ku/Ka satcom network

Cellular modems (CELL) and flavors of Wi-Fi, terminal wireless LAN (TLAN), have been connecting airplanes on the ground for about 20 years.  These have evolved into widely-available native IP networks.  AeroMACS is poised to augment the airport networking solutions. Sorely lacking is jetway.net; just plugging an 802.3 Ethernet cable into the airplane at the gate.

While the CMU has used ARINC 429 to interface to radios, and where the radios natively support ARINC 618; native IP networks are segmented and of no concern.  The ARINC 618 radio channel is set aside, dedicated to supporting the safety networking solely.  Inmarsat and Iridium amass multiple radio channels, dedicating them to safety or passenger communications exclusively.

IP Networking

The beauty of IP networking is being able to seamlessly manage multiple routes, using in this case multiple radio networks, from a simple application that just wants and a connection to a destination address.  The application does not care how the packets are routed.  The opportunity is to use IP switched networks as a common framework across the board.

AESS source IP (S-IP) wants to communicate with GESS destination IP (D-IP).

End-System Perspective


AESS declares that the information is either safety or non-safety.  This partitions the traffic, and may restrict which radio channels can be used.

AESS declares what level of performance (Quality of Service, QoS) is needed.

AESS declares what level of privacy is needed (encryption).

Seems so simple.  If we could just trust everyone.

PP848 SBAGI

SAE/ITC AEEC Project Paper 848, Secure Broadband IP Air/Ground Interface is being developed to address the need for strong authentication of the source and destination end-systems and restricting traffic only to packets that have been checked for integrity and are approved.  The challenge is to not break QoS, or bandwidth management, of the intermediate networks, notably the Air/Ground radio.

For the case of Ku/Ka satellite, ARINC 791 provided for a VLAN architecture across between the airborne radio (Radio) and the teleport.  This provides for segmenting traffic by QoS, including priority.  The VLAN methodology is compatible, in a generic way, with all satellite QoS methodologies used by Ku/Ka modem suppliers. 

PP848 uses DSCP and VLAN to segment QoS between AESS - Radio and between GESS - Teleport.

PP848 is a part of a defense-in-depth security architecture.  

PP848 Defense-in-Depth Security Model


The Radio/Teleport apply suitable measures consistent with Internet Service Provider (ISP) best-practices - e.g. SIM card, firewall, intrusion detection.) These measures restrict access to the sensitive radio interfaces from unauthorized traffic.

PP848 provides an end-end networking interface that spans the Radio/Teleport and across any intermediate networks to allow connection between the airborne sub-network connected to the AESS and the Enterprise sub-network connected to the GESS.  PP848 communicates between peer SBAGI instances on the airplane and the Enterprise using a VPN.  A VPN is dedicated specifically for a given QoS and for connecting the two specific sub-networks.  PP848 uses certificate-based authentication to establish the VPN between the peer instances.
PP848 End-End Security using VLAN and VPN (IPsec)


The AESS and GESS apply additional authentication and integrity checks as a final layer of protection, that is consistent with the applications being supported.

PP848 use of VPN can obscure the Radio/Teleport means to manage bandwidth.  PP848 provides for VLAN segmentation of VPN, such that the Radio/Teleport can focus on VLAN-based QoS without regard to the VPN traffic communicated.

ARINC 664 expresses that Ethernet networks be segregated, based on Aircraft Control, Aircraft Information, or Public Network.

Inmarsat and Iridium apply individual radio channels to segment the traffic across the air/ground wireless link.  

Ku/Ka satellite radios operate on a single data channel.  By necessity, all traffic is effectively squeezed into a serial stream of bits.  PP848 and ARINC 791 together provide for a single radio channel that can support multiple Ethernet domains, but applying physically-segmented Ethernet switches and VLAN.

ARINC 791 VLAN Radio-Teleport

Conclusion

PP848, along with ARINC 791, is an open-standards based approach to applying end-end network security while embracing radio-based quality of service.  PP848 maintains network segmentation and priority of communication as part of a defense-in-depth architecture.  Security measures at the teleport combined with application-specific features cooperatively enhance performance and ensure lowest cost of service.


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.






4 comments: