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

More documents

Recommendations

Info

appendix A. This parallelism means that ground systems would also need to address the same network management issues (see section 8.4). The exemplar network architecture recommended by this study, therefore, presumes that if airborne VPN enclaves are connected to other airborne VPN enclaves or to ground VPN enclaves at the same software (safety) level, then those linked VPN enclaves form a common distributed VPN network enclave together that jointly operates at that specific safety level. The specific VPN technology identified by this study was chosen because it is expected to be able to scale to whatever VPN network size is required to support a worldwide deployment. It is important to recognize that this connectivity means that the worldwide aeronautical network consists of both the nonenclave worldwide aeronautical network as well as the various worldwide VPN network enclaves, with each of the latter operating at a specific safety level. It therefore comprises partitioned network enclaves located within a larger civil aviation network whole. This relationship creates explicit policy issues that the worldwide civil aviation community will need to address in a coherent way. Specifically, what is the trust model between civil aviation regions? Will the trust model for the regions’ Level A software networks be the same as for their Level C software networks? What is the trust model between aircraft and ground entities? If air-to-air communications occur, what is the trust model between aircraft belonging to different airlines? Will the Level A VPN components of the NAS completely trust European Level A VPN components and vice versa, or will they establish distinct policies and service level agreement (SLA) mappings between their components? What security protections (e.g., firewalls) will be inserted to protect the rest of the VPN elements at that safety level from a contamination that occurred within a specific region? How will aircraft that travel between regions maintain their connectivity in a seamless, safe, and secure manner? If air-to-air applications and systems are created, what mechanisms (e.g., firewalls) will protect the VPN at a given safety level in one airplane from (perhaps undiagnosed) misbehaviors occurring in the VPN at that same safety level in a different airplane? What policy systems will govern the interrelationship between aircraft and ground entities? Will SLAs be required? For any airborne network architecture to be viable in real-life deployments, common worldwide design choices need to be agreed upon to decide how identity, IP addressing, naming, routing, and authentication will be handled systemwide. These common definitions and their associated infrastructure should be shared by both air and ground systems within the worldwide civil aviation network deployment if the resulting airborne network is to operate seamlessly between regions. 8.3.2 Physical Security. Specific physical security requirements are embedded within the figure 30 design. Those requirements are that aircraft control and the cockpit (pilot) networks or their devices must not be physically accessible by aircraft passengers. If there is any possibility of passengers physically accessing the cockpit (pilot) network, then the high-assurance LAN within the cockpit must be connected to the aircraft control network via the packet filter. Otherwise, the highassurance LAN in the cockpit can use the same physical high-assurance LAN as aircraft control. 114
HAGs are high-assurance devices that need to be physically protected from areas that are accessible by passengers. The noncockpit crew network devices should also not be accessible by passengers in general, but the design could accommodate situations in which passengers are not always physically excluded from the area where those devices are located. If physical separation is not possible, crew members must be very careful to not leave open applications running in situations when the crew member is not present (i.e., situations where passengers may access applications that have been opened with crew member authentications). 8.3.3 Encapsulation Gateways. Encapsulation gateways support IPsec in accordance with reference 99 (see section 8.3.1). The encapsulation gateways must be configured so that all packets sent to their nonenclave IP interfaces must be dropped unless they use the IPsec’s ESP. Encapsulation gateways communicate together using the ESP in tunnel mode. Network managers or IDS devices communicate with encapsulation gateways via the ESP in transport mode. Because of the authentication provisions contained within the ESP, encapsulation gateways should be configured so that they only accept communications from outside of the VPN enclave they support from three types of devices only: other encapsulation gateways, network managers, or IDS devices. They should be configured so that they ignore (e.g., drop) all non-IPsec packets coming from outside of the VPN. Packets sent to the VPN that they support must be IPsec in tunnel mode. The encapsulating gateway does not put any restriction upon packets sent within the VPN that it forwards. However, all packets addressed to the encapsulating gateway itself (from either outside of the VPN or within the VPN regardless) must be sent in IPsec or else they will be ignored (i.e., dropped). Because VPN gateways only link together distributed VPN elements that operate at the same software level, their IPsec’s security policy database (SPD) entries need to be configured to only permit IPsec security associations (SA) to be established with other encapsulating gateways operating at the same software level. Their SPD should be configured to prohibit any SAs to be created with any encapsulating gateway that services a different software level. The only exception is if a HAG exists on the plain text network (i.e., if the HAG is in place, then the two encapsulating gateways can be configured to establish SAs with each other). Encapsulating gateways should not be configured to permit SAs to become established between MSLS and system-high networks, regardless of whether they are operating at the same software level or not. Encapsulating gateways may also need to support network management relaying, depending on how a given implementation has configured its network management system. The relevant issue is that because each VPN system can only know about its own VPN, and the internals of that system are hidden from all entities not in that VPN, then there is no natural way for a single network management system to manage an airplane’s entire network environment if that airplane supports multiple VPNs. The most obvious management approach is to have a single management system per VPN; but that alternative means that multiple disjoint network management systems will exist, none of which have coordinated oversight over the aircrafts’ 115
Page 1 and 2:
DOT/FAA/AR-08/31 Air Traffic Organi
Page 3 and 4:
1. Report No. DOT/FAA/AR-08/31 4. T
Page 5 and 6:
5.4.2 Aircraft as a Node (MIP and M
Page 7 and 8:
11.1 Findings and Recommendations 1
Page 9 and 10:
22 Customer’s L3VPN Protocol Stac
Page 11 and 12:
LIST OF ACRONYMS AND ABBREVIATIONS
Page 13 and 14:
PBN PC PE PEP PFS PIB PIM-DM PIM-SM
Page 15 and 16:
This report states that the primary
Page 17 and 18:
1. INTRODUCTION. This is the final
Page 19 and 20:
protocol (IP)-based communications.
Page 21 and 22:
of linking aircraft-resident system
Page 23 and 24:
Industry and governments are extrem
Page 25 and 26:
2.1 NOTIONAL NETWORKED AIRCRAFT ARC
Page 27 and 28:
Other Control Sites Controller ATC
Page 29 and 30:
• The security viability of curre
Page 31 and 32:
alternative requires that parallel
Page 33 and 34:
Aircraft network security is a syst
Page 35 and 36:
4. NETWORK RISKS. This section spec
Page 37 and 38:
General Threat Identifiers FAILURE
Page 39 and 40:
esources so that the required real-
Page 41 and 42:
“With the rise of client-side att
Page 43 and 44:
• During an 11-month period (Apri
Page 45 and 46:
attempt the theft of passwords. Non
Page 47 and 48:
IP networks are organized in terms
Page 49 and 50:
either the user or the trusted soft
Page 51 and 52:
However, the previous paragraph beg
Page 53 and 54:
Table 1. Internet Engineering Task
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
• Lightweight directory access pr
Page 61 and 62:
mechanism to overcome the key distr
Page 63 and 64:
Deployments that need to support mu
Page 65 and 66:
Today’s Reality: Islands of Commu
Page 67 and 68:
Simultaneously, IP addresses are al
Page 69 and 70:
in-depth manner. Defense-in-depth m
Page 71 and 72:
Protection Detection Reaction / Neu
Page 73 and 74:
encrypted and then encapsulated wit
Page 75 and 76:
Internet (grouping of autonomous sy
Page 77 and 78:
via that same IP address. Specifica
Page 79 and 80: deployments. Regional flights that
Page 81 and 82: neighbor as a next hop after “Hol
Page 83 and 84: Interface Interface Customer Site S
Page 85 and 86: Interface Customer’s Application
Page 87 and 88: Although the vast majority of PBN s
Page 89 and 90: 6. RELATING SAFETY AND SECURITY FOR
Page 91 and 92: 6.1.1 Integrity. As section 4.3 ind
Page 93 and 94: As mentioned in section 4.4, the hi
Page 95 and 96: 6.1.4 Confidentiality. Confidential
Page 97 and 98: their own classification level nor
Page 99 and 100: integrity is not permitted to obser
Page 101 and 102: software has been confirmed as leve
Page 103 and 104: • Both safety and security are co
Page 105 and 106: Device at Safety level X Device at
Page 107 and 108: in a Biba Integrity Model environme
Page 109 and 110: Common Criteria Classes ACM—Confi
Page 111 and 112: (see section 9.10). A secure mechan
Page 113 and 114: employed in security-critical appli
Page 115 and 116: concept, which is needed to create
Page 117 and 118: 4. Learn from past mistakes. Poor d
Page 119 and 120: exemplar airborne network architect
Page 121 and 122: • Requirement 8: Biba Integrity M
Page 123 and 124: Figure 31 shows how the recommended
Page 125 and 126: to-live (TTL) field in the IP heade
Page 127 and 128: using the traditional dual router i
Page 129: mechanism relies upon the controlle
Page 133 and 134: 8.3.5 Firewall. The firewall needs
Page 135 and 136: (AJ) or low probability of intercep
Page 137 and 138: design decisions that need to be de
Page 139 and 140: 9.2 INTEGRATED MODULAR AVIONICS IMP
Page 141 and 142: 9.3 USING PUBLIC IPs. The model and
Page 143 and 144: alerted the pilots because the fail
Page 145 and 146: environments. If the certification
Page 147 and 148: DSS (FIPS 186 [81]). Code signing i
Page 149 and 150: elationship with other equipment in
Page 151 and 152: approach is to keep the log informa
Page 153 and 154: 11. SUMMARY. Current civilian aircr
Page 155 and 156: environments should be extended to
Page 157 and 158: 12. COTS computer systems cannot be
Page 159 and 160: 14. NAS and airborne network archit
Page 161 and 162: 22. If SWAP considerations permit,
Page 163 and 164: 11.2 TOPICS NEEDING FURTHER STUDY.
Page 165 and 166: 9. Lee, Y., Rachlin, E., and Scandu
Page 167 and 168: 32. Loscocco, P., Smalley, S., Muck
Page 169 and 170: 59. Raisinghani, V. and Sridhar, I.
Page 171 and 172: the following is a pointer to a rel
Page 173 and 174: Department of Defense Instruction N
Page 175 and 176: Information Assurance—The Departm
Page 177 and 178: Threat source—Either (1) intent a
Page 179 and 180: information found within these data
Page 181 and 182:
(HTTP) traffic (port 80), port scan
Page 183 and 184:
The simple network management proto
Page 185 and 186:
opportunities to crack the hosting
Page 187 and 188:
authorized to perform. 13 However,
Page 189 and 190:
sniffers, log-cleaning scripts, and
Page 191 and 192:
A.3.1 DENIAL OF SERVICE ATTACKS. Th
Page 193 and 194:
• Disclosure: Disclosure of routi
Page 195 and 196:
affected by the signal intermittenc
Page 197 and 198:
A-15. Barbir, A., Murphy, S., and Y
Page 199 and 200:
Survey Question What is the primary
Page 201 and 202:
Survey Question What is the primary
Page 203 and 204:
should be emphasized that there is
show all

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?