Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

using the traditional dual router implementation of reference 99 currently deployed in the
Internet today:
• To reduce the SWAP footprint of the encapsulation upon aircraft.
• To enable network management deployments where an entire airplane (e.g., multiple
enclaves) can be managed from a single network management system (see section 8.4).
It is probable that no middlebox implementation of this technology existed at the time this study
was written. Creating a middlebox variant of this technology, therefore, represents a
recommended development activity. Special care should be taken in the security design of its
network management support capability (see section 8.4).
Figure 30 shows that the encapsulating gateway that service Level A software networks on the
airplane communicates with its peer encapsulation gateways servicing Level A networks on
another airplane or on the ground via IPsec’s ESP in tunnel mode communications. Entities
within the Level A networks use normal IP communications between themselves (i.e., plain
text). From their perspective, they are using COTS IPs just like any other IP device would.
They are unaware that any network exists outside of their own Level A enclave. They are also
unaware that their enclave is using network services provided outside of their enclave (e.g., the
network between the encapsulation gateways that service their enclave). VPN encryption and
encapsulation is performed by their local encapsulation gateway so that no entity or network
outside of their network enclave sees intraenclave communication except in its encrypted and
encapsulated form. For example, from the point of view of the firewall in figure 30,
communications from a Level A device on the airplane to a Level A device off of the airplane is
merely an IP communication between two different encapsulation gateways (i.e., no entity
outside of the VPN-protected enclave itself knows about the enclave).
Therefore, the Level A VPN enclave entities have no knowledge about any entity outside of their
own enclave community. The same is true for the Level B VPN enclave, the Level C
VPN enclave, and so on—each VPN enclave only knows about itself. No entity outside of that
enclave knows about entities inside a different enclave. Therefore, the enclave population is
narrowly restricted to the members of the enclave only. Effective network partitioning has
occurred. Even in the worst-case scenario where all firewalls in the entire NAS and on every
airplane have become compromised and the airplanes are connected to the worldwide Internet,
the enclave population remains restricted to the enclave membership only. Airplane passengers
cannot communicate with devices inside an enclave (indeed, they do not know they exist) nor
can any other entity outside of the enclave do so. Therefore, the risks articulated in section 4.1
have been mitigated. If there is no human presence in an enclave (i.e., if the enclave is solely
populated by devices), then the risks articulated in section 4.2 have also been mitigated for that
enclave. If both of these are the case, then the concerns mentioned in sections 4.3 and 4.4 persist
at a diminished risk level because the threat agents that can directly attack VPN entities are now
restricted to the device population of the VPN itself. (Note: defense-in-depth protections (e.g.,
QoS) are still needed to ensure that the LAN supporting the VPN is not attacked, which, if
successful, could potentially result in DoS to the VPN.) Nevertheless, COTS devices are not
111