idnits 2.17.1 draft-haindl-lisp-gb-atn-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (22 March 2022) is 767 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6830bis' is mentioned on line 590, but not defined ** Obsolete undefined reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Missing Reference: 'RFC6833bis' is mentioned on line 590, but not defined ** Obsolete undefined reference: RFC 6833 (Obsoleted by RFC 9301) == Missing Reference: 'LISP-SEC' is mentioned on line 631, but not defined == Missing Reference: 'RFC6347' is mentioned on line 614, but not defined ** Obsolete undefined reference: RFC 6347 (Obsoleted by RFC 9147) == Missing Reference: 'RFC8061' is mentioned on line 614, but not defined == Missing Reference: 'LISP-RELT' is mentioned on line 705, but not defined == Missing Reference: 'RFC5925' is mentioned on line 740, but not defined == Missing Reference: 'RFC4895' is mentioned on line 740, but not defined == Missing Reference: 'LISP-RFIL' is mentioned on line 776, but not defined == Missing Reference: 'RFC7296' is mentioned on line 792, but not defined ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-09 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-09 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-25 == Outdated reference: A later version (-06) exists of draft-moreno-lisp-uberlay-05 Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group B.H. Haindl 3 Internet-Draft M.L. Lindner 4 Intended status: Informational Frequentis 5 Expires: 23 September 2022 V. Moreno 6 Google 7 M.P. Portoles 8 F.M. Maino 9 B.V. Venkatachalapathy 10 Cisco Systems 11 22 March 2022 13 Ground-Based LISP for the Aeronautical Telecommunications Network 14 draft-haindl-lisp-gb-atn-07 16 Abstract 18 This document describes the use of the LISP architecture and 19 protocols to address the requirements of the worldwide Aeronautical 20 Telecommunications Network with Internet Protocol Services, as 21 articulated by the International Civil Aviation Organization. 23 The ground-based LISP overlay provides mobility and multi-homing 24 services to the IPv6 networks hosted on commercial aircrafts, to 25 support Air Traffic Management communications with Air Traffic 26 Controllers and Air Operation Controllers. The proposed architecture 27 doesn't require support for LISP protocol in the airborne routers, 28 and can be easily deployed over existing ground infrastructures. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 23 September 2022. 53 Copyright Notice 55 Copyright (c) 2022 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 71 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Basic Protocol Operation . . . . . . . . . . . . . . . . . . 7 73 4.1. Endsystem Registration . . . . . . . . . . . . . . . . . 7 74 4.2. Ground to Airborne Traffic Flow . . . . . . . . . . . . . 8 75 4.3. Airborne to Ground Traffic Flow . . . . . . . . . . . . . 8 76 4.4. Default forwarding path . . . . . . . . . . . . . . . . . 9 77 4.5. Traffic symmetry . . . . . . . . . . . . . . . . . . . . 10 78 5. Multi-Homing and Mobility . . . . . . . . . . . . . . . . . . 10 79 6. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 6.1. Use of RLOC-probing . . . . . . . . . . . . . . . . . . . 12 81 6.2. Use of Solicit-Map-Request . . . . . . . . . . . . . . . 12 82 6.3. Use of LISP pub-sub . . . . . . . . . . . . . . . . . . . 12 83 7. Multi-domain structure of the ATN/IPS . . . . . . . . . . . . 13 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 8.1. LISP Basic Security Mechanisms . . . . . . . . . . . . . 13 86 8.2. Control Plane overload protection . . . . . . . . . . . . 14 87 8.3. Protecting the LISP control plane from overclaim 88 attacks . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 8.4. LISP Reliable Transport . . . . . . . . . . . . . . . . . 14 90 8.5. Reachability Control . . . . . . . . . . . . . . . . . . 16 91 8.6. Data Plane Security . . . . . . . . . . . . . . . . . . . 17 92 8.6.1. Segmentation . . . . . . . . . . . . . . . . . . . . 17 93 8.6.2. Automated RLOC Filtering . . . . . . . . . . . . . . 17 94 8.6.3. Confidentiality, Integrity and Anti-replay 95 protection . . . . . . . . . . . . . . . . . . . . . 18 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 100 11.2. Informative References . . . . . . . . . . . . . . . . . 18 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 103 1. Introduction 105 This document describes the use of the LISP [RFC6830] architecture 106 and protocols to address the requirements of the worldwide 107 Aeronautical Telecommunications Network with Internet Protocol 108 Services (ATN/IPS), as articulated by the International Civil 109 Aviation Organization (ICAO). 111 ICAO is proposing to replace the existing aeronautical communication 112 services with an IPv6 based infrastructure that supports Air Traffic 113 Management (ATM) between commercial aircrafts, Air Traffic 114 Controllers (ATC) and Air Operation Controllers (AOC). 116 This document describes how a LISP overlay can be used to offer 117 mobility and multi-homing services to the IPv6 networks hosted on 118 commercial aircrafts without requiring LISP support in the airborne 119 routers. Use of the LISP protocol is limited to the ground-based 120 routers, hence the name "ground-based LISP". The material for this 121 document is derived from [GBL]. 123 2. Definition of Terms 125 AOC: Airline Operational Control 127 ATN/IPS: Aeronautical Telecommunications Network with Internet 128 Protocol Services 130 AC-R: Access Ground Router 132 A/G-R: Air/Ground Router 134 G/G-R: Ground/Ground Router 136 A-R: Airborne Router 138 A-E: Airborne Endsystem 140 ATS-E: ATS Endsystem 142 For definitions of other terms, notably Map-Register, Map-Request, 143 Map-Reply, Routing Locator (RLOC), Solicit-Map-Request (SMR), Ingress 144 Tunnel Router (ITR), Egress Tunnel Router (ETR), xTR (ITR or ETR), 145 Map-Server (MS), and Map-Resolver (MR) please consult the LISP 146 specification [RFC6830]. 148 3. Design Overview 150 In the ATN/IPS architecture the airborne endsystems hosted on an 151 aircraft are part of an IPV6 network connected to the ground network 152 by one or more Airborne Routers (A-R). A-Rs have multiple radio 153 interfaces that connects them via various radios infrastructures 154 (e.g. SATCOM, LDACS, AeroMACS) to a given radio region, also known 155 as subnetwork, on the ground. Typically an A-R has a corresponding 156 ground based Access Router (AC-R) that terminates the radio protocol 157 with the A-R and provides access services to the ground based portion 158 of the radio network infrastructure. Each radio region is 159 interconnected with the ATN/IPS ground network via an Air-to-Ground 160 router (AG-R). 162 Similarly, the Air Traffic Controllers and Air Operation Controllers 163 Endsystems (ATS-E and AOC-E) are part of IPv6 networks reachable via 164 one or more Ground-to-Ground Routers (G/G-Rs). 166 The ATN/IPS ground network infrastructure is the internetworking 167 region located between the A/G routers and the G/G routers. 169 In the ground-based LISP architecture, a LISP overlay is laid over 170 the ATN/IPS internetworking region (that is in the LISP RLOC space) 171 and provides connectivity between endsystems (that are in the LISP 172 EID space) hosted in the aircrafts and in the AOC/ATS regions. The 173 A/G-Rs and the G/G-Rs assume the role of LISP xTRs supported by a 174 LISP mapping system infrastructure. 176 ,------, 177 ,---------. : A-E1 : 178 ,' `./'------' 179 ( AIRCRAFT ) 180 `. +-----+ ,'\ ,------, 181 `-| A-R |-' \: A-E2 : 182 +-----+ '------' 183 // \\ 184 // \\ 185 +---+--+ +-+--+--+ 186 .--.-.| AC-R1|'.-. .| AC-R2 |.-. 187 ( +---+--+ ) ( +-+--+--+ ) 188 ( __. ( '. 189 ..'SATCOM Region ) .' LDACS Region ) 190 ( .'-' ( .'-' 191 ' +-------+ ) ' +-------+ ) 192 '-| A/G-R |-' '-| A/G-R |-'' 193 | | | | 194 | xTR1 | | xTR2 | 195 +-------+ +-------+ 196 \ / 197 \ .--..--. .--. ../ 198 \ ( ' '.--. 199 .-.' Internetworking '' '-------' 200 ( region )--: MS/MR : 201 ( (RLOC SPACE) '-'' '-------' 202 ._.'--'._.'.-._.'.-._) 203 / \ 204 +---+---+ +-+--+--+ 205 -.-.| G/G-R |'. .| G/G-R |. 206 ( | | ) ( | | ) 207 ( | xTR3 | ) ( | xTR4 | ) 208 ( +---+---+ ) ( +-+--+--+ ) 209 ( _._. ( '. 210 ..' ATS Region ) .' AOC Region ) 211 ( .'-' ( .'-' 212 '--'._.'. )\ '--'._.'. )\ 213 / '--' \ / '--' \ 214 '--------' '--------' '--------' '--------' 215 : ATS-E1 : : ATS-E2 : : AOC-E1 : : AOC-E2 : 216 '--------' '--------' '--------' '--------' 218 Figure 1: ATN/IPS and ground-based LISP overlay 220 Endsystems in the AOC/ATS regions are mapped in the LISP overlay by 221 the G/G-Rs, that are responsible for the registration of the AOC/ATS 222 endsystems to the LISP mapping system. Each G/G-R is basically an 223 xTR which has direct connections only to the terrestrial regions, 224 i.e. no direct connection to the radio regions. 226 Aircrafts will attach to a specific radio region, via the radio 227 interfaces of the A-Rs. How the radio attachment works is specific 228 to each particular radio infrastructure, and out of the scope of this 229 document, see [GBL]. 231 Typically at the end of the attachment phase, the access router (AC- 232 R) corresponding to the A-R, will announce the reachability of the 233 EID prefixes corresponding to the attached aircraft (the announcement 234 is specific to each particular radio infrastructure, and is out of 235 the scope of this document). A/G-Rs in that particular radio region 236 are responsible to detect those announcements, and, since they act as 237 xTRs, register to the LISP mapping systems the corresponding IPv6 EID 238 prefixes on behalf of the A-R, but with the RLOC of the A/G-R. 240 The EID prefixes registered by the A/G-Rs are then reachable by any 241 of the AOC/ATS Endsystems that are part of the ground based LISP 242 overlay. 244 The LISP infrastructure is used to support seamless aircraft mobility 245 from one radio network to another, as well as multi-homing attachment 246 of an aircraft to multiple radio networks with use of LISP weight and 247 priorities to load balance traffic directed toward the aircraft. 249 The rest of this document provides further details on how ground- 250 based LISP is used to address the requirements of the ATN/IPS use 251 cases. The main design goals are: 253 * minimize added complexity on the aircraft 255 - airborne routers can assume that any ground system is reachable 256 via any A/G router. Static routing policies can be used on 257 board 259 - no need for routing/mobility protocols on board. Routing/ 260 mobility is managed on the ground ATN/IPS network 262 - on-board outgoing link selection can be done with simple static 263 policy 265 * seamless support for aircraft mobility and multi-homing with 266 minimal traffic overhead on the A/G datalink 268 * minimize complexity of ground deployment 270 - ground-based LISP can be easily deployed over existing ATN/IPS 271 ground infrastructure 273 - it is based on COTS solutions 275 - can ease IPv4 to IPv6 transition issues 277 4. Basic Protocol Operation 279 Figure 1 provides the reference topology for a description of the 280 basic operation. A more detailed description of the basic protocol 281 operation is described in [GBL]. 283 4.1. Endsystem Registration 285 The following are the steps via which airborne endsystem prefixes are 286 registered with the LISP mapping system: 288 1. Each Airborne Endsystem (A-E) is assigned an IPv6 address that is 289 the endsystem EID. Each EID includes a Network-ID prefix that 290 comprises (1) an ICAO ID which uniquely identifies the aircraft, 291 and possibly (2) an aircraft network identifier. Airborne 292 devices are grouped in one (and possibly several) IPv6 EID 293 prefixes. As an example an IPv6 EID prefix could be used for all 294 ATC applications located in a safety critical domain of the 295 aircraft network, another IPv6 EID prefix could be used for AOC 296 applications located in a less safety critical domain. 298 2. After the Airborne Router (A-R) on an aircraft attaches to one 299 radio region, the corresponding Access Router (AC-R) learns the 300 IPv6 EID prefixes belonging to the aircraft. The AC-R also 301 announces reachability of these prefixes in the radio region 302 (subnetwork) e.g. by using an IGP protocol like OSPF. The 303 attachment to a radio includes a preference parameter and a 304 quality parameter, these parameters are used e.g. to calculate 305 the IGP reachability advertisement metric. 307 3. The Air/Ground Router (A/G-R) in the subnetwork receives the 308 radio region announcements which contain reachablity information 309 for the IPv6 EID prefixes corresponding to the Airborne 310 Endsystems. Since each A/G-R is also an xTR, the A/G-R registers 311 the IPv6 EID prefixes with the LISP MS/MR on behalf of the A-R, 312 but with the RLOC of the A/G-R. The included quality parameter 313 (e.g. IGP metric) is converted to a LISP priority, so that a 314 lower quality metric results in a lower LISP priority value. 316 Ground based endsystems are part of ground subnetworks where the 317 Ground/Ground Router (G/G-R) is an xTR. Each G/G-R therefore 318 registers the prefixes corresponding to the AOC endsystems and ATS 319 endsystems with the LISP mapping system, as specified in [RFC6830]. 321 4.2. Ground to Airborne Traffic Flow 323 Here is an example of how traffic flows from the ground to the 324 airborne endsystems, when ATS endsystem 1 (ATS-E1) has traffic 325 destined to airborne endsystem 1 (A-E1): 327 1. The default route in the ATS region takes the traffic to xTR3 328 which is also a Ground/Ground Router (G/G-R). 330 2. xTR3 sends a Map-Request message for the address of A-E1 to the 331 LISP mapping system. xTR2 sends a Map-Reply to xTR3 with RLOC set 332 to its address which is reachable from xTR3 via the 333 internetworking region. 335 3. xTR3 encapsulates the traffic to xTR2 using the RLOC information 336 in the Map-Reply message. 338 4. xTR2 decapsulates the traffic coming from xTR3. The destination 339 address of the inner packet belongs to A-E1 which has been 340 advertised by the AC-R in the same region. The traffic is 341 therefore forwarded to AC-R2. 343 5. AC-R2 sends the traffic to the Airborne Router of the aircraft 344 and the A-R sends it to the endsystem. 346 4.3. Airborne to Ground Traffic Flow 348 Here is an example of how traffic flows from the airborne endsystems 349 to the ground when airborne endsystem 2 (A-E2) has traffic destined 350 to ATS endsystem 2 (ATS-E2): 352 1. The default route in the aircraft points to the Airborne Router 353 (A-R). The latter forwards the traffic over the radio link to 354 AC-R2. 356 2. The default route on AC-R2 points to xTR2 (also an A/G-R), so the 357 traffic is sent from AC-R2 to xTR2. 359 3. xTR2 sends a Map-Request message for the address of ATS-E2 to the 360 LISP mapping system. xTR3 sends a Map-Reply to xTR2 with RLOC set 361 to its address which is reachable from xTR2 via the 362 internetworking region. 364 4. xTR2 encapsulates the traffic to xTR3 using the RLOC information 365 in the Map-Reply message. 367 5. xTR3 decapsulates the traffic coming from xTR2, and forwards it 368 to ATS-E2. 370 4.4. Default forwarding path 372 When an xTR is waiting for a Map-Reply for an EID, the xTR does not 373 know how to forward the packets destined to that EID. This means 374 that the first packets for ground-to-air traffic would get dropped 375 until the Map-Reply is received and a map-cache entry is created. 376 However if a device acting as RTR, see 377 [I-D.ermagan-lisp-nat-traversal], has mappings for all EIDs, the xTR 378 could use the RTR as default path for packets which have to be 379 encapsulated. How the RTR gets all the mappings is outside the scope 380 of this document but one example is the use of LISP pub-sub as 381 specified in [I-D.ietf-lisp-pubsub]. Note that the RTR does not have 382 to be a new device, the device which has the MS/MR role can also act 383 as RTR. It is only the RTR which needs to subscribe to all the 384 aircraft EIDs, the XTRs (i.e. the A/G-Rs and G/G-Rs) do not need to 385 subscribe. 387 RTRs stitch two legs of a communication flow by acting as an ETR for 388 the purposes of the first leg and as an ITR for the purposes of the 389 second leg. As an ITR (second leg), the RTR will follow all standard 390 procedures of an ITR (issue requests, cache mappings, subscribe to 391 EIDs, etc). In the specific case of the first packet drop scenario, 392 the RTR will subscribe to the entire EID space registered in the 393 Mapping System and maintain a complete cache of all relevant 394 destinations. Any changes to the registration state will be 395 published promptly to the RTR using the pub/sub mechanisms. This ITR 396 role can be made redundant by simply having each RTR in the 397 redundancy group subscribe to the Mapping System. From an ETR 398 perspective, the RTR will also follow all standard procedures for an 399 ETR, but rather than registering specific prefixes, the RTRs will 400 (optionally) register themselves as the "First Packet Handlers". The 401 ITRs sending traffic requiring first packet handling will be 402 configured to forward traffic to the First Packet Handlers if there 403 isn't a mapping already cached for the destination. 405 The ITRs will know who the first packet handlers are by one of two 406 mechanisms: 408 1. Configuration of the RLOCs of the first packet handlers on the 409 ITR. This configuration would be done by a network management 410 system. 412 2. Subscription of the ITR to the "First Packet Handler" EID. As 413 First Packet Handler RLOCs are added or removed the subscribing ITRs 414 are updated. 416 In both cases the resiliency mechanisms for the RLOCs are the same as 417 for any other RLOC: Routing table reachability combined with optional 418 data plane probes can be leveraged to accelerate failover. In the 419 case in which subscriptions to the "First Packet Handler" EID are 420 used, the RTR will also benefit from the updates in the publication 421 to trigger failover processes. 423 4.5. Traffic symmetry 425 The requirements for traffic symmetry are still TBD. 427 5. Multi-Homing and Mobility 429 Multi-homing support builds on the procedures described in Section 4: 431 1. The Airborne Router (A-R) on an aircraft attaches to multiple 432 radio regions. As an example, and referring to Figure 1, the A-R 433 attaches to the LDACS and SATCOM regions, via AC-R2 and AC-R1 434 respectively. 436 2. Through the preference parameter sent to each region, the A-R has 437 control over which path (i.e. radio region) ground to air traffic 438 flows. For example, A-R would indicate preference of the LDACS 439 region by choosing a better preference value for the LDACS region 440 compared to the preference value sent to the SATCOM region. 442 3. Both xTR1 and xTR2 register the IPv6 EID prefixes with the LISP 443 mapping system using merge semantic, as specified in section 4.6 444 of [I-D.ietf-lisp-rfc6833bis]. Since the priority used in the 445 LISP registrations is derived from the preference and quality 446 parameters, xTR2 would use a lower priority value than xTR1. In 447 this way the LISP mapping system will favour xTR2 (A/G-R for the 448 LDACS region) over xTR1 (A/G-R for the SATCOM region), as 449 specified by the preference and quality parameters. 451 4. Upon registration the LISP MS/MR will send Map-Notify messages to 452 both xTR1 and xTR2, to inform that they have reachability to the 453 aircraft's IPv6 EID prefixes. Both xTRs are notified because 454 they have both set the merge-request and want-map-notify bits in 455 their respective Map-Register message. 457 5. Upstream and downstream traffic flows on the same path, i.e. both 458 use the LDACS region. 460 With mobility, the aircraft could want to switch traffic from one 461 radio link to another. For example while transiting from an area 462 covered by LDACS to an area covered by SATCOM, the aircraft could 463 desire to switch all traffic from LDACS to SATCOM. For air-to-ground 464 traffic, the A-R has complete control over which radio link to use, 465 and will simply select the SATCOM outgoing interface. For ground-to- 466 air traffic: 468 1. The A-R sends a radio advertisement to AC-R1 indicating a better 469 preference for the SATCOM link. 471 2. This leads to AC-R1 lowering its quality parameter (e.g. IGP 472 metric) for the IPv6 EID prefixes. 474 3. Upon receiving the better preference value, xTR1 registers the 475 IPv6 EID prefixes with the MS/MR, using a lower priority value 476 than what xTR2 had used. Both xTR1 and xTR2 receives Map-Notify 477 messages signaling to xTR2 that xTR1 is now the preferred path 478 toward the aircraft. 480 4. xTR3 has a map-cache which still points to xTR2, therefore xTR3 481 still sends traffic via xTR2. xTR2 sends Solicit-Map-Request 482 (SMR) to xTR3 who queries the LISP mapping system again. This 483 results in updating the map-cache on xTR3 which now points to 484 XTR1 so ground-to-air traffic now flows on the SATCOM radio link. 486 The procedure for mobility is derived from 487 [I-D.ietf-lisp-eid-mobility]. 489 6. Convergence 491 When traffic is flowing on a radio link and that link goes down, the 492 network has to converge rapidly on the other link available for that 493 aircraft. 495 For air-to-ground traffic, once the A-R detects the failure it can 496 switch immediatly to the other radio link. 498 For ground-to-air traffic, when a radio link fails, the corresponding 499 AC-R sends a reachability update that the IPv6 EID prefixes are not 500 reachable anymore. This leads to the A/G-R (also an xTR) in that 501 region to unregister the IPv6 EID prefixes with the MS/MR. This 502 indicates that the xTR in question has no reachability to the EID 503 prefixes. The notification of the failure should reach all relevant 504 xTRs as soon as possible. For example, if the LDACS radio link 505 fails, xTR3 and xTR4 need to learn about the failure so that they 506 stop sending traffic via xTR2 and use xTR1 instead. 508 In the sub-sections below, we the use of RLOC-probing, Solicit-Map- 509 Request, and LISP pub-sub as alternative mechanisms for link failure 510 notification. 512 6.1. Use of RLOC-probing 514 RLOC-probing is described in section 6.3.2 of [RFC6830]. 516 At regular intervals xTR3 sends Map-Request to xTR2 for the 517 aircraft's EID prefixes. When xTR3 detects via RLOC-probing that it 518 can not use xTR2 anymore, it sends a Map-Request for the aircraft's 519 EID prefixes. The corresponding Map-Reply indicates that xTR1 should 520 now be used. The map-cache on xTR3 is updated and air-to-ground 521 traffic now goes through xTR1 to use the SATCOM radio link to the 522 aircraft. 524 The disadvantage of RLOC-probing is that fast detection becomes more 525 difficult when the number of EID prefixes is large. 527 6.2. Use of Solicit-Map-Request 529 Solicit-Map-Request is used as described in Section 5: 531 1. xTR3 is still sending traffic to xTR2 since its map-cache has not 532 been updated yet. 534 2. Upon detecting that the link is down, and receiving data plane 535 traffic from the ground network, xTR2 sends an SMR to xTR3 that 536 sends a Map-Request to update its map-cache. The corresponding 537 Map-Reply indicates that xTR1 should now be used. 539 The disadvantage of this approach is that the traffic is delayed 540 pending control-plane resolution. This method also depends on data 541 traffic being continuous, in many cases data traffic may be sporadic, 542 leading to very slow convergence. 544 6.3. Use of LISP pub-sub 546 As specified in [I-D.ietf-lisp-pubsub], ITRs can subscribe to changes 547 in the LISP mapping system. So if all ITRs subscribe to the EID 548 prefixes for which they have traffic, the ITRs will be notified when 549 there is mapping change. 551 In the example where the LDACS radio link fails, when xTR2 552 unregisters the EID prefixes with the MS/MR, xTR3 would be notified 553 via LISP pub-sub (assuming xTR3 has a map-cache entry for these EID 554 prefixes). 556 This mechanism provides the fastest convergence at the cost of more 557 state in the LISP mapping system. 559 7. Multi-domain structure of the ATN/IPS 561 The overlay on the ATN/IPS can be structured as a collection of 562 independent administrative domains following the model defined in 563 [I-D.moreno-lisp-uberlay]. In this model, the different 564 administrative domains are interconnected by a transit area referred 565 to as an uberlay. Each administrative domain is independent from the 566 perspective of the control, data and administrative planes. 567 Structuring the ATN/IPS in this manner allows the combination of 568 different implementations and even different mobility methods in the 569 ATN/IPS. The structure proposed also improves resiliency by 570 isolating events and failures across the different administrative 571 domains and improves the scale of the ATN/IPS by distributing the 572 responsibility of maintaining granular aircraft state across the 573 different administrative domains. 575 The uberlay may be a BGP network as defined in [I-D.templin-atn-bgp]. 576 Following the definitions put forth in [I-D.templin-atn-bgp], the 577 uberlay transit is the core autonomous system and the different 578 administrative domains that conform the ATN/IPS are what 579 [I-D.templin-atn-bgp] defines as stub autonomous systems. 581 8. Security Considerations 583 For LISP control-plane message security, please refer to 584 [I-D.ietf-lisp-sec]. This addresses the control-plane threats that 585 target EID-to-RLOC mappings, including manipulations of Map-Request 586 and Map-Reply messages, and malicious ETR EID prefix overclaiming. 588 8.1. LISP Basic Security Mechanisms 590 The LISP specification, documented in [RFC6830bis] and [RFC6833bis], 591 includes basic security mechanisms for the control plane. The base 592 mechanisms are designed to prevent rogue unauthorized ETRs from 593 registering mappings into the Mapping System and to protect ITRs from 594 receiving unsolicited mapping information. To authenticate EID-to- 595 RLOC mapping registrations and ensure that they are from an 596 authorized ETR, LISP uses shared secret keys between ETRs and the 597 Mapping System. Only ETRs that have the shared secret key are able 598 to register EID-to-RLOC mappings to the Mapping System. Without the 599 correct key, the authenticity of the map-register message cannot be 600 verified, and the Mapping System must reject the map-register. The 601 shared keys used to authenticate map-registers are distributed across 602 ETRs and MS/MRs by the orchestration/configuration infrastructure. 604 The shared keys need to be distributed between the xTR and the 605 Mapping System. Since these components will be in the same 606 administrative domain in GB-LISP, it would be feasible to implement a 607 method for this key exchange (see Clause 6.5 in [LISP-SEC]. In 608 addition to authenticating EID registrations, it is recommended that 609 the Mapping System restricts EID registrations to configured EID 610 prefix ranges. Thus, an authorized ETR is allowed to register EID 611 prefixes only within the EID prefix range configured in the Map- 612 Server. The confidentiality of the LISP control plane messages can 613 be ensured by protecting the transport of control messages with DTLS 614 (over UDP) [RFC6347] or LISP-crypto [RFC8061]. DTLS is also proposed 615 in Clause 6.7 of [LISP-SEC] for providing message privacy. 617 8.2. Control Plane overload protection 619 Data-plane gleaning [Clause 9 in RFC6830bis] might need to be turned 620 off for avoiding potential attacks by forged data plane packets that 621 could overload the control plane. Another approach is data fusion 622 between multiple reachability verification mechanisms. Generic 623 control plane protection mechanism, such as packet filtering and rate 624 control, should be also deployed for GB-LISP nodes based on a risk 625 assessment. This could mitigate such attacks that try to misuse the 626 Map-Versioning mechanism in the data-plane for overloading the 627 control-plane. 629 8.3. Protecting the LISP control plane from overclaim attacks 631 The Internet Draft [LISP-SEC] defines a set of security mechanisms 632 (usually referred as LISP-SEC) to provide origin authentication, 633 integrity, and antireplay protection to the EID-to-RLOC mapping data 634 conveyed in the map-resolution process. It includes the usage of 635 multiple one-time-keys (OTK) and hash based message authentication. 636 LISP-SEC also enables authorization verification on EID-prefixes 637 claims made by ETRs, preventing so-called "overclaiming attacks" in 638 which an ETR attempts to claim EID-prefixes for which it is not 639 authoritative. A LISP-SEC protected map-reply, in fact, includes 640 metadata authenticated by the map-server that specify which 642 8.4. LISP Reliable Transport 644 The communication with the Mappin Systems is originally proposed 645 based on UDP that is not a reliable transport. For a proper 646 synchronization between the ETR and the Map-Servers periodic message 647 transmission would be needed. Usually, Map-Register messages are 648 retransmitted every minute by the ETR. The Map-Server removes the 649 EID entries if they are not refreshed for three successive periods. 651 In mobility solutions, typically a large number of EID entries needs 652 to be registered. Because of packet size limitations these entries 653 can be transported only by a significant number of Map-Register 654 messages in each period. A new reliable transport option has been 655 defined in [LISP-RELT] to solve these issues. Although this Internet 656 Draft has been expired, the new method is used in the latest widely 657 deployed LISP solution for Software Defined Access (SDA) by Cisco 658 Systems. The reliable transport is composed by new message formats 659 and the support for other then UDP as a transport in the control 660 plane. Both TCP and SCTP is addressed by the specification. The TCP 661 implementation could be traced in the labs. The messages are based 662 on a TLV format where a type filed support the future extensions of 663 the protocol. A message end marker provides extra integrity check 664 possibility for complex aggregated messages. Error notification 665 messages are also specified for notifying situations when the 666 receiver does not recognize or cannot parse message contents. The 667 following message types are specified for the reliable transport 668 mechanism: o Map-Register, o Registration acknowledgement, o 669 Registration rejection, o Registration refresh, o Mapping 670 notification, The session establishment has to be backward 671 compatible. The Map Server authenticates the ETR first using UDP 672 based messages. Once the ETR is authenticated, the Map Server 673 performs a passive open by listening on TCP port 4342. TCP 674 connections are accepted only from the already authenticated ETRs. 675 The ETR has to open the TCP connection actively towards the Map 676 Server one it has received the Map-Notify message on the UDP 677 transport. If the TCP session goes down, the same UDP based 678 procedure has to be repeated. The Map-Server will also revert to the 679 expiration mechanism used for UDP transport until the TCP based 680 session would be fully restored. A single TCP session is built up 681 for all subsequent control plane messages. This applies even when 682 multiple address families are used in the EID space. Once the 683 reliable transport can be used, the periodic refresh is not needed 684 anymore. Mapping information is sent only when there is new 685 information to share. Time-out based removal of registrations are 686 not used in this case. An explicit de-registration is needed by 687 carrying a zero TTL. The reliable transport session should be 688 authenticated. In the simpler case, it could be an RLOC spoofing 689 mitigation. If this is not reliable, then the TCP Authentication 690 Option [RFC5925], or the SCTP Authenticated Chunks [RFC4895] are 691 recommended. 693 8.5. Reachability Control 695 The communication with the Mappin Systems is originally proposed 696 based on UDP that is not a reliable transport. For a proper 697 synchronization between the ETR and the Map-Servers periodic message 698 transmission would be needed. Usually, Map-Register messages are 699 retransmitted every minute by the ETR. The Map-Server removes the 700 EID entries if they are not refreshed for three successive periods. 701 In mobility solutions, typically a large number of EID entries needs 702 to be registered. Because of packet size limitations these entries 703 can be transported only by a significant number of Map-Register 704 messages in each period. A new reliable transport option has been 705 defined in [LISP-RELT] to solve these issues. Although this Internet 706 Draft has been expired, the new method is used in the latest widely 707 deployed LISP solution for Software Defined Access (SDA) by Cisco 708 Systems. The reliable transport is composed by new message formats 709 and the support for other then UDP as a transport in the control 710 plane. Both TCP and SCTP is addressed by the specification. The TCP 711 implementation could be traced in the labs. The messages are based 712 on a TLV format where a type filed support the future extensions of 713 the protocol. A message end marker provides extra integrity check 714 possibility for complex aggregated messages. Error notification 715 messages are also specified for notifying situations when the 716 receiver does not recognize or cannot parse message contents. The 717 following message types are specified for the reliable transport 718 mechanism: o Map-Register, o Registration acknowledgement, o 719 Registration rejection, o Registration refresh, o Mapping 720 notification, The session establishment has to be backward 721 compatible. The Map Server authenticates the ETR first using UDP 722 based messages. Once the ETR is authenticated, the Map Server 723 performs a passive open by listening on TCP port 4342. TCP 724 connections are accepted only from the already authenticated ETRs. 725 The ETR has to open the TCP connection actively towards the Map 726 Server one it has received the Map-Notify message on the UDP 727 transport. If the TCP session goes down, the same UDP based 728 procedure has to be repeated. The Map-Server will also revert to the 729 expiration mechanism used for UDP transport until the TCP based 730 session would be fully restored. A single TCP session is built up 731 for all subsequent control plane messages. This applies even when 732 multiple address families are used in the EID space. Once the 733 reliable transport can be used, the periodic refresh is not needed 734 anymore. Mapping information is sent only when there is new 735 information to share. Time-out based removal of registrations are 736 not used in this case. An explicit de-registration is needed by 737 carrying a zero TTL. The reliable transport session should be 738 authenticated. In the simpler case, it could be an RLOC spoofing 739 mitigation. If this is not reliable, then the TCP Authentication 740 Option [RFC5925], or the SCTP Authenticated Chunks [RFC4895] are 741 recommended. 743 8.6. Data Plane Security 745 8.6.1. Segmentation 747 LISP inherently delivers segmentation by using extended endpoint 748 identifiers (EIDs) and Instance-IDs to partition the EID space, 749 segment the map-caches, and color the control and data plane messages 750 to create virtual networks. These virtual networks are a seamless 751 extension of the way EIDs are normally handled in LISP and therefore 752 enjoy all the benefits of scale, mobility, and address family 753 independence that LISP provides. 755 8.6.2. Automated RLOC Filtering 757 The communication on between the xTRs and Map-Servers use the RLOC 758 space data plane. Only those communications attempts shall be 759 accepted that are coming from valid RLOC addresses. Manual 760 configuration of such access lists would be too difficult to manage. 761 An automated RLOC membership mechanism is proposed in [LISP-RFIL]. 762 Although this Internet Draft has been expired, it is still included 763 in some LISP implementations. The Map-Server can authenticate each 764 xTR that wants to communicate. It will build up a list of xTRs that 765 are valid members of this LISP administrative domain. An xTR can 766 specifically subscribe to this membership information. Membership 767 can be maintained by address family and instance ID (VPN). This 768 allows an easy management of both RLOC and EID space segmentation by 769 VPNs. It also supports gateway functions between separated RLOC 770 spaces. Only valid xTR members can apply for notifications of 771 membership information. The xTR receiving the membership information 772 might use it for building internal access control lists 773 automatically. Proxy xTR information is not included in the 774 membership list, so communication with such nodes need to be 775 configured manually. A membership message format is defined in 776 [LISP-RFIL]. The following message type are specified: o Membership 777 subscribe, o Membership subscribe acknowledgement, o Membership 778 subscribe negative acknowledgement, o Membership unsubscribe, o 779 Membership element add, o Membership element delete, o Membership 780 refresh request, o Membership refresh begin, o Membership refresh 781 end. The membership information could be used by the xTR for other 782 future functions, too. Automated RLOC filtering is just one example. 784 8.6.3. Confidentiality, Integrity and Anti-replay protection 786 In those sections of the ATN/IPS network where data plane 787 confidentiality, integrity and anti-replay protection may be 788 required, the LISP data plane can be secured as any other IP traffic 789 by leveraging IPsec. The provisioning of an IPsec VPN to secure IP 790 encapsulated LISP frames is orthogonal to deployment of LISP and can 791 be done using well known IPsec key negotiation mechanisms such as 792 IKEv2 [RFC7296]. 794 IKEv2 uses X.509 certificates for authentication. A PKI is needed 795 for managing the certificates. The certificates are used for 796 generating the exchanged symmetric encryption keys. 798 9. IANA Considerations 800 No IANA considerations. 802 10. Acknowledgements 804 The original authors would like to thank Dino Farinacci and Bela 805 Varkonyi for their review of the document and deep insights. 807 The following people have contributed, over time, to the autorship of 808 this document: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc 809 Portoles-Comeras, Victor Moreno, Fabio Maino, Balaji 810 Venkatachalapathy. 812 11. References 814 11.1. Normative References 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, 818 DOI 10.17487/RFC2119, March 1997, 819 . 821 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 822 Locator/ID Separation Protocol (LISP)", RFC 6830, 823 DOI 10.17487/RFC6830, January 2013, 824 . 826 11.2. Informative References 828 [GBL] Frequentis, "Ground Based LISP for Multilink Operation, 829 https://www.icao.int/safety/acp/ACPWGF/CP WG-I 19/WP06 830 Ground_Based_LISP 2016-01-14.pdf", January 2016. 832 [I-D.ermagan-lisp-nat-traversal] 833 Ermagan, V., Farinacci, D., Lewis, D., Maino, F., Comeras, 834 M. P., Skriver, J., White, C., Lopez, A., and A. Cabellos, 835 "NAT traversal for LISP", Work in Progress, Internet- 836 Draft, draft-ermagan-lisp-nat-traversal-19, 7 May 2021, 837 . 840 [I-D.ietf-lisp-eid-mobility] 841 Comeras, M. P., Ashtaputre, V., Maino, F., Moreno, V., and 842 D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified 843 Control Plane", Work in Progress, Internet-Draft, draft- 844 ietf-lisp-eid-mobility-09, 18 January 2022, 845 . 848 [I-D.ietf-lisp-pubsub] 849 Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai, 850 S., and M. Boucadair, "Publish/Subscribe Functionality for 851 LISP", Work in Progress, Internet-Draft, draft-ietf-lisp- 852 pubsub-09, 28 June 2021, . 855 [I-D.ietf-lisp-rfc6833bis] 856 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 857 "Locator/ID Separation Protocol (LISP) Control-Plane", 858 Work in Progress, Internet-Draft, draft-ietf-lisp- 859 rfc6833bis-30, 18 November 2020, 860 . 863 [I-D.ietf-lisp-sec] 864 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 865 "LISP-Security (LISP-SEC)", Work in Progress, Internet- 866 Draft, draft-ietf-lisp-sec-25, 9 December 2021, 867 . 870 [I-D.moreno-lisp-uberlay] 871 Moreno, V., Farinacci, D., Rodriguez-Natal, A., Portoles- 872 Comeras, M., Maino, F., and S. Hooda, "Uberlay 873 Interconnection of Multiple LISP overlays", Work in 874 Progress, Internet-Draft, draft-moreno-lisp-uberlay-05, 18 875 January 2022, . 878 [I-D.templin-atn-bgp] 879 Templin, F. L., Saccone, G., Dawra, G., Lindem, A., and V. 880 Moreno, "A Simple BGP-based Mobile Routing System for the 881 Aeronautical Telecommunications Network", Work in 882 Progress, Internet-Draft, draft-templin-atn-bgp-08, 16 883 August 2018, . 886 Authors' Addresses 888 Bernhard Haindl 889 Frequentis 890 Email: bernhard.haindl@frequentis.com 892 Manfred Lindner 893 Frequentis 894 Email: manfred.lindner@frequentis.com 896 Victor Moreno 897 Google 898 Email: vimoreno@google.com 900 Marc Portoles Comeras 901 Cisco Systems 902 Email: mportole@cisco.com 904 Fabio Maino 905 Cisco Systems 906 Email: fmaino@cisco.com 908 Balaji Venkatachalapathy 909 Cisco Systems 910 Email: bvenkata@cisco.com