idnits 2.17.1 draft-moreno-lisp-multi-as-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (29 July 2021) is 1001 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3618' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC6831' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC8060' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'RFC8061' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'RFC8111' is defined on line 741, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-09) exists of draft-haindl-lisp-gb-atn-06 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V.M. Moreno 3 Internet-Draft Cisco Systems 4 Intended status: Experimental 29 July 2021 5 Expires: 30 January 2022 7 LISP Based Multi-AS Backbone Federation 8 draft-moreno-lisp-multi-as-00 10 Abstract 12 As multiple organizations interconnect their networks through peering 13 agreements, it is desirable to preserve the services enabled by a 14 LISP overlay over such interconnection of independent networks. This 15 specification documents the requirements imposed by the deployment 16 scenario in which multiple organizations federate their backbones 17 with the objective of running a LISP overlay to enable services such 18 as mobility or VPNs. The requirements for policies, enforcement and 19 authoritative control of network assets are captured from the 20 perspective of the operator. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 30 January 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 63 3. Problem statement and Requirements . . . . . . . . . . . . . 4 64 4. Multi-organizational federated LISP Overlay Network . . . . . 8 65 5. Policies and enforcement . . . . . . . . . . . . . . . . . . 9 66 5.1. Peering Agreement enforcement Policies . . . . . . . . . 9 67 5.1.1. RLOC alignment to AS_Paths . . . . . . . . . . . . . 10 68 5.2. Sender/Ingress Policies . . . . . . . . . . . . . . . . . 10 69 5.2.1. Application preference policies . . . . . . . . . . . 11 70 6. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Regionalization . . . . . . . . . . . . . . . . . . . . . . . 12 72 8. Host Roaming and EID preservation . . . . . . . . . . . . . . 12 73 9. Uberlay Deployment . . . . . . . . . . . . . . . . . . . . . 13 74 10. ICAO use cases . . . . . . . . . . . . . . . . . . . . . . . 13 75 10.1. Air Traffic Control . . . . . . . . . . . . . . . . . . 13 76 10.2. Airline Operation Control . . . . . . . . . . . . . . . 13 77 10.3. Multi-link . . . . . . . . . . . . . . . . . . . . . . . 14 78 10.4. Path Preference . . . . . . . . . . . . . . . . . . . . 14 79 11. Policy enforcement and Trust . . . . . . . . . . . . . . . . 14 80 11.1. Consensus mechanisms and enforceable evidence (data 81 plane) . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 11.2. Topological enforcement (RTRs) . . . . . . . . . . . . . 15 83 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 86 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 15.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 Multiple organizations often collaborate and interconnect their 94 networks in order to form a larger network that can provide broader 95 coverage and connectivity. When these networks are interconnected 96 the organizations enter peering agreements that specify the terms 97 under which the connectivity is provided. Part of such peering 98 agreements include the specification of the IP prefixes for which a 99 particular organization will agree to provide service. Traditionally 100 these inter-organizational peerings have been implemented using BGP 101 and constraining the distribution of routes between the Autonomous 102 Systems of the different organizations in order to enforce the 103 conditions set in the peering agreements. This is a tried and proven 104 mechanism to integrate networks, but it is not easily extensible to 105 include some of the services that overlay networks enable. One 106 example of an overlay service that is not easily ported into the 107 native IP routing stack is mobility. In order to support these 108 services, a model for a multi-organizational federated overlay 109 network is of interest. In such a model the multiple organizations 110 will peer with each other to provide underlay connectivity and will 111 participate in a common overlay network for which the control plane 112 will be federated in order to allow the different organizations to 113 define and enforce the policies necessary to conform to their peering 114 agreements. 116 In this model, organizations will be in control of a set of xTRs, a 117 series of Map Servers/Resolvers and a portion of the underlay 118 topology. Organizations will be able to author and enforce policies 119 governing the reachability of EID prefixes that are registered to 120 their Map Servers, as well as the policies that govern when their 121 underlay may be used as a transit network for traffic flows between 122 end-points registered to other organizations. The policies enforced 123 reflect the peering agreements that may exist between the different 124 organizations. 126 An important aspect of the peering relationships is the use of 127 network resources provided by the portions of the underlay topology 128 that are in control of each organization. The federation mechanisms 129 must therefore be aware of the underlay topology. 131 These types of networks are found primarily in operations involving 132 multiple governments or service providers. Accountability, policy 133 enforcement and autonomy are critical requirements for such 134 organizations. There is a high interest in the creation of a 135 federated network, yet the trust levels between organizations are 136 low. Additionally, this federation must function strictly amongst 137 peers, without the participation of an intermediary organization or 138 any hierarchy amongst the peers. 140 2. Definition of Terms 142 LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel 143 Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map- 144 Resolver (MR) are defined in the LISP specification [RFC6830]. 146 Terms defining interactions with the LISP Mapping System are defined 147 in [RFC6833]. 149 Terms related to the procedures for signal free multicast are defined 150 in [RFC8378]. 152 The following terms are here defined to facilitate the descriptions 153 and discussions within this particular document. 155 Organization - An administrative domain which is part of the 156 federation. An organization controls a series of xTRs, Map-Servers/ 157 Resolvers (MS/MR), portions of the underlay topology, and is 158 authoritative for the EIDs registered with its MS/MRs. 160 Underlay-AS - The autonomous system which includes all routers, 161 control plane and RLOC prefixes for an organization. Underlay-AS 162 will connect to each other at specific BGP peering points at which 163 only underlay routing information is exchanged. 165 Federated Overlay - The overlay network established collaboratively 166 between multiple organizations over a multitude of interconnected 167 Underlay-ASs. 169 3. Problem statement and Requirements 171 The objective is the creation of a cross organizational overlay 172 network that would leverage a multi-as underlay to provide a common 173 backbone across the different organizations. The organizations 174 should be able to define and enforce policies and agreements around 175 the connectivity that will be provided for EID prefixes. These 176 policies are relevant to the use of links and routers in the underlay 177 within the boundaries of the different ASs, but are instantiated and 178 enforced in the overlay, where the EIDs reside. Agreements around 179 RLOC prefix reachability in the underlay should also be possible. 180 All LISP services such as mobility, multi-homing, segmentation, 181 Explicit Locator Paths, Signal Free Multicast, etc. should be 182 available in this multi-AS backbone. At the same time, in order to 183 maintain control and administrative delineation between the 184 organizations, each organization will own and operate a set of MS/MRs 185 that participate in the multi-organization LISP Mapping System. 187 The following reference topology may be used to illustrate possible 188 multi-AS underlay connectivity scenarios over which a LISP overlay is 189 to be deployed as well as the types of policies, peering agreements 190 and transit scenarios that may need to be supported. 192 +------------------+ +-------------------+ 193 | | | | 194 | +------+ | | +------+ | 195 | |MSMR D| | | |MSMR E| | 196 | +------+ | | +------+ | 197 | +--+-+ +-+--+ | 198 +--+--+ |ASBR+-----------+ASBR| +--+--+ 199 EID-D |XTR D| +--+-+ +-+--+ |XTR E| EID-E 200 +--+--+ | | +--+--+ 201 | | | | 202 | AS-D +----+ | | +----+ AS-E | 203 +----------+ASBR+--+ +---+ASBR+----------+ 204 +--+-+ +--+-+ 205 | | 206 | | 207 | | 208 +--+-+ +--+-+ 209 +----------+ASBR+--+ +---+ASBR+----------+ 210 | +----+ | | +----+ | 211 | | | | 212 | +------+ | | +------+ | 213 | |MSMR A| | | |MSMR B| | 214 | +------+ +--+-+ +-+--+ +------+ | 215 +--+--+ |ASBR+-----------+ASBR| +--+--+ 216 EID-A |XTR A| +--+-+ +-+--+ |XTR B| EID-B 217 +--+--+ | | +--+--+ 218 | | | | 219 | AS-A +----+ | | +----+ AS-B | 220 +----------+ASBR+--+ +---+ASBR+----------+ 221 +-+--+ +--+-+ 222 | | 223 +-+--+ +--+-+ 224 +------+ASBR+----------------------+ASBR+---+ 225 | +----+ +----+ | 226 | +------+ | 227 | |MSMR C| | 228 | +------+ | 229 | | 230 | AS-C +-----+ | 231 +------------------+XTR|C+------------------+ 232 +-----+ 234 EID-C 236 Figure 1. Multi-AS backbone with LISP overlay 238 Figure 1 shows 5 organizations with a partial connectivity mesh in 239 the underlay. Each organization is represented by one AS. The AS- 240 border routers are underlay routers interconnecting the ASs with EBGP 241 and have no awareness of the overlay. From an overlay perspective, 242 all organizations are actually part of the same overlay network, 243 however the ownership and control of XTR and MS/MR resources is 244 scoped by organization within the confines of each AS. 246 From the perspective of the connectivity that could be established 247 between EID-A and EID-B in the topology of Figure 1, these are some 248 of the possible scenarios that could be encountered: 250 * No transit: EID-B is allowed in AS-A and B, but not allowed in AS- 251 C, D or E. The only possible path is the direct peering point 252 between AS-A and B 254 * Single AS transit: EID-B is allowed in AS-A, B and C. EID-B is 255 not allowed elsewhere. AS-C is a possible path for the flow 256 between EID-A and EID-B, AS-C would serve as a transit AS for this 257 connection. AS-A would have two possibe paths over which to 258 establish the connection with EID-B, the decision on which path to 259 use would be based on a local policy at AS-A that would factor the 260 terms given to A to use the different ASs in the available paths. 262 * Multi-AS transit: EID-B is allowed in AS-A, B, D and E. The path 263 that traverses AS-D and AS-E is a viable path for the session 264 between EID-A and EID-B. A local ingress policy at AS-A may 265 determine if this path is to be used vs. other paths such as the 266 direct peering or going over AS-C. It is important to note that 267 for the D,E path to be viable, both AS-D and AS-E must have an 268 agreement in which they commit to transporting data for EID-B. If 269 either one of these ASs does not have this agreement, the path 270 would not be viable and should not be used. 272 The solution provided must allow the evaluation of the viability of 273 different paths based on the peering agreements between 274 organizations, which would allow or deny specific prefixes from being 275 serviced by certain ASs. 277 When multiple viable paths are available, the solution should permit 278 the definition and enforcement of policies that can be used by the 279 ingress AS to select the preferred path for the forwarding of a 280 certain flow. The terms of service over different paths may differ, 281 leading to preferences in using the services of one AS over another. 283 EIDs must be able to move from one AS to another. All EIDs connected 284 to an AS must be registered with the MSMR in that AS and fold under 285 the authority of that AS's MSMR. This is required in order to 286 maintain accountability aligned with the AS providing service to a 287 particular EID. 289 Each organization owns and controls fully all network elements in 290 their AS, this includes XTRs, ASBRs, MSMRs as well as any underlay 291 routers within the AS. 293 The following is a summary list of requirements pertinent to this 294 environment: 296 * Organizations should be able to interconnect their backbone 297 networks at agreed upon peering points and form a multi-AS 298 federated underlay. 300 * Organizations should be able to participate in a common LISP 301 overlay over the top of the multi-AS federated underlay. 303 * Ideally the organizations will be able to tunnel traffic directly 304 between XTRs belonging to different organizations without 305 requiring the deployment of RTRs at the boundaries of the domains. 307 * Peering agreements can be enforced in the underlay control plane 308 to influence the multi-AS routing structure in the underlay RLOC 309 space. 311 * It must be possible to define and enforce peering agreements and 312 policies relevant to EID-prefixes. 314 * All peering and policy is to be negotiated in a federated manner. 315 There should not be a need for an intermediary organization that 316 brokers connectivity or policy between members of the federation. 318 * An organization should be able to restrict which flows use their 319 network resources (underlay) 321 * Policies may allow or deny connectivity to specific prefixes over 322 portions of the topology belonging to a particular organization. 324 * Policies may allow or deny transit services to specific prefixes 325 over portions of the topology belonging to a particular 326 organization. 328 * Organizations may structure their presence in the federation 329 regionally. Thus an organization may have multiple instances 330 participate in the federation. e.g. Org-A-East and Org-A-West. 332 * An organization is responsible, accountable and authoritative for 333 any host connected to its network (XTRs). Thus, a roaming host 334 must register to the Mapping System for the organization it is 335 connected to. 337 * A roaming host should be able to keep its EID constant as it 338 roams. 340 * A host may connect to more than one AS. The host may use 341 dedicated EIDs per interface or may use a single EID across all 342 interfaces, both cases must be considered. 344 * An organization should own and control the XTRs in their network. 346 * An organization should own and control all routes in its Underlay- 347 AS. 349 * Each organization should own and control their own set of MS/MRs. 351 * Each organization should be able to define and enforce 352 reachability policies for the EIDs attached to it on the MS/MRs it 353 owns/controls. 355 * An organization presented with multiple possible paths to reach a 356 particular remote destination should be able to define a 357 preference policy amongst the different paths. 359 The following sections discuss some of these requirements in more 360 detail. 362 4. Multi-organizational federated LISP Overlay Network 364 In a multi-organizational network, the underlay is a collection of 365 interconnected independent networks, each of which is owned and 366 operated by a different organization. The different networks are 367 interconnected at EBGP peering points. Given the use of Location- 368 Identity separation, the peering policies enforced by EBGP at these 369 peering points will be effective on the RLOCs used in the underlay 370 only. All peering policies for the EID prefixes must be handled in 371 the overlay control plane, which may be, in this case, a federation 372 of MS/MRs. 374 Over the top of this underlay, an overlay network is deployed, to 375 include XTRs and MS/MRs. Each organization will be in control of the 376 XTRs that are directly connected to their underlay network. 377 Furthermore, each organization will have its own set of MS/MRs that 378 it will own and control. One could think of this as a single overlay 379 network in which different portions of the network are owned and 380 controlled by different organizations. 382 The MS/MRs of the different organizations will federate with each 383 other without an intermediary and they will handle the resolution of 384 EID to RLOC mappings within and across organizations. The MS/MRs of 385 each organization are authoritative for the EID-RLOC mapping 386 information for EIDs directly connected to their network, but also 387 for the enforcement of policies governing the handling of EID traffic 388 that may use the organization's network as a transit network. 390 5. Policies and enforcement 392 The policies to be enforced will derive mainly from the peering 393 agreements between organizations. These are the policies related to 394 the handling of connectivity for EID prefixes and whether specific 395 prefixes may be serviced by a specific AS or not. Although the EIDs 396 are handled in the overlay control plane, the enforcement of the 397 policies must correlate to the use of the resources in the underlay 398 topology in the different ASs. For instance, if an AS does not 399 permit forwarding of traffic for a specific EID prefix, any tunnels 400 established to send traffic to that prefix may not traverse any links 401 in the underlay that belong to the AS that does not permit the 402 prefix. 404 5.1. Peering Agreement enforcement Policies 406 Based on their peering agreements, organizations may or may not allow 407 the servicing of traffic for specific EID-prefixes. Traditionally 408 this has been enforced by including or excluding the advertisment of 409 routes into the specific ASs. In the demand model used in LISP, the 410 equivalent would be to provide or withold a valid mapping for the 411 destination from a map-response. Thus, the MS/MRs for all 412 organizations in the possible underlay AS_Paths to be used must be 413 involved in the process of responding to a Map Request. This is so 414 that the policy can be enforced by the MS/MRs that are authoritative 415 for the resources in each AS. Thus, if any of the ASs a tunnel would 416 traverse does not permit the EID in question, the entire path is 417 unusable. It is key to preserve information on richness of paths in 418 the underlay. It may also be necessary to include mechanisms to 419 correlate the AS_Path topology in the underlay to the resolution of 420 mappings in the underlay. 422 5.1.1. RLOC alignment to AS_Paths 424 In order to share underlay information with the LISP control plane, 425 XTRs could provide a dedicated RLOC for each peer-AS with which its 426 underlay network AS has a peering relationship. Thus, if an AS has N 427 peering points to N different ASs then there should be N RLOCs 428 representing each XTR in the AS. Each distinct RLOC should only be 429 advertised to the peer AS for which it was instantiated. These 430 advertisements are managed by EBGP at the peering points between the 431 different networks. This way, the different RLOCs are representative 432 of the different paths through which an AS may be reached, more 433 importantly, each RLOC will be mapped unequivocaly to an AS_PATH as 434 the RLOC is advertised across the different peering points. We refer 435 to this notion of an RLOC that is only reachable via a particular AS 436 as an "AS-aligned-RLOC". The AS-aligned-RLOC concept allows the 437 forwarding over a specific AS_PATH by simply encapsulating traffic to 438 a particular RLOC. 440 Sending traffic to an EID destination by encapsulating to a 441 particular RLOC will result in the tunnel following a certain AS_PATH 442 as the specific RLOC should only be allowed in specific ASs. 444 5.2. Sender/Ingress Policies 446 In a scenarion in which multiple AS_Paths may be followed to arrive 447 at the ETR for a particular EID, a sender should be able to select a 448 preferred path over which to send traffic for a specific location. 449 The selection criteria is based on a subjective score given to each 450 peer service based on negotiated peering agreements. For instance, a 451 particular organization may have secured a better rate or 452 preferential treatment for certain type of traffic over specific 453 providers in the federation. When faced with multiple options to 454 transport traffic to such destinations, there will be a preferred set 455 of providers to use. Each provider is represented by an AS number 456 and for each AS the operator sending the traffic may assign a 457 preference score. Since the AS-PATH to the different RLOCs is 458 registered in the LISP Mapping Database, it is possible to calculate 459 a score of preference for different paths. The MS/MR sending the 460 Map-Response to the requesting ITR will be able to set the LISP 461 priorities and weights in the RLOC set of the mappings for these 462 destinations and prioritize the use of paths with better negotiated 463 terms over paths with a less beneficial agreement. The 464 implementation of a preference score for the different ASs may open 465 interesting applications such as the ability to calculate aggregate 466 scores for the evaluation of composite paths to different 467 destinations. 469 5.2.1. Application preference policies 471 In certain operations (e.g. ICAO ATN) application preferences may be 472 expressed in which a certain application should use a particular CSP 473 (AS). This is a clear example of an ingress policy in which the last 474 AS in the path must be the provider with the radio service preferred 475 for the application. As discussed in Section 6 the traffic will be 476 identified with an extended-EID in the form of a tuple of a DSCP 477 value and an IPv6 address, where the DSCP value represents the 478 specific application and the IPv6 address would represent the 479 aircraft. An alternative to this encoding is to simply provide a 480 dedicated IPv6 address to each application on the aircraft. The 481 addressing could be structured hierarchically where the aircraft uses 482 a covering prefix and the applications are represented by subnets of 483 that covering prefix. 485 6. Multi-homing 487 A host may be connected to more than one AS. This is known as multi- 488 homing. In the Civil Aviation use case, an aircraft will connect 489 simultaneously to multiple radio services, each radio service 490 ultimately connects the aircraft to a separate Conectivity Service 491 Provider (CSP) backbone. Each CSP backbone is an Autonomous System 492 in the reference model that we have provided. 494 The host will connect to different services using different 495 interfaces, however it is expected that the host will use a single IP 496 address for all interfaces. This results in an EID that is multi- 497 homed. In the Civil Aviation use case, the EID is an IPv6 prefix 498 that uniquely identifies the aircraft. It has been suggested that 499 different addresses may be used on different interfaces. 500 Nevertheless, the solution must accommodate both scenarios. 502 In a multi-homed scenario, the complete RLOC set for an EID is 503 registered to different Map-Servers. Thus, the RLOC set is merged to 504 a complete set upon resolution of the mapping. 506 In the Civil Aviation application different applications running on 507 the aircraft may be identified with different DSCP values. There may 508 be policy expressing a preference for the use of specific radio 509 services for specific applications. Thus, a DSCP+IPv6 tuple would 510 identify traffic for a particular application and this traffic should 511 be routed to the AS of the preferred radio service. 513 7. Regionalization 515 An organization, or Connectivity Service Provider (CSP), may be 516 organized in regions. Thus an organization may be in charge of 517 multiple ASs, where each AS is a regional network. The solution 518 should allow organizations to articulate intra and inter-regional 519 policies in addition to any inter-organizational policies. Some 520 examples of the types of connections expected to utilize these 521 regional networks are included in Section 10. 523 8. Host Roaming and EID preservation 525 EIDs are expected to constantly roam and attach to different 526 Connectivity Service Providers (CSPs). This behavior is combined 527 with the multi-homing behavior described in Section 6, so these are 528 multi-homed, roaming EIDs. When EIDs roam, they are expected to 529 register with the Map Servers of the organization they are connecting 530 to. Since these EIDs may be multi-homed, they may be registered in 531 multiple Map Servers at the time of roaming and the mobility updates 532 may also need to be sent back to multiple map-servers. 534 In a single AS LISP network, EIDs would not move their registration 535 from one Map Server to another, but the EIDs would remain under the 536 authority of one Map Server. There are however a few factors driving 537 the requirement for the EIDs to be re-homed to the Map-Server of the 538 CSP they are connecting to. The following list enumerates some of 539 those drivers: 541 * Resiliency and survivability. A problem in one CSP should not 542 impact aircraft connected to other CSPs 544 * Latency. Minimize RTT of signaling 546 * Authority assignment. CSPs must be able to autonomously render 547 and assure services, service levels and the enforcement of 548 policies 550 * Accountability and Audit. CSPs are accountable for all 551 communications of connected devices and must be able to show 552 complete Audit logs 554 * Trust. Limited across CSPs, governments and other stakeholders 556 9. Uberlay Deployment 558 This set of requirements originally emerged in the context of an 559 Uberlay based LISP design for the International Civil Aviation 560 Organization (ICAO). The base proposal is to have a site-overlay 561 deployed for each Connectivity Service Provider and interconnect all 562 those site overlays via the Uberlay. The Uberlay would basically be 563 an overlay network running over a multi-AS federated underlay. As 564 the design progressed, the requirements for the enforcement of 565 peering agreements that would have normally been implemented in BGP 566 became evident. The need for the LISP enabled services remains key, 567 but the requirement for the enforcement of peering agreements is also 568 critical. As these requirements are satisfied, it is important that 569 the solution proposed also works in the context of an Uberlay 570 deployment. The federation of the underlay is applicable within and 571 outside the scope of an Uberlay deployment. 573 10. ICAO use cases 575 These use cases are in reference to the solution described in the 576 Ground Based LISP draft. Please refer to [I-D.haindl-lisp-gb-atn] 577 for details and terminology. 579 10.1. Air Traffic Control 581 Air Traffic Control (ATC) communications are Regional, but cross- 582 CSPs. 584 A dedicated IP address for ATC (ATC-EID) has been proposed. 586 Policy: maintain the ATC EIDs local to the region, all CSPs involved 587 must be updated 589 10.2. Airline Operation Control 591 Airline Operation Control (AOC) communications may traverse CSPs, 592 often an Airline will work with a single global CSP. 594 A dedicated IP address for AOC (AOC-EID) has been proposed. 596 Policy: Maintain authority @ connecting CSP's. This involves Mapping 597 System Registrations, Access Control and Accountability. 599 Path preferences are expressed by aircraft and rendered by CSPs as 600 described in Section 6. 602 10.3. Multi-link 604 Aircraft connects to more than one CSP. 606 Aircraft sends communication preferences to A/G-Rs (A/G Interface) 607 per GB-LISP 609 Mappings are registered with matching Priorities and Weights 611 Aircraft signals whether it is leaving a link or adding new links 613 RTRs register the separate Aircraft mappings in the different Uberlay 614 Map Servers 616 Federated MS must merge the mappings for the aircraft 618 10.4. Path Preference 620 Some policies may dictate path restrictions based on Aircraft or 621 Airline preferences as well as CSP peering agreements. These (x)EID/ 622 Application level policies must be enforceable in the Uberlay and 623 will result in tunnels that traverse specific ASs. 625 11. Policy enforcement and Trust 627 11.1. Consensus mechanisms and enforceable evidence (data plane) 629 A malicious organization could override the Map-Reply information 630 received from another organization and violate the restrictions that 631 peering agreements may have imposed on certain flows. In order to 632 avoid the possibility of such malicious behavior, a consensus 633 mechanism involving the affected organization must be put in place. 634 Furthermore, once consensus is achieved, there must be data plane 635 mechanisms that would prevent unauthorized traffic from being sent 636 over a particular underlay-AS. The means to achieve consensus and 637 data plane verification are likely cryptographic. This is an area 638 clearly open to contributions. The mechanisms we seek should provide 639 the underlay/RLOC layer enforceable information relevant to the EID 640 space. In other words, the model should enable the enforcement of 641 EID centered policies in the underlay without the need for 642 decapsulation of the traffic. In order to do so, one option is to 643 create trusted metadata that can be used by the underlay to verify 644 the validity of a flow. The metadata would be created 645 cryptographically when consensus between the organizations is being 646 calculated. 648 11.2. Topological enforcement (RTRs) 650 Another approach to enforcing the EID restrictions posed by peering 651 agreements is to deploy RTRs at the AS Border-Routers and treat the 652 overlay as an ELP. This would allow the decapsulation of traffic and 653 the inspection of the EIDs in flight to check whether they are 654 permitted by the peering agreement. Although this makes the 655 enforcement of policy straightforward, it would require additional 656 logic for the signaling across organizations. Future revisions of 657 this document will explore this option should the workgroup not find 658 adequate consensus mechanisms with enforceable data plane metadata. 660 12. Security Considerations 662 13. IANA Considerations 664 This document has no IANA implications 666 14. Acknowledgements 668 The authors want to thank the members of the ICAO mobility Workgroup 669 for the countless hours of discussion around their requirements. 671 15. References 673 15.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, 677 DOI 10.17487/RFC2119, March 1997, 678 . 680 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 681 Discovery Protocol (MSDP)", RFC 3618, 682 DOI 10.17487/RFC3618, October 2003, 683 . 685 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 686 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 687 Protocol Specification (Revised)", RFC 4601, 688 DOI 10.17487/RFC4601, August 2006, 689 . 691 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 692 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 693 . 695 15.2. Informative References 697 [I-D.haindl-lisp-gb-atn] 698 Haindl, B., Lindner, M., Rahman, R., Comeras, M. P., 699 Moreno, V., Maino, F., and B. Venkatachalapathy, "Ground- 700 Based LISP for the Aeronautical Telecommunications 701 Network", Work in Progress, Internet-Draft, draft-haindl- 702 lisp-gb-atn-06, 6 March 2021, 703 . 706 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 707 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 708 October 2011, . 710 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 711 Locator/ID Separation Protocol (LISP)", RFC 6830, 712 DOI 10.17487/RFC6830, January 2013, 713 . 715 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 716 Locator/ID Separation Protocol (LISP) for Multicast 717 Environments", RFC 6831, DOI 10.17487/RFC6831, January 718 2013, . 720 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 721 Protocol (LISP) Map-Server Interface", RFC 6833, 722 DOI 10.17487/RFC6833, January 2013, 723 . 725 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 726 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 727 eXtensible Local Area Network (VXLAN): A Framework for 728 Overlaying Virtualized Layer 2 Networks over Layer 3 729 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 730 . 732 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 733 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 734 February 2017, . 736 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 737 (LISP) Data-Plane Confidentiality", RFC 8061, 738 DOI 10.17487/RFC8061, February 2017, 739 . 741 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 742 Smirnov, "Locator/ID Separation Protocol Delegated 743 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 744 May 2017, . 746 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 747 Separation Protocol (LISP) Multicast", RFC 8378, 748 DOI 10.17487/RFC8378, May 2018, 749 . 751 Author's Address 753 Victor Moreno 754 Cisco Systems 755 170 Tasman Drive 756 San Jose, California 95134 757 United States of America 759 Email: vimoreno@cisco.com