13.09.2014 Views

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

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!