Internet DRAFT - draft-moskowitz-drip-efficient-a2g-comm

draft-moskowitz-drip-efficient-a2g-comm







DRIP                                                        R. Moskowitz
Internet-Draft                                            HTT Consulting
Intended status: Standards Track                                 S. Card
Expires: 31 March 2024                                     AX Enterprize
                                                               A. Gurtov
                                                    Linköping University
                                                       28 September 2023


                  Efficient Air-Ground Communications
               draft-moskowitz-drip-efficient-a2g-comm-01

Abstract

   This document defines protocols to provide efficient air-ground
   communications without associated need for aircraft to maintain
   stateful connection to ground-tower infrastructure.  Instead, a
   secure source-routed ground infrastructure will not only provide the
   needed routing intelligence, but also reliable packet delivery
   through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error
   Correction (FEC) to address both reliable wireless packet delivery,
   and assured terrestrial packet delivery.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 31 March 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.



Moskowitz, et al.         Expires 31 March 2024                 [Page 1]

Internet-Draft             A2G Communications             September 2023


   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Enabling and Enhancing Functions  . . . . . . . . . . . . . .   3
     3.1.  Enabling Requirements . . . . . . . . . . . . . . . . . .   3
     3.2.  Enhancing Security Requirement  . . . . . . . . . . . . .   4
     3.3.  Enhancing Performance Requirements  . . . . . . . . . . .   4
   4.  Background Discussion . . . . . . . . . . . . . . . . . . . .   5
     4.1.  The problem and simple solution using IPnIP . . . . . . .   5
     4.2.  Improved tower trust through digital signing  . . . . . .   6
     4.3.  Inclusion of mobile ground systems  . . . . . . . . . . .   7
     4.4.  Improved uplink reliability . . . . . . . . . . . . . . .   7
     4.5.  Alternative dedicated Tower-GS tunneling  . . . . . . . .   8
   5.  Aircraft to GS Messaging  . . . . . . . . . . . . . . . . . .   8
     5.1.  The Tower to GS tunnel  . . . . . . . . . . . . . . . . .  10
   6.  GS to Aircraft Messaging  . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The goal of this design approach is to place minimal network
   intelligence in the aircraft and even the wireless towers.
   Practically all the networking intelligence is placed within the
   Ground Station (GS).  The justification for this approach is
   intelligence in the aircraft has disproportional costs to that in the
   GS; there are many factors in this claim.  Lower intelligence
   requirements in the towers will make the technology more attractive
   to tower owners, provided there is an associated functional payment
   mechanism for them for the service.

   The wireless downlink from the aircraft is treated as a broadcast
   message, with every receiving tower forwarding messages to the GS.
   The GS, in turns, notes which towers are in contact with the aircraft



Moskowitz, et al.         Expires 31 March 2024                 [Page 2]

Internet-Draft             A2G Communications             September 2023


   and sends uplink messages through them to the aircraft.  There is no
   need for complex aircraft/tower connection technologies.  At most,
   for billing purposes, the towers are aware of aircraft and GS that
   will use their connectivity services via their source IP addresses.

2.  Terms and Definitions

2.1.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Definitions

   A2G
      Communications from an aircraft to some ground equipment.  Also
      somethings GS.

3.  Enabling and Enhancing Functions

   The following is a list of enabling and enhancing functions.

3.1.  Enabling Requirements

   The aircraft:

   *  Support end-to-end secure communications with the GS and start the
      operation with the pre-configured GS IP address.  The aircraft
      sends the first message, to the GS, to establish the routing
      knowledge in the GS,

   *  use a fixed IP address for itself for the duration of the
      operation, and

   *  be able to process multiple copies of messages from the GS,
      received potentially from multiple towers.

   The tower:

   *  Support digital signing of messages from the aircraft, and the
      tower’s IP address, and forward these objects to the GS.

   The GS:

   *  Support end-to-end secure communications with the aircraft,



Moskowitz, et al.         Expires 31 March 2024                 [Page 3]

Internet-Draft             A2G Communications             September 2023


   *  support processing multiple copies of messages from the aircraft,

   *  support digital signing by the tower, and

   *  maintain a list/map of towers forwarding aircraft messages from
      the aircraft for messaging to the aircraft.  The list of trusted
      tower IP addresses is constructed from within the tower signed
      objects.

3.2.  Enhancing Security Requirement

   The GS should:

   *  Support digital signing for the tower to trust messages from the
      GS.

3.3.  Enhancing Performance Requirements

   The aircraft may:

   *  Support uplink usage optimizations like FEC and ARQ, and

   *  support GS IP address mobility (e.g. via HIP, [RFC7401]).

   The tower may:

   *  Include information like timestamp and its GPS-derived location
      (and accuracy of same) in the signed object delivered to the GS,

   *  may be IP address mobile, if so, then MUST provide its IP address
      within the signed object,

   *  support multicast and DETNET (rfc8938) for efficient and reliable
      communications with the GS, and

   *  use a subscription model to filter messages supported for
      forwarding.  If done with a list of registered IP addresses it
      MUST support GS IP address mobility.

   The GS may:

   *  Support intelligent operation routing and tower contact
      information to select towers to use to send messages to the
      aircraft,

   *  support tower subscription for tower communication filtering,





Moskowitz, et al.         Expires 31 March 2024                 [Page 4]

Internet-Draft             A2G Communications             September 2023


   *  support multicast and DETNET for efficient communications with the
      towers,and

   *  support FEC and ARQ for efficient use of uplinks to the aircraft.

4.  Background Discussion

   The following considers the possible technologies, some challenges,
   and final proposed solution.

4.1.  The problem and simple solution using IPnIP

   Internet Protocol (IP) transmissions from the aircraft to ground,
   though unicast in construction (i.e.  IP destination/source paired),
   are really broadcasts, as a practical matter, to all available ground
   towers.  Such towers can simply send the packets on their way and
   they will naturally get routed, i.e. relayed, to the GS which
   correspondingly simply recognizes and processes potential multiple
   receipts via the many relaying towers.  The problem is only the
   uplink: how to get IP transmissions from the GS to the aircraft.

   The GS needs to ‘know’ which towers can likely transmit up to the
   aircraft and how to route packets through them.  A simple solution is
   to use IP-in-IP (IPnIP) tunneling protocol [RFC1853].  Here, each
   receiving tower wraps the downlink message in IPnIP with the outer
   source address being the the tower’s address.  The aircraft always
   uses a fixed source address (e.g. their respective DET [RFC9374]).
   The GS maintains an IPnIP tunneling table for each aircraft DET of
   the tower addresses.  Packets inbound to the GS update this table
   (stale entries are purged) and the IPnIP service unwraps and forwards
   the inner content back through the IP kernel for sending up to the
   application.  Packets outbound to the aircraft address get routed
   internally to the IPnIP process which ends up sending out multiple
   copies to each of the tower addresses in the table.  Each receiving
   tower then simply unwarps and uplinks the content to the aircraft.

   Though this approach works, it has security and traffic management
   challenges.  First and foremost, the aircraft must know the GS IP
   address.  It either needs to be fixed or the aircraft needs a
   separate process to update its knowledge of the GS address.  The GS
   should have the aircraft address prior to operation start or can
   simply learn them through received messages.

   There are two security issues associated with the GS processing
   messages from any random aircraft address:

   *  Either these addresses are preset (e.g. registered DET), or there
      is some process for the GS to dynamically learn which to trust.



Moskowitz, et al.         Expires 31 March 2024                 [Page 5]

Internet-Draft             A2G Communications             September 2023


   *  A larger security challenge is why should the GS trust the address
      for the towers as a route to the aircraft.  A malicious source
      could provide bad tower addresses resulting in loss of aircraft
      contact at worst, or consumption, through DOS attacks, of both GS
      processing resources and tower uplink bandwidth.

   An additional challenge for the GS is determining which set of towers
   to use to send messages uplinked to the aircraft.  Which of the
   towers last sending messages from the aircraft are still in RF reach
   of the aircraft and are there now towers better able to message the
   aircraft?  If the GS can trust the towers and know their GPS location
   and the signal strengths of messages from the aircraft, the GS can
   use this map along with the map of the planned operation to better
   select towers for uplinking messages.

   With all these stated concerns, the IPnIP approach should only be
   used for PoC and general testing.  It presents too good of a DOS
   attack scenario for production deployments.

4.2.  Improved tower trust through digital signing

   Trust in tower messaging can be achieved by each tower
   cryptographically signing the received aircraft messages before
   forwarding them to the GS.  This must be a specific signed object,
   perhaps in COSE format [RFC8152].  Not only would it contain the
   aircraft message with the tower’s digital ID and signature, it should
   also minimally include a timestamp, the tower’s GPS location plus GPS
   accuracy, and signal strength.  With this information, a process on
   the GS can put the tower on a map with the planned aircraft flight
   plan.  If three or more towers forwarded the message, the GS can also
   multilaterate the aircraft location for accurate location on the map.
   This information would allow the GS to predict which towers are still
   in range, or soon in range (i.e. predicting new towers for
   communications) of the aircraft for uplink messaging.

   This signing method is preferable to secure tunnels from the tower to
   the GS as there will be thousands of GS using a small number of
   towers.  How should tunnels be set up and torn down recognizing the
   cost to the tower system?  It is preferable for the towers to be
   stateless in their forwarding to the GS.  Also, it is questionable
   whether the GS should sign messages for the uplink.  Doing so would
   potentially place the burden of processing cost on the tower, and
   analysis would be needed to avoid denial of service (DOS) attacks
   against towers and their uplink capacity.







Moskowitz, et al.         Expires 31 March 2024                 [Page 6]

Internet-Draft             A2G Communications             September 2023


   The inclusion of GPS accuracy supports improved mobile tower
   multilateration.  The timestamp also enables multilateration, in
   aging towers out of the reachable list of towers against the flight
   plan.

   Thus, inbound processing on the GS would first place tower
   information into the aircraft reachable table mentioned above, then
   forward the aircraft message up to the application.  For outbound,
   the aircraft address could result in passing the message to an IPnIP
   service for simple forwarding to the tower as above, but as mentioned
   above IPnIP has DOS risks.

4.3.  Inclusion of mobile ground systems

   If the air-ground communications are secured with the Host Identity
   Protocol (HIP, [RFC7401]), the HIP mobility function can update the
   aircraft with any changes in the GS IP address.  DTLS 1.3 [RFC9147]
   can be used only if the aircraft is the server as DTLS supports
   client, not server, mobility and the aircraft can learn of new GS
   addressing as it processes uplinked messages from the new addresses.

   In any case, the aircraft address should be its DET and be unchanging
   for the flight duration.

4.4.  Improved uplink reliability

   If three or more towers provide the uplink, the GS can use Forward
   Error Correction (FEC) and send the fragments to different towers.
   The aircraft need only receive the proper set of fragments to
   reconstruct the full message.  This both reduces the packet size on
   the uplink, conserving uplink capacity and increases both ground and
   wireless delivery reliability.  Static Context Header Compression
   (SCHC, [RFC8724]) should also be used to reduce the size of the
   aircraft-ground messages.  SCHC Automatic Repeat reQuest (ARQ) may
   also be used and will soon directly support FEC.

   The ground communications path reliability can be further improved
   through use of a subset of Deterministic Networking (DETNET) (tbd)
   and Bit Indexing Explicit Replication (BIER) multicasting from the GS
   to the towers.











Moskowitz, et al.         Expires 31 March 2024                 [Page 7]

Internet-Draft             A2G Communications             September 2023


4.5.  Alternative dedicated Tower-GS tunneling

   There will be areas where significant traffic exists between a tower
   (or group of towers) and a GS.  An example of such an area is around
   an aerodrome and its supporting systems.  Here it makes performance
   sense that a secure tunneling technology (e.g ESP, [RFC4303]) be used
   between the tower(s) and GS(s) rather than digitally signing
   individual messages.  Often, in such cases the ground network can be
   deployed to ensure reliable delivery.

5.  Aircraft to GS Messaging

   The aircraft and GS MAY have a pre-configured secure connection using
   technologies like DTLS, IPsec, or HIP.  The aircraft SHOULD use its
   DET as its IPv6 address, and underlying HI for the rawPublicKey to
   establish the connection.  Examples of this type of secure aircraft
   to GS is discussed in [drip-secure-nrid-c2].

   There is a bit of chicken-and-egg here if the initial connection
   setup is not over a single link, as DETs are not easy to route over
   an IPv6 network.  In such a case a tunnel, as discussed later, needs
   to be in place between the first hop from the aircraft (e.g.  WiFi
   Access Point) and the GS.

   In some instances, a pre-established aircraft-GS session is not
   practical (e.g. aircraft to airport traffic control).  A variant of
   Section 3.2 of [drip-a2x-adhoc-session] (Compressed UA Signed
   Evidence of the A2X message) can be sent to the pre-configured GS
   IPv6 address:






















Moskowitz, et al.         Expires 31 March 2024                 [Page 8]

Internet-Draft             A2G Communications             September 2023


    +=======+=================+=======================================+
    | Bytes | Name            | Explanation                           |
    +=======+=================+=======================================+
    | 16    | DET of Aircraft | DRIP Entity Tag of Aircraft           |
    +-------+-----------------+---------------------------------------+
    | 16    | Destination     | IPv6 address of GS                    |
    |       | Address         |                                       |
    +-------+-----------------+---------------------------------------+
    | 4     | VNA Timestamp   | Timestamp denoting recommended time   |
    |       |                 | to trust Evidence                     |
    +-------+-----------------+---------------------------------------+
    | 1     | Message ID      | A2G Message ID Number                 |
    +-------+-----------------+---------------------------------------+
    | n     | A2G Message     | Actual A2G Message                    |
    +-------+-----------------+---------------------------------------+
    | 64    | Signature by    | Signature over preceding fields using |
    |       | Aircraft        | the keypair of the Aircraft DET       |
    +-------+-----------------+---------------------------------------+

              Table 1: 101+n Byte Aircraft Signed A2G message

   This message is a SCHC compressed IPv6/UDP datagram.  The signature
   is on the whole datagram.  The wireless transport will have some
   mechanism (e.g.  SCHC as Ethertype) to trigger the SCHC rule
   processing to compress the datagram for transmission.  Depending on
   the wireless technology there will be a 1-byte SCHC RuleID after the
   SCHC Ethertype (or equivalent).  If the IP Header is sent without
   SCHC compression, then SCHC will need to be the Next Header in the
   IPv6 Header and the SCHC RuleID will immediately follow the IPv6
   Header.

   The full uncompressed message is:



















Moskowitz, et al.         Expires 31 March 2024                 [Page 9]

Internet-Draft             A2G Communications             September 2023


     +=======+===============+=======================================+
     | Bytes | Name          | Explanation                           |
     +=======+===============+=======================================+
     | 40    | IPv6 Header   | IPv6 Header from Aircraft to GS       |
     +-------+---------------+---------------------------------------+
     | 8     | UDP Header    | Full UDP Header                       |
     +-------+---------------+---------------------------------------+
     | 4     | VNA Timestamp | Timestamp denoting recommended time   |
     |       |               | to trust Evidence                     |
     +-------+---------------+---------------------------------------+
     | 1     | Message ID    | A2G Message ID Number                 |
     +-------+---------------+---------------------------------------+
     | n     | A2G Message   | Actual A2G Message                    |
     +-------+---------------+---------------------------------------+
     | 64    | Signature by  | Signature over preceding fields using |
     |       | Aircraft      | the keypair of the Aircraft DET       |
     +-------+---------------+---------------------------------------+

           Table 2: IPv6 117+m+n Byte Aircraft Signed A2G message

   Any tower that receives these messages and has a tunnel to the
   destination IPv6 address uses it to forward the message to the GS.
   The GS will use the aircraft DET to retrieve, via DNS, the HDA
   Endorsement of the DET.  This will provide the aircraft HI to
   validate the signature.

   A tower MAY validate the signature by using the aircraft DET to
   retrieve via DNS the HDA Endorsement of the aircraft DET.  The tower
   may choose to leave this validation to the GS as it is terrestrial
   network that may be DOSed from wireless transmissions.

5.1.  The Tower to GS tunnel

   It is impractical for most towers to maintain long-lived static
   tunnels as described in Section 4.5.  Too many towers will need to
   forward messages to too many GS for static tunneling.  Rather, per-
   packet tunneling will be frequently used.  These tunnels are the
   Aircraft-GS packets wrapped in a signed IPv6 datagram from the
   tower's IPv6 address to the GS's address that is in the A-GS packet:












Moskowitz, et al.         Expires 31 March 2024                [Page 10]

Internet-Draft             A2G Communications             September 2023


      +=======+===============+====================================+
      | Bytes | Name          | Explanation                        |
      +=======+===============+====================================+
      | 40    | IPv6 Header   | IPv6 Header from Tower to GS       |
      +-------+---------------+------------------------------------+
      | 8     | UDP Header    | Full UDP Header                    |
      +-------+---------------+------------------------------------+
      | 16    | DET of Tower  | DRIP Entity Tag of Tower           |
      +-------+---------------+------------------------------------+
      | 4     | VNA Timestamp | Timestamp from tower denoting      |
      |       |               | recommended time to trust Evidence |
      +-------+---------------+------------------------------------+
      | m     | Tower         | Optional tower location            |
      |       | Location      |                                    |
      +-------+---------------+------------------------------------+
      | m     | A2G Message   | Full A2G Message                   |
      +-------+---------------+------------------------------------+
      | 64    | Signature by  | Signature over preceding fields    |
      |       | Tower         | using the keypair of the Tower DET |
      +-------+---------------+------------------------------------+

         Table 3: IPv6 117+n Byte Aircraft Signed tunnel message

   The GS will use the tower DET to retrieve, via DNS, the HDA
   Endorsement of the tower.  This will provide the tower HI to validate
   the signature.

   The UDP Destination Port can be the indicator of the presence of the
   Tower Location information.  If absent, this information needs to be
   accessible via DNS using the Tower's DET (or pre-configured in the
   GS).  If the tower is physically mobile, this information SHOULD be
   included.

   The GS MUST be able to handle multiple copies of the A2G message.  It
   MUST use the Tower location information to maintain a mapping for
   routing messages to the aircraft.  It MAY use knowledge of the
   aircraft's planned flight to adjust this routing information as to
   which tower's are likely to be within reach of the aircraft.


6.  GS to Aircraft Messaging

   In most cases, the GS to aircraft messaging is the mirror of aircraft
   to GS.  The important difference is how the GS selects towers for
   forwarding G2A messages and how the towers pre-process these messages
   before using precious wireless bandwidth in sending messages.





Moskowitz, et al.         Expires 31 March 2024                [Page 11]

Internet-Draft             A2G Communications             September 2023


   The GS uses some process to select towers from the list of towers
   last forwarding aircraft messages to the GS plus knowledge of the
   aircraft flight and other towers in the area.

   The GS to tower tunnel is the mirror of Section 5.1 without the
   location information.  The tower SHOULD validate the authenticity of
   the GS via DNS retrieved HDA Endorsement of the GS DET.  It MAY also
   filter messages based on having recently received aircraft to GS
   messages.

   The tower takes the G2A message from within the tunnel, adding any
   needed wireless heading and transmits the datagram.

   The aircraft MUST be able to process multiple copies of an G2A
   message coming from multiple towers.

7.  IANA Considerations

   TBD

8.  Security Considerations

   TBD

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
              "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
              ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
              <https://www.rfc-editor.org/info/rfc9374>.

9.2.  Informative References








Moskowitz, et al.         Expires 31 March 2024                [Page 12]

Internet-Draft             A2G Communications             September 2023


   [drip-a2x-adhoc-session]
              Moskowitz, R., Card, S. W., and A. Gurtov, "Aircraft to
              Anything AdHoc Broadcasts and Session", Work in Progress,
              Internet-Draft, draft-moskowitz-drip-a2x-adhoc-session-02,
              23 July 2023, <https://datatracker.ietf.org/doc/html/
              draft-moskowitz-drip-a2x-adhoc-session-02>.

   [drip-secure-nrid-c2]
              Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
              Gurtov, "Secure UAS Network RID and C2 Transport", Work in
              Progress, Internet-Draft, draft-moskowitz-drip-secure-
              nrid-c2-13, 19 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-moskowitz-
              drip-secure-nrid-c2-13>.

   [RFC1853]  Simpson, W., "IP in IP Tunneling", RFC 1853,
              DOI 10.17487/RFC1853, October 1995,
              <https://www.rfc-editor.org/info/rfc1853>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.

   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/info/rfc9147>.

Acknowledgments

   Adam Wiethuechter of AX Enterprize provided review and implementation
   insights.  Michael Baum provided extensive review of the contents in
   chapters 3 and 4 in a prior white paper.



Moskowitz, et al.         Expires 31 March 2024                [Page 13]

Internet-Draft             A2G Communications             September 2023


Authors' Addresses

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI 48237
   United States of America
   Email: rgm@labs.htt-consult.com


   Stuart W. Card
   AX Enterprize
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America
   Email: stu.card@axenterprize.com


   Andrei Gurtov
   Linköping University
   IDA
   SE-58183 Linköping
   Sweden
   Email: gurtov@acm.org




























Moskowitz, et al.         Expires 31 March 2024                [Page 14]