idnits 2.17.1 draft-haindl-lisp-gb-atn-06.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 (March 5, 2021) is 1145 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 630, but not defined == Missing Reference: 'RFC6347' is mentioned on line 613, but not defined ** Obsolete undefined reference: RFC 6347 (Obsoleted by RFC 9147) == Missing Reference: 'RFC8061' is mentioned on line 613, but not defined == Missing Reference: 'LISP-RELT' is mentioned on line 703, but not defined == Missing Reference: 'RFC5925' is mentioned on line 738, but not defined == Missing Reference: 'RFC4895' is mentioned on line 738, but not defined == Missing Reference: 'LISP-RFIL' is mentioned on line 774, but not defined == Missing Reference: 'RFC7296' is mentioned on line 790, but not defined ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-18 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-07 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-07 == 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-22 == Outdated reference: A later version (-06) exists of draft-moreno-lisp-uberlay-03 Summary: 4 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group B. Haindl 3 Internet-Draft M. Lindner 4 Intended status: Informational Frequentis 5 Expires: September 6, 2021 R. Rahman 6 M. Portoles 7 V. Moreno 8 F. Maino 9 B. Venkatachalapathy 10 Cisco Systems 11 March 5, 2021 13 Ground-Based LISP for the Aeronautical Telecommunications Network 14 draft-haindl-lisp-gb-atn-06 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 September 6, 2021. 53 Copyright Notice 55 Copyright (c) 2021 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 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 72 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Basic Protocol Operation . . . . . . . . . . . . . . . . . . 7 74 4.1. Endsystem Registration . . . . . . . . . . . . . . . . . 7 75 4.2. Ground to Airborne Traffic Flow . . . . . . . . . . . . . 8 76 4.3. Airborne to Ground Traffic Flow . . . . . . . . . . . . . 8 77 4.4. Default forwarding path . . . . . . . . . . . . . . . . . 9 78 4.5. Traffic symmetry . . . . . . . . . . . . . . . . . . . . 10 79 5. Multi-Homing and Mobility . . . . . . . . . . . . . . . . . . 10 80 6. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. Use of RLOC-probing . . . . . . . . . . . . . . . . . . . 12 82 6.2. Use of Solicit-Map-Request . . . . . . . . . . . . . . . 12 83 6.3. Use of LISP pub-sub . . . . . . . . . . . . . . . . . . . 12 84 7. Multi-domain structure of the ATN/IPS . . . . . . . . . . . . 13 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 8.1. LISP Basic Security Mechanisms . . . . . . . . . . . . . 13 87 8.2. Control Plane overload protection . . . . . . . . . . . . 14 88 8.3. Protecting the LISP control plane from overclaim attacks 14 89 8.4. LISP Reliable Transport . . . . . . . . . . . . . . . . . 14 90 8.5. Reachability Control . . . . . . . . . . . . . . . . . . 15 91 8.6. Data Plane Security . . . . . . . . . . . . . . . . . . . 16 92 8.6.1. Segmentation . . . . . . . . . . . . . . . . . . . . 16 93 8.6.2. Automated RLOC Filtering . . . . . . . . . . . . . . 17 94 8.6.3. Confidentiality, Integrity and Anti-replay protection 17 95 8.7. new section . . . . . . . . . . . . . . . . . . . . . . . 18 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 101 11.2. Informative References . . . . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 104 1. Introduction 106 This document describes the use of the LISP [RFC6830] architecture 107 and protocols to address the requirements of the worldwide 108 Aeronautical Telecommunications Network with Internet Protocol 109 Services (ATN/IPS), as articulated by the International Civil 110 Aviation Organization (ICAO). 112 ICAO is proposing to replace the existing aeronautical communication 113 services with an IPv6 based infrastructure that supports Air Traffic 114 Management (ATM) between commercial aircrafts, Air Traffic 115 Controllers (ATC) and Air Operation Controllers (AOC). 117 This document describes how a LISP overlay can be used to offer 118 mobility and multi-homing services to the IPv6 networks hosted on 119 commercial aircrafts without requiring LISP support in the airborne 120 routers. Use of the LISP protocol is limited to the ground-based 121 routers, hence the name "ground-based LISP". The material for this 122 document is derived from [GBL]. 124 2. Definition of Terms 126 AOC: Airline Operational Control 128 ATN/IPS: Aeronautical Telecommunications Network with Internet 129 Protocol Services 131 AC-R: Access Ground Router 133 A/G-R: Air/Ground Router 135 G/G-R: Ground/Ground Router 137 A-R: Airborne Router 139 A-E: Airborne Endsystem 141 ATS-E: ATS Endsystem 143 For definitions of other terms, notably Map-Register, Map-Request, 144 Map-Reply, Routing Locator (RLOC), Solicit-Map-Request (SMR), Ingress 145 Tunnel Router (ITR), Egress Tunnel Router (ETR), xTR (ITR or ETR), 146 Map-Server (MS), and Map-Resolver (MR) please consult the LISP 147 specification [RFC6830]. 149 3. Design Overview 151 In the ATN/IPS architecture the airborne endsystems hosted on an 152 aircraft are part of an IPV6 network connected to the ground network 153 by one or more Airborne Routers (A-R). A-Rs have multiple radio 154 interfaces that connects them via various radios infrastructures 155 (e.g. SATCOM, LDACS, AeroMACS) to a given radio region, also known 156 as subnetwork, on the ground. Typically an A-R has a corresponding 157 ground based Access Router (AC-R) that terminates the radio protocol 158 with the A-R and provides access services to the ground based portion 159 of the radio network infrastructure. Each radio region is 160 interconnected with the ATN/IPS ground network via an Air-to-Ground 161 router (AG-R). 163 Similarly, the Air Traffic Controllers and Air Operation Controllers 164 Endsystems (ATS-E and AOC-E) are part of IPv6 networks reachable via 165 one or more Ground-to-Ground Routers (G/G-Rs). 167 The ATN/IPS ground network infrastructure is the internetworking 168 region located between the A/G routers and the G/G routers. 170 In the ground-based LISP architecture, a LISP overlay is laid over 171 the ATN/IPS internetworking region (that is in the LISP RLOC space) 172 and provides connectivity between endsystems (that are in the LISP 173 EID space) hosted in the aircrafts and in the AOC/ATS regions. The 174 A/G-Rs and the G/G-Rs assume the role of LISP xTRs supported by a 175 LISP mapping system infrastructure. 177 ,------, 178 ,---------. : A-E1 : 179 ,' `./'------' 180 ( AIRCRAFT ) 181 `. +-----+ ,'\ ,------, 182 `-| A-R |-' \: A-E2 : 183 +-----+ '------' 184 // \\ 185 // \\ 186 +---+--+ +-+--+--+ 187 .--.-.| AC-R1|'.-. .| AC-R2 |.-. 188 ( +---+--+ ) ( +-+--+--+ ) 189 ( __. ( '. 190 ..'SATCOM Region ) .' LDACS Region ) 191 ( .'-' ( .'-' 192 ' +-------+ ) ' +-------+ ) 193 '-| A/G-R |-' '-| A/G-R |-'' 194 | | | | 195 | xTR1 | | xTR2 | 196 +-------+ +-------+ 197 \ / 198 \ .--..--. .--. ../ 199 \ ( ' '.--. 200 .-.' Internetworking '' '-------' 201 ( region )--: MS/MR : 202 ( (RLOC SPACE) '-'' '-------' 203 ._.'--'._.'.-._.'.-._) 204 / \ 205 +---+---+ +-+--+--+ 206 -.-.| G/G-R |'. .| G/G-R |. 207 ( | | ) ( | | ) 208 ( | xTR3 | ) ( | xTR4 | ) 209 ( +---+---+ ) ( +-+--+--+ ) 210 ( _._. ( '. 211 ..' ATS Region ) .' AOC Region ) 212 ( .'-' ( .'-' 213 '--'._.'. )\ '--'._.'. )\ 214 / '--' \ / '--' \ 215 '--------' '--------' '--------' '--------' 216 : ATS-E1 : : ATS-E2 : : AOC-E1 : : AOC-E2 : 217 '--------' '--------' '--------' '--------' 219 Figure 1: ATN/IPS and ground-based LISP overlay 221 Endsystems in the AOC/ATS regions are mapped in the LISP overlay by 222 the G/G-Rs, that are responsible for the registration of the AOC/ATS 223 endsystems to the LISP mapping system. Each G/G-R is basically an 224 xTR which has direct connections only to the terrestrial regions, 225 i.e. no direct connection to the radio regions. 227 Aircrafts will attach to a specific radio region, via the radio 228 interfaces of the A-Rs. How the radio attachment works is specific 229 to each particular radio infrastructure, and out of the scope of this 230 document, see [GBL]. 232 Typically at the end of the attachment phase, the access router (AC- 233 R) corresponding to the A-R, will announce the reachability of the 234 EID prefixes corresponding to the attached aircraft (the announcement 235 is specific to each particular radio infrastructure, and is out of 236 the scope of this document). A/G-Rs in that particular radio region 237 are responsible to detect those announcements, and, since they act as 238 xTRs, register to the LISP mapping systems the corresponding IPv6 EID 239 prefixes on behalf of the A-R, but with the RLOC of the A/G-R. 241 The EID prefixes registered by the A/G-Rs are then reachable by any 242 of the AOC/ATS Endsystems that are part of the ground based LISP 243 overlay. 245 The LISP infrastructure is used to support seamless aircraft mobility 246 from one radio network to another, as well as multi-homing attachment 247 of an aircraft to multiple radio networks with use of LISP weight and 248 priorities to load balance traffic directed toward the aircraft. 250 The rest of this document provides further details on how ground- 251 based LISP is used to address the requirements of the ATN/IPS use 252 cases. The main design goals are: 254 o minimize added complexity on the aircraft 256 * airborne routers can assume that any ground system is reachable 257 via any A/G router. Static routing policies can be used on 258 board 260 * no need for routing/mobility protocols on board. Routing/ 261 mobility is managed on the ground ATN/IPS network 263 * on-board outgoing link selection can be done with simple static 264 policy 266 o seamless support for aircraft mobility and multi-homing with 267 minimal traffic overhead on the A/G datalink 269 o 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. 603 The shared keys need to be distributed between the xTR and the 604 Mapping System. Since these components will be in the same 605 administrative domain in GB-LISP, it would be feasible to implement a 606 method for this key exchange (see Clause 6.5 in [LISP-SEC]. In 607 addition to authenticating EID registrations, it is recommended that 608 the Mapping System restricts EID registrations to configured EID 609 prefix ranges. Thus, an authorized ETR is allowed to register EID 610 prefixes only within the EID prefix range configured in the Map- 611 Server. The confidentiality of the LISP control plane messages can 612 be ensured by protecting the transport of control messages with DTLS 613 (over UDP) [RFC6347] or LISP-crypto [RFC8061]. DTLS is also proposed 614 in Clause 6.7 of [LISP-SEC] for providing message privacy. 616 8.2. Control Plane overload protection 618 Data-plane gleaning [Clause 9 in RFC6830bis] might need to be turned 619 off for avoiding potential attacks by forged data plane packets that 620 could overload the control plane. Another approach is data fusion 621 between multiple reachability verification mechanisms. Generic 622 control plane protection mechanism, such as packet filtering and rate 623 control, should be also deployed for GB-LISP nodes based on a risk 624 assessment. This could mitigate such attacks that try to misuse the 625 Map-Versioning mechanism in the data-plane for overloading the 626 control-plane. 628 8.3. Protecting the LISP control plane from overclaim attacks 630 The Internet Draft [LISP-SEC] defines a set of security mechanisms 631 (usually referred as LISP-SEC) to provide origin authentication, 632 integrity, and antireplay protection to the EID-to-RLOC mapping data 633 conveyed in the map-resolution process. It includes the usage of 634 multiple one-time-keys (OTK) and hash based message authentication. 635 LISP-SEC also enables authorization verification on EID-prefixes 636 claims made by ETRs, preventing so-called "overclaiming attacks" in 637 which an ETR attempts to claim EID-prefixes for which it is not 638 authoritative. A LISP-SEC protected map-reply, in fact, includes 639 metadata authenticated by the map-server that specify which 641 8.4. LISP Reliable Transport 643 The communication with the Mappin Systems is originally proposed 644 based on UDP that is not a reliable transport. For a proper 645 synchronization between the ETR and the Map-Servers periodic message 646 transmission would be needed. Usually, Map-Register messages are 647 retransmitted every minute by the ETR. The Map-Server removes the 648 EID entries if they are not refreshed for three successive periods. 649 In mobility solutions, typically a large number of EID entries needs 650 to be registered. Because of packet size limitations these entries 651 can be transported only by a significant number of Map-Register 652 messages in each period. A new reliable transport option has been 653 defined in [LISP-RELT] to solve these issues. Although this Internet 654 Draft has been expired, the new method is used in the latest widely 655 deployed LISP solution for Software Defined Access (SDA) by Cisco 656 Systems. The reliable transport is composed by new message formats 657 and the support for other then UDP as a transport in the control 658 plane. Both TCP and SCTP is addressed by the specification. The TCP 659 implementation could be traced in the labs. The messages are based 660 on a TLV format where a type filed support the future extensions of 661 the protocol. A message end marker provides extra integrity check 662 possibility for complex aggregated messages. Error notification 663 messages are also specified for notifying situations when the 664 receiver does not recognize or cannot parse message contents. The 665 following message types are specified for the reliable transport 666 mechanism: o Map-Register, o Registration acknowledgement, o 667 Registration rejection, o Registration refresh, o Mapping 668 notification, The session establishment has to be backward 669 compatible. The Map Server authenticates the ETR first using UDP 670 based messages. Once the ETR is authenticated, the Map Server 671 performs a passive open by listening on TCP port 4342. TCP 672 connections are accepted only from the already authenticated ETRs. 673 The ETR has to open the TCP connection actively towards the Map 674 Server one it has received the Map-Notify message on the UDP 675 transport. If the TCP session goes down, the same UDP based 676 procedure has to be repeated. The Map-Server will also revert to the 677 expiration mechanism used for UDP transport until the TCP based 678 session would be fully restored. A single TCP session is built up 679 for all subsequent control plane messages. This applies even when 680 multiple address families are used in the EID space. Once the 681 reliable transport can be used, the periodic refresh is not needed 682 anymore. Mapping information is sent only when there is new 683 information to share. Time-out based removal of registrations are 684 not used in this case. An explicit de-registration is needed by 685 carrying a zero TTL. The reliable transport session should be 686 authenticated. In the simpler case, it could be an RLOC spoofing 687 mitigation. If this is not reliable, then the TCP Authentication 688 Option [RFC5925], or the SCTP Authenticated Chunks [RFC4895] are 689 recommended. 691 8.5. Reachability Control 693 The communication with the Mappin Systems is originally proposed 694 based on UDP that is not a reliable transport. For a proper 695 synchronization between the ETR and the Map-Servers periodic message 696 transmission would be needed. Usually, Map-Register messages are 697 retransmitted every minute by the ETR. The Map-Server removes the 698 EID entries if they are not refreshed for three successive periods. 699 In mobility solutions, typically a large number of EID entries needs 700 to be registered. Because of packet size limitations these entries 701 can be transported only by a significant number of Map-Register 702 messages in each period. A new reliable transport option has been 703 defined in [LISP-RELT] to solve these issues. Although this Internet 704 Draft has been expired, the new method is used in the latest widely 705 deployed LISP solution for Software Defined Access (SDA) by Cisco 706 Systems. The reliable transport is composed by new message formats 707 and the support for other then UDP as a transport in the control 708 plane. Both TCP and SCTP is addressed by the specification. The TCP 709 implementation could be traced in the labs. The messages are based 710 on a TLV format where a type filed support the future extensions of 711 the protocol. A message end marker provides extra integrity check 712 possibility for complex aggregated messages. Error notification 713 messages are also specified for notifying situations when the 714 receiver does not recognize or cannot parse message contents. The 715 following message types are specified for the reliable transport 716 mechanism: o Map-Register, o Registration acknowledgement, o 717 Registration rejection, o Registration refresh, o Mapping 718 notification, The session establishment has to be backward 719 compatible. The Map Server authenticates the ETR first using UDP 720 based messages. Once the ETR is authenticated, the Map Server 721 performs a passive open by listening on TCP port 4342. TCP 722 connections are accepted only from the already authenticated ETRs. 723 The ETR has to open the TCP connection actively towards the Map 724 Server one it has received the Map-Notify message on the UDP 725 transport. If the TCP session goes down, the same UDP based 726 procedure has to be repeated. The Map-Server will also revert to the 727 expiration mechanism used for UDP transport until the TCP based 728 session would be fully restored. A single TCP session is built up 729 for all subsequent control plane messages. This applies even when 730 multiple address families are used in the EID space. Once the 731 reliable transport can be used, the periodic refresh is not needed 732 anymore. Mapping information is sent only when there is new 733 information to share. Time-out based removal of registrations are 734 not used in this case. An explicit de-registration is needed by 735 carrying a zero TTL. The reliable transport session should be 736 authenticated. In the simpler case, it could be an RLOC spoofing 737 mitigation. If this is not reliable, then the TCP Authentication 738 Option [RFC5925], or the SCTP Authenticated Chunks [RFC4895] are 739 recommended. 741 8.6. Data Plane Security 743 8.6.1. Segmentation 745 LISP inherently delivers segmentation by using extended endpoint 746 identifiers (EIDs) and Instance-IDs to partition the EID space, 747 segment the map-caches, and color the control and data plane messages 748 to create virtual networks. These virtual networks are a seamless 749 extension of the way EIDs are normally handled in LISP and therefore 750 enjoy all the benefits of scale, mobility, and address family 751 independence that LISP provides. 753 8.6.2. Automated RLOC Filtering 755 The communication on between the xTRs and Map-Servers use the RLOC 756 space data plane. Only those communications attempts shall be 757 accepted that are coming from valid RLOC addresses. Manual 758 configuration of such access lists would be too difficult to manage. 759 An automated RLOC membership mechanism is proposed in [LISP-RFIL]. 760 Although this Internet Draft has been expired, it is still included 761 in some LISP implementations. The Map-Server can authenticate each 762 xTR that wants to communicate. It will build up a list of xTRs that 763 are valid members of this LISP administrative domain. An xTR can 764 specifically subscribe to this membership information. Membership 765 can be maintained by address family and instance ID (VPN). This 766 allows an easy management of both RLOC and EID space segmentation by 767 VPNs. It also supports gateway functions between separated RLOC 768 spaces. Only valid xTR members can apply for notifications of 769 membership information. The xTR receiving the membership information 770 might use it for building internal access control lists 771 automatically. Proxy xTR information is not included in the 772 membership list, so communication with such nodes need to be 773 configured manually. A membership message format is defined in 774 [LISP-RFIL]. The following message type are specified: o Membership 775 subscribe, o Membership subscribe acknowledgement, o Membership 776 subscribe negative acknowledgement, o Membership unsubscribe, o 777 Membership element add, o Membership element delete, o Membership 778 refresh request, o Membership refresh begin, o Membership refresh 779 end. The membership information could be used by the xTR for other 780 future functions, too. Automated RLOC filtering is just one example. 782 8.6.3. Confidentiality, Integrity and Anti-replay protection 784 In those sections of the ATN/IPS network where data plane 785 confidentiality, integrity and anti-replay protection may be 786 required, the LISP data plane can be secured as any other IP traffic 787 by leveraging IPsec. The provisioning of an IPsec VPN to secure IP 788 encapsulated LISP frames is orthogonal to deployment of LISP and can 789 be done using well known IPsec key negotiation mechanisms such as 790 IKEv2 [RFC7296]. 792 IKEv2 uses X.509 certificates for authentication. A PKI is needed 793 for managing the certificates. The certificates are used for 794 generating the exchanged symmetric encryption keys. 796 8.7. new section 798 9. IANA Considerations 800 No IANA considerations. 802 10. Acknowledgements 804 The authors would like to thank Dino Farinacci for his review of the 805 document. 807 11. References 809 11.1. Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, 813 DOI 10.17487/RFC2119, March 1997, 814 . 816 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 817 Locator/ID Separation Protocol (LISP)", RFC 6830, 818 DOI 10.17487/RFC6830, January 2013, 819 . 821 11.2. Informative References 823 [GBL] Frequentis, "Ground Based LISP for Multilink Operation, 824 https://www.icao.int/safety/acp/ACPWGF/CP WG-I 19/WP06 825 Ground_Based_LISP 2016-01-14.pdf", January 2016. 827 [I-D.ermagan-lisp-nat-traversal] 828 Ermagan, V., Farinacci, D., Lewis, D., Maino, F., 829 Portoles-Comeras, M., Skriver, J., White, C., Bresco, A., 830 and A. Cabellos-Aparicio, "NAT traversal for LISP", draft- 831 ermagan-lisp-nat-traversal-18 (work in progress), November 832 2020. 834 [I-D.ietf-lisp-eid-mobility] 835 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 836 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 837 Unified Control Plane", draft-ietf-lisp-eid-mobility-07 838 (work in progress), January 2021. 840 [I-D.ietf-lisp-pubsub] 841 Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., 842 Barkai, S., and M. Boucadair, "Publish/Subscribe 843 Functionality for LISP", draft-ietf-lisp-pubsub-07 (work 844 in progress), January 2021. 846 [I-D.ietf-lisp-rfc6833bis] 847 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 848 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 849 Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), 850 November 2020. 852 [I-D.ietf-lisp-sec] 853 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 854 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22 855 (work in progress), January 2021. 857 [I-D.moreno-lisp-uberlay] 858 Moreno, V., Farinacci, D., Rodriguez-Natal, A., Portoles- 859 Comeras, M., Maino, F., and S. Hooda, "Uberlay 860 Interconnection of Multiple LISP overlays", draft-moreno- 861 lisp-uberlay-03 (work in progress), August 2020. 863 [I-D.templin-atn-bgp] 864 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 865 Moreno, "A Simple BGP-based Mobile Routing System for the 866 Aeronautical Telecommunications Network", draft-templin- 867 atn-bgp-08 (work in progress), August 2018. 869 Authors' Addresses 871 Bernhard Haindl 872 Frequentis 874 Email: bernhard.haindl@frequentis.com 876 Manfred Lindner 877 Frequentis 879 Email: manfred.lindner@frequentis.com 881 Reshad Rahman 882 Cisco Systems 884 Email: rrahman@cisco.com 885 Marc Portoles Comeras 886 Cisco Systems 888 Email: mportole@cisco.com 890 Victor Moreno 891 Cisco Systems 893 Email: vimoreno@cisco.com 895 Fabio Maino 896 Cisco Systems 898 Email: fmaino@cisco.com 900 Balaji Venkatachalapathy 901 Cisco Systems 903 Email: bvenkata@cisco.com