idnits 2.17.1 draft-ietf-rtgwg-atn-bgp-01.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 (January 11, 2019) is 1931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-26 == Outdated reference: A later version (-99) exists of draft-templin-intarea-6706bis-03 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 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: July 15, 2019 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 January 11, 2019 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-01.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 July 15, 2019. 46 Copyright Notice 48 Copyright (c) 2019 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. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 14 70 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 12.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 The worldwide Air Traffic Management (ATM) system today uses a 83 service known as Aeronautical Telecommunications Network based on 84 Open Systems Interconnection (ATN/OSI). The service is used to 85 augment controller to pilot voice communications with rudimentary 86 short text command and control messages. The service has seen 87 successful deployment in a limited set of worldwide ATM domains. 89 The International Civil Aviation Organization [ICAO] is now 90 undertaking the development of a next-generation replacement for ATN/ 91 OSI known as Aeronautical Telecommunications Network with Internet 92 Protocol Services (ATN/IPS). ATN/IPS will eventually provide an 93 IPv6-based [RFC8200] service supporting pervasive ATM for Air Traffic 94 Controllers (ATC), Airline Operations Controllers (AOC), and all 95 commercial aircraft worldwide. As part of the ATN/IPS undertaking, a 96 new mobile routing service will be needed. This document presents an 97 approach based on the Border Gateway Protocol (BGP) [RFC4271]. 99 Aircraft communicate via wireless aviation data links that typically 100 support much lower data rates than terrestrial wireless and wired- 101 line communications. For example, some Very High Frequency (VHF)- 102 based data links only support data rates on the order of 32Kbps and 103 an emerging L-Band data link that is expected to play a key role in 104 future aeronautical communications only supports rates on the order 105 of 1Mbps. Although satellite data links can provide much higher data 106 rates during optimal conditions, like any other aviation data link 107 they are subject to errors, delay, disruption, signal intermittence, 108 degradation due to atmospheric conditions, etc. The well-connected 109 ground domain ATN/IPS network should therefore treat each safety-of- 110 flight critical packet produced by (or destined to) an aircraft as a 111 precious commodity and strive for an optimized service that provides 112 the highest possible degree of reliability. 114 The ATN/IPS is an IPv6-based overlay network that assumes a worldwide 115 connected Internetworking underlay for carrying tunneled ATM 116 communications. The Internetworking underlay could be manifested as 117 a private collection of long-haul backbone links (e.g., fiber optics, 118 copper, SATCOM, etc.) interconnected by high-performance networking 119 gear such as bridges, switches, and routers. Such a private network 120 would need to connect all ATN/IPS participants worldwide, and could 121 therefore present a considerable cost for a large-scale deployment of 122 new infrastructure. Alternatively, the ATN/IPS could be deployed as 123 a secured overlay over the existing global public Internet. For 124 example, ATN/IPS nodes could be deployed as part of an SD-WAN or an 125 MPLS-WAN that rides over the public Internet via secured tunnels. 126 Further details of the Internetworking underlay design are out of 127 scope for this document. 129 The ATN/IPS further assumes that each aircraft will receive an IPv6 130 Mobile Network Prefix (MNP) that accompanies the aircraft wherever it 131 travels. ICAO is further proposing to assign each aircraft an entire 132 /56 MNP for numbering its on-board networks. ATCs and AOCs will 133 likewise receive IPv6 prefixes, but they would typically appear in 134 static (not mobile) deployments such as air traffic control towers, 135 airline headquarters, etc. Throughout the rest of this document, we 136 therefore use the term "MNP" when discussing an IPv6 prefix that is 137 delegated to any ATN/IPS end system, including ATCs, AOCs, and 138 aircraft. We also use the term Mobility Service Prefix (MSP) to 139 refer to an aggregated prefix assigned to the ATN/IPS by an Internet 140 assigned numbers authority, and from which all MNPs are delegated 141 (e.g., up to 2^32 IPv6 /56 MNPs could be delegated from an IPv6 /24 142 MSP). 144 Connexion By Boeing [CBB] was an early aviation mobile routing 145 service based on dynamic updates in the global public Internet BGP 146 routing system. Practical experience with the approach has shown 147 that frequent injections and withdrawals of MNPs in the Internet 148 routing system can result in excessive BGP update messaging, slow 149 routing table convergence times, and extended outages when no route 150 is available. This is due to both conservative default BGP protocol 151 timing parameters (see Section 6) and the complex peering 152 interconnections of BGP routers within the global Internet 153 infrastructure. The situation is further exacerbated by frequent 154 aircraft mobility events that each result in BGP updates that must be 155 propagated to all BGP routers in the Internet that carry a full 156 routing table. 158 We therefore consider an approach using a BGP overlay network routing 159 system where a private BGP routing protocol instance is maintained 160 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 161 private BGP instance does not interact with the native BGP routing 162 system in the connected Internetworking underlay, and BGP updates are 163 unidirectional from "stub" ASBRs (s-ASBRs) to a small set of "core" 164 ASBRs (c-ASBRs) in a hub-and-spokes topology. No extensions to the 165 BGP protocol are necessary. 167 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 168 dedicated high speed links and/or tunnels across the Internetworking 169 underlay using industry-standard encapsulations (e.g., Generic 170 Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). In 171 particular, tunneling must be used when neighboring ASBRs are 172 separated by multiple Internetworking underlay hops. 174 The s-ASBRs engage in external BGP (eBGP) peerings with their 175 respective c-ASBRs, and only maintain routing table entries for the 176 MNPs currently active within the stub AS. The s-ASBRs send BGP 177 updates for MNP injections or withdrawals to c-ASBRs but do not 178 receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 179 default routes with their c-ASBRs as the next hop, and therefore hold 180 only partial topology information. 182 The c-ASBRs connect to other c-ASBRs using internal BGP (iBGP) 183 peerings over which they collaboratively maintain a full routing 184 table for all active MNPs currently in service. Therefore, only the 185 c-ASBRs maintain a full BGP routing table and never send any BGP 186 updates to s-ASBRs. This simple routing model therefore greatly 187 reduces the number of BGP updates that need to be synchronized among 188 peers, and the number is reduced further still when intradomain 189 routing changes within stub ASes are processed within the AS instead 190 of being propagated to the core. BGP Route Reflectors (RRs) 191 [RFC4456] can also be used to support increased scaling properties. 193 The remainder of this document discusses the proposed BGP-based ATN/ 194 IPS mobile routing service. 196 2. Terminology 198 The terms Autonomous System (AS) and Autonomous System Border Router 199 (ASBR) are the same as defined in [RFC4271]. 201 The following terms are defined for the purposes of this document: 203 Air Traffic Management (ATM) 204 The worldwide service for coordinating safe aviation operations. 206 Air Traffic Controller (ATC) 207 A government agent responsible for coordinating with aircraft 208 within a defined operational region via voice and/or data Command 209 and Control messaging. 211 Airline Operations Controller (AOC) 212 An airline agent responsible for tracking and coordinating with 213 aircraft within their fleet. 215 Aeronautical Telecommunications Network with Internet Protocol 216 Services (ATN/IPS) 217 A future aviation network for ATCs and AOCs to coordinate with all 218 aircraft operating worldwide. The ATN/IPS will be an IPv6-based 219 overlay network service that connects access networks via 220 tunneling over an Internetworking underlay. 222 Internetworking underlay A connected wide-area network that supports 223 overlay network tunneling and connects Radio Access Networks to 224 the rest of the ATN/IPS. 226 Radio Access Network (RAN) 227 An aviation radio data link service provider's network, including 228 radio transmitters and receivers as well as supporting ground- 229 domain infrastructure needed to convey a customer's data packets 230 to the outside world. The term RAN is intended in the same spirit 231 as for cellular operator networks and other radio-based Internet 232 service provider networks. For simplicity, we also use the term 233 RAN to refer to ground-domain networks that connect AOCs and ATCs 234 without any aviation radio communications. 236 Core Autonomous System Border Router (c-ASBR) A BGP router located 237 in the hub of the ATN/IPS hub-and-spokes overlay network topology. 239 Core Autonomous System The "hub" autonomous system maintained by all 240 c-ASBRs. 242 Stub Autonomous System Border Router (s-ASBR) A BGP router 243 configured as a spoke in the ATN/IPS hub-and-spokes overlay 244 network topology. 246 Stub Autonomous System A logical grouping that includes all Clients 247 currently associated with a given s-ASBR. 249 Client An ATC, AOC or aircraft that connects to the ATN/IPS as a 250 leaf node. The Client could be a singleton host, or a router that 251 connects a mobile network. 253 Proxy A node at the edge of a RAN that acts as a transparent 254 intermediary between Clients and s-ASBRs. From the Client's 255 perspective, the Proxy presents the appearance that the Client is 256 communicating directly with the s-ASBR. From the s-ASBR's 257 perspective, the Proxy presents the appearance that the s-ASBR is 258 communicating directly with the Client. 260 Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any 261 ATN/IPS end system, including ATCs, AOCs, and aircraft. 263 Mobility Service Prefix (MSP) An aggregated prefix assigned to the 264 ATN/IPS by an Internet assigned numbers authority, and from which 265 all MNPs are delegated (e.g., up to 2**32 IPv6 /56 MNPs could be 266 delegated from a /24 MSP). 268 3. ATN/IPS Routing System 270 The proposed ATN/IPS routing system comprises a private BGP instance 271 coordinated in an overlay network via tunnels between neighboring 272 ASBRs over the Internetworking underlay. The overlay does not 273 interact with the native BGP routing system in the connected 274 underlying Internetwork, and each c-ASBR advertises only a small and 275 unchanging set of MSPs into the Internetworking underlay routing 276 system instead of the full dynamically changing set of MNPs. (For 277 example, when the Internetworking underlay is the global public 278 Internet the c-ASBRs advertise the MSPs in the public BGP Internet 279 routing system.) 281 In a reference deployment, one or more s-ASBRs connect each stub AS 282 to the overlay using a shared stub AS Number (ASN). Each s-ASBR 283 further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are 284 members of the same core AS, and use a shared core ASN. Globally- 285 unique public ASNs could be assigned, e.g., either according to the 286 standard 16-bit ASN format or the 32-bit ASN scheme defined in 287 [RFC6793]. 289 The c-ASBRs use iBGP to maintain a synchronized consistent view of 290 all active MNPs currently in service. Figure 1 below represents the 291 reference deployment. (Note that the figure shows details for only 292 two s-ASBRs (s-ASBR1 and s-ASBR2) due to space constraints, but the 293 other s-ASBRs should be understood to have similar Stub AS, MNP and 294 eBGP peering arrangements.) The solution described in this document 295 is flexible enough to extend to these topologies. 297 ........................................................... 298 . . 299 . (:::)-. <- Stub ASes -> (:::)-. . 300 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 301 . `-(::::)-' `-(::::)-' . 302 . +-------+ +-------+ . 303 . |s-ASBR1+-----+ +-----+s-ASBR2| . 304 . +--+----+ eBGP \ / eBGP +-----+-+ . 305 . \ \/ / . 306 . \eBGP / \ /eBGP . 307 . \ / \ / . 308 . +-------+ +-------+ . 309 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 310 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 311 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 312 . +-------+ .-(::::::::) +-------+ . 313 . . .-(::::::::::::::)-. . . 314 . . (:::: Core AS :::) . . 315 . +-------+ `-(:::::::::::::)-' +-------+ . 316 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 317 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 318 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 319 . +-------+ +-------+ . 320 . / \ . 321 . /eBGP \eBGP . 322 . / \ . 323 . +---+---+ +-----+-+ . 324 . |s-ASBR | |s-ASBR | . 325 . +-------+ +-------+ . 326 . . 327 . . 328 . <------------ Internetworking Underlay --------------> . 329 ............................................................ 331 Figure 1: Reference Deployment 333 In the reference deployment, each s-ASBR maintains routes for active 334 MNPs that currently belong to its stub AS. In response to "Inter- 335 domain" mobility events, each s-ASBR will dynamically announces new 336 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. For larger-scale 391 applications (such as unmanned air vehicles and terrestrial vehicles) 392 even larger scales can be accommodated by adding more c-ASBRs. 394 4. ATN/IPS Radio Access Network (RAN) Model 396 Radio Access Networks (RANs) connect end system Clients such as 397 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 398 connect to multiple RANs at once, for example, when they have both 399 satellite and cellular data links activated simultaneously. Clients 400 may further move between RANs in a manner that is perceived as a 401 network layer mobility event. Clients could therefore employ a 402 multilink/mobility routing service such as those discussed in 403 Section 7. 405 Clients register all of their active data link connections with their 406 serving s-ASBRs as discussed in Section 3. Clients may connect to 407 s-ASBRs either directly, or via a Proxy at the edge of the RAN. 409 Figure 2 shows the ATN/IPS RAN model where Clients connect to RANs 410 via aviation data links. Clients register their RAN addresses with a 411 nearby s-ASBR, where the registration process may be brokered by a 412 Proxy at the edge of the RAN. 414 Data Link "A" +--------+ Data Link "B" 415 +----------- | Client |-----------+ 416 / +--------+ \ 417 / \ 418 / \ 419 (:::)-. (:::)-. 420 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 421 `-(::::)-' `-(::::)-' 422 +-------+ +-------+ 423 ... | Proxy | ............................ | Proxy | ... 424 . +-------+ +-------+ . 425 . ^^ ^^ . 426 . || || . 427 . || +--------+ || . 428 . ++============> | s-ASBR | <============++ . 429 . +--------+ . 430 . | eBGP . 431 . (:::)-. . 432 . .-(::::::::) . 433 . .-(::: ATN/IPS :::)-. . 434 . (::::: BGP Routing ::::) . 435 . `-(:: System ::::)-' . 436 . `-(:::::::-' . 437 . . 438 . . 439 . <------------- Internetworking Underlay -------------> . 440 ............................................................ 442 Figure 2: ATN/IPS RAN Architecture 444 When a Client logs into a RAN, it specifies a nearby s-ASBR that it 445 has selected to connect to the ATN/IPS. (Selection of a nearby 446 s-ASBR could be through consulting a geographically-keyed static host 447 file, through a DNS lookup, etc.) The login process is transparently 448 brokered by a Proxy at the border of the RAN, which then conveys the 449 connection request to the s-ASBR via tunneling across the 450 Internetworking underlay. The s-ASBR then registers the address of 451 the Proxy as the address for the Client, and the Proxy forwards the 452 s-ASBR's reply to the Client. If the Client connects to multiple 453 RANs, the s-ASBR will register the addresses of all Proxies as 454 addresses through which the Client can be reached. 456 The s-ASBR represents all of its active Clients as MNP routes in the 457 ATN/IPS BGP routing system. The s-ASBR's stub AS therefore consists 458 of the set of all of its active Clients (i.e., the stub AS is a 459 logical construct and not a physical construct). The s-ASBR injects 460 the MNPs of its active Clients and withdraws the MNPs of its departed 461 Clients via BGP updates to c-ASBRs. Since Clients are expected to 462 remain associated with their current s-ASBR for extended periods, the 463 level of MNP injections and withdrawals in the BGP routing system 464 will be on the order of the numbers of network joins, leaves and 465 s-ASBR handovers for aircraft operations (see: Section 6). It is 466 important to observe that fine-grained events such as Client mobility 467 and Quality of Service (QoS) signaling are coordinated only by 468 Proxies and the Client's current s-ASBRs, and do not involve other 469 ASBRs in the routing system. In this way, intradomain routing 470 changes within the stub AS are not propagated into the rest of the 471 ATN/IPS BGP routing system. 473 5. ATN/IPS Route Optimization 475 ATN/IPS end systems will frequently need to communicate with 476 correspondents associated with other s-ASBRs. In the BGP peering 477 topology discussed in Section 3, this can initially only be 478 accommodated by including multiple tunnel segments in the forwarding 479 path. In many cases, it would be desirable to eliminate extraneous 480 tunnel segments from this "dogleg" route so that packets can traverse 481 a minimum number of tunneling hops across the Internetworking 482 underlay. ATN/IPS end systems could therefore employ a route 483 optimization service according to the mobility service employed (see: 484 Section 7). 486 A route optimization example is shown in Figure 3 and Figure 4 below. 487 In the first figure, multiple tunneled segments between Proxys and 488 ASBRs are necessary to convey packets between Clients associated with 489 different s-ASBRs. In the second figure, the optimized route tunnels 490 packets directly between Proxys without involving the ASBRs. 492 +---------+ +---------+ 493 | Client1 | | Client2 | 494 +---v-----+ +-----^---+ 495 * * 496 * * 497 (:::)-. (:::)-. 498 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 499 `-(::::)-' `-(::::)-' 500 +--------+ +--------+ 501 ... | Proxy1 | .......................... | Proxy2 | ... 502 . +--------+ +--------+ . 503 . ** ** . 504 . ** ** . 505 . ** ** . 506 . +---------+ +---------+ . 507 . | s-ASBR1 | | s-ASBR2 | . 508 . +--+------+ +-----+---+ . 509 . \ ** Dogleg ** / . 510 . eBGP\ ** Route ** /eBGP . 511 . \ **==============** / . 512 . +---------+ +---------+ . 513 . | c-ASBR1 | | c-ASBR2 | . 514 . +---+-----+ +----+----+ . 515 . +--------------+ . 516 . iBGP . 517 . . 518 . <------------- Internetworking Underlay -------------> . 519 ............................................................ 521 Figure 3: Dogleg Route Before Optimization 523 +---------+ +---------+ 524 | Client1 | | Client2 | 525 +---v-----+ +-----^---+ 526 * * 527 * * 528 (:::)-. (:::)-. 529 .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) 530 `-(::::)-' `-(::::)-' 531 +--------+ +--------+ 532 ... | Proxy1 | .......................... | Proxy2 | ... 533 . +------v-+ +--^-----+ . 534 . * * . 535 . *================================* . 536 . . 537 . +---------+ +---------+ . 538 . | s-ASBR1 | | s-ASBR2 | . 539 . +--+------+ +-----+---+ . 540 . \ / . 541 . eBGP\ /eBGP . 542 . \ / . 543 . +---------+ +---------+ . 544 . | c-ASBR1 | | c-ASBR2 | . 545 . +---+-----+ +----+----+ . 546 . +--------------+ . 547 . iBGP . 548 . . 549 . <------------- Internetworking Underlay -------------> . 550 ............................................................ 552 Figure 4: Optimized Route 554 6. BGP Protocol Considerations 556 The number of eBGP peering sessions that each c-ASBR must service is 557 proportional to the number of s-ASBRs in the system. Network 558 emulations with lightweight virtual machines have shown that a single 559 c-ASBR can service at least 100 eBGP peerings from s-ASBRs that each 560 advertise 10K MNP routes (i.e., 1M total). It is expected that 561 robust c-ASBRs can service many more peerings than this - possibly by 562 multiple orders of magnitude. But even assuming a conservative 563 limit, the number of s-ASBRs could be increased by also increasing 564 the number of c-ASBRs. Since c-ASBRs also peer with each other using 565 iBGP, however, larger-scale c-ASBR deployments may need to employ an 566 adjunct facility such as BGP Route Reflectors (RRs)[RFC4456]. 568 The number of aircraft in operation at a given time worldwide is 569 likely to be significantly less than 1M, but we will assume this 570 number for a worst-case analysis. Assuming a worst-case average 1 571 hour flight profile from gate-to-gate with 10 service region 572 transitions per flight, the entire system will need to service at 573 most 10M BGP updates per hour (2778 updates per second). This number 574 is within the realm of the peak BGP update messaging seen in the 575 global public Internet today [BGP2]. Assuming a BGP update message 576 size of 100 bytes (800bits), the total amount of BGP control message 577 traffic to a single c-ASBR will be less than 2.5Mbps which is a 578 nominal rate for modern data links. 580 Industry standard BGP routers provide configurable parameters with 581 conservative default values. For example, the default hold time is 582 90 seconds, the default keepalive time is 1/3 of the hold time, and 583 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 584 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 585 For the simple mobile routing system described herein, these 586 parameters can and should be set to more aggressive values to support 587 faster neighbor/link failure detection and faster routing protocol 588 convergence times. For example, a hold time of 3 seconds and a 589 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 591 Each c-ASBR will be using eBGP both in the ATN/IPS and the 592 Internetworking Underlay with the ATN/IPS unicast IPv6 routes 593 resolving over Internetworking Underlay routes. Consequently, 594 c-ASBRs and potentially s-ASBRs will need to support separate local 595 ASes for the two BGP routing domains and routing policy or assure 596 routes are not propagated between the two BGP routing domains. From 597 a conceptual and operational standpoint, the implementation should 598 provide isolation between the two BGP routing domains (e.g., separate 599 BGP instances). 601 7. Stub AS Mobile Routing Services 603 Stub ASes maintain intradomain routing information for mobile node 604 clients, and are responsible for all localized mobility signaling 605 without disturbing the BGP routing system. Clients can enlist the 606 services of a candidate mobility service such as Mobile IPv6 (MIPv6) 607 [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO 608 [I-D.templin-intarea-6706bis] according to the service offered by the 609 stub AS. Further details of mobile routing services are out of scope 610 for this document. 612 8. Implementation Status 614 The BGP routing topology described in this document has been modeled 615 in realistic network emulations showing that at least 1 million MNPs 616 can be propagated to each c-ASBR even on lightweight virtual 617 machines. No BGP routing protocol extensions need to be adopted. 619 9. IANA Considerations 621 This document does not introduce any IANA considerations. 623 10. Security Considerations 625 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 626 profiles as for any Internet nodes. For this reason, ASBRs should 627 employ physical security and/or IP securing mechanisms such as IPsec 628 [RFC4301], TLS [RFC5246], etc. 630 ATN/IPS ASBRs present targets for Distributed Denial of Service 631 (DDoS) attacks. This concern is no different than for any node on 632 the open Internet, where attackers could send spoofed packets to the 633 node at high data rates. This can be mitigated by connecting ATN/IPS 634 ASBRs over dedicated links with no connections to the Internet and/or 635 when ASBR connections to the Internet are only permitted through 636 well-managed firewalls. 638 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 639 aviation data links from receiving DDoS packet floods. 641 This document does not include any new specific requirements for 642 mitigation of DDoS. 644 11. Acknowledgements 646 This work is aligned with the FAA as per the SE2025 contract number 647 DTFAWA-15-D-00030. 649 This work is aligned with the NASA Safe Autonomous Systems Operation 650 (SASO) program under NASA contract number NNA16BD84C. 652 This work is aligned with the Boeing Information Technology (BIT) 653 MobileNet program. 655 The following individuals contributed insights that have improved the 656 document: Erik Kline, Tony Li, Alexandre Petrescu, Pascal Thubert. 658 12. References 660 12.1. Normative References 662 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 663 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 664 DOI 10.17487/RFC4271, January 2006, 665 . 667 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 668 Control Message Protocol (ICMPv6) for the Internet 669 Protocol Version 6 (IPv6) Specification", STD 89, 670 RFC 4443, DOI 10.17487/RFC4443, March 2006, 671 . 673 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 674 Reflection: An Alternative to Full Mesh Internal BGP 675 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 676 . 678 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 679 (IPv6) Specification", STD 86, RFC 8200, 680 DOI 10.17487/RFC8200, July 2017, 681 . 683 12.2. Informative References 685 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 686 2016. 688 [BGP2] Huston, G., "BGP Instability Report, 689 http://bgpupdates.potaroo.net/instability/bgpupd.html", 690 May 2017. 692 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 693 Protocol (BGP), http://www.quark.net/docs/ 694 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 696 [I-D.ietf-lisp-rfc6830bis] 697 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 698 Cabellos-Aparicio, "The Locator/ID Separation Protocol 699 (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), 700 November 2018. 702 [I-D.templin-intarea-6706bis] 703 Templin, F., "Asymmetric Extended Route Optimization 704 (AERO)", draft-templin-intarea-6706bis-03 (work in 705 progress), December 2018. 707 [ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx", 708 February 2017. 710 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 711 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 712 DOI 10.17487/RFC2784, March 2000, 713 . 715 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 716 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 717 December 2005, . 719 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 720 (TLS) Protocol Version 1.2", RFC 5246, 721 DOI 10.17487/RFC5246, August 2008, 722 . 724 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 725 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 726 2011, . 728 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 729 Autonomous System (AS) Number Space", RFC 6793, 730 DOI 10.17487/RFC6793, December 2012, 731 . 733 Appendix A. Change Log 735 << RFC Editor - remove prior to publication >> 737 Changes from -00 to -01: 739 o incorporated clarifications due to list comments and questions. 741 o new section 7 on Stub AS Mobile Routing Services 743 o updated references, and included new reference for MIPv6 and LISP 745 Status as of 08/30/2018: 747 o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp' 749 Authors' Addresses 751 Fred L. Templin (editor) 752 Boeing Research & Technology 753 P.O. Box 3707 754 Seattle, WA 98124 755 USA 757 Email: fltemplin@acm.org 758 Greg Saccone 759 Boeing Research & Technology 760 P.O. Box 3707 761 Seattle, WA 98124 762 USA 764 Email: gregory.t.saccone@boeing.com 766 Gaurav Dawra 767 LinkedIn 768 USA 770 Email: gdawra.ietf@gmail.com 772 Acee Lindem 773 Cisco Systems, Inc. 774 USA 776 Email: acee@cisco.com 778 Victor Moreno 779 Cisco Systems, Inc. 780 USA 782 Email: vimoreno@cisco.com