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