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

More documents

Recommendations

Info

Protocol failure manifests itself in terms of route oscillations, routing loops, starvation (i.e., data traffic destined for a network or host is forwarded to a part of the network that cannot deliver it), network segmentation, and increased packet latencies (delays). The remainder of this section discusses BGP routing issues that derive from airplanes being in different ASs than other airplane or ground systems. This discussion presumes that each airplane will comprise its own AS. Because of this, aircraft will need to leverage the BGP protocol to remain connected to other air or ground entities. Readers not actively interested in BGP issues are encouraged to skip the remainder of this section. A growing body of research currently identifies mechanisms (e.g., cross-layer feedback [59-61]) to improve lower layer and IGP routing performance in highly mobile wireless IP environments. However, EGP routing within such environments has only recently begun to be studied [62]. Because it is anticipated that civilian aircraft will operate in different ASs than the ground or aircraft entities with which they communicate, the wireless links between aircraft and ground stations will need to support EGP routing. Inter-AS connectivity almost always occurs within IP environments today using BGP. Because BGP links two ASs together and because the AS is the unit of routing policy within the IP topology hierarchy (e.g., each AS has its own security and administrative requirements), BGP is designed to handle policy issues. Correctly reflecting these policies potentially complicates the configuration of the BGP connections, because they often reflect formal, legal contractual relationships established between those two organizations (i.e., corporations, governments). Specifically, BGP connections need to be well engineered and anticipated in advance [63] (i.e., it is not a reactive protocol) so that the specific configurations for each pairwise connection can be correctly orchestrated by both communicating peers. BGP has the undesirable characteristic that a small routing change is propagated globally, delaying routing convergence system-wide (see [64-66]) in the resulting network-of-networks. Mobility and movement may cause signal intermittencies, attenuation, and loss on the BGP connections that link ASs together, potentially causing system instability. While BGP is slow to detect changes and restore routing, shortening the BGP timers improves upon invalid and missing routes but creates much higher protocol traffic overhead and possible protocol instability. Because BGP was designed to be deployed within wired network environments, it exhibits a certain amount of brittleness when deployed across wireless links. Specifically, BGP was designed to support very stable interdomain connection environments. These assumptions may become challenged in environments where ASs move in relationship with each other. There are three issues that are particularly significant: • Signal intermittence events may exceed the BGP timer values. When a BGP peer fails to receive “KeepAlive” messages from its neighbor, it will expire routes that use the 64
neighbor as a next hop after “HoldTime” seconds. 17 If the timer values are increased to reduce the number of these time outs, then the responsiveness of the protocol is also reduced, including the time interval it takes for the remote peer to discover that the connection has been broken and, therefore, stop needlessly wasting wireless bandwidth by sending nondeliverable packets across that link. • BGP can only establish well-known, pairwise connections (i.e., it cannot support meshes) and lacks a peer discovery mechanism. Therefore, as ASs move in relationship with each other, the possibility exists that the communicating peers will move out of range of each other. If this happens, then the BGP connection is dropped, even if other routers within the peer AS are still within transmission range of the aircraft. This connectivity brittleness is a primary difficulty of using BGP in mobile environments. • Since BGP does not have a peer discovery capability, the AS boundary routers (ASBR) that host BGP communications need to be configured to connect to other ASBRs within their (remote) peer ASs where connectivity is anticipated to be needed during flight planning. Once such connectivity has been anticipated (i.e., the ASBRs for all ASs within the flight plan need to be correctly configured to enable each pairwise connectivity relationship), these connections can either be turned on in advance or turned on via a coordinated out-of-band mechanism during flight. The later alternative runs the risk of undergoing the loss of connectivity while the previous AS connections are torn down and the new AS connections established. If the aircraft is moving slowly enough, and the ground systems are positioned closely enough, it may be possible to accomplish this transaction while the aircraft is in range of both ground system locations, thereby avoiding loss of communications. However, a key point to recognize is that active BGP connections (i.e., unless the BGP connections on both sides are turned off) continue to attempt to connect with their peers even when they are physically out of range of each other, thereby needlessly wasting wireless network capacity. The second and third issues can be theoretically mitigated by establishing BGP relationships between ASs across satellite links. As long as each BGP peer remains within the satellite’s beam, the entity is not moving from the satellite’s perspective. Since satellite beams can be geographically quite large, this may be an attractive solution for airborne environments. However, the benefit is reduced if the aircraft or ground station is near the edge of a beam, if geographical movement exceeds the beam’s diameter in unforeseen ways, if the cumulative user capacity exceeds the cumulative satellite capacity of that geographic region, or if the satellite becomes unavailable. There is also the issue of mitigating adverse IP and TCP reactions to geo-stationary satellite latencies. For example, BGP itself runs over TCP transports. It is possible that other air-to-ground or air-to-air communications also run over TCP transports as well. Unfortunately, TCP treats latency as being network congestion. Thus, TCP inappropriately backs off its transmission rate for their sessions in response to geo-synchronous latency, reducing the efficiency of those links, unless mitigation techniques have been introduced into the system to address this issue. 17 The RFC 1771-recommended BGP timer values are 120 seconds for ConnectRetry, 90 seconds for HoldTime, and 30 seconds for KeepAlive. 65
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 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: deployments. Regional flights that
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 and 130: mechanism relies upon the controlle
Page 131 and 132:
HAGs are high-assurance devices tha
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

Create successful ePaper yourself

Delete template?

Save as template?