idnits 2.17.1 draft-templin-atn-bgp-07.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 (May 31, 2018) is 2157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: December 2, 2018 G. Dawra 6 LinkedIn 7 A. Lindem 8 Cisco Systems, Inc. 9 May 31, 2018 11 A Simple BGP-based Mobile Routing System for the Aeronautical 12 Telecommunications Network 13 draft-templin-atn-bgp-07.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 December 2, 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 Radio Access Network (RAN) Model . . . . . . . . . . 9 66 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 11 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 [RFC8200] 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 an 94 approach based on the Border Gateway Protocol (BGP) [RFC4271]. 96 Aircraft communicate via wireless aviation data links that typically 97 support much lower data rates than terrestrial wireless and wired- 98 line communications. For example, some Very High Frequency (VHF)- 99 based data links only support data rates on the order of 32Kbps and 100 an emerging L-Band data link that is expected to play a key role in 101 future aeronautical communications only supports rates on the order 102 of 1Mbps. Although satellite data links can provide much higher data 103 rates during optimal conditions, like any other aviation data link 104 they are subject to errors, delay, disruption, signal intermittence, 105 degradation due to atmospheric conditions, etc. The well-connected 106 ground domain ATN/IPS network should therefore treat each safety-of- 107 flight critical packet produced by (or destined to) an aircraft as a 108 precious commodity and strive for an optimized service that provides 109 the highest possible degree of reliability. 111 The ATN/IPS is an IPv6-based overlay network that assumes a worldwide 112 connected Internetworking underlay for carrying tunneled ATM 113 communications. The Internetworking underlay could be manifested as 114 a private collection of long-haul backbone links (e.g., fiberoptics, 115 copper, SATCOM, etc.) interconnected by high-performance networking 116 gear such as bridges, switches, and routers. Such a private network 117 would need to connect all ATN/IPS participants worldwide, and could 118 therefore present a considerable cost for a large-scale deployment of 119 new infrastructure. Alternatively, the ATN/IPS could be deployed as 120 a secured overlay over the existing global public Internet. For 121 example, ATN/IPS nodes could be deployed as part of an SD-WAN or an 122 MPLS-WAN that rides over the public Internet via secured tunnels. 124 The ATN/IPS further assumes that each aircraft will receive an IPv6 125 Mobile Network Prefix (MNP) that accompanies the aircraft wherever it 126 travels. ATCs and AOCs will likewise receive IPv6 prefixes, but they 127 would typically appear in static (not mobile) deployments such as air 128 traffic control towers, airline headquarters, etc. Throughout the 129 rest of this document, we therefore use the term "MNP" when 130 discussing an IPv6 prefix that is delegated to any ATN/IPS end 131 system, including ATCs, AOCs, and aircraft. We also use the term 132 Mobility Service Prefix (MSP) to refer to an aggregated prefix 133 assigned to the ATN/IPS by an Internet assigned numbers authority, 134 and from which all MNPs are delegated (e.g., up to 2**32 IPv6 /64 135 MNPs could be delegated from the MSP 2001:db8::/32). 137 Connexion By Boeing [CBB] was an early aviation mobile routing 138 service based on dynamic updates in the global public Internet BGP 139 routing system. Practical experience with the approach has shown 140 that frequent injections and withdrawals of MNPs in the Internet 141 routing system can result in excessive BGP update messaging, slow 142 routing table convergence times, and extended outages when no route 143 is available. This is due to both conservative default BGP protocol 144 timing parameters (see Section 6) and the complex peering 145 interconnections of BGP routers within the global Internet 146 infrastructure. The situation is further exacerbated by frequent 147 aircraft mobility events that each result in BGP updates that must be 148 propagated to all BGP routers in the Internet that carry a full 149 routing table. 151 We therefore consider an approach using a BGP overlay network routing 152 system where a private BGP routing protocol instance is maintained 153 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 154 private BGP instance does not interact with the native BGP routing 155 system in the connected Internetworking underlay, and BGP updates are 156 unidirectional from "stub" ASBRs (s-ASBRs) to a small set of "core" 157 ASBRs (c-ASBRs) in a hub-and-spokes topology. No extensions to the 158 BGP protocol are necessary. 160 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 161 dedicated high speed links and/or tunnels across the Internetworking 162 underlay using industry-standard encapsulations (e.g., Generic 163 Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). In 164 particular, tunneling must be used when neighboringing ASBRs are 165 separated by many Internetworking underlay hops. 167 The s-ASBRs engage in external BGP (eBGP) peerings with their 168 respective c-ASBRs, and only maintain routing table entries for the 169 MNPs currently active within the stub AS. The s-ASBRs send BGP 170 updates for MNP injections or withdrawals to c-ASBRs but do not 171 receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 172 default routes with their c-ASBRs as the next hop, and therefore hold 173 only partial topology information. 175 The c-ASBRs connect to other c-ASBRs using internal BGP (iBGP) 176 peerings over which they collaboratively maintain a full routing 177 table for all active MNPs currently in service. Therefore, only the 178 c-ASBRs maintain a full BGP routing table and never send any BGP 179 updates to s-ASBRs. This simple routing model therefore greatly 180 reduces the number of BGP updates that need to be synchronized among 181 peers, and the number is reduced further still when intradomain 182 routing changes within stub ASes are processed within the AS instead 183 of being propagated to the core. BGP Route Reflectors (RRs) 184 [RFC4456] can also be used to support increased scaling properties. 186 The remainder of this document discusses the proposed BGP-based ATN/ 187 IPS mobile routing service. 189 2. Terminology 191 The terms Autonomous System (AS) and Autonomous System Border Router 192 (ASBR) are the same as defined in [RFC4271]. 194 The following terms are defined for the purposes of this document: 196 Air Traffic Managemnet (ATM) 197 The worldwide service for coordinating safe aviation operations. 199 Air Traffic Controller (ATC) 200 A government agent responsible for coordinating with aircraft 201 within a defined operational region via voice and/or data Command 202 and Control messaging. 204 Airline Operations Controller (AOC) 205 An airline agent responsible for tracking and coordinating with 206 aircraft within their fleet. 208 Aeronautical Telecommunications Network with Internet Protocol 209 Services (ATN/IPS) 210 A future aviation network for ATCs and AOCs to coordinate with all 211 aircraft operating worldwide. The ATN/IPS will be an IPv6-based 212 overlay network service that connects access networks via 213 tunneling over an Internetworking underlay. 215 Internetworking underlay A connected wide-area network that supports 216 overlay network tunneling and connects Radio Access Networks to 217 the rest of the ATN/IPS. 219 Radio Access Network (RAN) 220 An aviation radio data link service provider's network, including 221 radio transmitters and receivers as well as suppporting ground- 222 domain infrastructure needed to convey a customer's data packets 223 to the outside world. The term RAN is intended in the same spirit 224 as for cellular operator networks and other radio-based Internet 225 service provider networks. For simplicity, we also use the term 226 RAN to refer to ground-domain networks that connect AOCs and ATCs 227 without any aviation radio communications. 229 Core Autonomous System Border Router (c-ASBR) A BGP router located 230 in the hub of the ATN/IPS hub-and-spokes overlay network topology. 232 Core Autonomous System The "hub" autonomous system maintained by all 233 c-ASBRs. 235 Stub Autonomous System Border Router (s-ASBR) A BGP router 236 configured as a spoke in the ATN/IPS hub-and-spokes overlay 237 network topology. 239 Stub Autonomous System A logical grouping that includes all Clients 240 currently associated with a given s-ASBR. 242 Client An ATC, AOC or aircraft that connects to the ATN/IPS as a 243 leaf node. The Client could be a singleton host, or a router that 244 connects a mobile network. 246 Proxy A node at the edge of a RAN that acts as an intermediary 247 between Clients and s-ASBRs. From the Client's perspective, the 248 Proxy presents the appearance that the Client is communicating 249 directly with the s-ASBR. From the s-ASBR's perspective, the 250 Proxy presents the appearance that the s-ASBR is communicating 251 directly with the Client. 253 Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any 254 ATN/IPS end system, including ATCs, AOCs, and aircraft. 256 Mobility Service Prefix (MSP) An aggregated prefix assigned to the 257 ATN/IPS by an Internet assigned numbers authority, and from which 258 all MNPs are delegated (e.g., up to 2**32 IPv6 /64 MNPs could be 259 delegated from the MSP 2001:db8::/32). 261 3. ATN/IPS Routing System 263 The proposed ATN/IPS routing system comprises a private BGP instance 264 coordinated in an overlay network via tunnels between neighboring 265 ASBRs over the Internetworking underlay. The overlay does not 266 interact with the native BGP routing system in the connected 267 undelying Internetwork, and each c-ASBR advertises only a small and 268 unchanging set of MSPs into the Internetworking underlay routing 269 system instead of the full dynamically changing set of MNPs. (For 270 example, when the Internetworking underlay is the global public 271 Internet the c-ASBRs advertise the MSPs in the public BGP Internet 272 routing system.) 274 In a reference deployment, one or more s-ASBRs connect each stub AS 275 to the overlay using a shared stub AS Number (ASN). Each s-ASBR 276 further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are 277 members of the same core AS, and use a shared core ASN. Since the 278 private BGP instance is separate from the global public Internet BGP 279 routing system, the ASBRs can use either a private ASN per [RFC6996] 280 or simply use public ASNs noting that the ASNs may overlap with those 281 already assigned in the Internet. (A third alternative would be to 282 procure globally-unique public ASNs, but cost and maintenance 283 requirements must be conisdered.) 285 The c-ASBRs use iBGP to maintain a synchronized consistent view of 286 all active MNPs currently in service. Figure 1 below represents the 287 reference deployment. (Note that the figure shows details for only 288 two s-ASBRs (s-ASBR1 and s-ASBR2) due to space constraints, but the 289 other s-ASBRs should be understood to have similar Stub AS, MNP and 290 eBGP peering arrangements.) The solution described in this document 291 is flexible enough to extend to these topologies. 293 ........................................................... 294 . . 295 . (:::)-. <- Stub ASes -> (:::)-. . 296 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 297 . `-(::::)-' `-(::::)-' . 298 . +-------+ +-------+ . 299 . |s-ASBR1+-----+ +-----+s-ASBR2| . 300 . +--+----+ eBGP \ / eBGP +-----+-+ . 301 . \ \/ / . 302 . \eBGP / \ /eBGP . 303 . \ / \ / . 304 . +-------+ +-------+ . 305 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 306 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 307 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 308 . +-------+ .-(::::::::) +-------+ . 309 . . .-(::::::::::::::)-. . . 310 . . (:::: Core AS :::) . . 311 . +-------+ `-(:::::::::::::)-' +-------+ . 312 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 313 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 314 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 315 . +-------+ +-------+ . 316 . / \ . 317 . /eBGP \eBGP . 318 . / \ . 319 . +---+---+ +-----+-+ . 320 . |s-ASBR | |s-ASBR | . 321 . +-------+ +-------+ . 322 . . 323 . . 324 . <------------ Internetworking Underlay --------------> . 325 ............................................................ 327 Figure 1: Reference Deployment 329 In the reference deployment, each s-ASBR maintains routes for active 330 MNPs that currently belong to its stub AS. In response to "Inter- 331 domain" mobility events, each s-ASBR will dynamically announces new 332 MNPs and withdraws departed MNPs in its eBGP updates to c-ASBRs. 333 Since ATN/IPS end systems are expected to remain within the same stub 334 AS for extended timeframes, however, intra-domain mobility events 335 (such as an aircraft handing off between cell towers) are handled 336 within the stub AS instead of being propagated as inter-domain eBGP 337 updates. 339 Each c-ASBR configures a black-hole route for each of its MSPs. By 340 black-holing the MSPs, the c-ASBR will maintain forwarding table 341 entries only for the MNPs that are currently active, and packets 342 destined to all other MNPs will correctly incur ICMPv6 Destination 343 Unreachable messages [RFC4443] due to the black hole route. (This is 344 the same behavior as for ordinary BGP routers in the Internet when 345 they receive packets for which there is no route available.) The 346 c-ASBRs do not send eBGP updates for MNPs to s-ASBRs, but instead 347 originate a default route. In this way, s-ASBRs have only partial 348 topology knowledge (i.e., they know only about the active MNPs 349 currently within their stub ASes) and they forward all other packets 350 to c-ASBRs which have full topology knowledge. 352 Scaling properties of this ATN/IPS routing system are limited by the 353 number of BGP routes that can be carried by the c-ASBRs. A 2015 354 study showed that BGP routers in the global public Internet at that 355 time carried more than 500K routes with linear growth and no signs of 356 router resource exhaustion [BGP]. A more recent network emulation 357 study also showed that a single c-ASBR can accommodate at least 1M 358 dynamically changing BGP routes even on a lightweight virtual 359 machine. Commercially-available high-performance dedicated router 360 hardware can support many millions of routes. 362 Therefore, assuming each c-ASBR can carry 1M or more routes, this 363 means that at least 1M ATN/IPS end system MNPs can be serviced by a 364 single set of c-ASBRs and that number could be furhter increased by 365 using RRs. Another means of increasing scale would be to assign a 366 different set of c-ASBRs for each set of MSPs. In that case, each 367 s-ASBR still peers with one or more c-ASBRs from each set of c-ASBRs, 368 but the s-ASBR institutes route filters so that it only sends BGP 369 updates to the specific set of c-ASBRs that aggregate the MSP. For 370 example, if the MSP for the ATN/IPS deployment is 2001:db8::/32, a 371 first set of c-ASBRs could service the MSP segment 2001:db8::/40, a 372 second set could service 2001:db8:0100::/40, a third set could 373 service 2001:db8:0200::/40, etc. 375 In this way, each set of c-ASBRs services a specific set of MSPs that 376 they inject into the Internetworking underlay native routing system, 377 and each s-ASBR configures MSP-specific routes that list the correct 378 set of c-ASBRs as next hops. This BGP routing design also allows for 379 natural incremental deployment, and can support initial small-scale 380 deployments followed by dynamic deployment of additional ATN/IPS 381 infrastructure elements without disturbing the already-deployed base. 383 4. ATN/IPS Radio Access Network (RAN) Model 385 Radio Access Networks (RANs) connect end system Clients such as 386 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 387 connect to multiple RANs at once, for example, when they have both 388 satellite and cellular data links activated simultaneously. Clients 389 may further move between RANs in a manner that is perceived as a 390 network layer mobility event. Clients could therefore employ a 391 multilink/mobility routing service such as that discussed in 392 [I-D.templin-aerolink]. 394 Clients register all of their active data link connections with their 395 serving s-ASBRs as discussed in Section 3. Clients may connect to 396 s-ASBRs either directly, or via a Proxy at the edge of the RAN. 398 Figure 2 shows the ATN/IPS RAN model where Clients connect to RANs 399 via aviation data links. Clients register their RAN addresses with a 400 nearby s-ASBR, where the registration process may be brokered by a 401 Proxy at the edge of the RAN. 403 Data Link "A" +--------+ Data Link "B" 404 +----------- | Client |-----------+ 405 / +--------+ \ 406 / \ 407 / \ 408 (:::)-. (:::)-. 409 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 410 `-(::::)-' `-(::::)-' 411 +-------+ +-------+ 412 ... | Proxy | ............................ | Proxy | ... 413 . +-------+ +-------+ . 414 . ^^ ^^ . 415 . || || . 416 . || +--------+ || . 417 . ++============> | s-ASBR | <============++ . 418 . +--------+ . 419 . | eBGP . 420 . (:::)-. . 421 . .-(::::::::) . 422 . .-(::: ATN/IPS :::)-. . 423 . (::::: BGP Routing ::::) . 424 . `-(:: System ::::)-' . 425 . `-(:::::::-' . 426 . . 427 . . 428 . <------------- Internetworking Underlay -------------> . 429 ............................................................ 431 Figure 2: ATN/IPS RAN Architecture 433 When a Client logs into a RAN, it specifies a nearby s-ASBR that it 434 has selected to connect to the ATN/IPS. The login process is 435 brokered by a Proxy at the border of the RAN, which then conveys the 436 connection request to the s-ASBR via tunneling across the 437 Internetworking underlay. The s-ASBR then registers the address of 438 the Proxy as the address for the Client, and the Proxy forwards the 439 s-ASBR's reply to the Client. If the Client connects to multiple 440 RANs, the s-ASBR will register the addresses of all Proxies as 441 addresses through which the Client can be reached. 443 The s-ASBR represents all of its active Clients as MNP routes in the 444 ATN/IPS BGP routing system. The s-ASBR's stub AS therefore consists 445 of the set of all of its active Clients (i.e., the stub AS is a 446 logical construct and not a physical construct). The s-ASBR injects 447 the MNPs of its active Clients and withdraws the MNPs of its departed 448 Clients via BGP updates to c-ASBRs. Since Clients are expected to 449 remain associated with their current s-ASBR for extended periods, the 450 level of MNP injections and withdrawals in the BGP routing system 451 will be on the order of the numbers of network joins, leaves and 452 s-ASBR handovers for aircraft operations (see: Section 6). It is 453 important to observe that fine-grained events such as Client mobility 454 and Quality of Service (QoS) signaling are coordinated only by 455 Proxies and the Client's current s-ASBRs, and do not involve other 456 ASBRs in the routing system. In this way, intradomain routing 457 changes within the stub AS are not propagated into the rest of the 458 ATN/IPS BGP routing system. 460 5. ATN/IPS Route Optimization 462 ATN/IPS end systems will frequently need to communicate with 463 correspondents associated with other s-ASBRs. In the BGP peering 464 topology discussed in Section 3, this can initially only be 465 accommodated by including multiple tunnel segments in the forwarding 466 path. In many cases, it would be desirable to eliminate extraneous 467 tunnel segments from this "dogleg" route so that packets can traverse 468 a minimum number of tunneling hops across the Internetworking 469 underlay. ATN/IPS end systems could therefore employ a route 470 optimization service such as that discussed in 471 [I-D.templin-aerolink]. 473 A route optimization example is shown in Figure 3 and Figure 4 below. 474 In the first figure, multiple tunneled segments between Proxys and 475 ASBRs are necessary to convey packets between Clients associted with 476 different s-ASBRs. In the second figure, the optimized route tunnels 477 packets directly between Proxys without involving the ASBRs. 479 +---------+ +---------+ 480 | Client1 | | Client2 | 481 +---v-----+ +-----^---+ 482 * * 483 * * 484 (:::)-. (:::)-. 485 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 486 `-(::::)-' `-(::::)-' 487 +--------+ +--------+ 488 ... | Proxy1 | .......................... | Proxy2 | ... 489 . +--------+ +--------+ . 490 . ** ** . 491 . ** ** . 492 . ** ** . 493 . +---------+ +---------+ . 494 . | s-ASBR1 | | s-ASBR2 | . 495 . +--+------+ +-----+---+ . 496 . \ ** Dogleg ** / . 497 . eBGP\ ** Route ** /eBGP . 498 . \ **==============** / . 499 . +---------+ +---------+ . 500 . | c-ASBR1 | | c-ASBR2 | . 501 . +---+-----+ +----+----+ . 502 . +--------------+ . 503 . iBGP . 504 . . 505 . <------------- Internetworking Underlay -------------> . 506 ............................................................ 508 Figure 3: Dogleg Route Before Optimization 510 +---------+ +---------+ 511 | Client1 | | Client2 | 512 +---v-----+ +-----^---+ 513 * * 514 * * 515 (:::)-. (:::)-. 516 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 517 `-(::::)-' `-(::::)-' 518 +--------+ +--------+ 519 ... | Proxy1 | .......................... | Proxy2 | ... 520 . +------v-+ +--^-----+ . 521 . * * . 522 . *================================* . 523 . . 524 . +---------+ +---------+ . 525 . | s-ASBR1 | | s-ASBR2 | . 526 . +--+------+ +-----+---+ . 527 . \ / . 528 . eBGP\ /eBGP . 529 . \ / . 530 . +---------+ +---------+ . 531 . | c-ASBR1 | | c-ASBR2 | . 532 . +---+-----+ +----+----+ . 533 . +--------------+ . 534 . iBGP . 535 . . 536 . <------------- Internetworking Underlay -------------> . 537 ............................................................ 539 Figure 4: Optimized Route 541 6. BGP Protocol Considerations 543 The number of eBGP peering sessions that each c-ASBR must service is 544 proportional to the number of s-ASBRs in the system. Network 545 emulations with lightweight virtual machines have shown that a single 546 c-ASBR can service at least 100 eBGP peerings from s-ASBRs that each 547 advertise 10K MNP routes (i.e., 1M total). It is expected that 548 robust c-ASBRs can service many more peerings than this - possibly by 549 multiple orders of magnitude. But even assuming a conservative 550 limit, the number of s-ASBRs could be increased by also increasing 551 the number of c-ASBRs. Since c-ASBRs also peer with each other using 552 iBGP, however, larger-scale c-ASBR deployments may need to employ an 553 adjunct facility such as BGP Route Reflectors (RRs)[RFC4456]. 555 The number of aircraft in operation at a given time worldwide is 556 likely to be significantly less than 1M, but we will assume this 557 number for a worst-case analysis. Assuming a worst-case average 1 558 hour flight profile from gate-to-gate with 10 service region 559 transitions per flight, the entire system will need to service at 560 most 10M BGP updates per hour (2778 updates per second). This number 561 is within the realm of the peak BGP update messaging seen in the 562 global public Internet today [BGP2]. Assuming a BGP update message 563 size of 100 bytes (800bits), the total amount of BGP control message 564 traffic to a single c-ASBR will be less than 2.5Mbps which is a 565 nominal rate for modern data links. 567 Industry standard BGP routers provide configurable parameters with 568 conservative default values. For example, the default hold time is 569 90 seconds, the default keepalive time is 1/3 of the hold time, and 570 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 571 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 572 For the simple mobile routing system described herein, these 573 parameters can and should be set to more aggressive values to support 574 faster neighbor/link failure detection and faster routing protocol 575 convergence times. For example, a hold time of 3 seconds and a 576 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 578 Each c-ASBR will be using eBGP both in the ATN/IPS and the 579 Internetworking Underlay with the ATN/IPS unicast IPv6 routes 580 resolving over Internetworking Underlay routes. Consequently, 581 c-ASBRs and potentially s-ASBRs will need to support separate local 582 ASes for the two BGP routing domains and routing policy or assure 583 routes are not propagated between the two BGP routing domains. From 584 a conceptual and operational standpoint, the implementation should 585 provide isolation between the two BGP routing domains (e.g., separate 586 BGP instances). 588 7. Implementation Status 590 The BGP routing topology described in this document has been modeled 591 in realistic network emulations showing that at least 1 million MNPs 592 can be propagated to each c-ASBR even on lightweight virtual 593 machines. No BGP routing protocol extensions need to be adopted. 595 8. IANA Considerations 597 This document does not introduce any IANA considerations. 599 9. Security Considerations 601 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 602 profiles as for any Internet nodes. For this reason, ASBRs should 603 employ physical security and/or IP securing mechanisms such as IPsec 604 [RFC4301], TLS [RFC5246], etc. 606 ATN/IPS ASBRs present targets for Distributed Denial of Service 607 (DDoS) attacks. This concern is no different than for any node on 608 the open Internet, where attackers could send spoofed packets to the 609 node at high data rates. This can be mitigated by connecting ATN/IPS 610 ASBRs over dedicated links with no connections to the Internet and/or 611 when ASBR connections to the Internet are only permitted through 612 well-managed firewalls. 614 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 615 aviation data links from receiving DDoS packet floods. 617 This document does not include any new specific requirements for 618 mitigation of DDoS. 620 10. Acknowledgements 622 This work is aligned with the FAA as per the SE2025 contract number 623 DTFAWA-15-D-00030. 625 This work is aligned with the NASA Safe Autonomous Systems Operation 626 (SASO) program under NASA contract number NNA16BD84C. 628 This work is aligned with the Boeing Information Technology (BIT) 629 MobileNet program. 631 11. References 633 11.1. Normative References 635 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 636 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 637 DOI 10.17487/RFC4271, January 2006, 638 . 640 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 641 Control Message Protocol (ICMPv6) for the Internet 642 Protocol Version 6 (IPv6) Specification", STD 89, 643 RFC 4443, DOI 10.17487/RFC4443, March 2006, 644 . 646 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 647 Reflection: An Alternative to Full Mesh Internal BGP 648 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 649 . 651 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 652 (IPv6) Specification", STD 86, RFC 8200, 653 DOI 10.17487/RFC8200, July 2017, 654 . 656 11.2. Informative References 658 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 659 2016. 661 [BGP2] Huston, G., "BGP Instability Report, 662 http://bgpupdates.potaroo.net/instability/bgpupd.html", 663 May 2017. 665 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 666 Protocol (BGP), http://www.quark.net/docs/ 667 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 669 [I-D.templin-aerolink] 670 Templin, F., "Asymmetric Extended Route Optimization 671 (AERO)", draft-templin-aerolink-82 (work in progress), May 672 2018. 674 [ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx", 675 February 2017. 677 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 678 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 679 DOI 10.17487/RFC2784, March 2000, 680 . 682 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 683 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 684 December 2005, . 686 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 687 (TLS) Protocol Version 1.2", RFC 5246, 688 DOI 10.17487/RFC5246, August 2008, 689 . 691 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 692 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 693 2013, . 695 Authors' Addresses 697 Fred L. Templin (editor) 698 Boeing Research & Technology 699 P.O. Box 3707 700 Seattle, WA 98124 701 USA 703 Email: fltemplin@acm.org 705 Greg Saccone 706 Boeing Research & Technology 707 P.O. Box 3707 708 Seattle, WA 98124 709 USA 711 Email: gregory.t.saccone@boeing.com 713 Gaurav Dawra 714 LinkedIn 715 USA 717 Email: gdawra.ietf@gmail.com 719 Acee Lindem 720 Cisco Systems, Inc. 721 USA 723 Email: acee@cisco.com