idnits 2.17.1 draft-templin-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 (March 29, 2017) is 2577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 519, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-08) exists of draft-templin-6man-rio-redirect-01 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-74 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational March 29, 2017 5 Expires: September 30, 2017 7 A Simple BGP-based Mobile Routing System for the Aeronautical 8 Telecommunications Network 9 draft-templin-atn-bgp-01.txt 11 Abstract 13 The International Civil Aviation Organization (ICAO) is investigating 14 mobile routing solutions for a worldwide Aeronautical 15 Telecommunications Network with Internet Protocol Services (ATN/IPS). 16 The ATN/IPS will eventually replace existing communication services 17 with an IPv6-based service supporting pervasive Air Traffic 18 Management (ATM) for Air Traffic Controllers (ATC), Airline 19 Operations Controllers (AOC), and all commercial aircraft worldwide. 20 This informational document describes a simple mobile routing service 21 based on mature industry standards to address the ATN/IPS 22 requirements. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 30, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Proposed BGP-based ATN/IPS Routing System . . . . . . . . . . 4 60 3. Route Optimization . . . . . . . . . . . . . . . . . . . . . 7 61 4. Route Availability . . . . . . . . . . . . . . . . . . . . . 9 62 5. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 10 63 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 11 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 70 11.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 The International Civil Aviation Organization [ICAO] is investigating 76 mobile routing solutions for a worldwide Aeronautical 77 Telecommunications Network with Internet Protocol Services (ATN/IPS). 78 The ATN/IPS will eventually replace existing communication services 79 with an IPv6-based service supporting pervasive Air Traffic 80 Management (ATM) for Air Traffic Controllers (ATC), Airline 81 Operations Controllers (AOC), and all commercial aircraft worldwide. 82 This informational document describes a simple mobile routing service 83 based on mature industry standards to address the ATN/IPS 84 requirements. 86 Aircraft communicate via wireless aviation data links that typically 87 support much lower data rates than terrestrial wireless and wired- 88 line communications. For example, VHF-based data links only support 89 data rates on the order of 32Kbps and an emerging L-Band data link 90 that is expected to play a key role in future aeronautical 91 communications only supports rates on the order of 1Mbps. Although 92 satellite data links can provide much higher data rates during 93 optimal conditions, they (like all other aviation data links) are 94 subject to errors, delay, disruption, signal intermittence, 95 degradation due to atmospheric conditions, etc. The well-connected 96 ground domain ATN/IPS network should therefore treat each safety-of- 97 flight critical packet produced by (or destined to) an aircraft as a 98 precious commodity and strive for a "better-than-best-effort" service 99 that provides the highest possible degree of reliability. 101 The ATN/IPS assumes a worldwide connected Internetwork for carrying 102 ATM communications. The Internetwork could be manifested as a 103 private collection of long-haul backbone links (e.g., fiberoptics, 104 copper, SATCOM, etc.) interconnected by high-performance networking 105 gear such as bridges, switches and routers. Such a private 106 Internetwork would need to connect all ATN/IPS participants 107 worldwide, and could therefore present a considerable cost for a 108 large-scale deployment of new infrastructure. Alternatively, the 109 ATN/IPS could be deployed as an overlay over the existing global 110 public Internet itself as long as sufficient security and reliability 111 provisions are met. 113 The ATN/IPS further assumes that each aircraft will receive an IPv6 114 Mobile Network Prefix (MNP) that accompanies the aircraft wherever it 115 travels. ATCs and AOCs will likewise receive IPv6 prefixes, but they 116 would typically appear in static (not mobile) deployments. 117 Throughout the rest of this document, we therefore use the term "MNP" 118 when discussing an IPv6 prefix that is delegated to any ATN/IPS end 119 system, including ATCs, AOCs and aircraft. We also use the term 120 Mobility Service Prefix (MSP) to refer to an aggregated prefix 121 assigned to the ATN/IPS by an Internet assigned numbers authority, 122 and from which all MNPs are delegated (e.g., up to 2**32 IPv6 /64 123 MNPs could be delegated from the MSP 2001:db8::/32). 125 [CBB] describes an aviation mobile routing service based on dynamic 126 updates in the global public Internet Border Gateway Protocol (BGP) 127 [RFC4271] routing system. Practical experience with the approach has 128 shown that frequent injections and withdrawals of MNPs in the 129 Internet routing system results in excessive BGP update messaging, 130 slow routing table convergence times, and extended outages when no 131 route is available. This is due to both conservative default BGP 132 protocol timing parameters (see Section 5) and the complex peering 133 interconnections of BGP routers within the global Internet 134 infrastructure. The situation is further exacerbated by frequent 135 aircraft mobility events that each result in BGP updates that must be 136 propagated to all BGP routers in the Internet that carry a full 137 routing table. 139 We therefore consider a new approach using a BGP overlay network 140 routing system where a private BGP routing protocol instance is 141 maintained between ATN/IPS Autonomous System (AS) Border Routers 142 (ASBRs). The private BGP instance does not interact with the 143 Internetwork BGP routing system, and BGP updates are unidirectional 144 from "stub" ASBRs (s-ASBRs) to a very small set of "core" ASBRs 145 (c-ASBRs) in a hub-and-spokes arrangement. No non-standard 146 extensions of the BGP protocol are necessary. 148 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 149 dedicated high speed links and/or tunnels across the Internetwork 150 using industry-standard encapsulations (e.g., Generic Routing 151 Encapsulation (GRE) [RFC2784], IPsec [RFC4301] etc.). The s-ASBRs 152 engage in external BGP (eBGP) peerings with their respective c-ASBRs, 153 and only maintain routing table entries for the MNPs currently active 154 within the stub AS. A stub AS may connect to the core via multiple 155 s-ASBRs, in which case the s-ASBRs would engage in an Interior 156 Gateway Protocol (IGP) among themselves to maintain a common view of 157 the stub AS MNPs. (The s-ASBRs need not engage in internal BGP 158 (iBGP) peerings, since they do not receive any BGP updates from 159 c-ASBRs and therefore have no BGP information to share with each 160 other.) Finally, the s-ASBRs also maintain default routes with their 161 c-ASBRs as the next hop, and therefore hold only partial topology 162 information. 164 The c-ASBRs connect to other c-ASBRs using iBGP peerings over which 165 they collaboratively maintain a full routing table for all active 166 MNPs currently in service. Therefore, only the c-ASBRs maintain a 167 full BGP routing table and never send any BGP updates to s-ASBRs. 168 This simple arrangement therefore greatly reduces the number of BGP 169 updates that need to be synchronized among peers, and the number is 170 reduced further still when localized mobility events within stub ASes 171 (i.e., "intradomain" mobility events) are mitigated within the AS 172 instead of being propagated to the core. 174 The following section provides a detailed discussion of the proposed 175 BGP-based ATN/IPS routing system. 177 2. Proposed BGP-based ATN/IPS Routing System 179 The proposed ATN/IPS routing system comprises a private BGP instance 180 coordinated between ASBRs in an overlay network. The overlay does 181 not interact with the native Internetwork BGP routing system, and 182 each c-ASBR advertises only a small and unchanging set of MSPs into 183 the Internetwork instead of the full dynamically changing set of 184 MNPs. 186 In a reference deployment, one or more s-ASBRs connect each stub AS 187 to the overlay using a shared stub AS Number (ASN). Each s-ASBR 188 further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are 189 members of the same core AS, and use a shared core ASN. The c-ASBRs 190 further use iBGP to maintain a synchronized consistent view of all 191 active MNPs currently in service. Figure 1 below represents the 192 reference deployment. Note that in the figure only two s-ASBRs show 193 detail, but similar arrangements are implied for all other s-ASBRs. 194 Note also that each stub AS shows only a single s-ASBR with a single 195 c-ASBR connection, but in practical deployments each stub AS may have 196 multiple s-ASBRs that peer with multiple c-ASBRs via eBGP, e.g., for 197 fault tolerance. 199 ........................................................... 200 . . 201 . (:::)-. <- Stub ASes -> (:::)-. . 202 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 203 . `-(::::)-' `-(::::)-' . 204 . +-------+ +-------+ . 205 . |s-ASBR1| |s-ASBR2| . 206 . +--+----+ +-----+-+ . 207 . \ / . 208 . \eBGP /eBGP . 209 . \ / . 210 . +-------+ +-------+ . 211 . eBGP+-----+c-ASBR1| +c-ASBR2+-----+eBGP . 212 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 213 . |s-ASBRn+/ iBGP\ (:::)-. /iBGP \+s-ASBR3| . 214 . +-------+ .-(::::::::) +-------+ . 215 . . .-(::::::::::::::)-. . 216 . . (:::: Core AS :::) . 217 . +-------+ `-(:::::::::::::)-' +-------+ . 218 . |s-ASBR7+\ iBGP/`-(:::::::-'\iBGP /+s-ASBR4| . 219 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 220 . eBGP+-----+c-ASBRn| |c-ASBR3+-----+eBGP . 221 . +-------+ +-------+ . 222 . / \ . 223 . /eBGP \eBGP . 224 . / \ . 225 . +---+---+ +-----+-+ . 226 . |s-ASBR6| |s-ASBR5| . 227 . +-------+ +-------+ . 228 . . 229 . . 230 . <------------------- Internetwork --------------------> . 231 ............................................................ 233 Figure 1: Reference Deployment 235 In the reference deployment, each s-ASBR maintains routes for active 236 MNPs that currently belong to its stub AS, and dynamically announces 237 new MNPs and withdraws departed MNPs in its eBGP updates to c-ASBRs 238 in response to "interdomain" mobility events. Since ATN/IPS end 239 systems are expected to remain within the same stub AS for extended 240 timeframes, however, intradomain mobility events (such as an aircraft 241 handing off between cell towers) are handled locally within the stub 242 AS instead of being propagated as interdomain eBGP updates. 244 Each c-ASBR configures a black-hole route for each of its MSPs. By 245 black-holing the MSPs, the c-ASBR will maintain forwarding table 246 entries only for the MNPs that are currently active, and packets 247 destined to all other MNPs will correctly incur ICMPv6 Destination 248 Unreachable messages [RFC4443] due to the black hole route. The 249 c-ASBRs do not send eBGP updates for MNPs to s-ASBRs, but instead 250 originate a default route. In this way, s-ASBRs have only partial 251 topology knowledge (i.e., they know only about the active MNPs 252 currently within their stub ASes) and they forward all other packets 253 to c-ASBRs which have full topology knowledge. 255 Scaling properties of this ATN/IPS routing system are limited by the 256 number of BGP routes that can be carried by the c-ASBRs. A 2015 257 study showed that BGP routers in the global public Internet at that 258 time carried more than 500K routes with linear growth and no signs of 259 router resource exhaustion [BGP]. A more recent network emulation 260 study also showed that a single c-ASBR can accommodate at least 1M 261 dynamically changing BGP routes even on a lightweight virtual 262 machine, with the expectation that high-performance dedicated router 263 hardware can support even more. 265 Therefore, assuming each c-ASBR can carry 1M or more routes, this 266 means that at least 1M ATN/IPS end system MNPs can be serviced by a 267 single set of c-ASBRs. A means of increasing scaling would be to 268 assign a different set of c-ASBRs for each set of MSPs. In that 269 case, each s-ASBR still peers with one or more c-ASBRs from each set 270 of c-ASBRs, but the s-ASBR institutes route filters so that it only 271 sends BGP updates to the specific set of c-ASBRs that aggregate the 272 MSP. For example, if the MSP for the ATN/IPS deployment is 273 2001:db8::/32, a first set of c-ASBRs could service the MSP segment 274 2001:db8::/40, a second set could service 2001:db8:0100::/40, a third 275 set could service 2001:db8:0200::/40, etc. 277 Assuming up to 1K sets of c-ASBRs, the ATN/IPS routing system can 278 then accommodate 1B or more MNPs. In this way, each set of c-ASBRs 279 services a specific set of MSPs that they advertise to the native 280 Internetwork routing system, and each s-ASBR configures MSP-specific 281 routes that list the correct set of c-ASBRs as next hops. This 282 arrangement also allows for natural incremental deployment, and can 283 support small scale initial deployments followed by dynamic 284 deployment of additional ATN/IPS infrastructure elements without 285 disturbing the already-deployed base. 287 Finally, c-ASBRs may have multiple routing table entries for a single 288 MNP advertised by multiple s-ASBRs. Each s-ASBR can be assigned a 289 MULTI_EXIT_DISC (MED) metric for routes that it originates in its 290 eBGP peering configurations [RFC4451] so that c-ASBRs can determine 291 preferences for MNPs learned from multiple s-ASBRs. In this way, 292 c-ASBRs can select the neighboring s-ASBR with the lowest MED value, 293 i.e., even if it is not on the shortest path. The c-ASBR can then 294 fail over to a s-ASBR with a larger MED value in case of MNP 295 withdrawal or s-ASBR failure. Such an event could correspond to an 296 aviation data link handover, e.g., when an aircraft switches over 297 from a satellite link to an L-Band link. 299 3. Route Optimization 301 ATN/IPS end systems will frequently need to communicate with 302 correspondents located in other stub ASes. In the ASBR peering 303 arrangement discussed in Section 2, this can initially only be 304 accommodated by having the source s-ASBR forward packets to a c-ASBR 305 which then forwards the packets toward the destination s-ASBR where 306 the destination ATN/IPS end system resides. In many cases, it would 307 be desirable to eliminate c-ASBRs from this "dogleg" route so that 308 the source s-ASBR can send packets directly to the destination s-ASBR 309 through tunneling across the Internetwork. This can be accomplished 310 using a route optimization service based on the IPv6 Neighbor 311 Discovery Redirect function [RFC4861][RFC6706][I-D.templin-aerolink][ 312 I-D.templin-6man-rio-redirect]. 314 A route optimization example is shown in Figure 2 and Figure 3 below. 315 In the first figure, the dogleg route between correspondents in the 316 stub ASes traverses the path from s-ASBR1 to c-ASBR1 to c-ASBR2 to 317 S-ASBR2. In the second figure, the optimized route goes directly 318 from s-ASBR1 to s-ASBR2, i.e., the c-ASBRs are not included in the 319 path. 321 ........................................................... 322 . . 323 . (:::)-. <- Stub ASes -> (:::)-. . 324 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 325 . `-(::::)-' `-(::::)-' . 326 . +-------+ +-------+ . 327 . |s-ASBR1| |s-ASBR2| . 328 . +--+--^^+ +^^---+-+ . 329 . \ \\ Dogleg // / . 330 . eBGP\ \\ Route // /eBGP . 331 . \ \\============// / . 332 . +-------+ +-------+ . 333 . +c-ASBR1| +c-ASBR2+ . 334 . +--+----+ +-----+-+ . 335 . +--------------+ . 336 . iBGP . 337 . . 338 . <------------------- Internetwork --------------------> . 339 ............................................................ 341 Figure 2: Dogleg Route Before Optimization 343 ........................................................... 344 . . 345 . (:::)-. <- Stub ASes -> (:::)-. . 346 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 347 . `-(::::)-' `-(::::)-' . 348 . +-------+ Direct +-------+ . 349 . |s-ASBR1<================>s-ASBR2| . 350 . +--+----+ Route +-----+-+ . 351 . \ / . 352 . eBGP\ /eBGP . 353 . \ / . 354 . +-------+ +-------+ . 355 . +c-ASBR1| +c-ASBR2+ . 356 . +--+----+ +-----+-+ . 357 . +--------------+ . 358 . iBGP . 359 . . 360 . <------------------- Internetwork --------------------> . 361 ............................................................ 363 Figure 3: Direct Route Following Optimization 365 It is very important to understand that route optimization can fail 366 if the source s-ASBR cannot tunnel packets directly to the 367 destination s-ASBR due to some form of Internetwork blockage such as 368 filtering middleboxes. It is also necessary for the source s-ASBR to 369 quickly detect and adjust to failure of the destination s-ASBR. In 370 both of these cases, significant packet loss could occur before the 371 source s-ASBR can detect that the route-optimized path has failed. 372 This implies that route optimized paths may not always be the best 373 choice for carrying safety-of-flight critical packets with high 374 reliability requirements. 376 In all cases, s-ASBRs do not adveritse MNPs discovered via route 377 optimization to c-ASBRs. Instead, s-ASBRs keep MNPs discovered via 378 route optimization in a local table that is kept seperate from the 379 MNPs of ATN/IPS end systems within their own stub AS. 381 4. Route Availability 383 In the ATN/IPS BGP-based routing system proposed in this document, 384 each s-ASBR always has a default route and can therefore always send 385 packets via the dogleg route through a c-ASBR even if a route 386 optimized path has been established. The direct paths between 387 s-ASBRs and c-ASBRs are maintained by BGP peering session keepalives 388 such that, if a link or an ASBR goes down, BGP will detect the 389 failure and readjust the routing tables. However, ASBRs and the 390 links that interconnect them are expected to be secured as highly- 391 available and fault tolerant critical infrastructure such that 392 peering session failures should be extremely rare. 394 This represents a distinct architectural difference from other 395 approaches that only operate over route optimized paths. With the 396 approach described herein the source s-ASBR will always have a 397 working route, even if only via a dogleg path through a c-ASBR. This 398 gives rise to the possibility of sending {high-priority, low-data- 399 rate} packets via the assured dogleg route and {low-priority, high- 400 data-rate} packets via the optimized route, e.g., based on per-packet 401 quality of service indications. This could also give rise to a fair 402 pricing model that would charge more for use of the high-assurance 403 dogleg path and less for use of the lesser-assured route-optimized 404 path. 406 This distinction is of vital importance to aviation networking, where 407 isolated safety-of-flight critical packets such as produced by the 408 Controller Pilot Data Link Communications (CPDLC) facility may not be 409 eligible for retransmission, e.g., if an aviation data link is 410 failing. If there is no route available, the packet can be dropped 411 or delayed and safety-of-flight parameters could be lost. Even when 412 an optimized route is discovered on-demand, the route may not work 413 and again safety-of-flight critical packets could be lost. 415 In summary, the approach proposed in this document is a proactive 416 routing protocol that ensures that a working route will always be 417 available. This is in contrast to on-demand routing protocols that 418 must either drop or delay safety-of-flight critical packets when 419 there is no route available, and may even report non-functioning 420 routes leading to packet loss. 422 5. BGP Protocol Considerations 424 The number of eBGP peering sessions that each c-ASBR must service is 425 proportional to the number of s-ASBRs in the system. Network 426 emulations with lightweight virtual machines have shown that a single 427 c-ASBR can service at least 100 eBGP peerings from s-ASBRs that each 428 advertise 10K MNP routes (i.e., 1M total). It is expected that 429 robust c-ASBRs can service many more peerings than this - possibly by 430 multiple orders of magnitude. But even assuming a conservative 431 limit, the number of s-ASBRs could be increased by also increasing 432 the number of c-ASBRs. Since c-ASBRs also peer with each other using 433 iBGP, however, larger-scale c-ASBR deployments may need to employ an 434 adjunct facility such as BGP route reflectors [RFC4456]. 436 Industry standard BGP routers provide configurable parameters with 437 conservative default values. For example, the default hold time is 438 90 seconds, the default keepalive time is 1/3 of the hold time, and 439 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 440 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 441 For the simple mobile routing system described herein, these 442 parameters can and should be set to more aggressive values to support 443 faster neighbor/link failure detection and faster routing protocol 444 convergence times. For example, a hold time of 3 seconds and a 445 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 447 By default, MED only compares metrics that originate from multiple 448 neighbors within the same AS [RFC4451]. In order to compare MED 449 metrics that come from different ASes, a router configuration file 450 entry may be needed (e.g., Cisco routers require the configuration 451 file entry "bgp always-compare-med"). Furthermore, in order for the 452 MED discriminator to be applied correctly, the AS_PATH phase in the 453 BGP route selection process must be disabled (e.g., Cisco routers use 454 the configuration file entry "bgp bestpath as-path ignore"). 456 6. Implementation Status 458 The BGP routing arrangement described in this document has been 459 modeled in realistic network emulations showing that the MED process 460 results in selection of the best peer when multiple peers advertise 461 the same MNP. Modeling has also shown that at least 1 million MNPs 462 can be propagated to each c-ASBR even on lightweight virtual 463 machines. 465 7. IANA Considerations 467 This document does not introduce any IANA considerations. 469 8. Security Considerations 471 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 472 profiles as for any Internet nodes. For this reason, ASBRs should 473 employ physical security and/or IP securing mechanisms such as IPsec 474 [RFC4301], TLS [RFC5246], etc. 476 ATN/IPS ASBRs present targets for Distributed Denial of Service 477 (DDoS) attacks. This concern is no different than for any node on 478 the open Internet, where attackers could send spoofed packets to the 479 node at high data rates. This can be mitigated by connecting ATN/IPS 480 ASBRs over dedicated links with no connections to the Internet and/or 481 when ASBR connections to the Internet are only permitted through 482 well-managed firewalls. 484 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 485 aviation data links from receiving DDoS packet floods. 487 9. Related Work 489 This work has evolved from the author's earlier publications, 490 including: 492 SEAL: [RFC5320][I-D.templin-intarea-seal]. 494 VET: [RFC5558][I-D.templin-intarea-vet]. 496 IRON: [RFC6179][I-D.templin-ironbis]. 498 AERO: [RFC6706][I-D.templin-aerolink][I-D.templin-6man-rio-redirect]. 500 10. Acknowledgements 502 This work is aligned with the FAA as per the SE2025 contract number 503 DTFAWA-15-D-00030. 505 This work is aligned with the NASA Safe Autonomous Systems Operation 506 (SASO) program under NASA contract number NNA16BD84C. 508 This work is aligned with the Boeing Information Technology (BIT) 509 MobileNet program. 511 11. References 513 11.1. Normative References 515 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 516 DOI 10.17487/RFC0791, September 1981, 517 . 519 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 520 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 521 December 1998, . 523 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 524 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 525 DOI 10.17487/RFC4271, January 2006, 526 . 528 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 529 Control Message Protocol (ICMPv6) for the Internet 530 Protocol Version 6 (IPv6) Specification", RFC 4443, 531 DOI 10.17487/RFC4443, March 2006, 532 . 534 [RFC4451] McPherson, D. and V. Gill, "BGP MULTI_EXIT_DISC (MED) 535 Considerations", RFC 4451, DOI 10.17487/RFC4451, March 536 2006, . 538 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 539 Reflection: An Alternative to Full Mesh Internal BGP 540 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 541 . 543 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 544 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 545 DOI 10.17487/RFC4861, September 2007, 546 . 548 11.2. Informative References 550 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 551 2016. 553 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 554 Protocol (BGP), http://www.quark.net/docs/ 555 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 557 [I-D.templin-6man-rio-redirect] 558 Templin, F. and j. woodyatt, "Route Information Options in 559 Redirect Messages", draft-templin-6man-rio-redirect-01 560 (work in progress), January 2017. 562 [I-D.templin-aerolink] 563 Templin, F., "Asymmetric Extended Route Optimization 564 (AERO)", draft-templin-aerolink-74 (work in progress), 565 November 2016. 567 [I-D.templin-intarea-seal] 568 Templin, F., "The Subnetwork Encapsulation and Adaptation 569 Layer (SEAL)", draft-templin-intarea-seal-68 (work in 570 progress), January 2014. 572 [I-D.templin-intarea-vet] 573 Templin, F., "Virtual Enterprise Traversal (VET)", draft- 574 templin-intarea-vet-40 (work in progress), May 2013. 576 [I-D.templin-ironbis] 577 Templin, F., "The Interior Routing Overlay Network 578 (IRON)", draft-templin-ironbis-16 (work in progress), 579 March 2014. 581 [ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx", 582 February 2017. 584 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 585 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 586 DOI 10.17487/RFC2784, March 2000, 587 . 589 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 590 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 591 December 2005, . 593 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 594 (TLS) Protocol Version 1.2", RFC 5246, 595 DOI 10.17487/RFC5246, August 2008, 596 . 598 [RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and 599 Adaptation Layer (SEAL)", RFC 5320, DOI 10.17487/RFC5320, 600 February 2010, . 602 [RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 603 RFC 5558, DOI 10.17487/RFC5558, February 2010, 604 . 606 [RFC6179] Templin, F., Ed., "The Internet Routing Overlay Network 607 (IRON)", RFC 6179, DOI 10.17487/RFC6179, March 2011, 608 . 610 [RFC6706] Templin, F., Ed., "Asymmetric Extended Route Optimization 611 (AERO)", RFC 6706, DOI 10.17487/RFC6706, August 2012, 612 . 614 Author's Address 616 Fred L. Templin (editor) 617 Boeing Research & Technology 618 P.O. Box 3707 619 Seattle, WA 98124 620 USA 622 Email: fltemplin@acm.org