Re: [Raw] Roman Danyliw's Discuss on draft-ietf-raw-ldacs-10: (with DISCUSS and COMMENT)

[[e-mail]]

Dear Roman Danyliw,

Thank you for your comments. Please find out answers inline below.

Best,
Nils Mäurer

-----Ursprüngliche Nachricht-----
Von: Roman Danyliw via Datatracker <[e-mail]> 
Gesendet: Donnerstag, 21. April 2022 05:24
An: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: Roman Danyliw's Discuss on draft-ietf-raw-ldacs-10: (with DISCUSS and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-raw-ldacs-10: Discuss


----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** With the upfront acknowledgement that I have little familiarity with LDACS,
I had significant difficulty in assessing the alignment of most this document
to the defined charter of RAW.  It appears to me that only a narrow portion of
the document is in-charter scope. References were provided for LDACS (e.g.,
[ICAO2015]), but as they were behind a paywall I was not able to review them. 
Relying primarily on Section 7.3 and Figure 3 of the [MAE20192], it appears
that LDACS is a series of technologies that operate below layer-3.  Operating
on top of LDACS at layer3+ is the FCI.  Section 4 reminds us that “The IPv6
architecture for the aeronautical telecommunication network is called the FCI.”

Per the RAW charter, “RAW will stay abstract to the radio layers underneath,
addressing the Layer 3 aspects in support of applications requiring high
reliability and availability.”  With that in mind, I was looking for the in
scope RAW work items to produce “Use Cases, Requirements,
Architecture/Framework Aspects for a Wireless Network, and an Evaluation of
Existing IETF Technologies and Gap Analysis” for technologies at or above layer
3.  In Section 5.2.3, I first found specifics on FCI that appear to a use cases
within that scope.  In Section 7.3.3,  there is text on the SNP which describes
activity germane to handling layer-3 services.  However, this section also
excludes this work as out of scope -- “[t]his work is ongoing and not part of
this document.”

In my assessment the overwhelming majority of the text in this document is
describing technologies and architecture not in RAW’s in-scope remit of layer
3+.

If the WG finds documenting this otherwise paywalled information in an
information document valuable, I see no issue keeping this material in an
Appendix.  However, the framing of this document needs to be clearer to
highlight the in-scope materials around FCI.

- Reply: LDACS is a cellular, ground-based digital communications system for flight guidance and communications related to the safety and regularity of flight. It is responsible for safely and reliably delivering Aeronautical Telecommunications Network (ATN)/Internet Protocol Suite (IPS) communications, which consist of Aeronautical Operational Control (AOC), Air Traffic Services (ATS) and Air Traffic Control (ATC) data. As such, LDACS interacts directly with IPv6 and uses the SNP layer in its protocol stack to translate IP traffic to LDACS specific packet format. While it is true, that a majority of this document describes below layer 3 technology, it is also explicitly mentioned in the charter of the RAW WG: "RAW extends the DetNet Working Group concepts to provide for high reliability and availability for an IP network utilizing scheduled wireless segments and other media, e.g., frequency/time-sharing physical media resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS)." 
The reason, why it is explicitly listed here is, that all future aeronautical communications will be routed over IP (ATN/IPS) and LDACS is one data-link candidate within the Future Communications Infrastructure (FCI) doing that.
We thought it beneficial to bring this fact to the attention of the IETF and also start working on an IETF agreed upon LDACS draft upon which future work, such as how translation from IP to LDACS/FCI datalinks works in detail, will be based upon.
We will update the draft with a clearer framing.

** Section 9.  Please explicitly document the Security Considerations of FCI
(i.e., the IPv6/layer behaviors).  Is that Section 9.2?

- Reply: ATN/IPS security considerations are listed in ARINC P858 and ICAO Doc 9896, both unfortunately behind a paywall. Currently, DTLS is foreseen as transport layer security for ATN/IPS traffic. Data-links within the FCI need to provide "a secure channel between the airborne radio systems and the peer radio access endpoints on the ground [...] to ensure authentication and integrity of air-ground message exchanges in support of an overall defense-in-depth security strategy." [ARINC P858].
We can extend our draft based on that and include all relevant points from both paywalled documents.

-- Section 9, Per “These requirements imply that LDACS must provide layer 2
security in addition to any higher layer mechanisms”, it isn’t clear how this
is in-scope given the remit of RAW (see above).

-- Section 9.1 is helpful background but what of that applies to layer 3?  The
specifics in the threat analysis of [STR2016] and the advent of SDRs appears to
be largely data link considerations.

-- Section 9.2  How does [MAE20181] inform layer 3 threats as it’s explicitly
focused on data link issues?

-- Section 9.3.  Which of these security objectives apply to the FCI?

-- Section 9.5.3.  Architecturally, it isn’t clear how IPSec, TLS are being
used by the FCI.

- Reply: Any data-link transporting ATN/IPS related traffic needs to establish a secure channel (here in ARINC/ICAO documents usually NIST is cited with "A path for transferring data between two entities or components that ensures confidentiality, integrity, and replay protection as well as mutual authentication between the entities or components" [https://csrc.nist.gov/glossary/term/secure_channel]) between " radio systems and the peer radio access endpoints on the ground ". That means, the data-link itself needs to implements all that, before any FCI traffic is allowed here. On the actual ATN/IPS layer, DTLS with own dedicated ATN/IPS certificates and PKI is foreseen. We will update the section, clearly stating, what the document is looking at, in terms of security, and how security is applied on the above layers.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I was unable to review the security claims of this document as several of the
references were not available to me. For example, [ARI2021], [ICAO2015], and
[ICA2018].  I leave it the judgement of the responsible AD to that the WG had
appropriate access and that they are being appropriately used.

** Section 1.  Editorial

(2) the introduction of IPv6 based networking protocols in
   aeronautical networks [RFC4291], [RFC7136], [ICAO2015].

I didn’t understand the link between [RFC4291] and [RFC7136] and aeronautical
networks.  If these are only intended to be citations to IPv6, then the text
would be clearer as:

(2) the introduction of IPv6 based networking protocols [RFC4291], [RFC7136] in
aeronautical networks  [ICAO2015].

- Reply: We will change that and reference RFC 8200 as was suggested.

** Section 5.2.1

The related protocol
   stack is currently under development by ICAO, within SESAR, and the
   IETF [I-D.haindl-lisp-gb-atn] [I-D.ietf-rtgwg-atn-bgp]

Judged entirely on datatracker meta-data, it appears to be a
mis-characterization to say that draft-haindl-lisp-gb-atn is under-development
in the IETF.  All I can confirm is the existence of an individual submission
that has been updated a number of times over 4+ years that has not been adopted
by a WG.

- Reply: We will correct that statement.

** From idnits:
  == Missing Reference: 'KOB1987' is mentioned on line 1211, but not defined

- Reply: We will update the missing reference.