idnits 2.17.1 draft-ietf-raw-ldacs-08.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (10 May 2021) is 1081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'ICAO20151' is defined on line 1494, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-raw-technologies-01 == Outdated reference: A later version (-11) exists of draft-ietf-raw-use-cases-01 == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-g-ikev2-02 Summary: 0 errors (**), 0 flaws (~~), 7 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: 11 November 2021 C. Schmitt, Ed. 6 Research Institute CODE, UniBwM 7 10 May 2021 9 L-band Digital Aeronautical Communications System (LDACS) 10 draft-ietf-raw-ldacs-08 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 11 November 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 5 59 3.1. Voice Communications Today . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 14 78 7.4. LDACS Data Link Layer . . . . . . . . . . . . . . . . . . 15 79 7.5. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 15 80 8. Reliability and Availability . . . . . . . . . . . . . . . . 15 81 8.1. Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8.2. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 18 83 9. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 18 84 9.1. Medium Access Control (MAC) Entity Services . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 22 90 10.1. Reasons for Wireless Digital Aeronautical 91 Communications . . . . . . . . . . . . . . . . . . . . . 23 92 10.2. LADACS Requirements . . . . . . . . . . . . . . . . . . 24 93 10.3. LDACS Security Objectives . . . . . . . . . . . . . . . 24 94 10.4. LDACS Security Functions . . . . . . . . . . . . . . . . 25 95 10.5. LDACS Security Architecture . . . . . . . . . . . . . . 25 96 10.5.1. Entities . . . . . . . . . . . . . . . . . . . . . . 25 97 10.5.2. Entity Identification . . . . . . . . . . . . . . . 25 98 10.5.3. Entity Authentication and Key Negotiation . . . . . 26 99 10.5.4. Message-in-transit Confidentiality, Integrity and 100 Authenticity . . . . . . . . . . . . . . . . . . . . 26 101 10.6. LDACS Security Modules . . . . . . . . . . . . . . . . . 27 102 10.6.1. Placements of Security Functionality in Protocol 103 Stack . . . . . . . . . . . . . . . . . . . . . . . . 27 104 10.6.2. Trust . . . . . . . . . . . . . . . . . . . . . . . 27 105 10.6.3. Mutual Authentication and Key Exchange (MAKE) . . . 28 106 10.6.4. Key Derivation and Key Hierarchy . . . . . . . . . . 28 107 10.6.5. User Data Security . . . . . . . . . . . . . . . . . 28 108 10.6.6. Control Data Security . . . . . . . . . . . . . . . 29 109 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 110 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 111 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 112 14. Normative References . . . . . . . . . . . . . . . . . . . . 30 113 15. Informative References . . . . . . . . . . . . . . . . . . . 31 114 Appendix A. Selected Information from DO-350A . . . . . . . . . 35 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 117 1. Introduction 119 One of the main pillars of the modern Air Traffic Management (ATM) 120 system is the existence of a communication infrastructure that 121 enables efficient aircraft control and safe separation in all phases 122 of flight. Current systems are technically mature but suffering from 123 the Very High Frequency (VHF) band's increasing saturation in high- 124 density areas and the limitations posed by analogue radio 125 communications. Therefore, aviation globally and the European Union 126 (EU) in particular, strives for a sustainable modernization of the 127 aeronautical communication infrastructure. 129 In the long-term, ATM communication shall transition from analogue 130 VHF voice [KAMA2010] and VHF Data Linke mode 2 (VDLM2) communication 131 to more spectrum efficient digital data communication. The European 132 ATM Master Plan foresees this transition to be realized for 133 terrestrial communications by the development (and potential 134 implementation) of the L-band Digital Aeronautical Communications 135 System (LDACS). LDACS shall enable IPv6 based air- ground 136 communication related to the aviation safety and regularity of flight 137 [ICAO20152]. The particular challenge is that no additional spectrum 138 can be made available for terrestrial aeronautical communication. It 139 was thus necessary to develop co-existence mechanism/procedures to 140 enable the interference free operation of LDACS in parallel with 141 other aeronautical services/systems in the same frequency band. 143 Since LDACS shall be used for aircraft guidance, high reliability and 144 availability for IP connectivity over LDACS are essential. 146 2. Terminology 148 The following terms are used in the context of RAW in this document: 150 A2A Air-to-Air 151 AeroMACS Aeronautical Mobile Airport Communication System 152 A2G Air-to-Ground 153 ACARS Aircraft Communications Addressing and Reporting System 154 ADS-C Automatic Dependent Surveillance - Contract 155 AM(R)S Aeronautical Mobile (Route) Service 156 ANSP Air Traffic Network Service Provider 157 AOC Aeronautical Operational Control 158 AS Aircraft Station 159 ATC Air Traffic Control 160 ATM Air Traffic Management 161 ATN Aeronautical Telecommunication Network 162 ATS Air Traffic Service 163 CCCH Common Control Channel 164 COTS IP Commercial Off-The-Shelf 165 CM Context Management 166 CNS Communication Navigation Surveillance 167 CPDLC Controller Pilot Data Link Communication 168 DCCH Dedicated Control Channel 169 DCH Data Channel 170 DLL Data Link Layer 171 DLS Data Link Service 172 DME Distance Measuring Equipment 173 DSB-AM Double Side-Band Amplitude Modulation 174 FCI Future Communication Infrastructure 175 FL Forward Link 176 GBAS Ground Based Augmentation System 177 GNSS Global Navigation Satellite System 178 GS Ground-Station 179 G2A Ground-to-Air 180 HF High Frequency 181 ICAO International Civil Aviation Organization 182 IP Internet Protocol 183 IPS Internet Protocol Suite 184 kbit/s kilobit per second 185 LDACS L-band Digital Aeronautical Communications System 186 LLC Logical Link Control 187 LME LDACS Management Entity 188 MAC Medium Access Layer 189 MF Multi Frame 190 OFDM Orthogonal Frequency-Division Multiplexing 191 OFDMA Orthogonal Frequency-Division Multiplexing Access 192 OSI Open Systems Interconnection 193 PHY Physical Layer 194 RL Reverse Link 195 SF Super-Frame 196 SN Serving Network 197 SNP Sub-Network Protocol 198 STS Station-to-Station 199 TDMA Time-Division Multiplexing-Access 200 VDLM1 VHF Data Link mode 1 201 VDLM2 VHF Data Link mode 2 202 VHF Very High Frequency 203 VI Voice Interface 205 3. Motivation and Use Cases 207 Aircraft are currently connected to Air Traffic Control (ATC) and 208 Aeronautical Operational Control (AOC) via voice and data 209 communications systems through all phases of a flight. AOC is a 210 generic term referring to the business communication of airlines. 211 Within the airport terminal, connectivity is focused on high 212 bandwidth communications, while during en-route high reliability, 213 robustness, and range is the main focus. Voice communications may 214 use the same or different equipment as data communications systems. 215 In the following the main differences between voice and data 216 communications capabilities are summarized. The assumed use cases 217 for LDACS completes the list of use cases stated in [RAW-USE-CASES] 218 and the list of reliable and available wireless technologies 219 presented in [RAW-TECHNOS]. 221 3.1. Voice Communications Today 223 Voice links are used for Air-to-Ground (A2G) and Air-to-Air (A2A) 224 communications. The communication equipment is either ground-based 225 working in the High Frequency (HF) or VHF frequency band or 226 satellite-based. All VHF and HF voice communications are operated 227 via open broadcast channels without authentication, encryption or 228 other protective measures. The use of well-proven communication 229 procedures via broadcast channels can help to enhance the safety of 230 communications. The main voice communications media is still the 231 analogue VHF Double Side-Band Amplitude Modulation (DSB-AM) 232 communications technique, supplemented by HF Single Side-Band 233 Amplitude Modulation and satellite communications for remote and 234 oceanic areas. DSB-AM has been in use since 1948, works reliably and 235 safely, and uses low-cost communication equipment. These are the 236 main reasons why VHF DSB-AM communications are still in use, and it 237 is 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 the 251 Aeronautical Mobile Airport Communication System (AeroMACS) or public 252 cellular networks, operating in the Airport (APT) domain and able to 253 deliver broadband communication capability. 255 The data communication networks used for the transmission of data 256 relating to the safety and regularity of the flight must be strictly 257 isolated from those providing entertainment services to passengers. 258 This leads to a situation that the flight crews are supported by 259 narrowband services during flight while passengers have access to 260 inflight broadband services. The current HF and VHF data links 261 cannot provide broadband services now or in the future, due to the 262 lack of available spectrum. This technical shortcoming is becoming a 263 limitation to enhanced ATM operations, such as Trajectory-Based 264 Operations and 4D trajectory negotiations. 266 Satellite-based communications are currently under investigation and 267 enhanced capabilities are under development which will be able to 268 provide inflight broadband services and communications supporting the 269 safety and regularity of flight. In parallel, the ground-based 270 broadband data link technology LDACS is being standardized by ICAO 271 and has recently shown its maturity during flight tests [SCH20191]. 272 The LDACS technology is scalable, secure and spectrum efficient and 273 provides significant advantages to the users and service providers. 274 It is expected that both - satellite systems and LDACS - will be 275 deployed to support the future aeronautical communication needs as 276 envisaged by the ICAO Global Air Navigation Plan. 278 4. Provenance and Documents 280 The development of LDACS has already made substantial progress in the 281 Single European Sky ATM Research framework, short SESAR, and is 282 currently being continued in the follow-up program SESAR2020 283 [RIH2018]. A key objective of the these activities is to develop, 284 implement and validate a modern aeronautical data link able to evolve 285 with aviation needs over long-term. To this end, an LDACS 286 specification has been produced [GRA2019] and is continuously 287 updated; transmitter demonstrators were developed to test the 288 spectrum compatibility of LDACS with legacy systems operating in the 289 L-band [SAJ2014]; and the overall system performance was analyzed by 290 computer simulations, indicating that LDACS can fulfil the identified 291 requirements [GRA2011]. 293 LDACS standardization within the framework of the ICAO started in 294 December 2016. The ICAO standardization group has produced an 295 initial Standards and Recommended Practices document [ICA2018]. It 296 defines the general characteristics of LDACS. The ICAO 297 standardization group plans to produce an ICAO technical manual - the 298 ICAO equivalent to a technical standard - within the next years. 299 Generally, the group is open to input from all sources and develops 300 LDACS in the open. 302 Up to now LDACS standardization has been focused on the development 303 of the physical layer and the data link layer, only recently have 304 higher layers come into the focus of the LDACS development 305 activities. There is currently no "IPv6 over LDACS" specification 306 publicly available; however, SESAR2020 has started the testing of 307 IPv6-based LDACS testbeds. 309 The IPv6 architecture for the aeronautical telecommunication network 310 is called the Future Communications Infrastructure (FCI). FCI shall 311 support quality of service, diversity, and mobility under the 312 umbrella of the "multi-link concept". This work is conducted by ICAO 313 Communication Panel working group WG-I. 315 In addition to standardization activities several industrial LDACS 316 prototypes have been built. One set of LDACS prototypes has been 317 evaluated in flight trials confirming the theoretical results 318 predicting the system performance [GRA2018] [SCH20191]. 320 5. Applicability 322 LDACS is a multi-application cellular broadband system capable of 323 simultaneously providing various kinds of Air Traffic Services (ATS) 324 including ATS-B3 and AOC communications services from deployed 325 Ground-Stations (GS). The A2G sub-system physical layer and data 326 link layer of LDACS are optimized for data link communications, but 327 the system also supports digital air-ground voice communications. 329 LDACS supports communication in all airspaces (airport, terminal 330 maneuvering area, and en-route), and on the airport surface. The 331 physical LDACS cell coverage is effectively de-coupled from the 332 operational coverage required for a particular service. This is new 333 in aeronautical communications. Services requiring wide-area 334 coverage can be installed at several adjacent LDACS cells. The 335 handover between the involved LDACS cells is seamless, automatic, and 336 transparent to the user. Therefore, the LDACS A2G communications 337 concept enables the aeronautical communication infrastructure to 338 support future dynamic airspace management concepts. 340 5.1. Advances Beyond the State-of-the-Art 342 LDACS offers several capabilities that are not provided in 343 contemporarily deployed aeronautical communication systems. 345 5.1.1. Priorities 347 LDACS is able to manage services priorities, an important feature not 348 available in some of the current data link deployments. Thus, LDACS 349 guarantees bandwidth, low latency, and high continuity of service for 350 safety critical ATS applications while simultaneously accommodating 351 less safety-critical AOC services. 353 5.1.2. Security 355 LDACS is a secure data link with built-in security mechanisms. It 356 enables secure data communications for ATS and AOC services, 357 including secured private communications for aircraft operators and 358 ANSPs (Air Traffic Network Service Providers). This includes 359 concepts for key and trust management, mutual authenticated key 360 exchange protocols, key derivation measures, user and control 361 message-in-transit confidentiality and authenticity protection, 362 secure logging and availability and robustness measures [MAE20181], 363 [MAE20191], [MAE20192]. 365 5.1.3. High Data Rates 367 The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the 368 forward link (FL) for the connection Ground-to-Air (G2A), and 294 369 kbit/s to 1390 kbit/s on the reverse link (RF) for the connection 370 A2G, depending on coding and modulation. This is 50 times the amount 371 terrestrial digital aeronautical communications systems such as VDLM2 372 provide [SCH20191]. 374 5.2. Application 376 LDACS shall be used by several aeronautical applications ranging from 377 enhanced communication protocol stacks (multi-homed mobile IPv6 378 networks in the aircraft and potentially ad-hoc networks between 379 aircraft) to classical communication applications (sending Ground 380 Based Augmentation System (GBAS) correction data) and integration 381 with other service domains (using the communication signal for 382 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 FCI and constitute 388 one of the main components of the multilink concept within the FCI. 390 Both technologies, LDACS and satellite systems, have their specific 391 benefits and technical capabilities which complement each other. 392 Especially, satellite systems are well-suited for large coverage 393 areas with less dense air traffic, e.g. oceanic regions. LDACS is 394 well-suited for dense air traffic areas, e.g. continental areas or 395 hot-spots around airports and terminal airspace. In addition, both 396 technologies offer comparable data link capacity and, thus, are well- 397 suited for redundancy, mutual back-up, or load balancing. 399 Technically the FCI multilink concept shall be realized by multi- 400 homed mobile IPv6 networks in the aircraft. The related protocol 401 stack is currently under development by ICAO and the Single European 402 Sky ATM Research framework. 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 A2A communication between aircrafts in terms of ad-hoc data 410 networks is currently considered a research topic since there is no 411 immediate operational need for it, although several possible use 412 cases are discussed (digital voice, wake vortex warnings, and 413 trajectory negotiation) [BEL2019]. It should also be noted that 414 currently deployed analog VHF voice radios support direct voice 415 communication between aircraft, making a similar use case for digital 416 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 GBAS is used to 451 improve the accuracy of GNSS to allow GNSS based instrument landings. 452 This is realized by sending GNSS correction data (e.g., compensating 453 ionospheric errors in the GNSS signal) to the aircraft's GNSS 454 receiver via a separate data link. Currently the VDB data link is 455 used. VDB is a narrow-band single-purpose datalink without advanced 456 security only used to transmit GBAS correction data. This makes VDB 457 a natural candidate for replacement by LDACS. 459 5.2.4. Business Communication of Airlines 461 In addition to air traffic services AOC services shall be transmitted 462 over LDACS. AOC is a generic term referring to the business 463 communication of airlines. Regulatory this is considered related to 464 the safety and regularity of flight and may therefore be transmitted 465 over LDACS. 467 AOC communication is considered the main business case for LDACS 468 communication service providers since modern aircraft generate 469 significant amounts of data (e.g., engine maintenance data). 471 5.2.5. LDACS Navigation 473 Beyond communication radio signals can always also be used for 474 navigation. LDACS takes this into account. 476 For future aeronautical navigation, ICAO RECOMMENDS the further 477 development of GNSS based technologies as primary means for 478 navigation. However, the drawback of GNSS is its inherent single 479 point of failure - the satellite. Due to the large separation 480 between navigational satellites and aircraft, the received power of 481 GNSS signals on the ground is very low. As a result, GNSS 482 disruptions might occasionally occur due to unintentional 483 interference, or intentional jamming. Yet the navigation services 484 must be available with sufficient performance for all phases of 485 flight. Therefore, during GNSS outages, or blockages, an alternative 486 solution is needed. This is commonly referred to as Alternative 487 Positioning, Navigation, and Timing (APNT). 489 One of such APNT solution consists of integrating the navigation 490 functionality into LDACS. The ground infrastructure for APNT is 491 deployed through the implementation of LDACS's GSs and the navigation 492 capability comes "for free". 494 LDACS navigation has already been demonstrated in practice in a 495 flight measurement campaign [SCH20191]. 497 6. Requirements to LDACS 499 The requirements to LDACS are mostly defined by its application area: 500 Communication related to safety and regularity of flight. 502 A particularity of the current aeronautical communication landscape 503 is that it is heavily regulated. Aeronautical data links (for 504 applications related to safety and regularity of flight) may only use 505 spectrum licensed to aviation and data links endorsed by ICAO. 506 Nation states can change this locally, however, due to the global 507 scale of the air transportation system adherence to these practices 508 is to be expected. 510 Aeronautical data links for the Aeronautical Telecommunication 511 Network (ATN) are therefore expected to remain in service for 512 decades. The VDLM2 data link currently used for digital terrestrial 513 internetworking was developed in the 1990es (the use of the Open 514 Systems Interconnection (OSI) stack indicates that as well). VDLM2 515 is 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 OSI stack. The 523 objective of the development effort LDACS as part of the FCI is to 524 replace legacy OSI stack and proprietary ACARS internetwork 525 technologies with industry standard IP technology. It is anticipated 526 that the use of Commercial Off-The-Shelf (COTS) IP technology mostly 527 applies to the ground network. The avionics networks on the aircraft 528 will likely be heavily modified or proprietary. 530 AOC applications currently mostly use the same stack (although some 531 applications, like the graphical weather service may use the 532 commercial passenger network). This creates capacity problems 533 (resulting in excessive amounts of timeouts) since the underlying 534 terrestrial data links (VDLM1/2) do not provide sufficient bandwidth. 535 The use of non-aviation specific data links is considered a security 536 problem. Ideally the aeronautical IP internetwork and the Internet 537 should be completely separated. 539 The objective of LDACS is to provide a next generation terrestrial 540 data link designed to support IP and provide much higher bandwidth to 541 avoid the currently experienced operational problems. 543 The requirement for LDACS is therefore to provide a terrestrial high- 544 throughput data link for IP internetworking in the aircraft. 546 In order to fulfil the above requirement LDACS needs to be 547 interoperable with IP (and IP-based services like Voice-over-IP) at 548 the gateway connecting the LDACS network to other aeronautical ground 549 networks (the totality of them being the ATN). On the avionics side 550 in the aircraft aviation specific solutions are to be expected. 552 In addition to the functional requirements LDACS and its IP stack 553 need to fulfil the requirements defined in RTCA DO-350A/EUROCAE ED- 554 228A [DO350A]. This document defines continuity, availability, and 555 integrity requirements at different scopes for each air traffic 556 management application (CPDLC, CM, and ADS-C). The scope most 557 relevant to IP over LDACS is the CSP (Communication Service Provider) 558 scope. 560 Continuity, availability, and integrity requirements are defined in 561 [DO350A] volume 1 Table 5-14, and Table 6-13. Appendix A presents 562 the required information. 564 In a similar vein, requirements to fault management are defined in 565 the same tables. 567 7. Characteristics of LDACS 569 LDACS will become one of several wireless access networks connecting 570 aircraft to the ATN implemented by the FCI and possibly ACARS/FANS 571 networks [FAN2019]. 573 The current LDACS design is focused on the specification of layer 2. 575 Achieving stringent the continuity, availability, and integrity 576 requirements defined in [DO350A] will require the specification of 577 layer 3 and above mechanisms (e.g. reliable crossover at the IP 578 layer). Fault management mechanisms are similarly undefined. Input 579 from the working group will be appreciated here. 581 7.1. LDACS Sub-Network 583 An LDACS sub-network contains an Access Router (AR) and several GS, 584 each of them providing one LDACS radio cell. 586 User plane interconnection to the ATN is facilitated by the AR 587 peering with an A2G Router connected to the ATN. 589 The internal control plane of an LDACS sub-network interconnects the 590 GS. An LDACS sub-network is illustrated in Figure 1. 592 wireless user 593 link plane 594 AS-------------GS---------------AR---A2G-----ATN 595 . | Router 596 . control | 597 . plane | 598 . | 599 GS...............| 600 . | 601 . | 602 GS---------------+ 604 Figure 1: LDACS sub-network with three GSs and one AS 606 7.2. Topology 608 LDACS operating in A2G mode is a cellular point-to-multipoint system. 609 The A2G mode assumes a star-topology in each cell where Aircraft 610 Stations (AS) belonging to aircraft within a certain volume of space 611 (the LDACS cell) is connected to the controlling GS. The LDACS GS is 612 a centralized instance that controls LDACS A2G communications within 613 its cell. The LDACS GS can simultaneously support multiple bi- 614 directional communications to the ASs under its control. LDACS's GSs 615 themselves are connected to each other and the AR. 617 Prior to utilizing the system an AS has to register with the 618 controlling GS to establish dedicated logical channels for user and 619 control data. Control channels have statically allocated resources, 620 while user channels have dynamically assigned resources according to 621 the current demand. Logical channels exist only between the GS and 622 the AS. 624 The LDACS wireless link protocol stack defines two layers, the 625 physical layer and the data link layer. 627 7.3. LDACS Physical Layer 629 The physical layer provides the means to transfer data over the radio 630 channel. The LDACS GS supports bi-directional links to multiple 631 aircraft under its control. The FL direction at the G2A connection 632 and the RL direction at the A2G connection are separated by Frequency 633 Division Duplex. FL and RL use a 500 kHz channel each. The GS 634 transmits a continuous stream of Orthogonal Frequency-Division 635 Multiplexing (OFDM) symbols on the FL. In the RL different aircraft 636 are separated in time and frequency using a combination of Orthogonal 637 Frequency-Division Multiple-Access (OFDMA) and Time-Division 638 Multiple-Access (TDMA). Aircraft thus transmit discontinuously on 639 the RL with radio bursts sent in precisely defined transmission 640 opportunities allocated by the GS. 642 7.4. LDACS Data Link Layer 644 The data-link layer provides the necessary protocols to facilitate 645 concurrent and reliable data transfer for multiple users. The LDACS 646 data link layer is organized in two sub-layers: The medium access 647 sub-layer and the Logical Link Control (LLC) sub-layer. The medium 648 access sub-layer manages the organization of transmission 649 opportunities in slots of time and frequency. The LLC sub-layer 650 provides acknowledged point-to-point logical channels between the 651 aircraft and the GS using an automatic repeat request protocol. 652 LDACS supports also unacknowledged point-to-point channels and G2A 653 broadcast. 655 7.5. LDACS Mobility 657 LDACS supports layer 2 handovers to different LDACS channels. 658 Handovers may be initiated by the aircraft (break-before-make) or by 659 the GS (make-before-break). Make-before-break handovers are only 660 supported for GSs connected to each other. 662 External handovers between non-connected LDACS sub-networks or 663 different aeronautical data links shall be handled by the FCI multi- 664 link concept. 666 8. Reliability and Availability 668 8.1. Layer 2 670 LDACS has been designed with applications related to the safety and 671 regularity of flight in mind. It has therefore been designed as a 672 deterministic wireless data link (as far as this is possible). 674 Based on channel measurements of the L-band channel [SCHN2016] and 675 respecting the specific nature of the area of application, LDACS was 676 designed from the PHY layer up with robustness in mind. 678 In order to maximize the capacity per channel and to optimally use 679 the available spectrum, LDACS was designed as an OFDM-based Frequency 680 Division Duplex system, supporting simultaneous transmissions in FL 681 at the G2A connection and RF at the A2G connection. The legacy 682 systems already deployed in the L-band limit the bandwidth of both 683 channels to approximately 500 kHz. 685 The LDACS physical layer design includes propagation guard times 686 sufficient for the operation at a maximum distance of 200 nautical 687 miles from the GS. In actual deployment, LDACS can be configured for 688 any range up to this maximum range. 690 The LDACS FL physical layer is a continuous OFDM transmission. LDACS 691 RL transmission is based on OFDMA-TDMA bursts, with silence between 692 such bursts. The RL resources (i.e. bursts) are assigned to 693 different ASs on demand by the GS. 695 The LDACS physical layer supports adaptive coding and modulation for 696 user data. Control data is always encoded with the most robust 697 coding and modulation (QPSK coding rate 1/2). 699 LDACS medium access on top of the physical layer uses a static frame 700 structure to support deterministic timer management. As shown in 701 Figure 3 and Figure 4, LDACS framing structure is based on Super- 702 Frames (SF) of 240ms duration corresponding to 2000 OFDM symbols. FL 703 and RL boundaries are aligned in time (from the GS perspective) 704 allowing for deterministic sending windows for KEEP ALIVE messages 705 and control and data channels in general. 707 LDACS medium access is always under the control of the GS of a radio 708 cell. Any medium access for the transmission of user data has to be 709 requested with a resource request message stating the requested 710 amount of resources and class of service. The GS performs resource 711 scheduling on the basis of these requests and grants resources with 712 resource allocation messages. Resource request and allocation 713 messages are exchanged over dedicated contention-free control 714 channels. 716 The purpose of Quality-of-Service in LDACS medium access is to 717 provide prioritized medium access at the bottleneck (the wireless 718 link). The signaling of higher layer Quality-of-Service requirements 719 to LDACS is yet to be defined. A DiffServ-based solution with a 720 small number of priorities is to be expected. 722 LDACS has two mechanisms to request resources from the scheduler in 723 the GS. 725 Resources can either be requested "on demand" with a given priority. 726 On the FL, this is done locally in the GS, on the RL a dedicated 727 contention-free control channel is used called Dedicated Control 728 Channel (DCCH), which is roughly 83 bit every 60 ms. A resource 729 allocation is always announced in the control channel of the FL, 730 short Common Control Channel (CCCH) having variable size. Due to the 731 spacing of the RL control channels every 60 ms, a medium access delay 732 in the same order of magnitude is to be expected. 734 Resources can also be requested "permanently". The permanent 735 resource request mechanism supports requesting recurring resources in 736 given time intervals. A permanent resource request has to be 737 canceled by the user (or by the GS, which is always in control). 739 User data transmissions over LDACS are therefore always scheduled by 740 the GS, while control data uses statically (i.e. at cell entry) 741 allocated recurring resources (DCCH and CCCH). The current 742 specification specifies no scheduling algorithm. Scheduling of RL 743 resources is done in physical Protocol Data Units of 112 bit (or 744 larger if more aggressive coding and modulation is used). Scheduling 745 on the FL is done Byte-wise since the FL is transmitted continuously 746 by the GS. 748 In addition to having full control over resource scheduling, the GS 749 can send forced Handover commands for off-loading or RF channel 750 management, e.g. when the signal quality declines and a more suitable 751 GS is in the AS reach. With robust resource management of the 752 capacities of the radio channel, reliability and robustness measures 753 are therefore also anchored in the LDACS management entity. 755 In addition, to radio resource management, the LDACS control channels 756 are also used to send keep-alive messages, when they are not 757 otherwise used. Since the framing of the control channels is 758 deterministic, missing keep-alive messages can thus be immediately 759 detected. This information is made available to the multi-link 760 protocols for fault management. 762 The protocol used to communicate faults is not defined in the LDACS 763 specification. It is assumed that vendors would use industry 764 standard protocols like the Simple Network Management Protocol or the 765 Network Configuration Protocol where security permits. 767 The LDACS data link layer protocol running on top of the medium 768 access sub-layer uses ARQ to provide reliable data transmission on 769 layer 2. 771 It employs selective repeat ARQ with transparent fragmentation and 772 reassembly to the resource allocation size to achieve low latency and 773 a low overhead without losing reliability. It ensures correct order 774 of packet delivery without duplicates. In case of transmission 775 errors it identifies lost fragments with deterministic timers synced 776 to the medium access frame structure and initiates retransmission. 777 Additionally, the priority mechanism of LDACS ensures the timely 778 delivery of messages with high importance. 780 8.2. Beyond Layer 2 782 LDACS availability can be increased by appropriately deploying LDACS 783 infrastructure: This means proliferating the number of terrestrial 784 base stations. However, the scarcity of aeronautical spectrum for 785 data link communication (in the case of LDACS: tens of MHz in the 786 L-band) and the long range (in the case of LDACS: up to 400 km) make 787 this quite hard. The deployment of a larger number of small cells is 788 certainly possible, suffers, however, also from the scarcity of 789 spectrum. An additional constraint to consider, is that Distance 790 Measuring Equipment (DME) is the primary user of the aeronautical 791 L-band. That is, any LDACS deployment has to take DME frequency 792 planning into account, too. 794 The aeronautical community has therefore decided not to rely on a 795 single communication system or frequency band. It is envisioned to 796 have multiple independent data link technologies in the aircraft 797 (e.g., terrestrial and satellite communications) in addition to 798 legacy VHF voice. 800 However, as of now no reliability and availability mechanisms that 801 could utilize the multi-link have been specified on Layer 3 and 802 above. Even if LDACS has been designed for reliability, the wireless 803 medium presents significant challenges to achieve deterministic 804 properties such as low packet error rate, bounded consecutive losses, 805 and bounded latency. Support for high reliability and availability 806 for IP connectivity over LDACS is therefore highly desirable, needs, 807 however, be adapted to the specific use case. 809 Below Layer 2 aeronautics usually relies on hardware redundancy. To 810 protect availability of the LDACS link, an aircraft equipped with 811 LDACS will have access to two L-band antennae with triple redundant 812 radio systems as required for any safety relevant aeronautical 813 systems by ICAO. 815 9. Protocol Stack 817 The protocol stack of LDACS is implemented in the AS and GS: It 818 consists of the Physical Layer (PHY) with five major functional 819 blocks above it. Four are placed in the Data Link Layer (DLL) of the 820 AS and GS: (1) Medium Access Layer (MAC), (2) Voice Interface (VI), 821 (3) Data Link Service (DLS), and (4) LDACS Management Entity (LME). 822 The last entity resides within the Sub-Network Layer: Sub-Network 823 Protocol (SNP). The LDACS network is externally connected to voice 824 units, radio control units, and the ATN Network Layer. 826 Figure 2 shows the protocol stack of LDACS as implemented in the AS 827 and GS. 829 IPv6 Network Layer 830 | 831 | 832 +------------------+ +----+ 833 | SNP |--| | Sub-Network 834 | | | | Layer 835 +------------------+ | | 836 | | LME| 837 +------------------+ | | 838 | DLS | | | Logical Link 839 | | | | Control Layer 840 +------------------+ +----+ 841 | | 842 DCH DCCH/CCCH 843 | RACH/BCCH 844 | | 845 +--------------------------+ 846 | MAC | Medium Access 847 | | Layer 848 +--------------------------+ 849 | 850 +--------------------------+ 851 | PHY | Physical Layer 852 +--------------------------+ 853 | 854 | 855 ((*)) 856 FL/RL radio channels 857 separated by 858 Frequency Division Duplex 860 Figure 2: LDACS protocol stack in AS and GS 862 9.1. Medium Access Control (MAC) Entity Services 864 The MAC time framing service provides the frame structure necessary 865 to realize slot-based Time Division Multiplex (TDM) access on the 866 physical link. It provides the functions for the synchronization of 867 the MAC framing structure and the PHY Layer framing. The MAC time 868 framing provides a dedicated time slot for each logical channel. 870 The MAC Sub-Layer offers access to the physical channel to its 871 service users. Channel access is provided through transparent 872 logical channels. The MAC Sub-Layer maps logical channels onto the 873 appropriate slots and manages the access to these channels. Logical 874 channels are used as interface between the MAC and LLC Sub-Layers. 876 The LDACS framing structure for FL and RL is based on Super-Frames 877 (SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbols. 878 The FL and RL SF boundaries are aligned in time (from the view of the 879 GS). 881 In the FL, an SF contains a Broadcast Frame of duration 6.72 ms (56 882 OFDM symbols) for the Broadcast Control Channel (BCCH), and four 883 Multi-Frames (MF), each of duration 58.32 ms (486 OFDM symbols). 885 In the RL, each SF starts with a Random Access (RA) slot of length 886 6.72 ms with two opportunities for sending RL random access frames 887 for the Random Access Channel (RACH), followed by four MFs. These 888 MFs have the same fixed duration of 58.32 ms as in the FL, but a 889 different internal structure 891 Figure 3 and Figure 4 illustrate the LDACS frame structure. 893 ^ 894 | +------+------------+------------+------------+------------+ 895 | FL | BCCH | MF | MF | MF | MF | 896 F +------+------------+------------+------------+------------+ 897 r <---------------- Super-Frame (SF) - 240ms ----------------> 898 e 899 q +------+------------+------------+------------+------------+ 900 u RL | RACH | MF | MF | MF | MF | 901 e +------+------------+------------+------------+------------+ 902 n <---------------- Super-Frame (SF) - 240ms ----------------> 903 c 904 y 905 | 906 ----------------------------- Time ------------------------------> 907 | 909 Figure 3: SF structure for LDACS 911 ^ 912 | +-------------+------+-------------+ 913 | FL | DCH | CCCH | DCH | 914 F +-------------+------+-------------+ 915 r <---- Multi-Frame (MF) - 58.32ms --> 916 e 917 q +------+---------------------------+ 918 u RL | DCCH | DCH | 919 e +------+---------------------------+ 920 n <---- Multi-Frame (MF) - 58.32ms --> 921 c 922 y 923 | 924 -------------------- Time ------------------> 925 | 927 Figure 4: MF structure for LDACS 929 9.2. Data Link Service (DLS) Entity Services 931 The DLS provides acknowledged and unacknowledged (including broadcast 932 and packet mode voice) bi-directional exchange of user data. If user 933 data is transmitted using the acknowledged DLS, the sending DLS 934 entity will wait for an acknowledgement from the receiver. If no 935 acknowledgement is received within a specified time frame, the sender 936 may automatically try to retransmit its data. However, after a 937 certain number of failed retries, the sender will suspend further 938 retransmission attempts and inform its client of the failure. 940 The DLS uses the logical channels provided by the MAC: 942 1. A GS announces its existence and access parameters in the 943 Broadcast Channel (BC). 944 2. The RA channel enables AS to request access to an LDACS cell. 945 3. In the FL the CCCH is used by the GS to grant access to data 946 channel resources. 947 4. The reverse direction is covered by the RL, where ASs need to 948 request resources before sending. This happens via the DCCH. 949 5. User data itself is communicated in the Data Channel (DCH) on the 950 FL and RL. 952 Access to the FL and RL data channel is granted by the scheduling 953 mechanism implemented in the LME discussed below. 955 9.3. Voice Interface (VI) Services 957 The VI provides support for virtual voice circuits. Voice circuits 958 may either be set-up permanently by the GS (e.g., to emulate voice 959 party line) or may be created on demand. The creation and selection 960 of voice circuits is performed in the LME. The VI provides only the 961 transmission services. 963 9.4. LDACS Management Entity (LME) Services 965 The mobility management service in the LME provides support for 966 registration and de-registration (cell entry and cell exit), scanning 967 RF channels of neighboring cells and handover between cells. In 968 addition, it manages the addressing of aircraft/ ASs within cells. 970 The resource management service provides link maintenance (power, 971 frequency and time adjustments), support for adaptive coding and 972 modulation, and resource allocation. 974 The resource management service accepts resource requests from/for 975 different AS and issues resource allocations accordingly. While the 976 scheduling algorithm is not specified and a point of possible vendor 977 differentiation, it is subject to the following requirements: 979 1. Resource scheduling must provide channel access according to the 980 priority of the request 981 2. Resource scheduling must support "one-time" requests 982 3. Resource scheduling must support "permanent" requests that 983 reserve a resource until the request is canceled e.g. for digital 984 voice circuits. 986 9.5. Sub-Network Protocol (SNP) Services 988 The DLS provides functions required for the transfer of user plane 989 data and control plane data over the LDACS sub-network. 991 The security service provides functions for secure communication over 992 the LDACS sub-network. Note that the SNP security service applies 993 cryptographic measures as configured by the GS. 995 10. Security Considerations 996 10.1. Reasons for Wireless Digital Aeronautical Communications 998 Aviation will require secure exchanges of data and voice messages for 999 managing the air traffic flow safely through the airspaces all over 1000 the world. Historically Communication Navigation Surveillance (CNS) 1001 wireless communications technology emerged from military and a threat 1002 landscape where inferior technological and financial capabilities of 1003 adversaries were assumed [STR2016]. The main communication method 1004 for ATC today is still an open analogue voice broadcast within the 1005 aeronautical VHF band. Currently, the information security is purely 1006 procedural based by using well-trained personnel and proven 1007 communications procedures. This communication method has been in 1008 service since 1948. However, since the emergence of civil 1009 aeronautical CNS application and today, the world has changed. Civil 1010 applications have significant lower spectrum available than military 1011 applications. This means several military defence mechanisms such as 1012 frequency hopping or pilot symbol scrambling and, thus, a defense-in- 1013 depth approach starting at the physical layer is infeasible for civil 1014 systems. With the rise of cheap Software Defined Radios, the 1015 previously existing financial barrier is almost gone and open source 1016 projects such as GNU radio [GNU2012] allow the new type of 1017 unsophisticated listeners and possible attackers. Most CNS 1018 technology developed in ICAO relies on open standards, thus syntax 1019 and semantics of wireless digital aeronautical communications should 1020 be expected to be common knowledge for attackers. With increased 1021 digitization and automation of civil aviation the human as control 1022 instance is being taken gradually out of the loop. Autonomous 1023 transport drones or single piloted aircraft demonstrate this trend. 1024 However, without profound cybersecurity measures such as authenticity 1025 and integrity checks of messages in-transit on the wireless link or 1026 mutual entity authentication, this lack of a control instance can 1027 prove disastrous. Thus, future digital communications waveforms will 1028 need additional embedded security features to fulfill modern 1029 information security requirements like authentication and integrity. 1030 These security features require sufficient bandwidth which is beyond 1031 the capabilities of a VHF narrowband communications system. For 1032 voice and data communications, sufficient data throughput capability 1033 is needed to support the security functions while not degrading 1034 performance. LDACS is a data link technology with sufficient 1035 bandwidth to incorporate security without losing too much user 1036 throughput. 1038 As digitalization progresses even further with LDACS and automated 1039 procedures such as 4D-Trajectories allowing semi-automated en-route 1040 flying of aircraft, LDACS requires stronger cybersecurity measures. 1042 10.2. LADACS Requirements 1044 Overall there are several business goals for cybersecurity to protect 1045 in FCI in civil aviation: 1047 1. Safety: The system must sufficiently mitigate attacks, which 1048 contribute to safety hazards. 1049 2. Flight regularity: The system must sufficiently mitigate attacks, 1050 which contribute to delays, diversions, or cancellations of 1051 flights. 1052 3. Protection of business interests: The system must sufficiently 1053 mitigate attacks which result in financial loss, reputation 1054 damage, disclosure of sensitive proprietary information, or 1055 disclosure of personal information. 1057 To further analyze assets and derive threats and thus protection 1058 scenarios several Threat-and Risk Analysis were performed for LDACS 1059 [MAE20181] , [MAE20191]. These results allowed deriving security 1060 scope and objectives from the requirements and the conducted Threat- 1061 and Risk Analysis. 1063 10.3. LDACS Security Objectives 1065 Security considerations for LDACS are defined by the official 1066 Standards And Recommended Practices (SARPS) document by ICAO 1067 [ICA2018]: 1069 1. LDACS shall provide a capability to protect the availability and 1070 continuity of the system. 1071 2. LDACS shall provide a capability including cryptographic 1072 mechanisms to protect the integrity of messages in transit. 1073 3. LDACS shall provide a capability to ensure the authenticity of 1074 messages in transit. 1075 4. LDACS should provide a capability for nonrepudiation of origin 1076 for messages in transit. 1077 5. LDACS should provide a capability to protect the confidentiality 1078 of messages in transit. 1079 6. LDACS shall provide an authentication capability. 1080 7. LDACS shall provide a capability to authorize the permitted 1081 actions of users of the system and to deny actions that are not 1082 explicitly authorized. 1083 8. If LDACS provides interfaces to multiple domains, LDACS shall 1084 provide capability to prevent the propagation of intrusions within 1085 LDACS domains and towards external domains. 1087 10.4. LDACS Security Functions 1089 These objectives were used to derive several security functions for 1090 LDACS required to be integrated in the LDACS cybersecurity 1091 architecture: (1) Identification, (2) Authentication, (3) 1092 Authorization, (4) Confidentiality, (5) System Integrity, (6) Data 1093 Integrity, (7) Robustness, (8) Reliability, (9) Availability, and 1094 (10) Key and Trust Management. Several works investigated possible 1095 measures to implement these security functions [BIL2017], [MAE20181], 1096 [MAE20191]. Having identified security requirements, objectives and 1097 functions it must be ensured that they are applicable. 1099 10.5. LDACS Security Architecture 1101 The requirements lead to a LDACS security model including different 1102 entities for identification, authentication and authorization 1103 purposes ensuring integrity, authenticity and confidentiality of data 1104 in-transit especially. 1106 10.5.1. Entities 1108 A simplified LDACS architectural modelrequires the following 1109 entities: Network operators such as the Societe Internationale de 1110 Telecommunications Aeronautiques (SITA) [SIT2020] and ARINC [ARI2020] 1111 are providing access to the (1) Ground IPS network via an (2) A2G 1112 LDACS Router. This router is attached to a closed off LDACS Access 1113 Network, (3) which connects via further (4) Access Routers to the 1114 different (5) LDACS Cell Ranges, each controlled by a (6) GS (serving 1115 one LDACS cell), with several interconnected GS (7) spanning a local 1116 LDACS access network. Via the (8) A2G wireless LDACS data link (9) 1117 AS the aircraft is connected to the ground network and via the (10) 1118 aircrafts's VI and (11) aircraft's network interface, aircraft's data 1119 can be sent via the AS back to the GS, LDACS local access network, 1120 access routers, LDACS access network, A2G LDACS router to the ground 1121 Internet Protocol Suite (IPS) network [ICAO20152]. 1123 10.5.2. Entity Identification 1125 LDACS needs specific identities for (1) the AS, (2) the GS, and (3) 1126 the Network Operator. The aircraft itself can be identified using 1127 the ICAO unique address of an aircraft, the call sign of that 1128 aircraft or the recently founded Privacy ICAO Address (PIA) program 1129 [FAA2020]. It is conceivable that the LDACS AS will use a 1130 combination of aircraft identification, radio component 1131 identification and even operator features identification to create a 1132 unique AS LDACS identification tag. Similar to a 4G's eNodeB Serving 1133 Network (SN) Identification tag, a GS could be identified using a 1134 similar field. The identification of the network operator is again 1135 similar to 4G (e.g., E-Plus, AT&T, and TELUS), in the way that the 1136 aeronautical network operators are listed (e.g., ARINC [ARI2020] and 1137 SITA [SIT2020]). 1139 10.5.3. Entity Authentication and Key Negotiation 1141 In order to anchor Trust within the system all LDACS entities 1142 connected to the ground IPS network shall be rooted in an LDACS 1143 specific chain-of-trust and PKI solution, quite similar to AeroMACS 1144 approach [CRO2016]. These X.509 certificates [RFC5280] residing at 1145 the entities and incorporated in the LDACS PKI proof the ownership of 1146 their respective public key, include information about the identity 1147 of the owner and the digital signature of the entity that has 1148 verified the certificate's content. First all ground infrastructures 1149 must mutually authenticate to each other, negotiate and derive keys 1150 and, thus, secure all ground connections. How this process is 1151 handled in detail is still an ongoing discussion. However, 1152 established methods to secure user plane by IPSec [RFC4301] and IKEv2 1153 [RFC7296] or the application layer via TLS 1.3 [RFC8446] are 1154 conceivable. The LDACS PKI with their chain-of-trust approach, 1155 digital certificates and public entity keys lay the groundwork for 1156 this step. In a second step the AS with the LDACS radio approaches 1157 an LDACS cell and performs a cell entry with the corresponding GS. 1158 Similar to the LTE cell attachment process [TS33.401], where 1159 authentication happens after basic communication has been enabled 1160 between AS and GS (step 5a in the UE attachment process [TS33.401]), 1161 the next step is mutual authentication and key exchange. Hence, in 1162 step three using the identity-based Station-to-Station (STS) protocol 1163 with Diffie-Hellman Key Exchange [MAE2020], AS and GS establish 1164 mutual trust by authenticating each other, exchanging key material 1165 and finally, both ending up with derived key material. A key 1166 confirmation is mandatory before the communication channel between 1167 the AS and the GS can be opened for user-data communications. 1169 10.5.4. Message-in-transit Confidentiality, Integrity and Authenticity 1171 The subsequent key material from the previous step can then be used 1172 to protect LDACS Layer 2 communications via applying encryption and 1173 integrity protection measures on the SNP layer of the LDACS protocol 1174 stack. As LDACS transports AOC and ATS data, the integrity of that 1175 data is most important, while confidentiality only needs to be 1176 applied to AOC data to protect business interests [ICA2018]. This 1177 possibility of providing low layered confidentiality and integrity 1178 protection ensures a secure delivery of user data over the air gap. 1179 Furthermore, it ensures integrity protection of LDACS control data. 1181 10.6. LDACS Security Modules 1183 A draft of the cybersecurity architecture of LDACS can be found in 1184 [ICA2018] and [MAE20182] and respective updates in [MAE20191], 1185 [MAE20192], and [MAE2020]. 1187 10.6.1. Placements of Security Functionality in Protocol Stack 1189 Placing protection mechanisms in the LME and SNP entities within the 1190 protocol stack of LDACS will be most efficient in securing LDACS. 1191 MAC and DLS will also receive new tasks like the measurement 1192 performance for control channel protection. Security endpoints for 1193 secure user data communication, control data protection and primary 1194 entity authentication are the AS and GS. 1196 10.6.2. Trust 1198 The LDACS security concept requires all entities in an LDACS network 1199 to authenticate to each other to ascertain that only trusted 1200 participants can use the system. To establish trust within the 1201 network, inter-operations between all FCI candidates must be 1202 possible, thus LDACS will follow AeroMACS lead and also use an FCI 1203 specific PKI [RFC5280]. A PKI can solve the problem of having to 1204 trust a communication's partner identity claim via involving a 1205 trusted third party who verifies the identities of the parties who 1206 wish to engage in communication via issuing a digital certificate. 1207 As aviation operates worldwide, a hierarchical PKI will have to be 1208 deployed with several sub-CAs being distributed over the world. 1210 Basically, there are two proposals on how to achieve worldwide trust 1211 coverage: 1213 1. One root CA is installed per geographic region and then it 1214 performs cross-certification with distributed root-CAs of all 1215 other geo-graphic regions around the world. Subdomains can exist 1216 within ATM organizations. Here trust emerges from the assured 1217 trustworthiness of each regional root CA cross-certifying other 1218 and being cross-certified by other regional CAs 1219 2. The other idea is to have one worldwide (probably offline) root 1220 CA, hosted by a trusted worldwide entity, such as ICAO, with 1221 several regions sub-CAs distributed around the world. That way, 1222 the ICAO hosted root CA serves as trust bridge. 1224 10.6.3. Mutual Authentication and Key Exchange (MAKE) 1226 Via a modified, identity-based STS procedure and digital certificate 1227 and public keys pre-deployed during maintenance at the respective 1228 end-entities, the MAKE procedure can guarantee (1) Mutual 1229 Authentication, (2) Secure Key Agreement, (3) Prefect Forward Secrecy 1230 and (4) Key Confirmation [MAE2020]. As Diffie-Hellman Key Exchange 1231 (DHKE) procedure, we are currently evaluating the classic ephemeral 1232 DHKE [DIF1976] with 3072bit keys, Elliptic Curve DHKE (ECDH) with 1233 256bit keys [KOB1987] and the Supersingular Isogeny DHKE (SIDH) with 1234 2624bit key sizes [JAO2011]. As minimization of security data on the 1235 datalink is key, ECDH is currently the favorite way forward. 1236 Assuming that an LDACS security header consists of TYPE, ID, UA and 1237 PRIO fields, the entire header is of length 48bit [GRA2019]. 1238 Cryptographic nonces are 96bit long, signatures 512bit and the public 1239 elliptic curve Diffie-Hellman keys 256bit. With these bit sizes, the 1240 entire STS-MAKE procedure between AS and GS requires a total of 4 1241 messages and 1920bit [MAE2021]. 1243 10.6.4. Key Derivation and Key Hierarchy 1245 Once all parties within the network have successfully authenticated 1246 to each other, key derivation is necessary to generate different keys 1247 for different purposes. We need different keys for user data 1248 protection and keys for control data protection. As key derivation 1249 function, we propose the Hash-based Message Authentication Code 1250 (HMAC) Key Derivation Function (KDF) - HKDF [RFC5869]. First the 1251 input keying material (here: master key/static Diffie Hellman shared 1252 key) is taken and a fixed-length pseudo-random key is extracted. We 1253 extract a pseudorandom key from the master key by adding a salt 1254 value, which can be any fixed non-secret string chosen at random. In 1255 the process the pseudo random key becomes indistinguishable from a 1256 uniform distribution of bits. As LDACS will be deployed in 2024 with 1257 a recommendation of a minimum-security level of 128bit. 1259 10.6.5. User Data Security 1261 It is proposed to secure LDACS Sub-Network Packet Data Units (SN- 1262 PDU)s, as their size can vary from 128 to 1536 Byte [GRA2019], which 1263 makes them possibly the largest PDUs within LDACS. This helps 1264 minimizing security data overhead, in case a Message Authentication 1265 Code (MAC) tag is attached to the SN-PDU. For confidentiality 1266 protection, it is recommended symmetric approaches for data 1267 encryption, due to low computational overhead and fast operation 1268 times. As encryption algorithm, it is recommended to use AES-128- 1269 GCM/AES-256-GCM [RFC5288] with Galois Counter Mode (GCM) being a mode 1270 of operation on symmetric key block. It provides authenticated 1271 encryption and decryption operations and it proves robust against 1272 currently known quantum-computer-based algorithms [BER2017]. For 1273 message integrity/authenticity protection, it is recommended either 1274 to use the aforementioned AES-GCM with tag lengths of at least 128bit 1275 or HMAC with hash-functions from the SHA-3 family [PRI2014]. At 1276 least HMAC-SHA3-128 with a tag length of 128bit is recommended. This 1277 way the tag security data overhead ranges from 1.04 to 12.50% for 1278 user data, depending on the SN-PDU size. 1280 10.6.6. Control Data Security 1282 LDACS has four control channels: AS announce their existence in the 1283 RA, at the beginning of each SF in the RL, where each AS can transmit 1284 56bit. GS announce their existence in the BC, at the beginning of 1285 each SF in the FL, where the GS can transmit a total of 2304bit. AS 1286 can request resources in the DC, where each AS has an 83bit long slot 1287 and GS can grant those resources in the CC, with 728bit per CC-PHY- 1288 SDU. As the control channels of LDACS are very small-size, it is 1289 obvious that protection is challenging. Having security requirements 1290 in mind it is recommended to introduce group key mechanisms for 1291 LDACS. Thus, after the MAKE procedure of LDACS, a control plane 1292 related group key is derived by the GS and shared with all AS in a 1293 protected manner. As group key procedure, several approaches are 1294 investigated (e.g., G-IKEv2 [I-D.ietf-ipsecme-g-ikev2], CRGT 1295 [ZHE2007], CAKE [GUG2018], LKH [SAK2014], and OFT [KUM2020]). As OFT 1296 has the least requirements on network operations compared to the 1297 other, LDACS will use OFT with a fixed tree of 512-member nodes for a 1298 maximum of 512 supported AS in an LDACS cell. All AS and GS use this 1299 group key to protect the exchanged control data in the CC/DC slots. 1300 As these messages remain valid for a time period in the order of 10 1301 ms and the transmission is distance bound by the MAC protocol of 1302 LDACS, very small digest tags of 16 or 32bit can suffice to protect a 1303 minimum of integrity of control messages of LDACS. To that end, it 1304 is proposed to use blake2b or blake2s and to trim the tag after 4 1305 bytes [RFC7693]. 1307 11. Privacy Considerations 1309 LDACS provides a Quality-of-Service, and the generic considerations 1310 for such mechanisms apply. 1312 12. IANA Considerations 1314 This memo includes no request to IANA. 1316 13. Acknowledgements 1318 Thanks to all contributors to the development of LDACS and ICAO PT-T. 1320 Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi 1321 Fantappie for further input to this draft. 1323 Thanks to the Chair for Network Security and the research institute 1324 CODE for their comments and improvements. 1326 Thanks to SBA Research Vienna for fruitful discussions on 1327 aeronautical communications concerning security incentives for 1328 industry and potential economic spillovers. 1330 14. Normative References 1332 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1333 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1334 December 2005, . 1336 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1337 Housley, R., and W. Polk, "Internet X.509 Public Key 1338 Infrastructure Certificate and Certificate Revocation List 1339 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1340 . 1342 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1343 Kivinen, "Internet Key Exchange Protocol Version 2 1344 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1345 2014, . 1347 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1348 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1349 . 1351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1352 Requirement Levels", BCP 14, RFC 2119, 1353 DOI 10.17487/RFC2119, March 1997, 1354 . 1356 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1357 Key Derivation Function (HKDF)", RFC 5869, 1358 DOI 10.17487/RFC5869, May 2010, 1359 . 1361 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1362 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1363 DOI 10.17487/RFC5288, August 2008, 1364 . 1366 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 1367 Cryptographic Hash and Message Authentication Code (MAC)", 1368 RFC 7693, DOI 10.17487/RFC7693, November 2015, 1369 . 1371 15. Informative References 1373 [SCHN2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M., 1374 Thiasiriphet, T., Schnell, M., and U.C. Fiebig, 1375 "Measurement of the L-band Air-to-Ground Channel for 1376 Positioning Applications", IEEE Transactions on Aerospace 1377 and Electronic Systems, 52(5), pp.2281-229 , 2016. 1379 [MAE20191] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of 1380 the LDACS Cybersecurity Implementation", IEEE 38th Digital 1381 Avionics Systems Conference (DACS), pp. 1-10, San Diego, 1382 CA, USA , 2019. 1384 [MAE20192] Maeurer, N. and C. Schmitt, "Towards Successful 1385 Realization of the LDACS Cybersecurity Architecture: An 1386 Updated Datalink Security Threat- and Risk Analysis", IEEE 1387 Integrated Communications, Navigation and Surveillance 1388 Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019. 1390 [GRA2019] Graeupl, T., Rihacek, C., and B. Haindl, "LDACS A/G 1391 Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2019. 1393 [FAN2019] Pierattelli, S., Fantappie, P., Tamalet, S., van den 1394 Einden, B., Rihacek, C., and T. Graeupl, "LDACS Deployment 1395 Options and Recommendations", SESAR2020 PJ14-02-01 1396 D3.4.020 , 2019. 1398 [MAE20182] Maeurer, N. and A. Bilzhause, "A Cybersecurity 1399 Architecture for the L-band Digital Aeronautical 1400 Communications System (LDACS)", IEEE 37th Digital Avionics 1401 Systems Conference (DASC), pp. 1-10, London, UK , 2017. 1403 [GRA2011] Graeupl, T. and M. Ehammer, "L-DACS1 Data Link Layer 1404 Evolution of ATN/IPS", 30th IEEE/AIAA Digital Avionics 1405 Systems Conference (DASC), pp. 1-28, Seattle, WA, USA , 1406 2011. 1408 [GRA2018] Graeupl, T., Schneckenburger, N., Jost, T., Schnell, M., 1409 Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Maeurer, 1410 N., Kumar, R., Osechas, O., and G. Battista, "L-band 1411 Digital Aeronautical Communications System (LDACS) flight 1412 trials in the national German project MICONAV", Integrated 1413 Communications, Navigation, Surveillance Conference 1414 (ICNS), pp. 1-7, Herndon, VA, USA , 2018. 1416 [SCH20191] Schnell, M., "DLR Tests Digital Communications 1417 Technologies Combined with Additional Navigation Functions 1418 for the First Time", 2019. 1420 [ICA2018] International Civil Aviation Organization (ICAO), "L-Band 1421 Digital Aeronautical Communication System (LDACS)", 1422 International Standards and Recommended Practices Annex 10 1423 - Aeronautical Telecommunications, Vol. III - 1424 Communication Systems , 2018. 1426 [SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Mueller, S., 1427 Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 1428 Conformance and Compatibility Assessment", IEEE/AIAA 33rd 1429 Digital Avionics Systems Conference (DASC), pp. 1-11, 1430 Colorado Springs, CO, USA , 2014. 1432 [RIH2018] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., 1433 Graeupl, T., Schnell, M., and N. Fistas, "L-band Digital 1434 Aeronautical Communications System (LDACS) Activities in 1435 SESAR2020", Integrated Communications Navigation and 1436 Surveillance Conference (ICNS), pp. 1-8, Herndon, VA, 1437 USA , 2018. 1439 [BEL2019] Bellido-Manganell, M. A. and M. Schnell, "Towards Modern 1440 Air-to-Air Communications: the LDACS A2A Mode", IEEE/AIAA 1441 38th Digital Avionics Systems Conference (DASC), pp. 1-10, 1442 San Diego, CA, USA , 2019. 1444 [TS33.401] Zhang, D., "3GPP System Architecture Evolution (SAE); 1445 Security architecture", T33.401, 3GPP , 2012. 1447 [CRO2016] Crowe, B., "Proposed AeroMACS PKI Specification is a Model 1448 for Global and National Aeronautical PKI Deployments", 1449 WiMAX Forum at 16th Integrated Communications, Navigation 1450 and Surveillance Conference (ICNS), pp. 1-19, New York, 1451 NY, USA , 2016. 1453 [MAE2020] Maeurer, N., Graeupl, T., and C. Schmitt, "Comparing 1454 Different Diffie-Hellman Key Exchange Flavors for LDACS", 1455 IEEE/AIAA 39th Digital Avionics Systems Conference (DASC), 1456 pp. 1-10, San Antonio, TX, USA , 2020. 1458 [STR2016] Strohmeier, M., Schaefer, M., Pinheiro, R., Lenders, V., 1459 and I. Martinovic, "On Perception and Reality in Wireless 1460 Air Traffic Communication Security", IEEE Transactions on 1461 Intelligent Transportation Systems, 18(6), pp. 1338-1357, 1462 New York, NY, USA , 2016. 1464 [BIL2017] Bilzhause, A., Belgacem, B., Mostafa, M., and T. Graeupl, 1465 "Datalink Security in the L-band Digital Aeronautical 1466 Communications System (LDACS) for Air Traffic Management", 1467 IEEE Aerospace and Electronic Systems Magazine, 32(11), 1468 pp. 22-33, New York, NY, USA , 2017. 1470 [MAE20181] Maeurer, N. and A. Bilzhause, "Paving the Way for an IT 1471 Security Architecture for LDACS: A Datalink Security 1472 Threat and Risk Analysis", IEEE Integrated Communications, 1473 Navigation, Surveillance Conference (ICNS), pp. 1-11, New 1474 York, NY, USA , 2018. 1476 [FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.", 1477 August 2020, 1478 . 1480 [GNU2012] GNU Radio project, "GNU radio", August 2012, 1481 . 1483 [SIT2020] SITA, "Societe Internationale de Telecommunications 1484 Aeronautiques", August 2020, . 1486 [ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020, 1487 . 1489 [DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline 1490 2 ATS Data Communications (Baseline 2 SPR Standard)", May 1491 2016, . 1494 [ICAO20151] 1495 International Civil Aviation Organization (ICAO), "Manual 1496 on VHF Digital Link (VDL) Mode 2, Doc 9776", January 2019, 1497 . 1500 [ICAO20152] 1501 International Civil Aviation Organization (ICAO), "Manual 1502 on the Aeronautical Telecommunication Network (ATN) using 1503 Internet Protocol Suite (IPS) Standards and Protocols, Doc 1504 9896", January 2015, 1505 . 1507 [KAMA2010] Kamali, B., "An Overview of VHF Civil Radio Network and 1508 the Resolution of Spectrum Depletion", Integrated 1509 Communications, Navigation, and Surveillance Conference, 1510 pp. F4-1-F4-8 , May 2010. 1512 [DIF1976] Diffie, W. and M. Hellman, "New Directions in 1513 Cryptography", IEEE Transactions on Information Theory, 1514 22(6):644-654 , November 1976. 1516 [KOB1987] Koblitz, N. and M. Hellman, "Elliptic Curve 1517 Cryptosystems", Mathematics of Computation, 1518 48(177):203-209. , January 1987. 1520 [JAO2011] Jao, D. and L. De Feo, "Towards Quantum-Resistant 1521 Cryptosystems from Super-singular Elliptic Curve 1522 Isogenies", 4th International Workshop on Post-Quantum 1523 Cryptography, Springer, Heidelberg, Germany, pp. 19-34 , 1524 November 2011. 1526 [MAE2021] Maeurer, N., Graeupl, T., and C. Schmitt, "Cybersecurity 1527 for the L-band DigitalAeronautical Communications System 1528 (LDACS)", Aviation Cybersecurity: Foundations, Principles, 1529 and Applications. H. Song, K. Hopkinson, T. De Cola, T. 1530 Alexandrovich, and D. Liu (Eds.), Chapter 07, in printing 1531 process , 2021. 1533 [BER2017] Bernstein, D.J. and T. Lange, "Post-Quantum Cryptography", 1534 Nature, 549(7671):188-194 , 2017. 1536 [PRI2014] Pritzker, P. and P.D. Gallagher, "SHA-3 standard: 1537 Permutation-Based Hash and Extendable-Output Functions", 1538 Information Tech Laboratory National Institute of 1539 Standards and Technology, pp. 1-35 , 2014. 1541 [ZHE2007] Zheng, X., Huang, C.T., and M. Matthews, "Chinese 1542 Remainder Theorem-Based Group Key Management", 45th Annual 1543 Southeast Regional Conference, ACM, New York, NY, USA, pp. 1544 266-271 , March 2007. 1546 [GUG2018] Guggemos, T., Streit, K., Knuepfer, M., gentsche Felde, 1547 N., and P. Hillmann, "No Cookies, Just CAKE: CRTbased Key 1548 Hierarchy for Efficient Key Management in Dynamic Groups", 1549 International Conference for Internet Technology and 1550 Secured Transactions, Cambridge, UK, pp. 25-32 , December 1551 2018. 1553 [SAK2014] Sakamoto, N., "An Efficient Structure for LKH Key Tree on 1554 Secure Multi-Cast Communications", 15th IEEE/ACIS 1555 International Conference on Software Engineering, 1556 Artificial Intelligence, Networking and Parallel/ 1557 Distributed Computing, New York, NY, USA, pp. 1-7 , 1558 November 2014. 1560 [KUM2020] Kumar, V., Kumar, R., and S.K. Pandey, "A Computationally 1561 Efficient Centralized Group Key Distribution Protocol for 1562 Secure Multicast Communications Based Upon RSA Public Key 1563 Cryptosystem", Journal of King Saud University - Computer 1564 and Information Sciences, 32(9):1081-1094 , 2020. 1566 [RAW-TECHNOS] 1567 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 1568 and J. Farkas, "Reliable and Available Wireless 1569 Technologies", Work in Progress, Internet-Draft, draft- 1570 ietf-raw-technologies-01, 19 February 2021, 1571 . 1574 [RAW-USE-CASES] 1575 Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. 1576 Bernardos, "RAW use cases", Work in Progress, Internet- 1577 Draft, draft-ietf-raw-use-cases-01, 21 February 2021, 1578 . 1580 [I-D.ietf-ipsecme-g-ikev2] 1581 Smyslov, V. and B. Weis, "Group Key Management using 1582 IKEv2", Work in Progress, Internet-Draft, draft-ietf- 1583 ipsecme-g-ikev2-02, 11 January 2021, 1584 . 1587 Appendix A. Selected Information from DO-350A 1589 This appendix includes the continuity, availability, and integrity 1590 requirements interesting for LDACS defined in [DO350A]. 1592 The following terms are used here: 1594 CPDLC Controller Pilot Data Link Communication 1595 DT Delivery Time (nominal) value for RSP 1596 ET Expiration Time value for RCP 1597 FH Flight Hour 1598 MA Monitoring and Alerting criteria 1599 OT Overdue Delivery Time value for RSP 1600 RCP Required Communication Performance 1601 RSP Required Surveillance Performance 1602 TT Transaction Time (nominal) value for RCP 1604 +========================+=============+=============+ 1605 | | ECP 130 | ECP 130 | 1606 +========================+=============+=============+ 1607 | Parameter | ET | TT95% | 1608 +------------------------+-------------+-------------+ 1609 | Transaction Time (sec) | 130 | 67 | 1610 +------------------------+-------------+-------------+ 1611 | Continuity | 0.999 | 0.95 | 1612 +------------------------+-------------+-------------+ 1613 | Availability | 0.989 | 0.989 | 1614 +------------------------+-------------+-------------+ 1615 | Integrity | 1E-5 per FH | 1E-5 per FH | 1616 +------------------------+-------------+-------------+ 1618 Table 1: CPDLC Requirements for ECP 1620 +==============+==========+==============+=========+=========+ 1621 | | RCP 240 | RCP 240 | RCP 400 | RCP 400 | 1622 +==============+==========+==============+=========+=========+ 1623 | Parameter | ET | TT95% | ET | TT95% | 1624 +--------------+----------+--------------+---------+---------+ 1625 | Transaction | 240 | 210 | 400 | 350 | 1626 | Time (sec) | | | | | 1627 +--------------+----------+--------------+---------+---------+ 1628 | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 1629 +--------------+----------+--------------+---------+---------+ 1630 | Availability | 0.989 | 0.989 | 0.989 | 0.989 | 1631 | | (safety) | (efficiency) | | | 1632 +--------------+----------+--------------+---------+---------+ 1633 | Integrity | 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 | 1634 | | FH | | per FH | per FH | 1635 +--------------+----------+--------------+---------+---------+ 1637 Table 2: CPDLC Requirements for RCP 1639 RCP Monitoring and Alerting Criteria in case of CPDLC: 1641 - MA-1: The system SHALL be capable of detecting failures and 1642 configuration changes that would cause the communication service 1643 no longer meet the RCP specification for the intended use. 1644 - MA-2: When the communication service can no longer meet the RCP 1645 specification for the intended function, the flight crew and/or 1646 the controller SHALL take appropriate action. 1648 +==============+=====+=====+==========+==============+======+=======+ 1649 | | RSP | RSP | RSP 180 | RSP 180 | RSP |RSP 400| 1650 | | 160 | 160 | | | 400 | | 1651 +==============+=====+=====+==========+==============+======+=======+ 1652 | Parameter | OT |DT95%| OT | DT95% | OT | DT95% | 1653 +--------------+-----+-----+----------+--------------+------+-------+ 1654 | Transaction | 160 | 90 | 180 | 90 | 400 | 300 | 1655 | Time (sec) | | | | | | | 1656 +--------------+-----+-----+----------+--------------+------+-------+ 1657 | Continuity |0.999| 0.95| 0.999 | 0.95 |0.999 | 0.95 | 1658 +--------------+-----+-----+----------+--------------+------+-------+ 1659 | Availability |0.989|0.989| 0.989 | 0.989 |0.989 | 0.989 | 1660 | | | | (safety) | (efficiency) | | | 1661 +--------------+-----+-----+----------+--------------+------+-------+ 1662 | Integrity | 1E-5| 1E-5| 1E-5 per | 1E-5 per FH | 1E-5 | 1E-5 | 1663 | | per | per | FH | |per FH| per FH| 1664 | | FH | FH | | | | | 1665 +--------------+-----+-----+----------+--------------+------+-------+ 1667 Table 3: ADS-C Requirements 1669 RCP Monitoring and Alerting Criteria: 1671 - MA-1: The system SHALL be capable of detecting failures and 1672 configuration changes that would cause the ADS-C service no longer 1673 meet the RSP specification for the intended function. 1674 - MA-2: When the ADS-C service can no longer meet the RSP 1675 specification for the intended function, the flight crew and/or 1676 the controller SHALL take appropriate action. 1678 Authors' Addresses 1680 Nils Maeurer (editor) 1681 German Aerospace Center (DLR) 1682 Muenchner Strasse 20 1683 82234 Wessling 1684 Germany 1686 Email: Nils.Maeurer@dlr.de 1687 Thomas Graeupl (editor) 1688 German Aerospace Center (DLR) 1689 Muenchner Strasse 20 1690 82234 Wessling 1691 Germany 1693 Email: Thomas.Graeupl@dlr.de 1695 Corinna Schmitt (editor) 1696 Research Institute CODE, UniBwM 1697 Werner-Heisenberg-Weg 28 1698 85577 Neubiberg 1699 Germany 1701 Email: corinna.schmitt@unibw.de