idnits 2.17.1 draft-templin-atn-bgp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 03, 2018) is 2239 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4451' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-ddt' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'RFC6836' is defined on line 747, but no explicit reference was found in the text == Outdated reference: A later version (-82) exists of draft-templin-aerolink-81 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft G. Saccone 4 Intended status: Informational Boeing Research & Technology 5 Expires: September 4, 2018 G. Dawra 6 LinkedIn 7 A. Lindem 8 Cisco Systems, Inc. 9 March 03, 2018 11 A Simple BGP-based Mobile Routing System for the Aeronautical 12 Telecommunications Network 13 draft-templin-atn-bgp-06.txt 15 Abstract 17 The International Civil Aviation Organization (ICAO) is investigating 18 mobile routing solutions for a worldwide Aeronautical 19 Telecommunications Network with Internet Protocol Services (ATN/IPS). 20 The ATN/IPS will eventually replace existing communication services 21 with an IPv6-based service supporting pervasive Air Traffic 22 Management (ATM) for Air Traffic Controllers (ATC), Airline 23 Operations Controllers (AOC), and all commercial aircraft worldwide. 24 This informational document describes a simple and extensible mobile 25 routing service based on industry-standard BGP to address the ATN/IPS 26 requirements. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 4, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 6 65 4. ATN/IPS Multilink and Mobility Service . . . . . . . . . . . 9 66 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 10 67 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 13 68 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 74 11.2. Informative References . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 The worldwide Air Traffic Management (ATM) system today uses a 80 service known as Aeronautical Telecommunications Network based on 81 Open Systems Interconnection (ATN/OSI). The service is used to 82 augment controller to pilot voice communications with rudimenatary 83 short text command and control messages. The service has seen 84 successful deployment in a limited set of worldwide ATM domains. 86 The International Civil Aviation Organization [ICAO] is now 87 undertaking the development of a next-generation replacement for ATN/ 88 OSI known as Aeronautical Telecommunications Network with Internet 89 Protocol Services (ATN/IPS). ATN/IPS will eventually provide an 90 IPv6-based service supporting pervasive ATM for Air Traffic 91 Controllers (ATC), Airline Operations Controllers (AOC), and all 92 commercial aircraft worldwide. As part of the ATN/IPS undertaking, a 93 new mobile routing service will be needed. This document presents a 94 candidate approach based on the Border Gateway Protocol (BGP) 95 [RFC4271]. 97 Aircraft communicate via wireless aviation data links that typically 98 support much lower data rates than terrestrial wireless and wired- 99 line communications. For example, some Very High Frequency (VHF)- 100 based data links only support data rates on the order of 32Kbps and 101 an emerging L-Band data link that is expected to play a key role in 102 future aeronautical communications only supports rates on the order 103 of 1Mbps. Although satellite data links can provide much higher data 104 rates during optimal conditions, like any other aviation data link 105 they are subject to errors, delay, disruption, signal intermittence, 106 degradation due to atmospheric conditions, etc. The well-connected 107 ground domain ATN/IPS network should therefore treat each safety-of- 108 flight critical packet produced by (or destined to) an aircraft as a 109 precious commodity and strive for an optimized Traffic Engineering 110 service that provides the highest possible degree of reliability. 112 The ATN/IPS is an IPv6-based [RFC8200] overlay network that assumes a 113 worldwide connected Internetworking underlay for carrying tunneled 114 ATM communications. The Internetworking underlay could be manifested 115 as a private collection of long-haul backbone links (e.g., 116 fiberoptics, copper, SATCOM, etc.) interconnected by high-performance 117 networking gear such as bridges, switches, and routers. Such a 118 private network would need to connect all ATN/IPS participants 119 worldwide, and could therefore present a considerable cost for a 120 large-scale deployment of new infrastructure. Alternatively, the 121 ATN/IPS could be deployed as a secured overlay over the existing 122 global public Internet. For example, ATN/IPS nodes could be deployed 123 as part of an SD-WAN or an MPLS-WAN that rides over the public 124 Internet via secured tunnels. 126 The ATN/IPS further assumes that each aircraft will receive an IPv6 127 Mobile Network Prefix (MNP) that accompanies the aircraft wherever it 128 travels. ATCs and AOCs will likewise receive IPv6 prefixes, but they 129 would typically appear in static (not mobile) deployments such as air 130 traffic control towers, airline headquarters, etc. Throughout the 131 rest of this document, we therefore use the term "MNP" when 132 discussing an IPv6 prefix that is delegated to any ATN/IPS end 133 system, including ATCs, AOCs, and aircraft. We also use the term 134 Mobility Service Prefix (MSP) to refer to an aggregated prefix 135 assigned to the ATN/IPS by an Internet assigned numbers authority, 136 and from which all MNPs are delegated (e.g., up to 2**32 IPv6 /64 137 MNPs could be delegated from the MSP 2001:db8::/32). 139 Connexion By Boeing [CBB] was an early aviation mobile routing 140 service based on dynamic updates in the global public Internet BGP 141 routing system. Practical experience with the approach has shown 142 that frequent injections and withdrawals of MNPs in the Internet 143 routing system can result in excessive BGP update messaging, slow 144 routing table convergence times, and extended outages when no route 145 is available. This is due to both conservative default BGP protocol 146 timing parameters (see Section 6) and the complex peering 147 interconnections of BGP routers within the global Internet 148 infrastructure. The situation is further exacerbated by frequent 149 aircraft mobility events that each result in BGP updates that must be 150 propagated to all BGP routers in the Internet that carry a full 151 routing table. 153 We therefore consider an approach using a BGP overlay network routing 154 system where a private BGP routing protocol instance is maintained 155 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 156 private BGP instance does not interact with the native BGP routing 157 system in the connected Internetworking underlay, and BGP updates are 158 unidirectional from "stub" ASBRs (s-ASBRs) to a very small set of 159 "core" ASBRs (c-ASBRs) in a hub-and-spokes topology. The Asymmetric 160 Extended Route Optimization (AERO) architecture 161 [I-D.templin-aerolink] is used to support mobility and route 162 optimization services, where the BGP s-ASBRs are one and the same as 163 AERO Servers and the BGP c-ASBRs are one and the same as AERO Relays. 164 No extensions to the BGP protocol are necessary. 166 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 167 dedicated high speed links and/or tunnels across the Internetworking 168 underlay using industry-standard encapsulations (e.g., Generic 169 Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). The 170 s-ASBRs engage in external BGP (eBGP) peerings with their respective 171 c-ASBRs, and only maintain routing table entries for the MNPs 172 currently active within the stub AS. The s-ASBRs send BGP updates 173 for MNP injections or withdrawals to c-ASBRs but do not receive any 174 BGP updates from c-ASBRs. Instead, the s-ASBRs maintain default 175 routes with their c-ASBRs as the next hop, and therefore hold only 176 partial topology information. 178 The c-ASBRs connect to other c-ASBRs using iBGP peerings over which 179 they collaboratively maintain a full routing table for all active 180 MNPs currently in service. Therefore, only the c-ASBRs maintain a 181 full BGP routing table and never send any BGP updates to s-ASBRs. 182 This simple routing model therefore greatly reduces the number of BGP 183 updates that need to be synchronized among peers, and the number is 184 reduced further still when localized mobility events within stub ASes 185 (i.e., "intra-domain" mobility events) are processed within the AS 186 instead of being propagated to the core. BGP Route Reflectors (RRs) 187 [RFC4456] can also be used to support increased scaling properties. 189 The remainder of this document discusses the proposed BGP-based ATN/ 190 IPS mobile routing service. 192 2. Terminology 194 The terms Autonomous System (AS) and Autonomous System Border Router 195 (ASBR) are the same as defined in [RFC4271]. 197 The terms "AERO Client", "AERO Proxy", "AERO Server", and "AERO 198 Relay" are the same as defined in [I-D.templin-aerolink]. 200 The following terms are defined for the purposes of this document: 202 Air Traffic Managemnet (ATM) 203 The worldwide service for coordinating safe aviation operations. 205 Air Traffic Controller (ATC) 206 A government agent responsible for coordinating with aircraft 207 within a defined operational region via voice and/or data Command 208 and Control messaging. 210 Airline Operations Controller (AOC) 211 An airline agent responsible for tracking and coordinating with 212 aircraft within their fleet. 214 Aeronautical Telecommunications Network with Internet Protocol 215 Services (ATN/IPS) 216 A future aviation network for ATCs and AOCs to coordinate with all 217 aircraft operating worldwide. The ATN/IPS will be an IPv6-based 218 overlay network service that connects access networks via 219 tunneling over an Internetworking underlay. 221 Internetworking underlay A connected wide-area network that supports 222 overlay network tunneling and connects Radio Access Networks to 223 the rest of the ATN/IPS. 225 Radio Access Network (RAN) 226 An aviation radio data link service provider's network, including 227 radio transmitters and receivers as well as suppporting ground- 228 domain infrastructure needed to convey a customer's data packets 229 to the outside world. The term RAN is intended in the same spirit 230 as for cellular operator networks and other radio-based Internet 231 service provider networks. For simplicity, we also use the term 232 RAN to refer to ground-domain networks that connect AOCs and ATCs 233 without any aviation radio communications. 235 Core Autonomous System Border Router (c-ASBR) A BGP router located 236 in the hub of a hub-and-spokes overlay network topology. Each 237 c-ASBR is also an AERO Relay. 239 Stub Autonomous System Border Router (s-ASBR) A BGP router 240 configured as a spoke in a hub-and-spokes overlay network 241 topology. Each s-ASBR is also an AERO Server. 243 Client An ATC, AOC or aircraft that connects to the ATN/IPS as a 244 leaf node. The Client could be a singleton host, or a router that 245 connects a mobile network. 247 Proxy A node at the edge of a RAN that acts as a proxy go-between 248 between Clients and Servers. 250 Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any 251 ATN/IPS end system, including ATCs, AOCs, and aircraft. 253 Mobility Service Prefix (MSP) An aggregated prefix assigned to the 254 ATN/IPS by an Internet assigned numbers authority, and from which 255 all MNPs are delegated (e.g., up to 2**32 IPv6 /64 MNPs could be 256 delegated from the MSP 2001:db8::/32). 258 3. ATN/IPS Routing System 260 The proposed ATN/IPS routing system comprises a private BGP instance 261 coordinated between ASBRs in an overlay network via tunnels over the 262 Internetworking underlay (where the tunnels between neighboring ASBRs 263 are set up as part of the BGP peering configuration.) The overlay 264 does not interact with the native BGP routing system in the connected 265 undelying Internetwork, and each c-ASBR advertises only a small and 266 unchanging set of MSPs into the Internetworking underlay routing 267 system instead of the full dynamically changing set of MNPs. (For 268 example, when the Internetworking underlay is the global public 269 Internet the c-ASBRs advertise the MSPs in the public BGP Internet 270 routing system.) The routing system is discussed in detail in 271 [I-D.templin-aerolink]. 273 In a reference deployment, one or more s-ASBRs connect each stub AS 274 to the overlay using a shared stub AS Number (ASN). Each s-ASBR 275 further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are 276 members of the same core AS, and use a shared core ASN. Since the 277 private BGP instance is separate from the global public Internet BGP 278 routing system, the ASBRs can use either a private ASN per [RFC6996] 279 or simply use public ASNs noting that the ASNs may overlap with those 280 already assigned in the Internet. (A third alternative would be to 281 procure globally-unique public ASNs, but cost and maintenance 282 requirements must be conisdered.) 283 The c-ASBRs use iBGP to maintain a synchronized consistent view of 284 all active MNPs currently in service. Figure 1 below represents the 285 reference deployment. (Note that the figure shows details for only 286 two s-ASBRs (s-ASBR1 and s-ASBR2) due to space constraints, but the 287 other s-ASBRs should be understood to have similar Stub AS and MNP 288 arrangements.) The solution described in this document is flexible 289 enough to extend to these topologies. 291 ........................................................... 292 . . 293 . (:::)-. <- Stub ASes -> (:::)-. . 294 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 295 . `-(::::)-' `-(::::)-' . 296 . +-------+ +-------+ . 297 . |s-ASBR1| |s-ASBR2| . 298 . +--+----+ +-----+-+ . 299 . \ / . 300 . \eBGP /eBGP . 301 . \ / . 302 . +-------+ +-------+ . 303 . eBGP+-----+c-ASBR1| +c-ASBR2+-----+eBGP . 304 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 305 . |s-ASBRn+/ iBGP\ (:::)-. /iBGP \+s-ASBR3| . 306 . +-------+ .-(::::::::) +-------+ . 307 . . .-(::::::::::::::)-. . 308 . . (:::: Core AS :::) . 309 . +-------+ `-(:::::::::::::)-' +-------+ . 310 . |s-ASBR7+\ iBGP/`-(:::::::-'\iBGP /+s-ASBR4| . 311 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 312 . eBGP+-----+c-ASBRn| |c-ASBR3+-----+eBGP . 313 . +-------+ +-------+ . 314 . / \ . 315 . /eBGP \eBGP . 316 . / \ . 317 . +---+---+ +-----+-+ . 318 . |s-ASBR6| |s-ASBR5| . 319 . +-------+ +-------+ . 320 . . 321 . . 322 . <------------ Internetworking Underlay --------------> . 323 ............................................................ 325 Figure 1: Reference Deployment 327 In the reference deployment, each s-ASBR maintains routes for active 328 MNPs that currently belong to its stub AS. In response to "Inter- 329 domain" mobility events, each S-ASBR will dynamically announces new 330 MNPs and withdraws departed MNPs in its eBGP updates to c-ASBRs. 332 Since ATN/IPS end systems are expected to remain within the same stub 333 AS for extended timeframes, however, intra-domain mobility events 334 (such as an aircraft handing off between cell towers) are handled 335 within the stub AS instead of being propagated as inter-domain eBGP 336 updates. 338 Each c-ASBR configures a black-hole route for each of its MSPs. By 339 black-holing the MSPs, the c-ASBR will maintain forwarding table 340 entries only for the MNPs that are currently active, and packets 341 destined to all other MNPs will correctly incur ICMPv6 Destination 342 Unreachable messages [RFC4443] due to the black hole route. (This is 343 the same behavior as for ordinary BGP routers in the Internet when 344 they receive packets for which there is no route available.) The 345 c-ASBRs do not send eBGP updates for MNPs to s-ASBRs, but instead 346 originate a default route. In this way, s-ASBRs have only partial 347 topology knowledge (i.e., they know only about the active MNPs 348 currently within their stub ASes) and they forward all other packets 349 to c-ASBRs which have full topology knowledge. 351 Scaling properties of this ATN/IPS routing system are limited by the 352 number of BGP routes that can be carried by the c-ASBRs. A 2015 353 study showed that BGP routers in the global public Internet at that 354 time carried more than 500K routes with linear growth and no signs of 355 router resource exhaustion [BGP]. A more recent network emulation 356 study also showed that a single c-ASBR can accommodate at least 1M 357 dynamically changing BGP routes even on a lightweight virtual 358 machine. Commercially-available high-performance dedicated router 359 hardware can support many millions of routes. 361 Therefore, assuming each c-ASBR can carry 1M or more routes, this 362 means that at least 1M ATN/IPS end system MNPs can be serviced by a 363 single set of c-ASBRs and that number could be furhter increased by 364 using RRs. Another means of increasing scale would be to assign a 365 different set of c-ASBRs for each set of MSPs. In that case, each 366 s-ASBR still peers with one or more c-ASBRs from each set of c-ASBRs, 367 but the s-ASBR institutes route filters so that it only sends BGP 368 updates to the specific set of c-ASBRs that aggregate the MSP. For 369 example, if the MSP for the ATN/IPS deployment is 2001:db8::/32, a 370 first set of c-ASBRs could service the MSP segment 2001:db8::/40, a 371 second set could service 2001:db8:0100::/40, a third set could 372 service 2001:db8:0200::/40, etc. 374 In this way, each set of c-ASBRs services a specific set of MSPs that 375 they inject into the Internetworking underlay native routing system, 376 and each s-ASBR configures MSP-specific routes that list the correct 377 set of c-ASBRs as next hops. This BGP routing design also allows for 378 natural incremental deployment, and can support initial small-scale 379 deployments followed by dynamic deployment of additional ATN/IPS 380 infrastructure elements without disturbing the already-deployed base. 382 4. ATN/IPS Multilink and Mobility Service 384 ATN/IPS end system multilink and mobility services are based on the 385 AERO architecture [I-D.templin-aerolink], where end systems connect 386 to aviation data link service provider Radio Access Networks (RANs). 387 ATN/IPS end systems such as aircraft act as AERO Clients and may 388 connect to multiple RANs at once, for example, when they have both a 389 satellite link and an L-Band link activated simultaneously. Clients 390 register all of their active data link connections with one or more 391 AERO Servers which also act as s-ASBRs as discussed in Section 3. 392 Clients may connect to Servers either directly, or via an AERO Proxy 393 at the edge of the RAN. The Proxy function corresponds to the manner 394 in which web proxies communicate with web servers on behalf of 395 clients in secured domains such as corporate enterprise networks. 397 Figure 2 shows the ATN/IPS multilink and mobility model where Clients 398 connect to RANs via aviation data links. Clients register their RAN 399 addresses with a nearby Server, where the registration process may be 400 brokered by a Proxy at the edge of the RAN. 402 Data Link "A" +--------+ Data Link "B" 403 +----------- | Client |-----------+ 404 / +--------+ \ 405 / \ 406 / \ 407 (:::)-. (:::)-. 408 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 409 `-(::::)-' `-(::::)-' 410 +-------+ +-------+ 411 ... | Proxy | ............................ | Proxy | ... 412 . +-------+ +-------+ . 413 . . 414 . . 415 . +--------+ (:::)-. . 416 . | Server | eBGP <-> .-(:::::::::) . 417 . |(s-ASBR)| `-(::::)-' . 418 . +--------+ ATN/IPS BGP Overlay . 419 . . 420 . . 421 . <------------- Internetworking Underlay -------------> . 422 ............................................................ 424 Figure 2: ATN/IPS Multilink and Mobility Architecture 426 In this model, when a Client logs into a RAN it specifies a nearby 427 Server (s-ASBR) that it has selected to connect to the ATN/IPS. The 428 login process is brokered by a Proxy at the border of the RAN, which 429 then conveys the connection request to the Server via tunneling 430 across the Internetworking underlay. The Server then registers the 431 address of the Proxy as the address for the Client, and the Proxy 432 forwards the Server's reply to the Client. If the Client connects to 433 multiple RANs, the Server will register the addresses of all Proxies 434 along with their Quality of Service (QoS) preferences as addresses 435 through which the Client can be reached. 437 Once the Client has registered its data link addresses with the 438 Server via one or more Proxies, the Proxies can signal fine-grained 439 events like QoS changes to the Server on behalf of the Clients. For 440 example, if a data link signal is fading, the Proxy can inform the 441 Server without involvement of the Client. Moreover, if the RAN 442 supports intra-domain route injection, the Client can avoid 443 encapsulation and send and receive all of its packets unencapsulated 444 since the RAN will natively route them to and from the Proxy. The 445 Proxy will then tunnel the packets to and from the Server across the 446 Internetworking underlay so that the Client need not incur any over- 447 the-air encapsulation on performance-constrained aviation data links. 449 The Server represents all of its active Clients as MNP routes in the 450 ATN/IPS BGP routing system. The Server's stub AS therefore consists 451 of the set of all of its active Clients. The Server injects the MNPs 452 of its active Clients and withdraws the MNPs of its departed Clients 453 via BGP updates to c-ASBRs. Since Clients are expected to remain 454 associated with their current Servers for extended periods, the level 455 of MNP injections and withdrawals in the BGP routing system will be 456 on the order of the numbers of network joins, leaves and Server 457 handovers for aircraft operations (see: Section 6). It is important 458 to observe that fine-grained events such as Client mobility and QoS 459 signaling are coordinated only by Proxies and Servers, and do not 460 involve other ASBRs in the routing system. In this way, localized 461 events are not propagated into the global BGP routing system. 463 5. ATN/IPS Route Optimization 465 ATN/IPS end systems will frequently need to communicate with 466 correspondents associated with other s-ASBRs. In the ASBR peering 467 topology discussed in Section 3, this can initially only be 468 accommodated by including multiple ASBRs-to-ASBR tunnel segments in 469 the forwarding path. In many cases, it would be desirable to 470 eliminate extraneous ASBR tunnel segments from this "dogleg" route so 471 that packets can traverse a minimum number of tunneling hops across 472 the Internetworking underlay using the AERO route optimization 473 service [I-D.templin-aerolink]. 475 A route optimization example is shown in Figure 3 and Figure 4 below. 476 In the first figure, packets sent from Client1 to Client2 are 477 transmitted across the source RAN to Proxy1 without encapsulation. 478 Proxy1 then tunnels the packets to Server 1 (s-ASBR1), which tunnels 479 them to Relay 1 (c-ASBR1), which tunnels them to Relay2 (c-ASBR2), 480 which tunnels them to Server2 (s-ASBR2), which finally tunnels them 481 to Proxy2. In the second figure, the optimized route tunnels packets 482 directly from Proxy1 to Proxy2 without involving the ASBRs. 484 +---------+ +---------+ 485 | Client1 | | Client2 | 486 +---v-----+ +-----^---+ 487 * * 488 * * 489 (:::)-. (:::)-. 490 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 491 `-(::::)-' `-(::::)-' 492 +--------+ +--------+ 493 ... | Proxy1 | .......................... | Proxy2 | ... 494 . +--------+ +--------+ . 495 . ** ** . 496 . ** ** . 497 . ** ** . 498 . +---------+ +---------+ . 499 . | Server1 | | Server2 | . 500 . |(s-ASBR1)| |(s-ASBR2)| . 501 . +--+------+ +-----+---+ . 502 . \ ** Dogleg ** / . 503 . eBGP\ ** Route ** /eBGP . 504 . \ **==============** / . 505 . +---------+ +---------+ . 506 . | Relay1 | | Relay2 | . 507 . |(c-ASBR1)| |(c-ASBR2)| . 508 . +---+-----+ +----+----+ . 509 . +--------------+ . 510 . iBGP . 511 . . 512 . <------------- Internetworking Underlay -------------> . 513 ............................................................ 515 Figure 3: Dogleg Route Before Optimization 517 +---------+ +---------+ 518 | Client1 | | Client2 | 519 +---v-----+ +-----^---+ 520 * * 521 * * 522 (:::)-. (:::)-. 523 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 524 `-(::::)-' `-(::::)-' 525 +--------+ +--------+ 526 ... | Proxy1 | .......................... | Proxy2 | ... 527 . +------v-+ +--^-----+ . 528 . * * . 529 . *================================* . 530 . . 531 . +---------+ +---------+ . 532 . | Server1 | | Server2 | . 533 . |(s-ASBR1)| |(s-ASBR2)| . 534 . +--+------+ +-----+---+ . 535 . \ / . 536 . eBGP\ /eBGP . 537 . \ / . 538 . +---------+ +---------+ . 539 . | Relay1 | | Relay2 | . 540 . |(c-ASBR1)| |(c-ASBR2)| . 541 . +---+-----+ +----+----+ . 542 . +--------------+ . 543 . iBGP . 544 . . 545 . <------------- Internetworking Underlay -------------> . 546 ............................................................ 548 Figure 4: Optimized Route 550 The route optimization is accommodated by control message signaling 551 between the Proxies and ASBRs. When the Proxy nearest the source 552 sends a route optimization request, the request is forwarded toward 553 the Server and nearest the destination. If the request is authentic, 554 the destination Server provides the source Proxy with the address of 555 the destination Proxy so that unnecessary tunnel segments are 556 eliminated and direct Proxy-to-Proxy tunneling is enabled. At the 557 same time, the destination Server keeps track of the source Proxies 558 it has sent route optimization messages to so it can quickly update 559 them if network mobility or Quality of Service (QoS) conditions 560 change. 562 Note that route optimization can fail if Proxy1 cannot tunnel packets 563 directly to Proxy2 due to some form of blockage in the 564 Internetworking underlay such as filtering middle-boxes. It is also 565 necessary for Proxy1 to detect and adjust to failure of Proxy2 566 through receipt of a Server's IPv6 Neighbor Advertisement message 567 and/or Neighbor Unreachability Detection (NUD) [RFC4861]. Note also 568 that the Servers still maintain state so they can echo link QoS 569 update messages coming from the RANs to inform correspondents of QoS 570 changes (e.g., a link signal strength fading, a data link connection 571 loss, etc.). 573 Finally, each s-ASBR always has a default route and can therefore 574 always send packets via the dogleg route through a c-ASBR even if a 575 route optimized path has been established. The direct paths between 576 s-ASBRs and c-ASBRs are tunnels are maintained by BGP peering session 577 keepalives such that, if a link or an ASBR goes down, BGP will detect 578 the failure and readjust the routing tables. However, ASBRs and the 579 links that interconnect them are expected to be secured as highly- 580 available and fault tolerant critical infrastructure such that 581 peering session failures should be extremely rare. 583 6. BGP Protocol Considerations 585 The number of eBGP peering sessions that each c-ASBR must service is 586 proportional to the number of s-ASBRs in the system. Network 587 emulations with lightweight virtual machines have shown that a single 588 c-ASBR can service at least 100 eBGP peerings from s-ASBRs that each 589 advertise 10K MNP routes (i.e., 1M total). It is expected that 590 robust c-ASBRs can service many more peerings than this - possibly by 591 multiple orders of magnitude. But even assuming a conservative 592 limit, the number of s-ASBRs could be increased by also increasing 593 the number of c-ASBRs. Since c-ASBRs also peer with each other using 594 iBGP, however, larger-scale c-ASBR deployments may need to employ an 595 adjunct facility such as BGP Route Reflectors (RRs)[RFC4456]. 597 The number of aircraft in operation at a given time worldwide is 598 likely to be significantly less than 1M, but we will assume this 599 number for a worst-case analysis. Assuming a worst-case average 1 600 hour flight profile from gate-to-gate with 10 Server transitions per 601 flight, the entire system will need to service at most 10M BGP 602 updates per hour (2778 updates per second). This number is within 603 the realm of the peak BGP update messaging seen in the global public 604 Internet today [BGP2]. Assuming a BGP update message size of 100 605 bytes (800bits), the total amount of BGP control message traffic to a 606 single c-ASBR will be less than 2.5Mbps which is a nominal rate for 607 modern data links. 609 Industry standard BGP routers provide configurable parameters with 610 conservative default values. For example, the default hold time is 611 90 seconds, the default keepalive time is 1/3 of the hold time, and 612 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 613 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 614 For the simple mobile routing system described herein, these 615 parameters can and should be set to more aggressive values to support 616 faster neighbor/link failure detection and faster routing protocol 617 convergence times. For example, a hold time of 3 seconds and a 618 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 620 C-ASBRs will be using EBGP both in the ATN/IPS and the 621 Internetworking Underlay with the ATN/IPS unicast IPv6 routes 622 resolving over Internetworking Underlay routes. Consequently, 623 c-ASBRs and potentially s-ASBRs will need to support separate local 624 ASes for the two BGP routing domains and routing policy or assure 625 routes are not propagated between the two BGP routing domains. From 626 a conceptual and operational standpoint, the implementation should 627 provide isolation between the two BGP routing domains (e.g., separate 628 BGP instances). 630 7. Implementation Status 632 The BGP routing topology described in this document has been modeled 633 in realistic network emulations showing that at least 1 million MNPs 634 can be propagated to each c-ASBR even on lightweight virtual 635 machines. No BGP routing protocol extensions need to be adopted. 637 8. IANA Considerations 639 This document does not introduce any IANA considerations. 641 9. Security Considerations 643 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 644 profiles as for any Internet nodes. For this reason, ASBRs should 645 employ physical security and/or IP securing mechanisms such as IPsec 646 [RFC4301], TLS [RFC5246], etc. 648 ATN/IPS ASBRs present targets for Distributed Denial of Service 649 (DDoS) attacks. This concern is no different than for any node on 650 the open Internet, where attackers could send spoofed packets to the 651 node at high data rates. This can be mitigated by connecting ATN/IPS 652 ASBRs over dedicated links with no connections to the Internet and/or 653 when ASBR connections to the Internet are only permitted through 654 well-managed firewalls. 656 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 657 aviation data links from receiving DDoS packet floods. 659 This document does not include any new specific requirements for 660 mitigation of DDoS. 662 10. Acknowledgements 664 This work is aligned with the FAA as per the SE2025 contract number 665 DTFAWA-15-D-00030. 667 This work is aligned with the NASA Safe Autonomous Systems Operation 668 (SASO) program under NASA contract number NNA16BD84C. 670 This work is aligned with the Boeing Information Technology (BIT) 671 MobileNet program. 673 11. References 675 11.1. Normative References 677 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 678 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 679 DOI 10.17487/RFC4271, January 2006, 680 . 682 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 683 Control Message Protocol (ICMPv6) for the Internet 684 Protocol Version 6 (IPv6) Specification", STD 89, 685 RFC 4443, DOI 10.17487/RFC4443, March 2006, 686 . 688 [RFC4451] McPherson, D. and V. Gill, "BGP MULTI_EXIT_DISC (MED) 689 Considerations", RFC 4451, DOI 10.17487/RFC4451, March 690 2006, . 692 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 693 Reflection: An Alternative to Full Mesh Internal BGP 694 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 695 . 697 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 698 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 699 DOI 10.17487/RFC4861, September 2007, 700 . 702 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 703 (IPv6) Specification", STD 86, RFC 8200, 704 DOI 10.17487/RFC8200, July 2017, 705 . 707 11.2. Informative References 709 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 710 2016. 712 [BGP2] Huston, G., "BGP Instability Report, 713 http://bgpupdates.potaroo.net/instability/bgpupd.html", 714 May 2017. 716 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 717 Protocol (BGP), http://www.quark.net/docs/ 718 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 720 [I-D.ietf-lisp-ddt] 721 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 722 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 723 ddt-09 (work in progress), January 2017. 725 [I-D.templin-aerolink] 726 Templin, F., "Asymmetric Extended Route Optimization 727 (AERO)", draft-templin-aerolink-81 (work in progress), 728 February 2018. 730 [ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx", 731 February 2017. 733 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 734 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 735 DOI 10.17487/RFC2784, March 2000, 736 . 738 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 739 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 740 December 2005, . 742 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 743 (TLS) Protocol Version 1.2", RFC 5246, 744 DOI 10.17487/RFC5246, August 2008, 745 . 747 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 748 "Locator/ID Separation Protocol Alternative Logical 749 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 750 January 2013, . 752 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 753 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 754 2013, . 756 Authors' Addresses 758 Fred L. Templin (editor) 759 Boeing Research & Technology 760 P.O. Box 3707 761 Seattle, WA 98124 762 USA 764 Email: fltemplin@acm.org 766 Greg Saccone 767 Boeing Research & Technology 768 P.O. Box 3707 769 Seattle, WA 98124 770 USA 772 Email: gregory.t.saccone@boeing.com 774 Gaurav Dawra 775 LinkedIn 776 USA 778 Email: gdawra.ietf@gmail.com 780 Acee Lindem 781 Cisco Systems, Inc. 782 USA 784 Email: acee@cisco.com