| Internet-Draft | draft-haindl-lisp-gb-atn | March 2022 |
| Haindl, et al. | Expires 23 September 2022 | [Page] |
This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization.¶
The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 23 September 2022.¶
Copyright (c) 2022 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 (https://trustee.ietf.org/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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes the use of the LISP [RFC6830] architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS), as articulated by the International Civil Aviation Organization (ICAO).¶
ICAO is proposing to replace the existing aeronautical communication services with an IPv6 based infrastructure that supports Air Traffic Management (ATM) between commercial aircrafts, Air Traffic Controllers (ATC) and Air Operation Controllers (AOC).¶
This document describes how a LISP overlay can be used to offer mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts without requiring LISP support in the airborne routers. Use of the LISP protocol is limited to the ground-based routers, hence the name "ground-based LISP". The material for this document is derived from [GBL].¶
For definitions of other terms, notably Map-Register, Map-Request, Map-Reply, Routing Locator (RLOC), Solicit-Map-Request (SMR), Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), xTR (ITR or ETR), Map-Server (MS), and Map-Resolver (MR) please consult the LISP specification [RFC6830].¶
In the ATN/IPS architecture the airborne endsystems hosted on an aircraft are part of an IPV6 network connected to the ground network by one or more Airborne Routers (A-R). A-Rs have multiple radio interfaces that connects them via various radios infrastructures (e.g. SATCOM, LDACS, AeroMACS) to a given radio region, also known as subnetwork, on the ground. Typically an A-R has a corresponding ground based Access Router (AC-R) that terminates the radio protocol with the A-R and provides access services to the ground based portion of the radio network infrastructure. Each radio region is interconnected with the ATN/IPS ground network via an Air-to-Ground router (AG-R).¶
Similarly, the Air Traffic Controllers and Air Operation Controllers Endsystems (ATS-E and AOC-E) are part of IPv6 networks reachable via one or more Ground-to-Ground Routers (G/G-Rs).¶
The ATN/IPS ground network infrastructure is the internetworking region located between the A/G routers and the G/G routers.¶
In the ground-based LISP architecture, a LISP overlay is laid over the ATN/IPS internetworking region (that is in the LISP RLOC space) and provides connectivity between endsystems (that are in the LISP EID space) hosted in the aircrafts and in the AOC/ATS regions. The A/G-Rs and the G/G-Rs assume the role of LISP xTRs supported by a LISP mapping system infrastructure.¶
,------,
,---------. : A-E1 :
,' `./'------'
( AIRCRAFT )
`. +-----+ ,'\ ,------,
`-| A-R |-' \: A-E2 :
+-----+ '------'
// \\
// \\
+---+--+ +-+--+--+
.--.-.| AC-R1|'.-. .| AC-R2 |.-.
( +---+--+ ) ( +-+--+--+ )
( __. ( '.
..'SATCOM Region ) .' LDACS Region )
( .'-' ( .'-'
' +-------+ ) ' +-------+ )
'-| A/G-R |-' '-| A/G-R |-''
| | | |
| xTR1 | | xTR2 |
+-------+ +-------+
\ /
\ .--..--. .--. ../
\ ( ' '.--.
.-.' Internetworking '' '-------'
( region )--: MS/MR :
( (RLOC SPACE) '-'' '-------'
._.'--'._.'.-._.'.-._)
/ \
+---+---+ +-+--+--+
-.-.| G/G-R |'. .| G/G-R |.
( | | ) ( | | )
( | xTR3 | ) ( | xTR4 | )
( +---+---+ ) ( +-+--+--+ )
( _._. ( '.
..' ATS Region ) .' AOC Region )
( .'-' ( .'-'
'--'._.'. )\ '--'._.'. )\
/ '--' \ / '--' \
'--------' '--------' '--------' '--------'
: ATS-E1 : : ATS-E2 : : AOC-E1 : : AOC-E2 :
'--------' '--------' '--------' '--------'
Endsystems in the AOC/ATS regions are mapped in the LISP overlay by the G/G-Rs, that are responsible for the registration of the AOC/ATS endsystems to the LISP mapping system. Each G/G-R is basically an xTR which has direct connections only to the terrestrial regions, i.e. no direct connection to the radio regions.¶
Aircrafts will attach to a specific radio region, via the radio interfaces of the A-Rs. How the radio attachment works is specific to each particular radio infrastructure, and out of the scope of this document, see [GBL].¶
Typically at the end of the attachment phase, the access router (AC-R) corresponding to the A-R, will announce the reachability of the EID prefixes corresponding to the attached aircraft (the announcement is specific to each particular radio infrastructure, and is out of the scope of this document). A/G-Rs in that particular radio region are responsible to detect those announcements, and, since they act as xTRs, register to the LISP mapping systems the corresponding IPv6 EID prefixes on behalf of the A-R, but with the RLOC of the A/G-R.¶
The EID prefixes registered by the A/G-Rs are then reachable by any of the AOC/ATS Endsystems that are part of the ground based LISP overlay.¶
The LISP infrastructure is used to support seamless aircraft mobility from one radio network to another, as well as multi-homing attachment of an aircraft to multiple radio networks with use of LISP weight and priorities to load balance traffic directed toward the aircraft.¶
The rest of this document provides further details on how ground-based LISP is used to address the requirements of the ATN/IPS use cases. The main design goals are:¶
minimize added complexity on the aircraft¶
minimize complexity of ground deployment¶
Figure 1 provides the reference topology for a description of the basic operation. A more detailed description of the basic protocol operation is described in [GBL].¶
The following are the steps via which airborne endsystem prefixes are registered with the LISP mapping system:¶
Ground based endsystems are part of ground subnetworks where the Ground/Ground Router (G/G-R) is an xTR. Each G/G-R therefore registers the prefixes corresponding to the AOC endsystems and ATS endsystems with the LISP mapping system, as specified in [RFC6830].¶
Here is an example of how traffic flows from the ground to the airborne endsystems, when ATS endsystem 1 (ATS-E1) has traffic destined to airborne endsystem 1 (A-E1):¶
Here is an example of how traffic flows from the airborne endsystems to the ground when airborne endsystem 2 (A-E2) has traffic destined to ATS endsystem 2 (ATS-E2):¶
When an xTR is waiting for a Map-Reply for an EID, the xTR does not know how to forward the packets destined to that EID. This means that the first packets for ground-to-air traffic would get dropped until the Map-Reply is received and a map-cache entry is created. However if a device acting as RTR, see [I-D.ermagan-lisp-nat-traversal], has mappings for all EIDs, the xTR could use the RTR as default path for packets which have to be encapsulated. How the RTR gets all the mappings is outside the scope of this document but one example is the use of LISP pub-sub as specified in [I-D.ietf-lisp-pubsub]. Note that the RTR does not have to be a new device, the device which has the MS/MR role can also act as RTR. It is only the RTR which needs to subscribe to all the aircraft EIDs, the XTRs (i.e. the A/G-Rs and G/G-Rs) do not need to subscribe.¶
RTRs stitch two legs of a communication flow by acting as an ETR for the purposes of the first leg and as an ITR for the purposes of the second leg. As an ITR (second leg), the RTR will follow all standard procedures of an ITR (issue requests, cache mappings, subscribe to EIDs, etc). In the specific case of the first packet drop scenario, the RTR will subscribe to the entire EID space registered in the Mapping System and maintain a complete cache of all relevant destinations. Any changes to the registration state will be published promptly to the RTR using the pub/sub mechanisms. This ITR role can be made redundant by simply having each RTR in the redundancy group subscribe to the Mapping System. From an ETR perspective, the RTR will also follow all standard procedures for an ETR, but rather than registering specific prefixes, the RTRs will (optionally) register themselves as the "First Packet Handlers". The ITRs sending traffic requiring first packet handling will be configured to forward traffic to the First Packet Handlers if there isn't a mapping already cached for the destination.¶
The ITRs will know who the first packet handlers are by one of two mechanisms:¶
1. Configuration of the RLOCs of the first packet handlers on the ITR. This configuration would be done by a network management system.¶
2. Subscription of the ITR to the "First Packet Handler" EID. As First Packet Handler RLOCs are added or removed the subscribing ITRs are updated.¶
In both cases the resiliency mechanisms for the RLOCs are the same as for any other RLOC: Routing table reachability combined with optional data plane probes can be leveraged to accelerate failover. In the case in which subscriptions to the "First Packet Handler" EID are used, the RTR will also benefit from the updates in the publication to trigger failover processes.¶
The requirements for traffic symmetry are still TBD.¶
Multi-homing support builds on the procedures described in Section 4:¶
With mobility, the aircraft could want to switch traffic from one radio link to another. For example while transiting from an area covered by LDACS to an area covered by SATCOM, the aircraft could desire to switch all traffic from LDACS to SATCOM. For air-to-ground traffic, the A-R has complete control over which radio link to use, and will simply select the SATCOM outgoing interface. For ground-to-air traffic:¶
The procedure for mobility is derived from [I-D.ietf-lisp-eid-mobility].¶
When traffic is flowing on a radio link and that link goes down, the network has to converge rapidly on the other link available for that aircraft.¶
For air-to-ground traffic, once the A-R detects the failure it can switch immediatly to the other radio link.¶
For ground-to-air traffic, when a radio link fails, the corresponding AC-R sends a reachability update that the IPv6 EID prefixes are not reachable anymore. This leads to the A/G-R (also an xTR) in that region to unregister the IPv6 EID prefixes with the MS/MR. This indicates that the xTR in question has no reachability to the EID prefixes. The notification of the failure should reach all relevant xTRs as soon as possible. For example, if the LDACS radio link fails, xTR3 and xTR4 need to learn about the failure so that they stop sending traffic via xTR2 and use xTR1 instead.¶
In the sub-sections below, we the use of RLOC-probing, Solicit-Map-Request, and LISP pub-sub as alternative mechanisms for link failure notification.¶
RLOC-probing is described in section 6.3.2 of [RFC6830].¶
At regular intervals xTR3 sends Map-Request to xTR2 for the aircraft's EID prefixes. When xTR3 detects via RLOC-probing that it can not use xTR2 anymore, it sends a Map-Request for the aircraft's EID prefixes. The corresponding Map-Reply indicates that xTR1 should now be used. The map-cache on xTR3 is updated and air-to-ground traffic now goes through xTR1 to use the SATCOM radio link to the aircraft.¶
The disadvantage of RLOC-probing is that fast detection becomes more difficult when the number of EID prefixes is large.¶
Solicit-Map-Request is used as described in Section 5:¶
The disadvantage of this approach is that the traffic is delayed pending control-plane resolution. This method also depends on data traffic being continuous, in many cases data traffic may be sporadic, leading to very slow convergence.¶
As specified in [I-D.ietf-lisp-pubsub], ITRs can subscribe to changes in the LISP mapping system. So if all ITRs subscribe to the EID prefixes for which they have traffic, the ITRs will be notified when there is mapping change.¶
In the example where the LDACS radio link fails, when xTR2 unregisters the EID prefixes with the MS/MR, xTR3 would be notified via LISP pub-sub (assuming xTR3 has a map-cache entry for these EID prefixes).¶
This mechanism provides the fastest convergence at the cost of more state in the LISP mapping system.¶
The overlay on the ATN/IPS can be structured as a collection of independent administrative domains following the model defined in [I-D.moreno-lisp-uberlay]. In this model, the different administrative domains are interconnected by a transit area referred to as an uberlay. Each administrative domain is independent from the perspective of the control, data and administrative planes. Structuring the ATN/IPS in this manner allows the combination of different implementations and even different mobility methods in the ATN/IPS. The structure proposed also improves resiliency by isolating events and failures across the different administrative domains and improves the scale of the ATN/IPS by distributing the responsibility of maintaining granular aircraft state across the different administrative domains.¶
The uberlay may be a BGP network as defined in [I-D.templin-atn-bgp]. Following the definitions put forth in [I-D.templin-atn-bgp], the uberlay transit is the core autonomous system and the different administrative domains that conform the ATN/IPS are what [I-D.templin-atn-bgp] defines as stub autonomous systems.¶
For LISP control-plane message security, please refer to [I-D.ietf-lisp-sec]. This addresses the control-plane threats that target EID-to-RLOC mappings, including manipulations of Map-Request and Map-Reply messages, and malicious ETR EID prefix overclaiming.¶
The LISP specification, documented in [RFC6830bis] and [RFC6833bis], includes basic security mechanisms for the control plane. The base mechanisms are designed to prevent rogue unauthorized ETRs from registering mappings into the Mapping System and to protect ITRs from receiving unsolicited mapping information. To authenticate EID-to-RLOC mapping registrations and ensure that they are from an authorized ETR, LISP uses shared secret keys between ETRs and the Mapping System. Only ETRs that have the shared secret key are able to register EID-to-RLOC mappings to the Mapping System. Without the correct key, the authenticity of the map-register message cannot be verified, and the Mapping System must reject the map-register. The shared keys used to authenticate map-registers are distributed across ETRs and MS/MRs by the orchestration/configuration infrastructure. The shared keys need to be distributed between the xTR and the Mapping System. Since these components will be in the same administrative domain in GB-LISP, it would be feasible to implement a method for this key exchange (see Clause 6.5 in [LISP-SEC]. In addition to authenticating EID registrations, it is recommended that the Mapping System restricts EID registrations to configured EID prefix ranges. Thus, an authorized ETR is allowed to register EID prefixes only within the EID prefix range configured in the Map-Server. The confidentiality of the LISP control plane messages can be ensured by protecting the transport of control messages with DTLS (over UDP) [RFC6347] or LISP-crypto [RFC8061]. DTLS is also proposed in Clause 6.7 of [LISP-SEC] for providing message privacy.¶
Data-plane gleaning [Clause 9 in RFC6830bis] might need to be turned off for avoiding potential attacks by forged data plane packets that could overload the control plane. Another approach is data fusion between multiple reachability verification mechanisms. Generic control plane protection mechanism, such as packet filtering and rate control, should be also deployed for GB-LISP nodes based on a risk assessment. This could mitigate such attacks that try to misuse the Map-Versioning mechanism in the data-plane for overloading the control-plane.¶
The Internet Draft [LISP-SEC] defines a set of security mechanisms (usually referred as LISP-SEC) to provide origin authentication, integrity, and antireplay protection to the EID-to-RLOC mapping data conveyed in the map-resolution process. It includes the usage of multiple one-time-keys (OTK) and hash based message authentication. LISP-SEC also enables authorization verification on EID-prefixes claims made by ETRs, preventing so-called "overclaiming attacks" in which an ETR attempts to claim EID-prefixes for which it is not authoritative. A LISP-SEC protected map-reply, in fact, includes metadata authenticated by the map-server that specify which¶
The communication with the Mappin Systems is originally proposed based on UDP that is not a reliable transport. For a proper synchronization between the ETR and the Map-Servers periodic message transmission would be needed. Usually, Map-Register messages are retransmitted every minute by the ETR. The Map-Server removes the EID entries if they are not refreshed for three successive periods. In mobility solutions, typically a large number of EID entries needs to be registered. Because of packet size limitations these entries can be transported only by a significant number of Map-Register messages in each period. A new reliable transport option has been defined in [LISP-RELT] to solve these issues. Although this Internet Draft has been expired, the new method is used in the latest widely deployed LISP solution for Software Defined Access (SDA) by Cisco Systems. The reliable transport is composed by new message formats and the support for other then UDP as a transport in the control plane. Both TCP and SCTP is addressed by the specification. The TCP implementation could be traced in the labs. The messages are based on a TLV format where a type filed support the future extensions of the protocol. A message end marker provides extra integrity check possibility for complex aggregated messages. Error notification messages are also specified for notifying situations when the receiver does not recognize or cannot parse message contents. The following message types are specified for the reliable transport mechanism: o Map-Register, o Registration acknowledgement, o Registration rejection, o Registration refresh, o Mapping notification, The session establishment has to be backward compatible. The Map Server authenticates the ETR first using UDP based messages. Once the ETR is authenticated, the Map Server performs a passive open by listening on TCP port 4342. TCP connections are accepted only from the already authenticated ETRs. The ETR has to open the TCP connection actively towards the Map Server one it has received the Map-Notify message on the UDP transport. If the TCP session goes down, the same UDP based procedure has to be repeated. The Map-Server will also revert to the expiration mechanism used for UDP transport until the TCP based session would be fully restored. A single TCP session is built up for all subsequent control plane messages. This applies even when multiple address families are used in the EID space. Once the reliable transport can be used, the periodic refresh is not needed anymore. Mapping information is sent only when there is new information to share. Time-out based removal of registrations are not used in this case. An explicit de-registration is needed by carrying a zero TTL. The reliable transport session should be authenticated. In the simpler case, it could be an RLOC spoofing mitigation. If this is not reliable, then the TCP Authentication Option [RFC5925], or the SCTP Authenticated Chunks [RFC4895] are recommended.¶
The communication with the Mappin Systems is originally proposed based on UDP that is not a reliable transport. For a proper synchronization between the ETR and the Map-Servers periodic message transmission would be needed. Usually, Map-Register messages are retransmitted every minute by the ETR. The Map-Server removes the EID entries if they are not refreshed for three successive periods. In mobility solutions, typically a large number of EID entries needs to be registered. Because of packet size limitations these entries can be transported only by a significant number of Map-Register messages in each period. A new reliable transport option has been defined in [LISP-RELT] to solve these issues. Although this Internet Draft has been expired, the new method is used in the latest widely deployed LISP solution for Software Defined Access (SDA) by Cisco Systems. The reliable transport is composed by new message formats and the support for other then UDP as a transport in the control plane. Both TCP and SCTP is addressed by the specification. The TCP implementation could be traced in the labs. The messages are based on a TLV format where a type filed support the future extensions of the protocol. A message end marker provides extra integrity check possibility for complex aggregated messages. Error notification messages are also specified for notifying situations when the receiver does not recognize or cannot parse message contents. The following message types are specified for the reliable transport mechanism: o Map-Register, o Registration acknowledgement, o Registration rejection, o Registration refresh, o Mapping notification, The session establishment has to be backward compatible. The Map Server authenticates the ETR first using UDP based messages. Once the ETR is authenticated, the Map Server performs a passive open by listening on TCP port 4342. TCP connections are accepted only from the already authenticated ETRs. The ETR has to open the TCP connection actively towards the Map Server one it has received the Map-Notify message on the UDP transport. If the TCP session goes down, the same UDP based procedure has to be repeated. The Map-Server will also revert to the expiration mechanism used for UDP transport until the TCP based session would be fully restored. A single TCP session is built up for all subsequent control plane messages. This applies even when multiple address families are used in the EID space. Once the reliable transport can be used, the periodic refresh is not needed anymore. Mapping information is sent only when there is new information to share. Time-out based removal of registrations are not used in this case. An explicit de-registration is needed by carrying a zero TTL. The reliable transport session should be authenticated. In the simpler case, it could be an RLOC spoofing mitigation. If this is not reliable, then the TCP Authentication Option [RFC5925], or the SCTP Authenticated Chunks [RFC4895] are recommended.¶
LISP inherently delivers segmentation by using extended endpoint identifiers (EIDs) and Instance-IDs to partition the EID space, segment the map-caches, and color the control and data plane messages to create virtual networks. These virtual networks are a seamless extension of the way EIDs are normally handled in LISP and therefore enjoy all the benefits of scale, mobility, and address family independence that LISP provides.¶
The communication on between the xTRs and Map-Servers use the RLOC space data plane. Only those communications attempts shall be accepted that are coming from valid RLOC addresses. Manual configuration of such access lists would be too difficult to manage. An automated RLOC membership mechanism is proposed in [LISP-RFIL]. Although this Internet Draft has been expired, it is still included in some LISP implementations. The Map-Server can authenticate each xTR that wants to communicate. It will build up a list of xTRs that are valid members of this LISP administrative domain. An xTR can specifically subscribe to this membership information. Membership can be maintained by address family and instance ID (VPN). This allows an easy management of both RLOC and EID space segmentation by VPNs. It also supports gateway functions between separated RLOC spaces. Only valid xTR members can apply for notifications of membership information. The xTR receiving the membership information might use it for building internal access control lists automatically. Proxy xTR information is not included in the membership list, so communication with such nodes need to be configured manually. A membership message format is defined in [LISP-RFIL]. The following message type are specified: o Membership subscribe, o Membership subscribe acknowledgement, o Membership subscribe negative acknowledgement, o Membership unsubscribe, o Membership element add, o Membership element delete, o Membership refresh request, o Membership refresh begin, o Membership refresh end. The membership information could be used by the xTR for other future functions, too. Automated RLOC filtering is just one example.¶
In those sections of the ATN/IPS network where data plane confidentiality, integrity and anti-replay protection may be required, the LISP data plane can be secured as any other IP traffic by leveraging IPsec. The provisioning of an IPsec VPN to secure IP encapsulated LISP frames is orthogonal to deployment of LISP and can be done using well known IPsec key negotiation mechanisms such as IKEv2 [RFC7296].¶
IKEv2 uses X.509 certificates for authentication. A PKI is needed for managing the certificates. The certificates are used for generating the exchanged symmetric encryption keys.¶
No IANA considerations.¶
The original authors would like to thank Dino Farinacci and Bela Varkonyi for their review of the document and deep insights.¶
The following people have contributed, over time, to the autorship of this document: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino, Balaji Venkatachalapathy.¶