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