Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
20. The packet filter <strong>in</strong> the aircraft control must be configured such that noncockpit crew<br />
network cannot address any encapsulation gateway. If the aircraft is us<strong>in</strong>g figure 1 target<br />
architecture (i.e., no air gap between the passenger and avionics systems), then the packet<br />
filter needs to additionally provide the follow<strong>in</strong>g services:<br />
• No device with<strong>in</strong> the passenger network can access the noncockpit crew network<br />
or the cockpit-pilot network.<br />
• No device with<strong>in</strong> the passenger network can send packets to any encapsulation<br />
gateways (located with<strong>in</strong> aircraft control).<br />
• The packet filter, or a device closely associated with the packet filter compris<strong>in</strong>g a<br />
common system with it (e.g., QoS middlebox), rate limits communications from<br />
the passenger network to ensure that passenger communications cannot exceed a<br />
certa<strong>in</strong> threshold rate. This provision attempts to ensure that passengers alone<br />
cannot cause a DoS attack on the aircraft control’s high-assurance LAN by<br />
consum<strong>in</strong>g a disproportionate share of its capacity.<br />
21. The firewall needs to be configured to be as exclusive as possible. Because of the<br />
presence of passengers <strong>in</strong> the network <strong>in</strong> the figure 1 target, the HTTP overt channel<br />
vulnerability (see section 4.1 and appendix A.1), unfortunately, cannot be fully plugged,<br />
unlike the figure 3 target alternative. However, if aircraft design restricts pilot and crew<br />
communications such that they never use HTTP, then the firewall can be configured so<br />
that HTTP traffic (i.e., both Port 80 and Port 443) is filtered out by the firewall whenever<br />
the packet’s dest<strong>in</strong>ation address is a nonpassenger device. Such a rule would provide<br />
pilot and crew devices helpful protection <strong>in</strong> figure 1 environments. Even if the pilot and<br />
crew were permitted to use secure HTTP only (i.e., Port 443), then at least the more<br />
dangerous Port 80 transmissions could be filtered. In any case, the firewall needs to be<br />
configured so that:<br />
• All f<strong>in</strong>gerpr<strong>in</strong>t<strong>in</strong>g attempts (see appendix A, section A.1) orig<strong>in</strong>at<strong>in</strong>g from outside<br />
of the aircraft to any entity with<strong>in</strong> the aircraft will fail (except for those that<br />
rema<strong>in</strong> through the HTTP hole).<br />
• All communications to encapsulation gateways from outside of an airplane are<br />
blocked by the firewall unless they use IPsec’s ESP. (Note: both the firewall and<br />
the gateways themselves need to redundantly enforce this same rule for defense<strong>in</strong>-depth<br />
reasons.)<br />
• The firewall should also be configured to drop all packets orig<strong>in</strong>at<strong>in</strong>g from<br />
outside of the aircraft to IP dest<strong>in</strong>ation addresses that are not deployed with<strong>in</strong> the<br />
aircraft LAN. Please recall that the firewall only has visibility <strong>in</strong>to VPNs s<strong>in</strong>ce it<br />
only sees their encapsulat<strong>in</strong>g packet headers, which are solely addressed to<br />
encapsulation gateways.<br />
144