idnits 2.17.1 draft-ietf-raw-ldacs-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1071: '... functions it MUST be ensured that t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 October 2020) is 1246 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW N. Maeurer, Ed. 3 Internet-Draft T. Graeupl, Ed. 4 Intended status: Informational German Aerospace Center (DLR) 5 Expires: 2 May 2021 C. Schmitt, Ed. 6 Research Institute CODE, UniBwM 7 29 October 2020 9 L-band Digital Aeronautical Communications System (LDACS) 10 draft-ietf-raw-ldacs-04 12 Abstract 14 This document provides an overview of the architecture of the L-band 15 Digital Aeronautical Communications System (LDACS), which provides a 16 secure, scalable and spectrum efficient terrestrial data link for 17 civil aviation. LDACS is a scheduled, reliable multi-application 18 cellular broadband system with support for IPv6. LDACS shall provide 19 a data link for IP network-based aircraft guidance. High reliability 20 and availability for IP connectivity over LDACS are therefore 21 essential. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 2 May 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 5 59 3.1. Voice Communications Today . . . . . . . . . . . . . . . 5 60 3.2. Data Communications Today . . . . . . . . . . . . . . . . 6 61 4. Provenance and Documents . . . . . . . . . . . . . . . . . . 7 62 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 8 64 5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 8 65 5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 9 67 5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2.1. Air-to-Ground Multilink . . . . . . . . . . . . . . . 9 69 5.2.2. Air-to-Air Extension for LDACS . . . . . . . . . . . 9 70 5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 10 71 5.2.4. Business Communication of Airlines . . . . . . . . . 11 72 5.2.5. LDACS Navigation . . . . . . . . . . . . . . . . . . 11 73 6. Requirements to LDACS . . . . . . . . . . . . . . . . . . . . 11 74 7. Characteristics of LDACS . . . . . . . . . . . . . . . . . . 13 75 7.1. LDACS Sub-Network . . . . . . . . . . . . . . . . . . . . 13 76 7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 14 77 7.3. LDACS Physical Layer . . . . . . . . . . . . . . . . . . 14 78 7.4. LDACS Data Link Layer . . . . . . . . . . . . . . . . . . 15 79 7.5. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 15 80 8. Reliability and Availability . . . . . . . . . . . . . . . . 15 81 8.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8.2. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 18 83 9. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 18 84 9.1. MAC Entity Services . . . . . . . . . . . . . . . . . . . 19 85 9.2. DLS Entity Services . . . . . . . . . . . . . . . . . . . 21 86 9.3. VI Services . . . . . . . . . . . . . . . . . . . . . . . 22 87 9.4. LME Services . . . . . . . . . . . . . . . . . . . . . . 22 88 9.5. SNP Services . . . . . . . . . . . . . . . . . . . . . . 22 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 10.1. Reasons for Wireless Digital Aeronautical 91 Communications . . . . . . . . . . . . . . . . . . . . . 22 92 10.2. Requirements for LDACS . . . . . . . . . . . . . . . . . 23 93 10.3. Security Objectives for LDACS . . . . . . . . . . . . . 24 94 10.4. Security Functions for LDACS . . . . . . . . . . . . . . 24 95 10.5. Security Architectural Details for LDACS . . . . . . . . 24 96 10.5.1. Entities in LDACS Security Model . . . . . . . . . . 25 97 10.5.2. Matter of LDACS Entity Identification . . . . . . . 25 98 10.5.3. Matter of LDACS Entity Authentication and Key 99 Negotiation . . . . . . . . . . . . . . . . . . . . . 25 100 10.5.4. Matter of LDACS Message-in-transit Confidentiality, 101 Integrity and Authenticity . . . . . . . . . . . . . 26 102 10.6. Security Architecture for LDACS . . . . . . . . . . . . 26 103 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 105 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 106 14. Normative References . . . . . . . . . . . . . . . . . . . . 27 107 15. Informative References . . . . . . . . . . . . . . . . . . . 27 108 Appendix A. Selected Information from DO-350A . . . . . . . . . 30 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 111 1. Introduction 113 One of the main pillars of the modern Air Traffic Management (ATM) 114 system is the existence of a communication infrastructure that 115 enables efficient aircraft control and safe separation in all phases 116 of flight. Current systems are technically mature but suffering from 117 the VHF band's increasing saturation in high-density areas and the 118 limitations posed by analogue radio communications. Therefore, 119 aviation globally and the European Union (EU) in particular, strives 120 for a sustainable modernization of the aeronautical communication 121 infrastructure. 123 In the long-term, ATM communication shall transition from analogue 124 VHF voice and VDLM2 communication to more spectrum efficient digital 125 data communication. The European ATM Master Plan foresees this 126 transition to be realized for terrestrial communications by the 127 development (and potential implementation) of the L-band Digital 128 Aeronautical Communications System (LDACS). LDACS shall enable IPv6 129 based air- ground communication related to the aviation safety and 130 regularity of flight. The particular challenge is that no additional 131 spectrum can be made available for terrestrial aeronautical 132 communication. It was thus necessary to develop co-existence 133 mechanism/procedures to enable the interference free operation of 134 LDACS in parallel with other aeronautical services/systems in the 135 same frequency band. 137 Since LDACS shall be used for aircraft guidance, high reliability and 138 availability for IP connectivity over LDACS are essential. 140 2. Terminology 142 The following terms are used in the context of RAW in this document: 144 A2A Air-to-Air 145 AeroMACS Aeronautical Mobile Airport Communication System 146 A2G Air-to-Ground 147 ACARS Aircraft Communications Addressing and Reporting System 148 ADS-C Automatic Dependent Surveillance - Contract 149 AM(R)S Aeronautical Mobile (Route) Service 150 ANSP Air Traffic Network Service Provider 151 AOC Aeronautical Operational Control 152 AS Aircraft Station 153 ATC Air-Traffic Control 154 ATM Air-Traffic Management 155 ATN Aeronautical Telecommunication Network 156 ATS Air Traffic Service 157 CCCH Common Control Channel 158 COTS IP Commercial Off-The-Shelf 159 CM Context Management 160 CNS Communication Navigation Surveillance 161 CPDLC Controller Pilot Data Link Communication 162 DCCH Dedicated Control Channel 163 DCH Data Channel 164 DLL Data Link Layer 165 DLS Data Link Service 166 DME Distance Measuring Equipment 167 DSB-AM Double Side-Band Amplitude Modulation 168 FCI Future Communication Infrastructure 169 FL Forward Link 170 GNSS Global Navigation Satellite System 171 GS Ground-Station 172 GSC Ground-Station Controller 173 G2A Ground-to-Air 174 HF High Frequency 175 ICAO International Civil Aviation Organization 176 IP Internet Protocol 177 kbit/s kilobit per second 178 LDACS L-band Digital Aeronautical Communications System 179 LLC Logical Link Control 180 LME LDACS Management Entity 181 MAC Medium Access Layer 182 MF Multi Frame 183 OFDM Orthogonal Frequency-Division Multiplexing 184 OFDMA Orthogonal Frequency-Division Multiplexing Access 185 OSI Open Systems Interconnection 186 PHY Physical Layer 187 RL Reverse Link 188 SF Super-Frame 189 SNP Sub-Network Protocol 190 TDMA Time-Division Multiplexing-Access 191 VDLM1 VHF Data Link mode 1 192 VDLM2 VHF Data Link mode 2 193 VHF Very High Frequency 194 VI Voice Interface 196 3. Motivation and Use Cases 198 Aircraft are currently connected to Air-Traffic Control (ATC) and 199 Aeronautical Operational Control (AOC) via voice and data 200 communications systems through all phases of a flight. Within the 201 airport terminal, connectivity is focused on high bandwidth 202 communications, while during en-route high reliability, robustness, 203 and range is the main focus. Voice communications may use the same 204 or different equipment as data communications systems. In the 205 following the main differences between voice and data communications 206 capabilities are summarized. The assumed use cases for LDACS 207 completes the list of use cases stated in [RAW-USE-CASES] and the 208 list of reliable and available wireless technologies presented in 209 [RAW-TECHNOS]. 211 3.1. Voice Communications Today 213 Voice links are used for Air-to-Ground (A2G) and Air-to-Air (A2A) 214 communications. The communication equipment is either ground-based 215 working in the High Frequency (HF) or Very High Frequency (VHF) 216 frequency band or satellite-based. All VHF and HF voice 217 communications is operated via open broadcast channels without 218 authentication, encryption or other protective measures. The use of 219 well-proven communication procedures via broadcast channels helps to 220 enhance the safety of communications by taking into account that 221 other users may encounter communication problems and may be 222 supported, if required. The main voice communications media is still 223 the analogue VHF Double Side-Band Amplitude Modulation (DSB-AM) 224 communications technique, supplemented by HF Single Side-Band 225 Amplitude Modulation and satellite communications for remote and 226 oceanic areas. DSB-AM has been in use since 1948, works reliably and 227 safely, and uses low-cost communication equipment. These are the 228 main reasons why VHF DSB-AM communications is still in use, and it is 229 likely that this technology will remain in service for many more 230 years. This however results in current operational limitations and 231 impediments in deploying new Air-Traffic Management (ATM) 232 applications, such as flight-centric operation with Point-to-Point 233 communications. 235 3.2. Data Communications Today 237 Like for voice, data communications into the cockpit is currently 238 provided by ground-based equipment operating either on HF or VHF 239 radio bands or by legacy satellite systems. All these communication 240 systems are using narrowband radio channels with a data throughput 241 capacity in order of kilobits per second. While the aircraft is on 242 ground some additional communications systems are available, like the 243 Aeronautical Mobile Airport Communication System (AeroMACS) or public 244 cellular networks, operating in the Airport (APT) domain and able to 245 deliver broadband communication capability. 247 The data communication networks used for the transmission of data 248 relating to the safety and regularity of the flight must be strictly 249 isolated from those providing entertainment services to passengers. 250 This leads to a situation that the flight crews are supported by 251 narrowband services during flight while passengers have access to 252 inflight broadband services. The current HF and VHF data links 253 cannot provide broadband services now or in the future, due to the 254 lack of available spectrum. This technical shortcoming is becoming a 255 limitation to enhanced ATM operations, such as Trajectory-Based 256 Operations and 4D trajectory negotiations. 258 Satellite-based communications are currently under investigation and 259 enhanced capabilities are under development which will be able to 260 provide inflight broadband services and communications supporting the 261 safety and regularity of flight. In parallel, the ground-based 262 broadband data link technology LDACS is being standardized by ICAO 263 and has recently shown its maturity during flight tests [SCH20191]. 264 The LDACS technology is scalable, secure and spectrum efficient and 265 provides significant advantages to the users and service providers. 266 It is expected that both - satellite systems and LDACS - will be 267 deployed to support the future aeronautical communication needs as 268 envisaged by the ICAO Global Air Navigation Plan. 270 4. Provenance and Documents 272 The development of LDACS has already made substantial progress in the 273 Single European Sky ATM Research framework, short SESAR, and is 274 currently being continued in the follow-up program SESAR2020 275 [RIH2018]. A key objective of the this activities is to develop, 276 implement and validate a modern aeronautical data link able to evolve 277 with aviation needs over long-term. To this end, an LDACS 278 specification has been produced [GRA2019] and is continuously 279 updated; transmitter demonstrators were developed to test the 280 spectrum compatibility of LDACS with legacy systems operating in the 281 L-band [SAJ2014]; and the overall system performance was analyzed by 282 computer simulations, indicating that LDACS can fulfil the identified 283 requirements [GRA2011]. 285 LDACS standardization within the framework of the ICAO started in 286 December 2016. The ICAO standardization group has produced an 287 initial Standards and Recommended Practices document [ICA2018]. It 288 defines the general characteristics of LDACS. The ICAO 289 standardization group plans to produce an ICAO technical manual - the 290 ICAO equivalent to a technical standard - within the next years. 291 Generally, the group is open to input from all sources and develops 292 LDACS in the open. 294 Up to now LDACS standardization has been focused on the development 295 of the physical layer and the data link layer, only recently have 296 higher layers come into the focus of the LDACS development 297 activities. There is currently no "IPv6 over LDACS" specification 298 publicly available; however, SESAR2020 has started the testing of 299 IPv6-based LDACS testbeds. 301 The IPv6 architecture for the aeronautical telecommunication network 302 is called the Future Communications Infrastructure (FCI). FCI shall 303 support quality of service, diversity, and mobility under the 304 umbrella of the "multi-link concept". This work is conducted by ICAO 305 Communication Panel working group WG-I. 307 In addition to standardization activities several industrial LDACS 308 prototypes have been built. One set of LDACS prototypes has been 309 evaluated in flight trials confirming the theoretical results 310 predicting the system performance [GRA2018] [SCH20191]. 312 5. Applicability 314 LDACS is a multi-application cellular broadband system capable of 315 simultaneously providing various kinds of Air Traffic Services 316 (including ATS-B3) and AOC communications services from deployed 317 Ground-Stations (GS). The LDACS A2G sub-system physical layer and 318 data link layer are optimized for data link communications, but the 319 system also supports digital air-ground voice communications. 321 LDACS supports communication in all airspaces (airport, terminal 322 maneuvering area, and en-route), and on the airport surface. The 323 physical LDACS cell coverage is effectively de-coupled from the 324 operational coverage required for a particular service. This is new 325 in aeronautical communications. Services requiring wide-area 326 coverage can be installed at several adjacent LDACS cells. The 327 handover between the involved LDACS cells is seamless, automatic, and 328 transparent to the user. Therefore, the LDACS A2G communications 329 concept enables the aeronautical communication infrastructure to 330 support future dynamic airspace management concepts. 332 5.1. Advances Beyond the State-of-the-Art 334 LDACS offers several capabilities that are not provided in 335 contemporarily deployed aeronautical communication systems. 337 5.1.1. Priorities 339 LDACS is able to manage services priorities, an important feature not 340 available in some of the current data link deployments. Thus, LDACS 341 guarantees bandwidth, low latency, and high continuity of service for 342 safety critical ATS applications while simultaneously accommodating 343 less safety-critical AOC services. 345 5.1.2. Security 347 LDACS is a secure data link with built-in security mechanisms. It 348 enables secure data communications for ATS and AOC services, 349 including secured private communications for aircraft operators and 350 ANSPs (Air Traffic Network Service Providers). This includes 351 concepts for key and trust management, mutual authenticated key 352 exchange protocols, key derivation measures, user and control 353 message-in-transit confidentiality and authenticity protection, 354 secure logging and availability and robustness measures [MAE20181], 355 [MAE20191], [MAE20192]. 357 5.1.3. High Data Rates 359 The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the 360 forward link (FL) for the connection Ground-to-Air (G2A), and 294 361 kbit/s to 1390 kbit/s on the reverse link (RF) for the connection 362 A2G, depending on coding and modulation. This is 50 times the amount 363 terrestrial digital aeronautical communications systems such as VDLM2 364 provide [SCH20191]. 366 5.2. Application 368 LDACS shall be used by several aeronautical applications ranging from 369 enhanced communication protocol stacks (multi-homed mobile IPv6 370 networks in the aircraft and potentially ad-hoc networks between 371 aircraft) to classical communication applications (sending GBAS 372 correction data) and integration with other service domains (using 373 the communication signal for navigation). 375 5.2.1. Air-to-Ground Multilink 377 It is expected that LDACS together with upgraded satellite-based 378 communications systems will be deployed within the FCI and constitute 379 one of the main components of the multilink concept within the FCI. 381 Both technologies, LDACS and satellite systems, have their specific 382 benefits and technical capabilities which complement each other. 383 Especially, satellite systems are well-suited for large coverage 384 areas with less dense air traffic, e.g. oceanic regions. LDACS is 385 well-suited for dense air traffic areas, e.g. continental areas or 386 hot-spots around airports and terminal airspace. In addition, both 387 technologies offer comparable data link capacity and, thus, are well- 388 suited for redundancy, mutual back-up, or load balancing. 390 Technically the FCI multilink concept shall be realized by multi- 391 homed mobile IPv6 networks in the aircraft. The related protocol 392 stack is currently under development by ICAO and the Single European 393 Sky ATM Research framework. 395 5.2.2. Air-to-Air Extension for LDACS 397 A potential extension of the multi-link concept is its extension to 398 ad-hoc networks between aircraft. 400 Direct A2A communication between aircrafts in terms of ad-hoc data 401 networks is currently considered a research topic since there is no 402 immediate operational need for it, although several possible use 403 cases are discussed (digital voice, wake vortex warnings, and 404 trajectory negotiation) [BEL2019]. It should also be noted that 405 currently deployed analog VHF voice radios support direct voice 406 communication between aircraft, making a similar use case for digital 407 voice plausible. 409 LDACS direct A2A is currently not part of standardization. 411 5.2.3. Flight Guidance 413 The FCI (and therefore LDACS) shall be used to host flight guidance. 414 This is realized using three applications: 416 1. Context Management (CM): The CM application shall manage the 417 automatic logical connection to the ATC center currently 418 responsible to guide the aircraft. Currently this is done by the 419 air crew manually changing VHF voice frequencies according to the 420 progress of the flight. The CM application automatically sets up 421 equivalent sessions. 422 2. Controller Pilot Data Link Communication (CPDLC): The CPDLC 423 application provides the air crew with the ability to exchange 424 data messages similar to text messages with the currently 425 responsible ATC center. The CPDLC application shall take over 426 most of the communication currently performed over VHF voice and 427 enable new services that do not lend themselves to voice 428 communication (e.g., trajectory negotiation). 429 3. Automatic Dependent Surveillance - Contract (ADS-C): ADS-C 430 reports the position of the aircraft to the currently active ATC 431 center. Reporting is bound to "contracts", i.e. pre-defined 432 events related to the progress of the flight (i.e. the 433 trajectory). ADS-C and CPDLC are the primary applications used to 434 implement in-flight trajectory management. 436 CM, CPDLC, and ADS-C are available on legacy datalinks, but not 437 widely deployed and with limited functionality. 439 Further ATC applications may be ported to use the FCI or LDACS as 440 well. A notable application is GBAS for secure, automated landings: 441 The Global Navigation Satellite System (GNSS) based Ground Based 442 Augmentation System (GBAS) is used to improve the accuracy of GNSS to 443 allow GNSS based instrument landings. This is realized by sending 444 GNSS correction data (e.g., compensating ionospheric errors in the 445 GNSS signal) to the aircraft's GNSS receiver via a separate data 446 link. Currently the VDB data link is used. VDB is a narrow-band 447 single-purpose datalink without advanced security only used to 448 transmit GBAS correction data. This makes VDB a natural candidate 449 for replacement by LDACS. 451 5.2.4. Business Communication of Airlines 453 In addition to air traffic services AOC services shall be transmitted 454 over LDACS. AOC is a generic term referring to the business 455 communication of airlines. Regulatory this is considered related to 456 the safety and regularity of flight and may therefore be transmitted 457 over LDACS. 459 AOC communication is considered the main business case for LDACS 460 communication service providers since modern aircraft generate 461 significant amounts of data (e.g., engine maintenance data). 463 5.2.5. LDACS Navigation 465 Beyond communication radio signals can always also be used for 466 navigation. LDACS takes this into account. 468 For future aeronautical navigation, ICAO recommends the further 469 development of GNSS based technologies as primary means for 470 navigation. However, the drawback of GNSS is its inherent single 471 point of failure - the satellite. Due to the large separation 472 between navigational satellites and aircraft, the received power of 473 GNSS signals on the ground is very low. As a result, GNSS 474 disruptions might occasionally occur due to unintentional 475 interference, or intentional jamming. Yet the navigation services 476 must be available with sufficient performance for all phases of 477 flight. Therefore, during GNSS outages, or blockages, an alternative 478 solution is needed. This is commonly referred to as Alternative 479 Positioning, Navigation, and Timing (APNT). 481 One of such APNT solution consists of integrating the navigation 482 functionality into LDACS. The ground infrastructure for APNT is 483 deployed through the implementation of LDACS's GSs and the navigation 484 capability comes "for free". 486 LDACS navigation has already been demonstrated in practice in a 487 flight measurement campaign [SCH20191]. 489 6. Requirements to LDACS 491 The requirements to LDACS are mostly defined by its application area: 492 Communication related to safety and regularity of flight. 494 A particularity of the current aeronautical communication landscape 495 is that it is heavily regulated. Aeronautical data links (for 496 applications related to safety and regularity of flight) may only use 497 spectrum licensed to aviation and data links endorsed by ICAO. 498 Nation states can change this locally, however, due to the global 499 scale of the air transportation system adherence to these practices 500 is to be expected. 502 Aeronautical data links for the Aeronautical Telecommunication 503 Network (ATN) are therefore expected to remain in service for 504 decades. The VDLM2 data link currently used for digital terrestrial 505 internetworking was developed in the 1990es (the use of the Open 506 Systems Interconnection (OSI) stack indicates that as well). VDLM2 507 is expected to be used at least for several decades. In this respect 508 aeronautical communication (for applications related to safety and 509 regularity of flight) is more comparable to industrial applications 510 than to the open Internet. 512 Internetwork technology is already installed in current aircraft. 513 Current ATS applications use either the Aircraft Communications 514 Addressing and Reporting System (ACARS) or the OSI stack. The 515 objective of the development effort LDACS as part of the FCI is to 516 replace legacy OSI stack and proprietary ACARS internetwork 517 technologies with industry standard IP technology. It is anticipated 518 that the use of Commercial Off-The-Shelf (COTS) IP technology mostly 519 applies to the ground network. The avionics networks on the aircraft 520 will likely be heavily modified or proprietary. 522 AOC applications currently mostly use the same stack (although some 523 applications, like the graphical weather service may use the 524 commercial passenger network). This creates capacity problems 525 (resulting in excessive amounts of timeouts) since the underlying 526 terrestrial data links (VDLM1/2) do not provide sufficient bandwidth. 527 The use of non-aviation specific data links is considered a security 528 problem. Ideally the aeronautical IP internetwork and the Internet 529 should be completely separated. 531 The objective of LDACS is to provide a next generation terrestrial 532 data link designed to support IP and provide much higher bandwidth to 533 avoid the currently experienced operational problems. 535 The requirement for LDACS is therefore to provide a terrestrial high- 536 throughput data link for IP internetworking in the aircraft. 538 In order to fulfil the above requirement LDACS needs to be 539 interoperable with IP (and IP-based services like Voice-over-IP) at 540 the gateway connecting the LDACS network to other aeronautical ground 541 networks (the totality of them being the ATN). On the avionics side 542 in the aircraft aviation specific solutions are to be expected. 544 In addition to the functional requirements LDACS and its IP stack 545 need to fulfil the requirements defined in RTCA DO-350A/EUROCAE ED- 546 228A [DO350A]. This document defines continuity, availability, and 547 integrity requirements at different scopes for each air traffic 548 management application (CPDLC, CM, and ADS-C). The scope most 549 relevant to IP over LDACS is the CSP (Communication Service Provider) 550 scope. 552 Continuity, availability, and integrity requirements are defined in 553 [DO350A] volume 1 Table 5-14, and Table 6-13. Appendix A presents 554 the required information. 556 In a similar vein, requirements to fault management are defined in 557 the same tables. 559 7. Characteristics of LDACS 561 LDACS will become one of several wireless access networks connecting 562 aircraft to the ATN implemented by the FCI and possibly ACARS/FANS 563 networks [FAN2019]. 565 The current LDACS design is focused on the specification of layer 2. 567 Achieving stringent the continuity, availability, and integrity 568 requirements defined in [DO350A] will require the specification of 569 layer 3 and above mechanisms (e.g. reliable crossover at the IP 570 layer). Fault management mechanisms are similarly undefined. Input 571 from the working group will be appreciated here. 573 7.1. LDACS Sub-Network 575 An LDACS sub-network contains an Access Router (AR), a Ground-Station 576 Controller (GSC), and several GS, each of them providing one LDACS 577 radio cell. 579 User plane interconnection to the ATN is facilitated by the AR 580 peering with an A2G Router connected to the ATN. It is up to 581 implementer's choice to keep AR and A2G Router functions separated, 582 or to merge them. 584 The internal control plane of an LDACS sub-network is managed by the 585 GSC. An LDACS sub-network is illustrated in Figure 1. 587 wireless user 588 link plane 589 A--------------G----------------AR---A2G-----ATN 590 S..............S | Router 591 . control . | 592 . plane . | 593 . . | 594 GSC..............| 595 . | 596 . | 597 GS---------------+ 599 Figure 1: LDACS sub-network with two GSs and one AS 601 7.2. Topology 603 LDACS operating in A2G mode is a cellular point-to-multipoint system. 604 The A2G mode assumes a star-topology in each cell where Aircraft 605 Stations (AS) belonging to aircraft within a certain volume of space 606 (the LDACS cell) is connected to the controlling GS. The LDACS GS is 607 a centralized instance that controls LDACS A2G communications within 608 its cell. The LDACS GS can simultaneously support multiple bi- 609 directional communications to the ASs under its control. LDACS's GSs 610 themselves are connected to a GSC controlling the LDACS sub-network. 612 Prior to utilizing the system an AS has to register with the 613 controlling GS to establish dedicated logical channels for user and 614 control data. Control channels have statically allocated resources, 615 while user channels have dynamically assigned resources according to 616 the current demand. Logical channels exist only between the GS and 617 the AS. 619 The LDACS wireless link protocol stack defines two layers, the 620 physical layer and the data link layer. 622 7.3. LDACS Physical Layer 624 The physical layer provides the means to transfer data over the radio 625 channel. The LDACS GS supports bi-directional links to multiple 626 aircraft under its control. The FL direction at the G2A connection 627 and the RL direction at the A2G connection are separated by Frequency 628 Division Duplex. FL and RL use a 500 kHz channel each. The GS 629 transmits a continuous stream of Orthogonal Frequency-Division 630 Multiplexing (OFDM) symbols on the FL. In the RL different aircraft 631 are separated in time and frequency using a combination of Orthogonal 632 Frequency-Division Multiple-Access (OFDMA) and Time-Division 633 Multiple-Access (TDMA). Aircraft thus transmit discontinuously on 634 the RL with radio bursts sent in precisely defined transmission 635 opportunities allocated by the GS. 637 7.4. LDACS Data Link Layer 639 The data-link layer provides the necessary protocols to facilitate 640 concurrent and reliable data transfer for multiple users. The LDACS 641 data link layer is organized in two sub-layers: The medium access 642 sub-layer and the Logical Link Control (LLC) sub-layer. The medium 643 access sub-layer manages the organization of transmission 644 opportunities in slots of time and frequency. The LLC sub-layer 645 provides acknowledged point-to-point logical channels between the 646 aircraft and the GS using an automatic repeat request protocol. 647 LDACS supports also unacknowledged point-to-point channels and G2A 648 broadcast. 650 7.5. LDACS Mobility 652 LDACS supports layer 2 handovers to different LDACS channels. 653 Handovers may be initiated by the aircraft (break-before-make) or by 654 the GS (make-before-break). Make-before-break handovers are only 655 supported for GSs connected to the same GSC. 657 External handovers between non-connected LDACS sub-networks or 658 different aeronautical data links shall be handled by the FCI multi- 659 link concept. 661 8. Reliability and Availability 663 8.1. Layer 2 665 LDACS has been designed with applications related to the safety and 666 regularity of flight in mind. It has therefore been designed as a 667 deterministic wireless data link (as far as this is possible). 669 Based on channel measurements of the L-band channel [SCHN2016] and 670 respecting the specific nature of the area of application, LDACS was 671 designed from the PHY layer up with robustness in mind. 673 In order to maximize the capacity per channel and to optimally use 674 the available spectrum, LDACS was designed as an OFDM-based Frequency 675 Division Duplex system, supporting simultaneous transmissions in FL 676 at the G2A connection and RF at the A2G connection. The legacy 677 systems already deployed in the L-band limit the bandwidth of both 678 channels to approximately 500 kHz. 680 The LDACS physical layer design includes propagation guard times 681 sufficient for the operation at a maximum distance of 200 nautical 682 miles from the GS. In actual deployment, LDACS can be configured for 683 any range up to this maximum range. 685 The LDACS FL physical layer is a continuous OFDM transmission. LDACS 686 RL transmission is based on OFDMA-TDMA bursts, with silence between 687 such bursts. The RL resources (i.e. bursts) are assigned to 688 different ASs on demand by the GS. 690 The LDACS physical layer supports adaptive coding and modulation for 691 user data. Control data is always encoded with the most robust 692 coding and modulation (QPSK coding rate 1/2). 694 LDACS medium access on top of the physical layer uses a static frame 695 structure to support deterministic timer management. As shown in 696 Figure 3 and Figure 4, LDACS framing structure is based on Super- 697 Frames (SF) of 240ms duration corresponding to 2000 OFDM symbols. FL 698 and RL boundaries are aligned in time (from the GS perspective) 699 allowing for deterministic sending windows for KEEP ALIVE messages 700 and control and data channels in general. 702 LDACS medium access is always under the control of the GS of a radio 703 cell. Any medium access for the transmission of user data has to be 704 requested with a resource request message stating the requested 705 amount of resources and class of service. The GS performs resource 706 scheduling on the basis of these requests and grants resources with 707 resource allocation messages. Resource request and allocation 708 messages are exchanged over dedicated contention-free control 709 channels. 711 The purpose of Quality-of-Service in LDACS medium access is to 712 provide prioritized medium access at the bottleneck (the wireless 713 link). The signaling of higher layer Quality-of-Service requirements 714 to LDACS is yet to be defined. A DiffServ-based solution with a 715 small number of priorities is to be expected. 717 LDACS has two mechanisms to request resources from the scheduler in 718 the GS. 720 Resources can either be requested "on demand" with a given priority. 721 On the FL, this is done locally in the GS, on the RL a dedicated 722 contention-free control channel is used called Dedicated Control 723 Channel (DCCH), which is roughly 83 bit every 60 ms. A resource 724 allocation is always announced in the control channel of the FL, 725 short Common Control Channel (CCCH) having variable size. Due to the 726 spacing of the RL control channels every 60 ms, a medium access delay 727 in the same order of magnitude is to be expected. 729 Resources can also be requested "permanently". The permanent 730 resource request mechanism supports requesting recurring resources in 731 given time intervals. A permanent resource request has to be 732 canceled by the user (or by the GS, which is always in control). 734 User data transmissions over LDACS are therefore always scheduled by 735 the GS, while control data uses statically (i.e. at cell entry) 736 allocated recurring resources (DCCH and CCCH). The current 737 specification specifies no scheduling algorithm. Scheduling of RL 738 resources is done in physical Protocol Data Units of 112 bit (or 739 larger if more aggressive coding and modulation is used). Scheduling 740 on the FL is done Byte-wise since the FL is transmitted continuously 741 by the GS. 743 In addition to having full control over resource scheduling, the GS 744 can send forced Handover commands for off-loading or RF channel 745 management, e.g. when the signal quality declines and a more suitable 746 GS is in the AS reach. With robust resource management of the 747 capacities of the radio channel, reliability and robustness measures 748 are therefore also anchored in the LDACS management entity. 750 In addition, to radio resource management, the LDACS control channels 751 are also used to send keep-alive messages, when they are not 752 otherwise used. Since the framing of the control channels is 753 deterministic, missing keep-alive messages can thus be immediately 754 detected. This information is made available to the multi-link 755 protocols for fault management. 757 The protocol used to communicate faults is not defined in the LDACS 758 specification. It is assumed that vendors would use industry 759 standard protocols like the Simple Network Management Protocol or the 760 Network Configuration Protocol where security permits. 762 The LDACS data link layer protocol running on top of the medium 763 access sub-layer uses ARQ to provide reliable data transmission on 764 layer 2. 766 It employs selective repeat ARQ with transparent fragmentation and 767 reassembly to the resource allocation size to achieve low latency and 768 a low overhead without losing reliability. It ensures correct order 769 of packet delivery without duplicates. In case of transmission 770 errors it identifies lost fragments with deterministic timers synced 771 to the medium access frame structure and initiates retransmission. 772 Additionally, the priority mechanism of LDACS ensures the timely 773 delivery of messages with high importance. 775 8.2. Beyond Layer 2 777 LDACS availability can be increased by appropriately deploying LDACS 778 infrastructure: This means proliferating the number of terrestrial 779 base stations. However, the scarcity of aeronautical spectrum for 780 data link communication (in the case of LDACS: tens of MHz in the 781 L-band) and the long range (in the case of LDACS: up to 400 km) make 782 this quite hard. The deployment of a larger number of small cells is 783 certainly possible, suffers, however, also from the scarcity of 784 spectrum. An additional constraint to take into account, is that 785 Distance Measuring Equipment (DME) is the primary user of the 786 aeronautical L-band. That is, any LDACS deployment has to take DME 787 frequency planning into account, too. 789 The aeronautical community has therefore decided not to rely on a 790 single communication system or frequency band. It is envisioned to 791 have multiple independent data link technologies in the aircraft 792 (e.g., terrestrial and SatCom) in addition to legacy VHF voice. 794 However, as of now no reliability and availability mechanisms that 795 could utilize the multi-link have been specified on Layer 3 and 796 above. 798 Below Layer 2 aeronautics usually relies on hardware redundancy. To 799 protect availability of the LDACS link, an aircraft equipped with 800 LDACS will have access to two L-band antennae with triple redundant 801 radio systems as required for any safety relevant system by ICAO. 803 9. Protocol Stack 805 The protocol stack of LDACS is implemented in the AS, GS, and GSC: It 806 consists of the Physical Layer (PHY) with five major functional 807 blocks above it. Four are placed in the Data Link Layer (DLL) of the 808 AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI), 809 (3) Data Link Service (DLS), and (4) LDACS Management Entity (LME). 810 The last entity resides within the Sub-Network Layer: Sub-Network 811 Protocol (SNP). The LDACS network is externally connected to voice 812 units, radio control units, and the ATN Network Layer. 814 Figure 2 shows the protocol stack of LDACS as implemented in the AS 815 and GS. 817 IPv6 Network Layer 818 | 819 | 820 +------------------+ +----+ 821 | SNP |--| | Sub-Network 822 | | | | Layer 823 +------------------+ | | 824 | | LME| 825 +------------------+ | | 826 | DLS | | | Logical Link 827 | | | | Control Layer 828 +------------------+ +----+ 829 | | 830 DCH DCCH/CCCH 831 | RACH/BCCH 832 | | 833 +--------------------------+ 834 | MAC | Medium Access 835 | | Layer 836 +--------------------------+ 837 | 838 +--------------------------+ 839 | PHY | Physical Layer 840 +--------------------------+ 841 | 842 | 843 ((*)) 844 FL/RL radio channels 845 separated by 846 Frequency Division Duplex 848 Figure 2: LDACS protocol stack in AS and GS 850 9.1. MAC Entity Services 852 The MAC time framing service provides the frame structure necessary 853 to realize slot-based Time Division Multiplex access on the physical 854 link. It provides the functions for the synchronization of the MAC 855 framing structure and the PHY Layer framing. The MAC time framing 856 provides a dedicated time slot for each logical channel. 858 The MAC Sub-Layer offers access to the physical channel to its 859 service users. Channel access is provided through transparent 860 logical channels. The MAC Sub-Layer maps logical channels onto the 861 appropriate slots and manages the access to these channels. Logical 862 channels are used as interface between the MAC and LLC Sub-Layers. 864 The LDACS framing structure for FL and RL is based on Super-Frames 865 (SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbols. 866 The FL and RL SF boundaries are aligned in time (from the view of the 867 GS). 869 In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56 870 OFDM symbols) for the Broadcast Control Channel (BCCH), and four 871 Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols). 873 In the RL, each SF starts with a Random Access (RA) slot of length 874 6.72 ms with two opportunities for sending RL random access frames 875 for the Random Access Channel (RACH), followed by four MFs. These 876 MFs have the same fixed duration of 58.32 ms as in the FL, but a 877 different internal structure 879 Figure 3 and Figure 4 illustrate the LDACS frame structure. 881 ^ 882 | +------+------------+------------+------------+------------+ 883 | FL | BCCH | MF | MF | MF | MF | 884 F +------+------------+------------+------------+------------+ 885 r <---------------- Super-Frame (SF) - 240ms ----------------> 886 e 887 q +------+------------+------------+------------+------------+ 888 u RL | RACH | MF | MF | MF | MF | 889 e +------+------------+------------+------------+------------+ 890 n <---------------- Super-Frame (SF) - 240ms ----------------> 891 c 892 y 893 | 894 ----------------------------- Time ------------------------------> 895 | 897 Figure 3: SF structure for LDACS 899 ^ 900 | +-------------+------+-------------+ 901 | FL | DCH | CCCH | DCH | 902 F +-------------+------+-------------+ 903 r <---- Multi-Frame (MF) - 58.32ms --> 904 e 905 q +------+---------------------------+ 906 u RL | DCCH | DCH | 907 e +------+---------------------------+ 908 n <---- Multi-Frame (MF) - 58.32ms --> 909 c 910 y 911 | 912 -------------------- Time ------------------> 913 | 915 Figure 4: MF structure for LDACS 917 9.2. DLS Entity Services 919 The DLS provides acknowledged and unacknowledged (including broadcast 920 and packet mode voice) bi-directional exchange of user data. If user 921 data is transmitted using the acknowledged DLS, the sending DLS 922 entity will wait for an acknowledgement from the receiver. If no 923 acknowledgement is received within a specified time frame, the sender 924 may automatically try to retransmit its data. However, after a 925 certain number of failed retries, the sender will suspend further 926 retransmission attempts and inform its client of the failure. 928 The DLS uses the logical channels provided by the MAC: 930 1. A GS announces its existence and access parameters in the 931 Broadcast Channel (BC). 932 2. The RA channel enables AS to request access to an LDACS cell. 933 3. In the FL the CCCH is used by the GS to grant access to data 934 channel resources. 935 4. The reverse direction is covered by the RL, where ASs need to 936 request resources before sending. This happens via the DCCH. 937 5. User data itself is communicated in the Data Channel (DCH) on the 938 FL and RL. 940 9.3. VI Services 942 The VI provides support for virtual voice circuits. Voice circuits 943 may either be set-up permanently by the GS (e.g., to emulate voice 944 party line) or may be created on demand. The creation and selection 945 of voice circuits is performed in the LME. The VI provides only the 946 transmission services. 948 9.4. LME Services 950 The mobility management service in the LME provides support for 951 registration and de-registration (cell entry and cell exit), scanning 952 RF channels of neighboring cells and handover between cells. In 953 addition, it manages the addressing of aircraft/ ASs within cells. 954 It is controlled by the network management service in the GSC. 956 The resource management service provides link maintenance (power, 957 frequency and time adjustments), support for adaptive coding and 958 modulation, and resource allocation. 960 9.5. SNP Services 962 The DLS provides functions required for the transfer of user plane 963 data and control plane data over the LDACS sub-network. 965 The security service provides functions for secure communication over 966 the LDACS sub-network. Note that the SNP security service applies 967 cryptographic measures as configured by the GSC. 969 10. Security Considerations 971 10.1. Reasons for Wireless Digital Aeronautical Communications 973 Aviation will require secure exchanges of data and voice messages for 974 managing the air-traffic flow safely through the airspaces all over 975 the world. Historically Communication Navigation Surveillance (CNS) 976 wireless communications technology emerged from military and a threat 977 landscape where inferior technological and financial capabilities of 978 adversaries were assumed [STR2016]. The main communication method 979 for ATC today is still an open analogue voice broadcast within the 980 aeronautical VHF band. Currently, the information security is purely 981 procedural based by using well-trained personnel and proven 982 communications procedures. This communication method has been in 983 service since 1948. However since the emergence of civil 984 aeronautical CNS application and today, the world has changed. First 985 of all civil applications have significant lower spectrum available 986 than military applications. This means several military defense 987 mechanisms such as frequency hopping or pilot symbol scrambling and 988 thus a defense-in-depth approach starting at the physical layer is 989 impossible for civil systems. With the rise of cheap Software 990 Defined Radios, the previously existing financial barrier is almost 991 gone and open source projects such as GNU radio [GNU2012] allow the 992 new type of unsophisticated listeners and possible attackers. 993 Furthermore most CNS technology developed in ICAO relies on open 994 standards, thus syntax and semantics of wireless digital aeronautical 995 communications can be common knowledge for attackers. Finally with 996 increased digitization and automation of civil aviation the human as 997 control instance is being taken gradually out of the loop. 998 Autonomous transport drones or single piloted aircraft demonstrate 999 this trend. However without profound cybersecurity measures such as 1000 authenticity and integrity checks of messages in-transit on the 1001 wireless link or mutual entity authentication, this lack of a control 1002 instance can prove disastrous. Thus future digital communications 1003 waveforms will need additional embedded security features to fulfill 1004 modern information security requirements like authentication and 1005 integrity. However, these security features require sufficient 1006 bandwidth which is beyond the capabilities of a VHF narrowband 1007 communications system. For voice and data communications, sufficient 1008 data throughput capability is needed to support the security 1009 functions while not degrading performance. LDACS is a data link 1010 technology with sufficient bandwidth to incorporate security without 1011 losing too much user throughput. 1013 As digitalization progresses even further with LDACS and automated 1014 procedures such as 4D-Trajectories allowing semi-automated en-route 1015 flying of aircraft, LDACS requires stronger cybersecurity measures. 1017 10.2. Requirements for LDACS 1019 Overall there are several business goals for cybersecurity to protect 1020 in FCI in civil aviation: 1022 1. Safety: The system must sufficiently mitigate attacks, which 1023 contribute to safety hazards. 1024 2. Flight regularity: The system must sufficiently mitigate attacks, 1025 which contribute to delays, diversions, or cancellations of 1026 flights. 1027 3. Protection of business interests: The system must sufficiently 1028 mitigate attacks which result in financial loss, reputation 1029 damage, disclosure of sensitive proprietary information, or 1030 disclosure of personal information. 1032 To further analyze assets and derive threats and thus protection 1033 scenarios several Threat-and Risk Analysis were performed for LDACS 1034 [MAE20181] , [MAE20191]. These results allowed deriving security 1035 scope and objectives from the requirements and the conducted Threat- 1036 and Risk Analysis. 1038 10.3. Security Objectives for LDACS 1040 Security considerations for LDACS are defined by the official 1041 Standards And Recommended Practices document by ICAO [ICA2018]: 1043 1. LDACS shall provide a capability to protect the availability and 1044 continuity of the system. 1045 2. LDACS shall provide a capability including cryptographic 1046 mechanisms to protect the integrity of messages in transit. 1047 3. LDACS shall provide a capability to ensure the authenticity of 1048 messages in transit. 1049 4. LDACS should provide a capability for nonrepudiation of origin 1050 for messages in transit. 1051 5. LDACS should provide a capability to protect the confidentiality 1052 of messages in transit. 1053 6. LDACS shall provide an authentication capability. 1054 7. LDACS shall provide a capability to authorize the permitted 1055 actions of users of the system and to deny actions that are not 1056 explicitly authorized. 1057 8. If LDACS provides interfaces to multiple domains, LDACS shall 1058 provide capability to prevent the propagation of intrusions within 1059 LDACS domains and towards external domains. 1061 10.4. Security Functions for LDACS 1063 These objectives were used to derive several security functions for 1064 LDACS required to be integrated in the LDACS cybersecurity 1065 architecture: (1) Identification, (2) Authentication, (3) 1066 Authorization, (4) Confidentiality, (5) System Integrity, (6) Data 1067 Integrity, (7) Robustness, (8) Reliability, (9) Availability, and 1068 (10) Key and Trust Management. Several works investigated possible 1069 measures to implement these security functions [BIL2017], [MAE20181], 1070 [MAE20191]. Having identified security requirements, objectives and 1071 functions it MUST be ensured that they are applicable. 1073 10.5. Security Architectural Details for LDACS 1075 The requirements lead to a LDACS security model including different 1076 entities for identification, authentication and authorization 1077 purposes ensuring integrity, authenticity and confidentiality of data 1078 in-transit especially. 1080 10.5.1. Entities in LDACS Security Model 1082 A simplified LDACS architectural modelrequires the following 1083 entities: Network operators such as the Societe Internationale de 1084 Telecommunications Aeronautiques (SITA) [SIT2020] and ARINC [ARI2020] 1085 are providing access to the (1) Ground IPS network via an (2) A2G 1086 LDACS Router. This router is attached to a closed off LDACS Access 1087 Network (3) which connects via further (4) Access Routers to the 1088 different (5) LDACS Cell Ranges, each controlled by a (6) GSC and 1089 spanning a local LDACS Access Network connecting to the (7) GSs that 1090 serve one LDACS cell. Via the (8) A2G wireless LDACS data link (9) 1091 AS the aircraft is connected to the ground network and via the (10) 1092 aircrafts's VI and (11) aircraft's network interface, aircraft's data 1093 can be sent via the AS back to the GS and the forwarded back via GSC, 1094 LDACS local access network, access routers, LDACS access network, A2G 1095 LDACS router to the ground IPS network. 1097 10.5.2. Matter of LDACS Entity Identification 1099 LDACS needs specific identities for (1) the AS, (2) the GS, (3) the 1100 GSC and (4) the Network Operator. The aircraft itself can be 1101 identified using the ICAO unique address of an aircraft, the call 1102 sign of that aircraft or the recently founded Privacy ICAO Address 1103 (PIA) program [FAA2020]. It is conceivable that the LDACS AS will 1104 use a combination of aircraft identification, radio component 1105 identification such as MAC addresses and even operator features 1106 identification to create a unique AS LDACS identification tag. 1107 Similar to a 4G's eNodeB Serving Network (SN) Identification tag, a 1108 GS could be identified using a similar field. And again similar to 1109 4G's Mobility Management Entities (MME), a GSC could be identified 1110 using similar identification fields within the LDACS network. The 1111 identification of the network operator is again similar to 4G (e.g., 1112 E-Plus, AT&T, and TELUS), in the way that the aeronautical network 1113 operators are listed (e.g., ARINC [ARI2020] and SITA [SIT2020]). 1115 10.5.3. Matter of LDACS Entity Authentication and Key Negotiation 1117 In order to anchor Trust within the system all LDACS entities 1118 connected to the ground IPS network shall be rooted in an LDACS 1119 specific chain-of-trust and PKI solution, quite similar to AeroMACS 1120 approach [CRO2016]. These X.509 certificates [RFC5280] residing at 1121 the entities and incorporated in the LDACS PKI proof the ownership of 1122 their respective public key, include information about the identity 1123 of the owner and the digital signature of the entity that has 1124 verified the certificate's content. First all ground infrastructures 1125 must mutually authenticate to each other, negotiate and derive keys 1126 and, thus, secure all ground connections. How this process is 1127 handled in detail is still an ongoing discussion. However, 1128 established methods to secure user plane by IPSec [RFC4301] and IKEv2 1129 [RFC7296] or the application layer via TLS 1.3 [RFC8446] are 1130 conceivable. The LDACS PKI with their chain-of-trust approach, 1131 digital certificates and public entity keys lay the groundwork for 1132 this step. In a second step the AS with the LDACS radio approaches 1133 an LDACS cell and performs a cell entry with the corresponding GS. 1134 Similar to the LTE cell attachment process [TS33.401], where 1135 authentication happens after basic communication has been enabled 1136 between AS and GS (step 5a in the UE attachment process [TS33.401]), 1137 the next step is mutual authentication and key exchange. Hence, in 1138 step three using the identity based Station-to-Station (STS) protocol 1139 with Diffie-Hellman Key Exchange [MAE2020], AS and GS establish 1140 mutual trust by authenticating each other, exchanging key material 1141 and finally both ending up with derived key material. A key 1142 confirmation is mandatory before the communication channel between 1143 the AS and the GS can be opened for user-data communications. 1145 10.5.4. Matter of LDACS Message-in-transit Confidentiality, Integrity 1146 and Authenticity 1148 The subsequent key material from the previous step can then be used 1149 to protect LDACS Layer 2 communications via applying encryption and 1150 integrity protection measures on the SNP layer of the LDACS protocol 1151 stack. As LDACS transports AOC and ATS data, the integrity of that 1152 data is most important, while confidentiality only needs to be 1153 applied to AOC data to protect business interests [ICA2018]. This 1154 possibility of providing low layered confidentiality and integrity 1155 protection ensures a secure delivery of user data over the air gap. 1156 Furthermore it ensures integrity protection of LDACS control data. 1158 10.6. Security Architecture for LDACS 1160 A draft of the cybersecurity architecture of LDACS can be found in 1161 [ICA2018] and [MAE20182] and respective updates in [MAE20191], 1162 [MAE20192], and [MAE2020]. It proposes the use of an own LDACS PKI, 1163 identity management based on aircraft identities and network operator 1164 identities (e.g., SITA and ARINC), public key certificates 1165 incorporated in the PKI based chain-of-trust and stored in the 1166 entities allowing for mutual authentication and key exchange 1167 procedures, key derivation mechanisms for perfect forward secrecy and 1168 user/control plane message-in-transit integrity and confidentiality 1169 protection. This secures data traveling over the airgap between AS 1170 and GS and also between GS and ANSP regardless of the secure or 1171 unsecure nature of application data. Of course application data 1172 itself must be additionally secured to achieve end-to-end security 1173 (secure dialogue service), however the LDACS datalinks aims to 1174 provide an additional layer of protection just for this network 1175 segment. 1177 11. Privacy Considerations 1179 LDACS provides a Quality-of-Service, and the generic considerations 1180 for such mechanisms apply. 1182 12. IANA Considerations 1184 This memo includes no request to IANA. 1186 13. Acknowledgements 1188 Thanks to all contributors to the development of LDACS and ICAO PT-T. 1190 Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi 1191 Fantappie for further input to this draft. 1193 Thanks to SBA Research Vienna for fruitful discussions on 1194 aeronautical communications concerning security incentives for 1195 industry and potential economic spillovers. 1197 14. Normative References 1199 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1200 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1201 December 2005, . 1203 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1204 Housley, R., and W. Polk, "Internet X.509 Public Key 1205 Infrastructure Certificate and Certificate Revocation List 1206 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1207 . 1209 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1210 Kivinen, "Internet Key Exchange Protocol Version 2 1211 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1212 2014, . 1214 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1215 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1216 . 1218 15. Informative References 1220 [SCHN2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M., 1221 Thiasiriphet, T., Schnell, M., and U.C. Fiebig, 1222 "Measurement of the L-band Air-to-Ground Channel for 1223 Positioning Applications", IEEE Transactions on Aerospace 1224 and Electronic Systems, 52(5), pp.2281-229 , 2016. 1226 [MAE20191] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of 1227 the LDACS Cybersecurity Implementation", IEEE 38th Digital 1228 Avionics Systems Conference (DACS), pp. 1-10, San Diego, 1229 CA, USA , 2019. 1231 [MAE20192] Maeurer, N. and C. Schmitt, "Towards Successful 1232 Realization of the LDACS Cybersecurity Architecture: An 1233 Updated Datalink Security Threat- and Risk Analysis", IEEE 1234 Integrated Communications, Navigation and Surveillance 1235 Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019. 1237 [GRA2019] Graeupl, T., Rihacek, C., and B. Haindl, "LDACS A/G 1238 Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2019. 1240 [FAN2019] Pierattelli, S., Fantappie, P., Tamalet, S., van den 1241 Einden, B., Rihacek, C., and T. Graeupl, "LDACS Deployment 1242 Options and Recommendations", SESAR2020 PJ14-02-01 1243 D3.4.020 , 2019. 1245 [MAE20182] Maeurer, N. and A. Bilzhause, "A Cybersecurity 1246 Architecture for the L-band Digital Aeronautical 1247 Communications System (LDACS)", IEEE 37th Digital Avionics 1248 Systems Conference (DASC), pp. 1-10, London, UK , 2017. 1250 [GRA2011] Graeupl, T. and M. Ehammer, "L-DACS1 Data Link Layer 1251 Evolution of ATN/IPS", 30th IEEE/AIAA Digital Avionics 1252 Systems Conference (DASC), pp. 1-28, Seattle, WA, USA , 1253 2011. 1255 [GRA2018] Graeupl, T., Schneckenburger, N., Jost, T., Schnell, M., 1256 Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Maeurer, 1257 N., Kumar, R., Osechas, O., and G. Battista, "L-band 1258 Digital Aeronautical Communications System (LDACS) flight 1259 trials in the national German project MICONAV", Integrated 1260 Communications, Navigation, Surveillance Conference 1261 (ICNS), pp. 1-7, Herndon, VA, USA , 2018. 1263 [SCH20191] Schnell, M., "DLR Tests Digital Communications 1264 Technologies Combined with Additional Navigation Functions 1265 for the First Time", 2019. 1267 [ICA2018] International Civil Aviation Organization (ICAO), "L-Band 1268 Digital Aeronautical Communication System (LDACS)", 1269 International Standards and Recommended Practices Annex 10 1270 - Aeronautical Telecommunications, Vol. III - 1271 Communication Systems , 2018. 1273 [SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Mueller, S., 1274 Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 1275 Conformance and Compatibility Assessment", IEEE/AIAA 33rd 1276 Digital Avionics Systems Conference (DASC), pp. 1-11, 1277 Colorado Springs, CO, USA , 2014. 1279 [RIH2018] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., 1280 Graeupl, T., Schnell, M., and N. Fistas, "L-band Digital 1281 Aeronautical Communications System (LDACS) Activities in 1282 SESAR2020", Integrated Communications Navigation and 1283 Surveillance Conference (ICNS), pp. 1-8, Herndon, VA, 1284 USA , 2018. 1286 [BEL2019] Bellido-Manganell, M. A. and M. Schnell, "Towards Modern 1287 Air-to-Air Communications: the LDACS A2A Mode", IEEE/AIAA 1288 38th Digital Avionics Systems Conference (DASC), pp. 1-10, 1289 San Diego, CA, USA , 2019. 1291 [TS33.401] Zhang, D., "3GPP System Architecture Evolution (SAE); 1292 Security architecture", T33.401, 3GPP , 2012. 1294 [CRO2016] Crowe, B., "Proposed AeroMACS PKI Specification is a Model 1295 for Global and National Aeronautical PKI Deployments", 1296 WiMAX Forum at 16th Integrated Communications, Navigation 1297 and Surveillance Conference (ICNS), pp. 1-19, New York, 1298 NY, USA , 2016. 1300 [MAE2020] Maeurer, N., Graeupl, T., and C. Schmitt, "Comparing 1301 Different Diffie-Hellman Key Exchange Flavors for LDACS", 1302 IEEE/AIAA 39th Digital Avionics Systems Conference (DASC), 1303 pp. 1-10, San Antonio, TX, USA , 2020. 1305 [STR2016] Strohmeier, M., Schaefer, M., Pinheiro, R., Lenders, V., 1306 and I. Martinovic, "On Perception and Reality in Wireless 1307 Air Traffic Communication Security", IEEE Transactions on 1308 Intelligent Transportation Systems, 18(6), pp. 1338-1357, 1309 New York, NY, USA , 2016. 1311 [BIL2017] Bilzhause, A., Belgacem, B., Mostafa, M., and T. Graeupl, 1312 "Datalink Security in the L-band Digital Aeronautical 1313 Communications System (LDACS) for Air Traffic Management", 1314 IEEE Aerospace and Electronic Systems Magazine, 32(11), 1315 pp. 22-33, New York, NY, USA , 2017. 1317 [MAE20181] Maeurer, N. and A. Bilzhause, "Paving the Way for an IT 1318 Security Architecture for LDACS: A Datalink Security 1319 Threat and Risk Analysis", IEEE Integrated Communications, 1320 Navigation, Surveillance Conference (ICNS), pp. 1-11, New 1321 York, NY, USA , 2018. 1323 [FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.", 1324 August 2020, 1325 . 1327 [GNU2012] GNU Radio project, "GNU radio", August 2012, 1328 . 1330 [SIT2020] SITA, "Societe Internationale de Telecommunications 1331 Aeronautiques", August 2020, . 1333 [ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020, 1334 . 1336 [DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline 1337 2 ATS Data Communications (Baseline 2 SPR Standard)", May 1338 2016, . 1341 [RAW-TECHNOS] 1342 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 1343 and J. Farkas, "Reliable and Available Wireless 1344 Technologies", Work in Progress, Internet-Draft, draft- 1345 thubert-raw-technologies-05, 18 May 2020, 1346 . 1349 [RAW-USE-CASES] 1350 Papadopoulos, G., Thubert, P., Theoleyre, F., and C. 1351 Bernardos, "RAW use cases", Work in Progress, Internet- 1352 Draft, draft-bernardos-raw-use-cases-04, 13 July 2020, 1353 . 1356 Appendix A. Selected Information from DO-350A 1358 This appendix includes the continuity, availability, and integrity 1359 requirements interesting for LDACS defined in [DO350A]. 1361 The following terms are used here: 1363 CPDLC Controller Pilot Data Link Communication 1364 DT Delivery Time (nominal) value for RSP 1365 ET Expiration Time value for RCP 1366 FH Flight Hour 1367 MA Monitoring and Alerting criteria 1368 OT Overdue Delivery Time value for RSP 1369 RCP Required Communication Performance 1370 RSP Required Surveillance Performance 1371 TT Transaction Time (nominal) value for RCP 1373 +========================+=============+=============+ 1374 | | ECP 130 | ECP 130 | 1375 +========================+=============+=============+ 1376 | Parameter | ET | TT95% | 1377 +------------------------+-------------+-------------+ 1378 | Transaction Time (sec) | 130 | 67 | 1379 +------------------------+-------------+-------------+ 1380 | Continuity | 0.999 | 0.95 | 1381 +------------------------+-------------+-------------+ 1382 | Availability | 0.989 | 0.989 | 1383 +------------------------+-------------+-------------+ 1384 | Integrity | 1E-5 per FH | 1E-5 per FH | 1385 +------------------------+-------------+-------------+ 1387 Table 1: CPDLC Requirements for ECP 1389 +==============+==========+==============+=========+=========+ 1390 | | RCP 240 | RCP 240 | RCP 400 | RCP 400 | 1391 +==============+==========+==============+=========+=========+ 1392 | Parameter | ET | TT95% | ET | TT95% | 1393 +--------------+----------+--------------+---------+---------+ 1394 | Transaction | 240 | 210 | 400 | 350 | 1395 | Time (sec) | | | | | 1396 +--------------+----------+--------------+---------+---------+ 1397 | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 1398 +--------------+----------+--------------+---------+---------+ 1399 | Availability | 0.989 | 0.989 | 0.989 | 0.989 | 1400 | | (safety) | (efficiency) | | | 1401 +--------------+----------+--------------+---------+---------+ 1402 | Integrity | 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 | 1403 | | FH | | per FH | per FH | 1404 +--------------+----------+--------------+---------+---------+ 1406 Table 2: CPDLC Requirements for RCP 1408 RCP Monitoring and Alerting Criteria in case of CPDLC: 1410 - MA-1: The system shall be capable of detecting failures and 1411 configuration changes that would cause the communication service 1412 no longer meet the RCP specification for the intended use. 1413 - MA-2: When the communication service can no longer meet the RCP 1414 specification for the intended function, the flight crew and/or 1415 the controller shall take appropriate action. 1417 +==============+=====+=====+==========+==============+======+=======+ 1418 | | RSP | RSP | RSP 180 | RSP 180 | RSP |RSP 400| 1419 | | 160 | 160 | | | 400 | | 1420 +==============+=====+=====+==========+==============+======+=======+ 1421 | Parameter | OT |DT95%| OT | DT95% | OT | DT95% | 1422 +--------------+-----+-----+----------+--------------+------+-------+ 1423 | Transaction | 160 | 90 | 180 | 90 | 400 | 300 | 1424 | Time (sec) | | | | | | | 1425 +--------------+-----+-----+----------+--------------+------+-------+ 1426 | Continuity |0.999| 0.95| 0.999 | 0.95 |0.999 | 0.95 | 1427 +--------------+-----+-----+----------+--------------+------+-------+ 1428 | Availability |0.989|0.989| 0.989 | 0.989 |0.989 | 0.989 | 1429 | | | | (safety) | (efficiency) | | | 1430 +--------------+-----+-----+----------+--------------+------+-------+ 1431 | Integrity | 1E-5| 1E-5| 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 | 1432 | | per | per | FH | |per FH| per FH| 1433 | | FH | FH | | | | | 1434 +--------------+-----+-----+----------+--------------+------+-------+ 1436 Table 3: ADS-C Requirements 1438 RCP Monitoring and Alerting Criteria: 1440 - MA-1: The system shall be capable of detecting failures and 1441 configuration changes that would cause the ADS-C service no longer 1442 meet the RSP specification for the intended function. 1443 - MA-2: When the ADS-C service can no longer meet the RSP 1444 specification for the intended function, the flight crew and/or 1445 the controller shall take appropriate action. 1447 Authors' Addresses 1449 Nils Maeurer (editor) 1450 German Aerospace Center (DLR) 1451 Muenchner Strasse 20 1452 82234 Wessling 1453 Germany 1455 Email: Nils.Maeurer@dlr.de 1456 Thomas Graeupl (editor) 1457 German Aerospace Center (DLR) 1458 Muenchner Strasse 20 1459 82234 Wessling 1460 Germany 1462 Email: Thomas.Graeupl@dlr.de 1464 Corinna Schmitt (editor) 1465 Research Institute CODE, UniBwM 1466 Werner-Heisenberg-Weg 28 1467 85577 Neubiberg 1468 Germany 1470 Email: corinna.schmitt@unibw.de