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