idnits 2.17.1 draft-ietf-rtgwg-atn-bgp-00.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 (August 30, 2018) is 2058 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: March 3, 2019 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 August 30, 2018 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-00.txt 16 Abstract 18 The International Civil Aviation Organization (ICAO) is investigating 19 mobile routing solutions for a worldwide Aeronautical 20 Telecommunications Network with Internet Protocol Services (ATN/IPS). 21 The ATN/IPS will eventually replace existing communication services 22 with an IPv6-based service supporting pervasive Air Traffic 23 Management (ATM) for Air Traffic Controllers (ATC), Airline 24 Operations Controllers (AOC), and all commercial aircraft worldwide. 25 This informational document describes a simple and extensible mobile 26 routing service based on industry-standard BGP to address the ATN/IPS 27 requirements. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 3, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 6 66 4. ATN/IPS Radio Access Network (RAN) Model . . . . . . . . . . 9 67 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 11 68 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 13 69 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 11.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 The worldwide Air Traffic Management (ATM) system today uses a 82 service known as Aeronautical Telecommunications Network based on 83 Open Systems Interconnection (ATN/OSI). The service is used to 84 augment controller to pilot voice communications with rudimentary 85 short text command and control messages. The service has seen 86 successful deployment in a limited set of worldwide ATM domains. 88 The International Civil Aviation Organization [ICAO] is now 89 undertaking the development of a next-generation replacement for ATN/ 90 OSI known as Aeronautical Telecommunications Network with Internet 91 Protocol Services (ATN/IPS). ATN/IPS will eventually provide an 92 IPv6-based [RFC8200] service supporting pervasive ATM for Air Traffic 93 Controllers (ATC), Airline Operations Controllers (AOC), and all 94 commercial aircraft worldwide. As part of the ATN/IPS undertaking, a 95 new mobile routing service will be needed. This document presents an 96 approach based on the Border Gateway Protocol (BGP) [RFC4271]. 98 Aircraft communicate via wireless aviation data links that typically 99 support much lower data rates than terrestrial wireless and wired- 100 line communications. For example, some Very High Frequency (VHF)- 101 based data links only support data rates on the order of 32Kbps and 102 an emerging L-Band data link that is expected to play a key role in 103 future aeronautical communications only supports rates on the order 104 of 1Mbps. Although satellite data links can provide much higher data 105 rates during optimal conditions, like any other aviation data link 106 they are subject to errors, delay, disruption, signal intermittence, 107 degradation due to atmospheric conditions, etc. The well-connected 108 ground domain ATN/IPS network should therefore treat each safety-of- 109 flight critical packet produced by (or destined to) an aircraft as a 110 precious commodity and strive for an optimized service that provides 111 the highest possible degree of reliability. 113 The ATN/IPS is an IPv6-based overlay network that assumes a worldwide 114 connected Internetworking underlay for carrying tunneled ATM 115 communications. The Internetworking underlay could be manifested as 116 a private collection of long-haul backbone links (e.g., fiber optics, 117 copper, SATCOM, etc.) interconnected by high-performance networking 118 gear such as bridges, switches, and routers. Such a private network 119 would need to connect all ATN/IPS participants worldwide, and could 120 therefore present a considerable cost for a large-scale deployment of 121 new infrastructure. Alternatively, the ATN/IPS could be deployed as 122 a secured overlay over the existing global public Internet. For 123 example, ATN/IPS nodes could be deployed as part of an SD-WAN or an 124 MPLS-WAN that rides over the public Internet via secured tunnels. 125 Further details of the Internetworking underlay design are out of 126 scope for this document. 128 The ATN/IPS further assumes that each aircraft will receive an IPv6 129 Mobile Network Prefix (MNP) that accompanies the aircraft wherever it 130 travels. ICAO is further proposing to assign each aircraft an entire 131 /56 MNP for numbering its on-board networks. ATCs and AOCs will 132 likewise receive IPv6 prefixes, but they would typically appear in 133 static (not mobile) deployments such as air traffic control towers, 134 airline headquarters, etc. Throughout the rest of this document, we 135 therefore use the term "MNP" when discussing an IPv6 prefix that is 136 delegated to any ATN/IPS end system, including ATCs, AOCs, and 137 aircraft. We also use the term Mobility Service Prefix (MSP) to 138 refer to an aggregated prefix assigned to the ATN/IPS by an Internet 139 assigned numbers authority, and from which all MNPs are delegated 140 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from an IPv6 /24 141 MSP). 143 Connexion By Boeing [CBB] was an early aviation mobile routing 144 service based on dynamic updates in the global public Internet BGP 145 routing system. Practical experience with the approach has shown 146 that frequent injections and withdrawals of MNPs in the Internet 147 routing system can result in excessive BGP update messaging, slow 148 routing table convergence times, and extended outages when no route 149 is available. This is due to both conservative default BGP protocol 150 timing parameters (see Section 6) and the complex peering 151 interconnections of BGP routers within the global Internet 152 infrastructure. The situation is further exacerbated by frequent 153 aircraft mobility events that each result in BGP updates that must be 154 propagated to all BGP routers in the Internet that carry a full 155 routing table. 157 We therefore consider an approach using a BGP overlay network routing 158 system where a private BGP routing protocol instance is maintained 159 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 160 private BGP instance does not interact with the native BGP routing 161 system in the connected Internetworking underlay, and BGP updates are 162 unidirectional from "stub" ASBRs (s-ASBRs) to a small set of "core" 163 ASBRs (c-ASBRs) in a hub-and-spokes topology. No extensions to the 164 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.). In 170 particular, tunneling must be used when neighboring ASBRs are 171 separated by many Internetworking underlay hops. 173 The s-ASBRs engage in external BGP (eBGP) peerings with their 174 respective c-ASBRs, and only maintain routing table entries for the 175 MNPs currently active within the stub AS. The s-ASBRs send BGP 176 updates for MNP injections or withdrawals to c-ASBRs but do not 177 receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 178 default routes with their c-ASBRs as the next hop, and therefore hold 179 only partial topology information. 181 The c-ASBRs connect to other c-ASBRs using internal BGP (iBGP) 182 peerings over which they collaboratively maintain a full routing 183 table for all active MNPs currently in service. Therefore, only the 184 c-ASBRs maintain a full BGP routing table and never send any BGP 185 updates to s-ASBRs. This simple routing model therefore greatly 186 reduces the number of BGP updates that need to be synchronized among 187 peers, and the number is reduced further still when intradomain 188 routing changes within stub ASes are processed within the AS instead 189 of being propagated to the core. BGP Route Reflectors (RRs) 190 [RFC4456] can also be used to support increased scaling properties. 192 The remainder of this document discusses the proposed BGP-based ATN/ 193 IPS mobile routing service. 195 2. Terminology 197 The terms Autonomous System (AS) and Autonomous System Border Router 198 (ASBR) are the same as defined in [RFC4271]. 200 The following terms are defined for the purposes of this document: 202 Air Traffic Management (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 supporting 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 the ATN/IPS hub-and-spokes overlay network topology. 238 Core Autonomous System The "hub" autonomous system maintained by all 239 c-ASBRs. 241 Stub Autonomous System Border Router (s-ASBR) A BGP router 242 configured as a spoke in the ATN/IPS hub-and-spokes overlay 243 network topology. 245 Stub Autonomous System A logical grouping that includes all Clients 246 currently associated with a given s-ASBR. 248 Client An ATC, AOC or aircraft that connects to the ATN/IPS as a 249 leaf node. The Client could be a singleton host, or a router that 250 connects a mobile network. 252 Proxy A node at the edge of a RAN that acts as an intermediary 253 between Clients and s-ASBRs. From the Client's perspective, the 254 Proxy presents the appearance that the Client is communicating 255 directly with the s-ASBR. From the s-ASBR's perspective, the 256 Proxy presents the appearance that the s-ASBR is communicating 257 directly with the Client. 259 Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any 260 ATN/IPS end system, including ATCs, AOCs, and aircraft. 262 Mobility Service Prefix (MSP) An aggregated prefix assigned to the 263 ATN/IPS by an Internet assigned numbers authority, and from which 264 all MNPs are delegated (e.g., up to 2**32 IPv6 /56 MNPs could be 265 delegated from a /24 MSP). 267 3. ATN/IPS Routing System 269 The proposed ATN/IPS routing system comprises a private BGP instance 270 coordinated in an overlay network via tunnels between neighboring 271 ASBRs over the Internetworking underlay. The overlay does not 272 interact with the native BGP routing system in the connected 273 underlying Internetwork, and each c-ASBR advertises only a small and 274 unchanging set of MSPs into the Internetworking underlay routing 275 system instead of the full dynamically changing set of MNPs. (For 276 example, when the Internetworking underlay is the global public 277 Internet the c-ASBRs advertise the MSPs in the public BGP Internet 278 routing system.) 280 In a reference deployment, one or more s-ASBRs connect each stub AS 281 to the overlay using a shared stub AS Number (ASN). Each s-ASBR 282 further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are 283 members of the same core AS, and use a shared core ASN. Globally- 284 unique public ASNs could be assigned, e.g., either according to the 285 standard 16-bit ASN format or the 32-bit ASN scheme defined in 286 [RFC6793]. 288 The c-ASBRs use iBGP to maintain a synchronized consistent view of 289 all active MNPs currently in service. Figure 1 below represents the 290 reference deployment. (Note that the figure shows details for only 291 two s-ASBRs (s-ASBR1 and s-ASBR2) due to space constraints, but the 292 other s-ASBRs should be understood to have similar Stub AS, MNP and 293 eBGP peering arrangements.) The solution described in this document 294 is flexible enough to extend to these topologies. 296 ........................................................... 297 . . 298 . (:::)-. <- Stub ASes -> (:::)-. . 299 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 300 . `-(::::)-' `-(::::)-' . 301 . +-------+ +-------+ . 302 . |s-ASBR1+-----+ +-----+s-ASBR2| . 303 . +--+----+ eBGP \ / eBGP +-----+-+ . 304 . \ \/ / . 305 . \eBGP / \ /eBGP . 306 . \ / \ / . 307 . +-------+ +-------+ . 308 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 309 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 310 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 311 . +-------+ .-(::::::::) +-------+ . 312 . . .-(::::::::::::::)-. . . 313 . . (:::: Core AS :::) . . 314 . +-------+ `-(:::::::::::::)-' +-------+ . 315 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 316 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 317 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 318 . +-------+ +-------+ . 319 . / \ . 320 . /eBGP \eBGP . 321 . / \ . 322 . +---+---+ +-----+-+ . 323 . |s-ASBR | |s-ASBR | . 324 . +-------+ +-------+ . 325 . . 326 . . 327 . <------------ Internetworking Underlay --------------> . 328 ............................................................ 330 Figure 1: Reference Deployment 332 In the reference deployment, each s-ASBR maintains routes for active 333 MNPs that currently belong to its stub AS. In response to "Inter- 334 domain" mobility events, each s-ASBR will dynamically announces new 335 MNPs and withdraws departed MNPs in its eBGP updates to c-ASBRs. 337 Since ATN/IPS end systems are expected to remain within the same stub 338 AS for extended timeframes, however, intra-domain mobility events 339 (such as an aircraft handing off between cell towers) are handled 340 within the stub AS instead of being propagated as inter-domain eBGP 341 updates. 343 Each c-ASBR configures a black-hole route for each of its MSPs. By 344 black-holing the MSPs, the c-ASBR will maintain forwarding table 345 entries only for the MNPs that are currently active, and packets 346 destined to all other MNPs will correctly incur ICMPv6 Destination 347 Unreachable messages [RFC4443] due to the black hole route. (This is 348 the same behavior as for ordinary BGP routers in the Internet when 349 they receive packets for which there is no route available.) The 350 c-ASBRs do not send eBGP updates for MNPs to s-ASBRs, but instead 351 originate a default route. In this way, s-ASBRs have only partial 352 topology knowledge (i.e., they know only about the active MNPs 353 currently within their stub ASes) and they forward all other packets 354 to c-ASBRs which have full topology knowledge. 356 Scaling properties of this ATN/IPS routing system are limited by the 357 number of BGP routes that can be carried by the c-ASBRs. A 2015 358 study showed that BGP routers in the global public Internet at that 359 time carried more than 500K routes with linear growth and no signs of 360 router resource exhaustion [BGP]. A more recent network emulation 361 study also showed that a single c-ASBR can accommodate at least 1M 362 dynamically changing BGP routes even on a lightweight virtual 363 machine. Commercially-available high-performance dedicated router 364 hardware can support many millions of routes. 366 Therefore, assuming each c-ASBR can carry 1M or more routes, this 367 means that at least 1M ATN/IPS end system MNPs can be serviced by a 368 single set of c-ASBRs and that number could be further increased by 369 using RRs and/or more powerful routers. Another means of increasing 370 scale would be to assign a different set of c-ASBRs for each set of 371 MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs 372 from each set of c-ASBRs, but the s-ASBR institutes route filters so 373 that it only sends BGP updates to the specific set of c-ASBRs that 374 aggregate the MSP. In this way, each set of c-ASBRs maintains 375 separate routing and forwarding tables so that scaling is distributed 376 across multiple c-ASBR sets instead of concentrated in a single 377 c-ASBR set. For example, a first c-ASBR set could aggregate an MSP 378 segment A::/32, a second set could aggregate B::/32, a third could 379 aggregate C::/32, etc. The union of all MSP segments would then 380 constitute the collective MSP(s) for the entire ATN/IPS. 382 In this way, each set of c-ASBRs services a specific set of MSPs that 383 they inject into the Internetworking underlay native routing system, 384 and each s-ASBR configures MSP-specific routes that list the correct 385 set of c-ASBRs as next hops. This design also allows for natural 386 incremental deployment, and can support initial medium-scale 387 deployments followed by dynamic deployment of additional ATN/IPS 388 infrastructure elements without disturbing the already-deployed base. 389 For example, a few more c-ASBRs could be added if the MNP service 390 demand ever outgrows the initial deployment. 392 4. ATN/IPS Radio Access Network (RAN) Model 394 Radio Access Networks (RANs) connect end system Clients such as 395 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 396 connect to multiple RANs at once, for example, when they have both 397 satellite and cellular data links activated simultaneously. Clients 398 may further move between RANs in a manner that is perceived as a 399 network layer mobility event. Clients could therefore employ a 400 multilink/mobility routing service such as that discussed in 401 [I-D.templin-aerolink]. 403 Clients register all of their active data link connections with their 404 serving s-ASBRs as discussed in Section 3. Clients may connect to 405 s-ASBRs either directly, or via a Proxy at the edge of the RAN. 407 Figure 2 shows the ATN/IPS RAN model where Clients connect to RANs 408 via aviation data links. Clients register their RAN addresses with a 409 nearby s-ASBR, where the registration process may be brokered by a 410 Proxy at the edge of the RAN. 412 Data Link "A" +--------+ Data Link "B" 413 +----------- | Client |-----------+ 414 / +--------+ \ 415 / \ 416 / \ 417 (:::)-. (:::)-. 418 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 419 `-(::::)-' `-(::::)-' 420 +-------+ +-------+ 421 ... | Proxy | ............................ | Proxy | ... 422 . +-------+ +-------+ . 423 . ^^ ^^ . 424 . || || . 425 . || +--------+ || . 426 . ++============> | s-ASBR | <============++ . 427 . +--------+ . 428 . | eBGP . 429 . (:::)-. . 430 . .-(::::::::) . 431 . .-(::: ATN/IPS :::)-. . 432 . (::::: BGP Routing ::::) . 433 . `-(:: System ::::)-' . 434 . `-(:::::::-' . 435 . . 436 . . 437 . <------------- Internetworking Underlay -------------> . 438 ............................................................ 440 Figure 2: ATN/IPS RAN Architecture 442 When a Client logs into a RAN, it specifies a nearby s-ASBR that it 443 has selected to connect to the ATN/IPS. The login process is 444 brokered by a Proxy at the border of the RAN, which then conveys the 445 connection request to the s-ASBR via tunneling across the 446 Internetworking underlay. The s-ASBR then registers the address of 447 the Proxy as the address for the Client, and the Proxy forwards the 448 s-ASBR's reply to the Client. If the Client connects to multiple 449 RANs, the s-ASBR will register the addresses of all Proxies as 450 addresses through which the Client can be reached. 452 The s-ASBR represents all of its active Clients as MNP routes in the 453 ATN/IPS BGP routing system. The s-ASBR's stub AS therefore consists 454 of the set of all of its active Clients (i.e., the stub AS is a 455 logical construct and not a physical construct). The s-ASBR injects 456 the MNPs of its active Clients and withdraws the MNPs of its departed 457 Clients via BGP updates to c-ASBRs. Since Clients are expected to 458 remain associated with their current s-ASBR for extended periods, the 459 level of MNP injections and withdrawals in the BGP routing system 460 will be on the order of the numbers of network joins, leaves and 461 s-ASBR handovers for aircraft operations (see: Section 6). It is 462 important to observe that fine-grained events such as Client mobility 463 and Quality of Service (QoS) signaling are coordinated only by 464 Proxies and the Client's current s-ASBRs, and do not involve other 465 ASBRs in the routing system. In this way, intradomain routing 466 changes within the stub AS are not propagated into the rest of the 467 ATN/IPS BGP routing system. 469 5. ATN/IPS Route Optimization 471 ATN/IPS end systems will frequently need to communicate with 472 correspondents associated with other s-ASBRs. In the BGP peering 473 topology discussed in Section 3, this can initially only be 474 accommodated by including multiple tunnel segments in the forwarding 475 path. In many cases, it would be desirable to eliminate extraneous 476 tunnel segments from this "dogleg" route so that packets can traverse 477 a minimum number of tunneling hops across the Internetworking 478 underlay. ATN/IPS end systems could therefore employ a route 479 optimization service such as that discussed in 480 [I-D.templin-aerolink]. 482 A route optimization example is shown in Figure 3 and Figure 4 below. 483 In the first figure, multiple tunneled segments between Proxys and 484 ASBRs are necessary to convey packets between Clients associated with 485 different s-ASBRs. In the second figure, the optimized route tunnels 486 packets directly between Proxys without involving the ASBRs. 488 +---------+ +---------+ 489 | Client1 | | Client2 | 490 +---v-----+ +-----^---+ 491 * * 492 * * 493 (:::)-. (:::)-. 494 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 495 `-(::::)-' `-(::::)-' 496 +--------+ +--------+ 497 ... | Proxy1 | .......................... | Proxy2 | ... 498 . +--------+ +--------+ . 499 . ** ** . 500 . ** ** . 501 . ** ** . 502 . +---------+ +---------+ . 503 . | s-ASBR1 | | s-ASBR2 | . 504 . +--+------+ +-----+---+ . 505 . \ ** Dogleg ** / . 506 . eBGP\ ** Route ** /eBGP . 507 . \ **==============** / . 508 . +---------+ +---------+ . 509 . | c-ASBR1 | | c-ASBR2 | . 510 . +---+-----+ +----+----+ . 511 . +--------------+ . 512 . iBGP . 513 . . 514 . <------------- Internetworking Underlay -------------> . 515 ............................................................ 517 Figure 3: Dogleg Route Before Optimization 519 +---------+ +---------+ 520 | Client1 | | Client2 | 521 +---v-----+ +-----^---+ 522 * * 523 * * 524 (:::)-. (:::)-. 525 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 526 `-(::::)-' `-(::::)-' 527 +--------+ +--------+ 528 ... | Proxy1 | .......................... | Proxy2 | ... 529 . +------v-+ +--^-----+ . 530 . * * . 531 . *================================* . 532 . . 533 . +---------+ +---------+ . 534 . | s-ASBR1 | | s-ASBR2 | . 535 . +--+------+ +-----+---+ . 536 . \ / . 537 . eBGP\ /eBGP . 538 . \ / . 539 . +---------+ +---------+ . 540 . | c-ASBR1 | | c-ASBR2 | . 541 . +---+-----+ +----+----+ . 542 . +--------------+ . 543 . iBGP . 544 . . 545 . <------------- Internetworking Underlay -------------> . 546 ............................................................ 548 Figure 4: Optimized Route 550 6. BGP Protocol Considerations 552 The number of eBGP peering sessions that each c-ASBR must service is 553 proportional to the number of s-ASBRs in the system. Network 554 emulations with lightweight virtual machines have shown that a single 555 c-ASBR can service at least 100 eBGP peerings from s-ASBRs that each 556 advertise 10K MNP routes (i.e., 1M total). It is expected that 557 robust c-ASBRs can service many more peerings than this - possibly by 558 multiple orders of magnitude. But even assuming a conservative 559 limit, the number of s-ASBRs could be increased by also increasing 560 the number of c-ASBRs. Since c-ASBRs also peer with each other using 561 iBGP, however, larger-scale c-ASBR deployments may need to employ an 562 adjunct facility such as BGP Route Reflectors (RRs)[RFC4456]. 564 The number of aircraft in operation at a given time worldwide is 565 likely to be significantly less than 1M, but we will assume this 566 number for a worst-case analysis. Assuming a worst-case average 1 567 hour flight profile from gate-to-gate with 10 service region 568 transitions per flight, the entire system will need to service at 569 most 10M BGP updates per hour (2778 updates per second). This number 570 is within the realm of the peak BGP update messaging seen in the 571 global public Internet today [BGP2]. Assuming a BGP update message 572 size of 100 bytes (800bits), the total amount of BGP control message 573 traffic to a single c-ASBR will be less than 2.5Mbps which is a 574 nominal rate for modern data links. 576 Industry standard BGP routers provide configurable parameters with 577 conservative default values. For example, the default hold time is 578 90 seconds, the default keepalive time is 1/3 of the hold time, and 579 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 580 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 581 For the simple mobile routing system described herein, these 582 parameters can and should be set to more aggressive values to support 583 faster neighbor/link failure detection and faster routing protocol 584 convergence times. For example, a hold time of 3 seconds and a 585 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 587 Each c-ASBR will be using eBGP both in the ATN/IPS and the 588 Internetworking Underlay with the ATN/IPS unicast IPv6 routes 589 resolving over Internetworking Underlay routes. Consequently, 590 c-ASBRs and potentially s-ASBRs will need to support separate local 591 ASes for the two BGP routing domains and routing policy or assure 592 routes are not propagated between the two BGP routing domains. From 593 a conceptual and operational standpoint, the implementation should 594 provide isolation between the two BGP routing domains (e.g., separate 595 BGP instances). 597 7. Implementation Status 599 The BGP routing topology described in this document has been modeled 600 in realistic network emulations showing that at least 1 million MNPs 601 can be propagated to each c-ASBR even on lightweight virtual 602 machines. No BGP routing protocol extensions need to be adopted. 604 8. IANA Considerations 606 This document does not introduce any IANA considerations. 608 9. Security Considerations 610 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 611 profiles as for any Internet nodes. For this reason, ASBRs should 612 employ physical security and/or IP securing mechanisms such as IPsec 613 [RFC4301], TLS [RFC5246], etc. 615 ATN/IPS ASBRs present targets for Distributed Denial of Service 616 (DDoS) attacks. This concern is no different than for any node on 617 the open Internet, where attackers could send spoofed packets to the 618 node at high data rates. This can be mitigated by connecting ATN/IPS 619 ASBRs over dedicated links with no connections to the Internet and/or 620 when ASBR connections to the Internet are only permitted through 621 well-managed firewalls. 623 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 624 aviation data links from receiving DDoS packet floods. 626 This document does not include any new specific requirements for 627 mitigation of DDoS. 629 10. Acknowledgements 631 This work is aligned with the FAA as per the SE2025 contract number 632 DTFAWA-15-D-00030. 634 This work is aligned with the NASA Safe Autonomous Systems Operation 635 (SASO) program under NASA contract number NNA16BD84C. 637 This work is aligned with the Boeing Information Technology (BIT) 638 MobileNet program. 640 11. References 642 11.1. Normative References 644 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 645 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 646 DOI 10.17487/RFC4271, January 2006, 647 . 649 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 650 Control Message Protocol (ICMPv6) for the Internet 651 Protocol Version 6 (IPv6) Specification", STD 89, 652 RFC 4443, DOI 10.17487/RFC4443, March 2006, 653 . 655 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 656 Reflection: An Alternative to Full Mesh Internal BGP 657 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 658 . 660 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 661 (IPv6) Specification", STD 86, RFC 8200, 662 DOI 10.17487/RFC8200, July 2017, 663 . 665 11.2. Informative References 667 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 668 2016. 670 [BGP2] Huston, G., "BGP Instability Report, 671 http://bgpupdates.potaroo.net/instability/bgpupd.html", 672 May 2017. 674 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 675 Protocol (BGP), http://www.quark.net/docs/ 676 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 678 [I-D.templin-aerolink] 679 Templin, F., "Asymmetric Extended Route Optimization 680 (AERO)", draft-templin-aerolink-82 (work in progress), May 681 2018. 683 [ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx", 684 February 2017. 686 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 687 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 688 DOI 10.17487/RFC2784, March 2000, 689 . 691 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 692 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 693 December 2005, . 695 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 696 (TLS) Protocol Version 1.2", RFC 5246, 697 DOI 10.17487/RFC5246, August 2008, 698 . 700 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 701 Autonomous System (AS) Number Space", RFC 6793, 702 DOI 10.17487/RFC6793, December 2012, 703 . 705 Appendix A. Change Log 707 << RFC Editor - remove prior to publication >> 709 Status as of 08/30/2018: 711 o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp' 713 Authors' Addresses 715 Fred L. Templin (editor) 716 Boeing Research & Technology 717 P.O. Box 3707 718 Seattle, WA 98124 719 USA 721 Email: fltemplin@acm.org 723 Greg Saccone 724 Boeing Research & Technology 725 P.O. Box 3707 726 Seattle, WA 98124 727 USA 729 Email: gregory.t.saccone@boeing.com 731 Gaurav Dawra 732 LinkedIn 733 USA 735 Email: gdawra.ietf@gmail.com 737 Acee Lindem 738 Cisco Systems, Inc. 739 USA 741 Email: acee@cisco.com 743 Victor Moreno 744 Cisco Systems, Inc. 745 USA 747 Email: vimoreno@cisco.com