Network Working Group                                        V.M. Moreno
Internet-Draft                                             Cisco Systems
Intended status: Experimental                               29 July 2021
Expires: 30 January 2022

                LISP Based Multi-AS Backbone Federation


   As multiple organizations interconnect their networks through peering
   agreements, it is desirable to preserve the services enabled by a
   LISP overlay over such interconnection of independent networks.  This
   specification documents the requirements imposed by the deployment
   scenario in which multiple organizations federate their backbones
   with the objective of running a LISP overlay to enable services such
   as mobility or VPNs.  The requirements for policies, enforcement and
   authoritative control of network assets are captured from the
   perspective of the operator.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 30 January 2022.

Moreno                   Expires 30 January 2022                [Page 1]

Internet-Draft                LISP Multi-as                    July 2021

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   4
   3.  Problem statement and Requirements  . . . . . . . . . . . . .   4
   4.  Multi-organizational federated LISP Overlay Network . . . . .   8
   5.  Policies and enforcement  . . . . . . . . . . . . . . . . . .   9
     5.1.  Peering Agreement enforcement Policies  . . . . . . . . .   9
       5.1.1.  RLOC alignment to AS_Paths  . . . . . . . . . . . . .  10
     5.2.  Sender/Ingress Policies . . . . . . . . . . . . . . . . .  10
       5.2.1.  Application preference policies . . . . . . . . . . .  11
   6.  Multi-homing  . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Regionalization . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Host Roaming and EID preservation . . . . . . . . . . . . . .  12
   9.  Uberlay Deployment  . . . . . . . . . . . . . . . . . . . . .  13
   10. ICAO use cases  . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Air Traffic Control  . . . . . . . . . . . . . . . . . .  13
     10.2.  Airline Operation Control  . . . . . . . . . . . . . . .  13
     10.3.  Multi-link . . . . . . . . . . . . . . . . . . . . . . .  14
     10.4.  Path Preference  . . . . . . . . . . . . . . . . . . . .  14
   11. Policy enforcement and Trust  . . . . . . . . . . . . . . . .  14
     11.1.  Consensus mechanisms and enforceable evidence (data
            plane) . . . . . . . . . . . . . . . . . . . . . . . . .  14
     11.2.  Topological enforcement (RTRs) . . . . . . . . . . . . .  15
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     15.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

Moreno                   Expires 30 January 2022                [Page 2]

Internet-Draft                LISP Multi-as                    July 2021

1.  Introduction

   Multiple organizations often collaborate and interconnect their
   networks in order to form a larger network that can provide broader
   coverage and connectivity.  When these networks are interconnected
   the organizations enter peering agreements that specify the terms
   under which the connectivity is provided.  Part of such peering
   agreements include the specification of the IP prefixes for which a
   particular organization will agree to provide service.  Traditionally
   these inter-organizational peerings have been implemented using BGP
   and constraining the distribution of routes between the Autonomous
   Systems of the different organizations in order to enforce the
   conditions set in the peering agreements.  This is a tried and proven
   mechanism to integrate networks, but it is not easily extensible to
   include some of the services that overlay networks enable.  One
   example of an overlay service that is not easily ported into the
   native IP routing stack is mobility.  In order to support these
   services, a model for a multi-organizational federated overlay
   network is of interest.  In such a model the multiple organizations
   will peer with each other to provide underlay connectivity and will
   participate in a common overlay network for which the control plane
   will be federated in order to allow the different organizations to
   define and enforce the policies necessary to conform to their peering

   In this model, organizations will be in control of a set of xTRs, a
   series of Map Servers/Resolvers and a portion of the underlay
   topology.  Organizations will be able to author and enforce policies
   governing the reachability of EID prefixes that are registered to
   their Map Servers, as well as the policies that govern when their
   underlay may be used as a transit network for traffic flows between
   end-points registered to other organizations.  The policies enforced
   reflect the peering agreements that may exist between the different

   An important aspect of the peering relationships is the use of
   network resources provided by the portions of the underlay topology
   that are in control of each organization.  The federation mechanisms
   must therefore be aware of the underlay topology.

   These types of networks are found primarily in operations involving
   multiple governments or service providers.  Accountability, policy
   enforcement and autonomy are critical requirements for such
   organizations.  There is a high interest in the creation of a
   federated network, yet the trust levels between organizations are
   low.  Additionally, this federation must function strictly amongst
   peers, without the participation of an intermediary organization or
   any hierarchy amongst the peers.

Moreno                   Expires 30 January 2022                [Page 3]

Internet-Draft                LISP Multi-as                    July 2021

2.  Definition of Terms

   LISP related terms, notably Map-Request, Map-Reply, Ingress Tunnel
   Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-
   Resolver (MR) are defined in the LISP specification [RFC6830].

   Terms defining interactions with the LISP Mapping System are defined
   in [RFC6833].

   Terms related to the procedures for signal free multicast are defined
   in [RFC8378].

   The following terms are here defined to facilitate the descriptions
   and discussions within this particular document.

   Organization - An administrative domain which is part of the
   federation.  An organization controls a series of xTRs, Map-Servers/
   Resolvers (MS/MR), portions of the underlay topology, and is
   authoritative for the EIDs registered with its MS/MRs.

   Underlay-AS - The autonomous system which includes all routers,
   control plane and RLOC prefixes for an organization.  Underlay-AS
   will connect to each other at specific BGP peering points at which
   only underlay routing information is exchanged.

   Federated Overlay - The overlay network established collaboratively
   between multiple organizations over a multitude of interconnected

3.  Problem statement and Requirements

   The objective is the creation of a cross organizational overlay
   network that would leverage a multi-as underlay to provide a common
   backbone across the different organizations.  The organizations
   should be able to define and enforce policies and agreements around
   the connectivity that will be provided for EID prefixes.  These
   policies are relevant to the use of links and routers in the underlay
   within the boundaries of the different ASs, but are instantiated and
   enforced in the overlay, where the EIDs reside.  Agreements around
   RLOC prefix reachability in the underlay should also be possible.
   All LISP services such as mobility, multi-homing, segmentation,
   Explicit Locator Paths, Signal Free Multicast, etc. should be
   available in this multi-AS backbone.  At the same time, in order to
   maintain control and administrative delineation between the
   organizations, each organization will own and operate a set of MS/MRs
   that participate in the multi-organization LISP Mapping System.

Moreno                   Expires 30 January 2022                [Page 4]

Internet-Draft                LISP Multi-as                    July 2021

   The following reference topology may be used to illustrate possible
   multi-AS underlay connectivity scenarios over which a LISP overlay is
   to be deployed as well as the types of policies, peering agreements
   and transit scenarios that may need to be supported.

           +------------------+               +-------------------+
           |                  |               |                   |
           |    +------+      |               |         +------+  |
           |    |MSMR D|      |               |         |MSMR E|  |
           |    +------+      |               |         +------+  |
           |               +--+-+           +-+--+                |
        +--+--+            |ASBR+-----------+ASBR|             +--+--+
EID-D   |XTR D|            +--+-+           +-+--+             |XTR E|   EID-E
        +--+--+               |               |                +--+--+
           |                  |               |                   |
           | AS-D     +----+  |               |   +----+    AS-E  |
           +----------+ASBR+--+               +---+ASBR+----------+
                      +--+-+                      +--+-+
                         |                           |
                         |                           |
                         |                           |
                      +--+-+                      +--+-+
           +----------+ASBR+--+               +---+ASBR+----------+
           |          +----+  |               |   +----+          |
           |                  |               |                   |
           |    +------+      |               |         +------+  |
           |    |MSMR A|      |               |         |MSMR B|  |
           |    +------+   +--+-+           +-+--+      +------+  |
        +--+--+            |ASBR+-----------+ASBR|             +--+--+
EID-A   |XTR A|            +--+-+           +-+--+             |XTR B|   EID-B
        +--+--+               |               |                +--+--+
           |                  |               |                   |
           | AS-A     +----+  |               |   +----+    AS-B  |
           +----------+ASBR+--+               +---+ASBR+----------+
                      +-+--+                      +--+-+
                        |                            |
                      +-+--+                      +--+-+
               |      +----+                      +----+   |
               |                  +------+                 |
               |                  |MSMR C|                 |
               |                  +------+                 |
               |                                           |
               | AS-C             +-----+                  |


Moreno                   Expires 30 January 2022                [Page 5]

Internet-Draft                LISP Multi-as                    July 2021

               Figure 1. Multi-AS backbone with LISP overlay

   Figure 1 shows 5 organizations with a partial connectivity mesh in
   the underlay.  Each organization is represented by one AS.  The AS-
   border routers are underlay routers interconnecting the ASs with EBGP
   and have no awareness of the overlay.  From an overlay perspective,
   all organizations are actually part of the same overlay network,
   however the ownership and control of XTR and MS/MR resources is
   scoped by organization within the confines of each AS.

   From the perspective of the connectivity that could be established
   between EID-A and EID-B in the topology of Figure 1, these are some
   of the possible scenarios that could be encountered:

   *  No transit: EID-B is allowed in AS-A and B, but not allowed in AS-
      C, D or E.  The only possible path is the direct peering point
      between AS-A and B

   *  Single AS transit: EID-B is allowed in AS-A, B and C.  EID-B is
      not allowed elsewhere.  AS-C is a possible path for the flow
      between EID-A and EID-B, AS-C would serve as a transit AS for this
      connection.  AS-A would have two possibe paths over which to
      establish the connection with EID-B, the decision on which path to
      use would be based on a local policy at AS-A that would factor the
      terms given to A to use the different ASs in the available paths.

   *  Multi-AS transit: EID-B is allowed in AS-A, B, D and E.  The path
      that traverses AS-D and AS-E is a viable path for the session
      between EID-A and EID-B.  A local ingress policy at AS-A may
      determine if this path is to be used vs. other paths such as the
      direct peering or going over AS-C.  It is important to note that
      for the D,E path to be viable, both AS-D and AS-E must have an
      agreement in which they commit to transporting data for EID-B.  If
      either one of these ASs does not have this agreement, the path
      would not be viable and should not be used.

   The solution provided must allow the evaluation of the viability of
   different paths based on the peering agreements between
   organizations, which would allow or deny specific prefixes from being
   serviced by certain ASs.

   When multiple viable paths are available, the solution should permit
   the definition and enforcement of policies that can be used by the
   ingress AS to select the preferred path for the forwarding of a
   certain flow.  The terms of service over different paths may differ,
   leading to preferences in using the services of one AS over another.

Moreno                   Expires 30 January 2022                [Page 6]

Internet-Draft                LISP Multi-as                    July 2021

   EIDs must be able to move from one AS to another.  All EIDs connected
   to an AS must be registered with the MSMR in that AS and fold under
   the authority of that AS's MSMR.  This is required in order to
   maintain accountability aligned with the AS providing service to a
   particular EID.

   Each organization owns and controls fully all network elements in
   their AS, this includes XTRs, ASBRs, MSMRs as well as any underlay
   routers within the AS.

   The following is a summary list of requirements pertinent to this

   *  Organizations should be able to interconnect their backbone
      networks at agreed upon peering points and form a multi-AS
      federated underlay.

   *  Organizations should be able to participate in a common LISP
      overlay over the top of the multi-AS federated underlay.

   *  Ideally the organizations will be able to tunnel traffic directly
      between XTRs belonging to different organizations without
      requiring the deployment of RTRs at the boundaries of the domains.

   *  Peering agreements can be enforced in the underlay control plane
      to influence the multi-AS routing structure in the underlay RLOC

   *  It must be possible to define and enforce peering agreements and
      policies relevant to EID-prefixes.

   *  All peering and policy is to be negotiated in a federated manner.
      There should not be a need for an intermediary organization that
      brokers connectivity or policy between members of the federation.

   *  An organization should be able to restrict which flows use their
      network resources (underlay)

   *  Policies may allow or deny connectivity to specific prefixes over
      portions of the topology belonging to a particular organization.

   *  Policies may allow or deny transit services to specific prefixes
      over portions of the topology belonging to a particular

   *  Organizations may structure their presence in the federation
      regionally.  Thus an organization may have multiple instances
      participate in the federation. e.g.  Org-A-East and Org-A-West.

Moreno                   Expires 30 January 2022                [Page 7]

Internet-Draft                LISP Multi-as                    July 2021

   *  An organization is responsible, accountable and authoritative for
      any host connected to its network (XTRs).  Thus, a roaming host
      must register to the Mapping System for the organization it is
      connected to.

   *  A roaming host should be able to keep its EID constant as it

   *  A host may connect to more than one AS.  The host may use
      dedicated EIDs per interface or may use a single EID across all
      interfaces, both cases must be considered.

   *  An organization should own and control the XTRs in their network.

   *  An organization should own and control all routes in its Underlay-

   *  Each organization should own and control their own set of MS/MRs.

   *  Each organization should be able to define and enforce
      reachability policies for the EIDs attached to it on the MS/MRs it

   *  An organization presented with multiple possible paths to reach a
      particular remote destination should be able to define a
      preference policy amongst the different paths.

   The following sections discuss some of these requirements in more

4.  Multi-organizational federated LISP Overlay Network

   In a multi-organizational network, the underlay is a collection of
   interconnected independent networks, each of which is owned and
   operated by a different organization.  The different networks are
   interconnected at EBGP peering points.  Given the use of Location-
   Identity separation, the peering policies enforced by EBGP at these
   peering points will be effective on the RLOCs used in the underlay
   only.  All peering policies for the EID prefixes must be handled in
   the overlay control plane, which may be, in this case, a federation
   of MS/MRs.

Moreno                   Expires 30 January 2022                [Page 8]

Internet-Draft                LISP Multi-as                    July 2021

   Over the top of this underlay, an overlay network is deployed, to
   include XTRs and MS/MRs.  Each organization will be in control of the
   XTRs that are directly connected to their underlay network.
   Furthermore, each organization will have its own set of MS/MRs that
   it will own and control.  One could think of this as a single overlay
   network in which different portions of the network are owned and
   controlled by different organizations.

   The MS/MRs of the different organizations will federate with each
   other without an intermediary and they will handle the resolution of
   EID to RLOC mappings within and across organizations.  The MS/MRs of
   each organization are authoritative for the EID-RLOC mapping
   information for EIDs directly connected to their network, but also
   for the enforcement of policies governing the handling of EID traffic
   that may use the organization's network as a transit network.

5.  Policies and enforcement

   The policies to be enforced will derive mainly from the peering
   agreements between organizations.  These are the policies related to
   the handling of connectivity for EID prefixes and whether specific
   prefixes may be serviced by a specific AS or not.  Although the EIDs
   are handled in the overlay control plane, the enforcement of the
   policies must correlate to the use of the resources in the underlay
   topology in the different ASs.  For instance, if an AS does not
   permit forwarding of traffic for a specific EID prefix, any tunnels
   established to send traffic to that prefix may not traverse any links
   in the underlay that belong to the AS that does not permit the

5.1.  Peering Agreement enforcement Policies

   Based on their peering agreements, organizations may or may not allow
   the servicing of traffic for specific EID-prefixes.  Traditionally
   this has been enforced by including or excluding the advertisment of
   routes into the specific ASs.  In the demand model used in LISP, the
   equivalent would be to provide or withold a valid mapping for the
   destination from a map-response.  Thus, the MS/MRs for all
   organizations in the possible underlay AS_Paths to be used must be
   involved in the process of responding to a Map Request.  This is so
   that the policy can be enforced by the MS/MRs that are authoritative
   for the resources in each AS.  Thus, if any of the ASs a tunnel would
   traverse does not permit the EID in question, the entire path is
   unusable.  It is key to preserve information on richness of paths in
   the underlay.  It may also be necessary to include mechanisms to
   correlate the AS_Path topology in the underlay to the resolution of
   mappings in the underlay.

Moreno                   Expires 30 January 2022                [Page 9]

Internet-Draft                LISP Multi-as                    July 2021

5.1.1.  RLOC alignment to AS_Paths

   In order to share underlay information with the LISP control plane,
   XTRs could provide a dedicated RLOC for each peer-AS with which its
   underlay network AS has a peering relationship.  Thus, if an AS has N
   peering points to N different ASs then there should be N RLOCs
   representing each XTR in the AS.  Each distinct RLOC should only be
   advertised to the peer AS for which it was instantiated.  These
   advertisements are managed by EBGP at the peering points between the
   different networks.  This way, the different RLOCs are representative
   of the different paths through which an AS may be reached, more
   importantly, each RLOC will be mapped unequivocaly to an AS_PATH as
   the RLOC is advertised across the different peering points.  We refer
   to this notion of an RLOC that is only reachable via a particular AS
   as an "AS-aligned-RLOC".  The AS-aligned-RLOC concept allows the
   forwarding over a specific AS_PATH by simply encapsulating traffic to
   a particular RLOC.

   Sending traffic to an EID destination by encapsulating to a
   particular RLOC will result in the tunnel following a certain AS_PATH
   as the specific RLOC should only be allowed in specific ASs.

5.2.  Sender/Ingress Policies

   In a scenarion in which multiple AS_Paths may be followed to arrive
   at the ETR for a particular EID, a sender should be able to select a
   preferred path over which to send traffic for a specific location.
   The selection criteria is based on a subjective score given to each
   peer service based on negotiated peering agreements.  For instance, a
   particular organization may have secured a better rate or
   preferential treatment for certain type of traffic over specific
   providers in the federation.  When faced with multiple options to
   transport traffic to such destinations, there will be a preferred set
   of providers to use.  Each provider is represented by an AS number
   and for each AS the operator sending the traffic may assign a
   preference score.  Since the AS-PATH to the different RLOCs is
   registered in the LISP Mapping Database, it is possible to calculate
   a score of preference for different paths.  The MS/MR sending the
   Map-Response to the requesting ITR will be able to set the LISP
   priorities and weights in the RLOC set of the mappings for these
   destinations and prioritize the use of paths with better negotiated
   terms over paths with a less beneficial agreement.  The
   implementation of a preference score for the different ASs may open
   interesting applications such as the ability to calculate aggregate
   scores for the evaluation of composite paths to different

Moreno                   Expires 30 January 2022               [Page 10]

Internet-Draft                LISP Multi-as                    July 2021

5.2.1.  Application preference policies

   In certain operations (e.g.  ICAO ATN) application preferences may be
   expressed in which a certain application should use a particular CSP
   (AS).  This is a clear example of an ingress policy in which the last
   AS in the path must be the provider with the radio service preferred
   for the application.  As discussed in Section 6 the traffic will be
   identified with an extended-EID in the form of a tuple of a DSCP
   value and an IPv6 address, where the DSCP value represents the
   specific application and the IPv6 address would represent the
   aircraft.  An alternative to this encoding is to simply provide a
   dedicated IPv6 address to each application on the aircraft.  The
   addressing could be structured hierarchically where the aircraft uses
   a covering prefix and the applications are represented by subnets of
   that covering prefix.

6.  Multi-homing

   A host may be connected to more than one AS.  This is known as multi-
   homing.  In the Civil Aviation use case, an aircraft will connect
   simultaneously to multiple radio services, each radio service
   ultimately connects the aircraft to a separate Conectivity Service
   Provider (CSP) backbone.  Each CSP backbone is an Autonomous System
   in the reference model that we have provided.

   The host will connect to different services using different
   interfaces, however it is expected that the host will use a single IP
   address for all interfaces.  This results in an EID that is multi-
   homed.  In the Civil Aviation use case, the EID is an IPv6 prefix
   that uniquely identifies the aircraft.  It has been suggested that
   different addresses may be used on different interfaces.
   Nevertheless, the solution must accommodate both scenarios.

   In a multi-homed scenario, the complete RLOC set for an EID is
   registered to different Map-Servers.  Thus, the RLOC set is merged to
   a complete set upon resolution of the mapping.

   In the Civil Aviation application different applications running on
   the aircraft may be identified with different DSCP values.  There may
   be policy expressing a preference for the use of specific radio
   services for specific applications.  Thus, a DSCP+IPv6 tuple would
   identify traffic for a particular application and this traffic should
   be routed to the AS of the preferred radio service.

Moreno                   Expires 30 January 2022               [Page 11]

Internet-Draft                LISP Multi-as                    July 2021

7.  Regionalization

   An organization, or Connectivity Service Provider (CSP), may be
   organized in regions.  Thus an organization may be in charge of
   multiple ASs, where each AS is a regional network.  The solution
   should allow organizations to articulate intra and inter-regional
   policies in addition to any inter-organizational policies.  Some
   examples of the types of connections expected to utilize these
   regional networks are included in Section 10.

8.  Host Roaming and EID preservation

   EIDs are expected to constantly roam and attach to different
   Connectivity Service Providers (CSPs).  This behavior is combined
   with the multi-homing behavior described in Section 6, so these are
   multi-homed, roaming EIDs.  When EIDs roam, they are expected to
   register with the Map Servers of the organization they are connecting
   to.  Since these EIDs may be multi-homed, they may be registered in
   multiple Map Servers at the time of roaming and the mobility updates
   may also need to be sent back to multiple map-servers.

   In a single AS LISP network, EIDs would not move their registration
   from one Map Server to another, but the EIDs would remain under the
   authority of one Map Server.  There are however a few factors driving
   the requirement for the EIDs to be re-homed to the Map-Server of the
   CSP they are connecting to.  The following list enumerates some of
   those drivers:

   *  Resiliency and survivability.  A problem in one CSP should not
      impact aircraft connected to other CSPs

   *  Latency.  Minimize RTT of signaling

   *  Authority assignment.  CSPs must be able to autonomously render
      and assure services, service levels and the enforcement of

   *  Accountability and Audit.  CSPs are accountable for all
      communications of connected devices and must be able to show
      complete Audit logs

   *  Trust.  Limited across CSPs, governments and other stakeholders

Moreno                   Expires 30 January 2022               [Page 12]

Internet-Draft                LISP Multi-as                    July 2021

9.  Uberlay Deployment

   This set of requirements originally emerged in the context of an
   Uberlay based LISP design for the International Civil Aviation
   Organization (ICAO).  The base proposal is to have a site-overlay
   deployed for each Connectivity Service Provider and interconnect all
   those site overlays via the Uberlay.  The Uberlay would basically be
   an overlay network running over a multi-AS federated underlay.  As
   the design progressed, the requirements for the enforcement of
   peering agreements that would have normally been implemented in BGP
   became evident.  The need for the LISP enabled services remains key,
   but the requirement for the enforcement of peering agreements is also
   critical.  As these requirements are satisfied, it is important that
   the solution proposed also works in the context of an Uberlay
   deployment.  The federation of the underlay is applicable within and
   outside the scope of an Uberlay deployment.

10.  ICAO use cases

   These use cases are in reference to the solution described in the
   Ground Based LISP draft.  Please refer to [I-D.haindl-lisp-gb-atn]
   for details and terminology.

10.1.  Air Traffic Control

   Air Traffic Control (ATC) communications are Regional, but cross-

   A dedicated IP address for ATC (ATC-EID) has been proposed.

   Policy: maintain the ATC EIDs local to the region, all CSPs involved
   must be updated

10.2.  Airline Operation Control

   Airline Operation Control (AOC) communications may traverse CSPs,
   often an Airline will work with a single global CSP.

   A dedicated IP address for AOC (AOC-EID) has been proposed.

   Policy: Maintain authority @ connecting CSP's.  This involves Mapping
   System Registrations, Access Control and Accountability.

   Path preferences are expressed by aircraft and rendered by CSPs as
   described in Section 6.

Moreno                   Expires 30 January 2022               [Page 13]

Internet-Draft                LISP Multi-as                    July 2021

10.3.  Multi-link

   Aircraft connects to more than one CSP.

   Aircraft sends communication preferences to A/G-Rs (A/G Interface)
   per GB-LISP

   Mappings are registered with matching Priorities and Weights

   Aircraft signals whether it is leaving a link or adding new links

   RTRs register the separate Aircraft mappings in the different Uberlay
   Map Servers

   Federated MS must merge the mappings for the aircraft

10.4.  Path Preference

   Some policies may dictate path restrictions based on Aircraft or
   Airline preferences as well as CSP peering agreements.  These (x)EID/
   Application level policies must be enforceable in the Uberlay and
   will result in tunnels that traverse specific ASs.

11.  Policy enforcement and Trust

11.1.  Consensus mechanisms and enforceable evidence (data plane)

   A malicious organization could override the Map-Reply information
   received from another organization and violate the restrictions that
   peering agreements may have imposed on certain flows.  In order to
   avoid the possibility of such malicious behavior, a consensus
   mechanism involving the affected organization must be put in place.
   Furthermore, once consensus is achieved, there must be data plane
   mechanisms that would prevent unauthorized traffic from being sent
   over a particular underlay-AS.  The means to achieve consensus and
   data plane verification are likely cryptographic.  This is an area
   clearly open to contributions.  The mechanisms we seek should provide
   the underlay/RLOC layer enforceable information relevant to the EID
   space.  In other words, the model should enable the enforcement of
   EID centered policies in the underlay without the need for
   decapsulation of the traffic.  In order to do so, one option is to
   create trusted metadata that can be used by the underlay to verify
   the validity of a flow.  The metadata would be created
   cryptographically when consensus between the organizations is being

Moreno                   Expires 30 January 2022               [Page 14]

Internet-Draft                LISP Multi-as                    July 2021

11.2.  Topological enforcement (RTRs)

   Another approach to enforcing the EID restrictions posed by peering
   agreements is to deploy RTRs at the AS Border-Routers and treat the
   overlay as an ELP.  This would allow the decapsulation of traffic and
   the inspection of the EIDs in flight to check whether they are
   permitted by the peering agreement.  Although this makes the
   enforcement of policy straightforward, it would require additional
   logic for the signaling across organizations.  Future revisions of
   this document will explore this option should the workgroup not find
   adequate consensus mechanisms with enforceable data plane metadata.

12.  Security Considerations

13.  IANA Considerations

   This document has no IANA implications

14.  Acknowledgements

   The authors want to thank the members of the ICAO mobility Workgroup
   for the countless hours of discussion around their requirements.

15.  References

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC3618]  Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
              Discovery Protocol (MSDP)", RFC 3618,
              DOI 10.17487/RFC3618, October 2003,

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601,
              DOI 10.17487/RFC4601, August 2006,

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,

Moreno                   Expires 30 January 2022               [Page 15]

Internet-Draft                LISP Multi-as                    July 2021

15.2.  Informative References

              Haindl, B., Lindner, M., Rahman, R., Comeras, M. P.,
              Moreno, V., Maino, F., and B. Venkatachalapathy, "Ground-
              Based LISP for the Aeronautical Telecommunications
              Network", Work in Progress, Internet-Draft, draft-haindl-
              lisp-gb-atn-06, 6 March 2021,

   [RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
              of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
              October 2011, <>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, DOI 10.17487/RFC6831, January
              2013, <>.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              DOI 10.17487/RFC6833, January 2013,

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,

   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
              February 2017, <>.

   [RFC8061]  Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
              (LISP) Data-Plane Confidentiality", RFC 8061,
              DOI 10.17487/RFC8061, February 2017,

Moreno                   Expires 30 January 2022               [Page 16]

Internet-Draft                LISP Multi-as                    July 2021

   [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
              Smirnov, "Locator/ID Separation Protocol Delegated
              Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
              May 2017, <>.

   [RFC8378]  Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
              Separation Protocol (LISP) Multicast", RFC 8378,
              DOI 10.17487/RFC8378, May 2018,

Author's Address

   Victor Moreno
   Cisco Systems
   170 Tasman Drive
   San Jose, California 95134
   United States of America


Moreno                   Expires 30 January 2022               [Page 17]