Mathematical Mesh 3.0 Part VI: Reliable Datagram Protocol
draft-hallambaker-mesh-rdp-00

Document Type Active Internet-Draft (individual)
Author Phillip Hallam-Baker 
Last updated 2021-04-13
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                 P. M. Hallam-Baker
Internet-Draft                                      ThresholdSecrets.com
Intended status: Informational                             13 April 2021
Expires: 15 October 2021

       Mathematical Mesh 3.0 Part VI: Reliable Datagram Protocol
                     draft-hallambaker-mesh-rdp-00

Abstract

   A presentation layer suitable for use in conjunction with HTTP and
   UDP transports is described.

   https://mailarchive.ietf.org/arch/browse/mathmesh/
   (http://whatever)Discussion of this draft should take place on the
   MathMesh mailing list (mathmesh@ietf.org), which is archived at .

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 15 October 2021.

Copyright Notice

   Copyright (c) 2021 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.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Hallam-Baker             Expires 15 October 2021                [Page 1]
Internet-Draft         Reliable Datagram Protocol             April 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  Protocol Elements . . . . . . . . . . . . . . . . . .   5
       1.1.2.  Application Interface . . . . . . . . . . . . . . . .   7
     1.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   8
       1.2.1.  Network Agility . . . . . . . . . . . . . . . . . . .   8
       1.2.2.  Connection Transfer and Delegation  . . . . . . . . .   9
       1.2.3.  Presence  . . . . . . . . . . . . . . . . . . . . . .   9
       1.2.4.  NAT Transit . . . . . . . . . . . . . . . . . . . . .  10
       1.2.5.  IPv6 Agility  . . . . . . . . . . . . . . . . . . . .  11
       1.2.6.  Tunneling . . . . . . . . . . . . . . . . . . . . . .  12
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .  12
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .  12
     2.2.  Defined Terms . . . . . . . . . . . . . . . . . . . . . .  12
     2.3.  Related Specifications  . . . . . . . . . . . . . . . . .  12
     2.4.  Implementation Status . . . . . . . . . . . . . . . . . .  13
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .  13
     3.1.  Connections . . . . . . . . . . . . . . . . . . . . . . .  15
     3.2.  Ports . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     3.3.  Stream  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       3.3.1.  Transactional stream  . . . . . . . . . . . . . . . .  16
       3.3.2.  Asynchronous stream . . . . . . . . . . . . . . . . .  16
     3.4.  Credentials . . . . . . . . . . . . . . . . . . . . . . .  17
       3.4.1.  Device  . . . . . . . . . . . . . . . . . . . . . . .  17
       3.4.2.  Principal . . . . . . . . . . . . . . . . . . . . . .  17
     3.5.  Datagram Format . . . . . . . . . . . . . . . . . . . . .  18
       3.5.1.  Stream Identifier . . . . . . . . . . . . . . . . . .  18
       3.5.2.  Nonce . . . . . . . . . . . . . . . . . . . . . . . .  18
       3.5.3.  Ciphertext  . . . . . . . . . . . . . . . . . . . . .  19
       3.5.4.  Authentication Tag  . . . . . . . . . . . . . . . . .  19
     3.6.  Packet Format and Packetized Datagrams  . . . . . . . . .  19
       3.6.1.  Packet Header . . . . . . . . . . . . . . . . . . . .  19
       3.6.2.  Flow Control  . . . . . . . . . . . . . . . . . . . .  20
     3.7.  Connection Datagrams  . . . . . . . . . . . . . . . . . .  21
   4.  Connection Establishment and Maintenance  . . . . . . . . . .  21
     4.1.  Key Exchange modes  . . . . . . . . . . . . . . . . . . .  21
       4.1.1.  First Contact . . . . . . . . . . . . . . . . . . . .  22
       4.1.2.  Immediate . . . . . . . . . . . . . . . . . . . . . .  23
       4.1.3.  Deferred Trip . . . . . . . . . . . . . . . . . . . .  23
     4.2.  Ticketed Connection . . . . . . . . . . . . . . . . . . .  24
     4.3.  Connection Forward Secrecy Rekeying . . . . . . . . . . .  24
   5.  Stream Establishment and Maintenance  . . . . . . . . . . . .  24
     5.1.  Stream Creation and Binding . . . . . . . . . . . . . . .  24
     5.2.  Stream Close  . . . . . . . . . . . . . . . . . . . . . .  25
     5.3.  One Time Stream Identifier  . . . . . . . . . . . . . . .  25
     5.4.  Stream Rekey  . . . . . . . . . . . . . . . . . . . . . .  25

Hallam-Baker             Expires 15 October 2021                [Page 2]
Internet-Draft         Reliable Datagram Protocol             April 2021

   6.  Schema  . . . . . . . . . . . . . . . . . . . . . . . . . . .  26
     6.1.  Connection Datagrams  . . . . . . . . . . . . . . . . . .  26
     6.2.  Packet Extensions . . . . . . . . . . . . . . . . . . . .  26
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  26
   11. Informative References  . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   The Reliable Datagram Protocol (RDP) is a lightweight key exchange,
   authentication and encryption protocol that provides a transactional
   presentation when layered over a HTTP transport and transactional and
   streaming presentations when layered over a UDP transport.

   The UDP binding of RDP provides much of the functionality normally
   provided through use of TCP, TLS, HTTP and Web Sockets with
   considerably less complexity.  RDP does not attempt to reproduce all
   the functionality of these protocols, only the functionality required
   by Web Services and streaming applications is provided.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

   Figure 1: Mesh Presentation Layer provides a combination of necessary
             functionality from TCP, TLS, HTTP and Web Sockets.

   As recognized in the design of QUIC, combining these protocols allows
   greater efficiency and security.  But QUIC is the product of one set
   of design choices optimized to meet an important but specific set of
   needs.  RDP makes a different set of choices to meet a different set
   of needs.  A natural consequence of moving TCP functionality from a
   platform capability implemented in the OS kernel to an application
   level resource it that applications are now free to chose the
   transport and security capabilities that best fit their needs rather
   than being limited to a single size fits all.

   The reduction in complexity afforded by combining four protocols into
   one allows entirely new communications patterns to be supported that
   are poorly supported by traditional approaches.  HTTP is built on the
   Remote Procedure Call model of transactions that consist of a single
   request followed by a response.  Using this communication pattern, a
   device attempting to synchronize a local store with a store at a
   remote service is required to periodically poll the service for
   updates:

Hallam-Baker             Expires 15 October 2021                [Page 3]
Internet-Draft         Reliable Datagram Protocol             April 2021

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

          Figure 2: Limiting communications to a request/response
          communication requires inefficient polling for updates.

   RDP allows a client device with this particular requirement to
   subscribe to a continuous stream of updates.  There is no need for
   the device to poll the remote store for updates as it will be
   notified every time an update occurs.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

      Figure 3: RDP supports asynchronous streaming of updates as they
                                   occur.

   While it is possible to achieve the same functionality in TCP, this
   requires that the device and service maintain a TCP connection for
   the duration of the connection.  This consumes communication
   resources and operating system resources.

   As is shown in later sections, the 'blank slate' design approach of
   RDP allows completely new approaches to service discovery, network
   agility, presence, NAT tunneling and many other requirements that are
   critical in modern network use.

1.1.  Background

   Web Services have traditionally made use of HTTP bindings over TCP or
   TLS transports.  While this approach is functional, it is less than
   satisfactory.  The HTTP and TLS stacks are designed to meet the needs
   of Web browsing but fail to provide significant capabilities required
   by a service.  Modern implementations of these stacks are large and
   cumbersome but little of that complexity addresses needs relevant to
   Web Services.

   A basic requirement for a Web Service is the need to authenticate
   requests and the party making them.  In particular, a Web Service
   requires the ability to authenticate the source of a request and
   verify that authentication of the request data is complete before
   acting on it.  As its original name, 'Secure Socket Layer' implies,
   TLS is designed to present an abstract socket layer that hides this
   information from the application layer.  In many large enterprise
   deployments, TLS processing and Web Service transactions are
   performed on separate machines and information from the TLS session
   is only visible to the transaction processor if special provision is
   made.

Hallam-Baker             Expires 15 October 2021                [Page 4]
Internet-Draft         Reliable Datagram Protocol             April 2021

   HTTP provides a wide range of protocol capabilities but almost none
   of this complexity is relevant to Web Services needs.

   *  Providing access to multiple Web Services through a single TCP/IP
      port.

   *  Delineating the beginning and end of request and response data.

   Recognizing these needs, the DARE envelope format was originally
   conceived as a JSON equivalent of the XML Signature and Encryption
   protocols applied to provide message layer security in the WS-
   Security stack.  Consideration of the resource requirements needed to
   verify each transaction request and sign each response led to the
   need for a key exchange mechanism and that this should be separate
   from the Mesh Service Protocol.  This in turn led to the realization
   that in most circumstances, an AEAD scheme such as AES-GCM or AES-CFB
   would provide encryption with the same or less overhead than use of a
   MAC.

   Having taken these considerations into account, a new lightweight
   envelope format was designed to allow authentication and encryption
   of Web Services messages as the payload of HTTP requests and
   responses.  The success of this approach led to the realization that
   the same format could be modified to enable direct binding to UDP,
   allowing provision of HTTP support to be made optional.

1.1.1.  Protocol Elements

   A TCP connection provides a single pair of bidirectional
   communication streams between two devices connected to the network.
   While the TCP connection is symmetric from the application layer
   point of view, the HTTP presentation layer is not.  HTTP limits
   communications to a request/response communication pattern in which
   the initiator device makes all the requests and the responder device
   makes all the responses.

   RDP affords greater communication flexibility requiring distinctions
   to be made between terms which may be used interchangeably in the
   HTTP over TCP/IP case.

   Connection  An RDP connection is a bidirectional relationship between
      a pair of endpoints established through a cryptographic key
      exchange establishing a shared secret called the Connection Origin
      Key.

   Stream  An RDP stream is an individual communication channel
      established within a connection.  An RDP connection comprises one
      or more streams.

Hallam-Baker             Expires 15 October 2021                [Page 5]
Internet-Draft         Reliable Datagram Protocol             April 2021

   Port  An RDP port is a network interface through which data is
      exchanged.  Currently only UDP and HTTP ports are supported.  Each
      end of an RDP Connection accepts packets through one or more
      ports.

   The distinction between connections and streams is analogous to that
   made between processes and threads.  While any task that is performed
   by a separate thread may be performed by a separate process, use of
   threads consumes fewer platform resources and greater convenience to
   the programmer.

   In the TCP/IP model, each stream is bound to a single pair of IP
   port.  In the RDP model, any stream MAY make use of any available
   destination port to send traffic.  This allows Alice to move from her
   home to her car to her office without dropping the connection to her
   conference call.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

     Figure 4: An RDP connection comprises one or more streams and one
                               or more ports.

   New streams may be created at any time by either party in a
   connection for many different reasons:

   *  To establish a client/service relationship to a different Web
      Service.

   *  To establish a new asynchronous streaming relationship

   *  To signal changes to the cryptographic context (e.g., forward
      secrecy rachet operation).

   *  Exhaustion of the datagram counter identifier space.

   *  To make use of traffic analysis avoidance techniques.

   *  To enable datagrams to be sent at different priorities.

   A device connected to three separate Web Services provided by the
   same host establishes a separate stream for each service.  This
   enables the device to present different application-level credentials
   top the different services.  If permitted by the service, separate
   tasks on the same device MAY establish separate streams to the same
   service.  This allows separate threads to wait on transactions taking
   a long time to complete without contention.

Hallam-Baker             Expires 15 October 2021                [Page 6]
Internet-Draft         Reliable Datagram Protocol             April 2021

   Each stream presents a sequence of datagrams spanning one or more
   packets according to a declared characteristic.  The datagram
   represents the unit of payload data that is authenticated and thus
   the unit of payload data that is presented to the calling API.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

     Figure 5: An RDP stream presents a sequence of datagrams, each of
                      which may span multiple packets.

   Two stream characteristics are currently defined, both of which are
   asymmetric.

   Transactional Stream  Each request sent in the forward direction is
      followed by a response returned in the reverse direction.

   Asynchronous Stream  A sequence of frames is received in the forward
      direction as directed by control messages sent in the reverse
      direction.

   Thus, a bidirectional voice call between Alice and Bob requires a
   minimum of two Asynchronous Content streams, from Alice to Bob and
   from Bob to Alice.

1.1.2.  Application Interface

   The traditional TCP/IP programming API exposes only an
   undifferentiated stream of bytes to the application program context.
   Information such as packet latency, packet loss rate, error rate,
   etc. are only available through proprietary platform specific APIs,
   if at all.

   RDP is designed to provide application programs with relevant
   connection information including:

   *  Time since the most recent forward secrecy exchange

   *  Average round trip latency (per port)

   *  Packet loss (per port)

   Providing this information allows applications to adapt to changing
   network conditions.

   *  Forcing a forward secrecy exchange when a participant leaves a
      shared chat context

Hallam-Baker             Expires 15 October 2021                [Page 7]
Internet-Draft         Reliable Datagram Protocol             April 2021

   *  Making use of an outbound port with a different physical network
      connection.

   *  Establishing communication to a different host.

   *  Pre-empt (i.e. abandon) transfer of large datagrams in mid
      transfer.

   The API exposes the following object classes:

   Connection  Reports the connection status, supports creation of new
      Streams.

   Transactional Stream Initiator  Supports the Post method comprising
      sending a request to the service to which the stream is bound and
      waiting for a response.

   Transactional Stream Responder  Is generated on receipt of a service
      request to which it is dispatched to obtain the service response.

   Asynchronous Stream Sender  Allows transmission of a sequence of
      datagrams to a receiver.  Reports stream properties set by the
      receiver.

   Asynchronous Stream Receiver  Receives a continuous sequence of
      datagrams from the sender.  Allows setting of stream properties.

   Datagram  Exposes the packet data relevant transmission information.

   Stream Creation Ticket  A stream creation ticket is a record created
      by an issuer device consisting of a stream identifier, a set of
      network endpoints, a shared secret and the issuer device's
      credential.

   The details of the RDP API are out of scope for this specification.

1.2.  Use Cases

   Despite representing a modest incremental advance on the complexity
   of TCP and a substantial reduction in complexity compared to TLS, RDP
   provides support for a wide range of use cases outside the scope of
   either.

1.2.1.  Network Agility

   The separation of RDP streams from the network ports through which
   they are realized allows network agility to be supported without any
   additional complexity.

Hallam-Baker             Expires 15 October 2021                [Page 8]
Internet-Draft         Reliable Datagram Protocol             April 2021

   For example, Alice joins a conference call from her mobile phone in
   her home office.  When she leaves for work in her car, the connection
   to her conference call is transferred seamlessly from hew home WiFi
   service to her mobile carrier.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

      Figure 6: Alice maintains connection to her conference call when
                    moving from her home to her office.

   The same approach MAY be employed to provide fault tolerance in an
   enterprise server hosting environment.

1.2.2.  Connection Transfer and Delegation

   It is frequently desirable for a device to negotiate delivery of a
   service with one host that will ultimately be delivered by another.
   RDP supports the issue of a 'ticket' credential by a host providing a
   discovery service that MAY be used to establish a connection with the
   host that will deliver the requested service:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

    Figure 7: Connection establishment by means of a discovery service.

   The same capability MAY be applied to enable hosts to direct
   connected devices to seek service from a different host, either
   immediately or in case of service interruption.  This allows for
   greater flexibility in configuring systems to provide fault tolerance
   and to effect load balancing strategies.

1.2.3.  Presence

   Presence is a particular form of connection transfer.  A presence
   service facilitates creation of a voice or video connection between
   the device used by the initiator to make the request to one of the
   multiple receiver devices on which it might be accepted.

   Each receiver device maintains a connection to the presence service
   that is active whenever the receiver device is available to accept
   calls.  To request a connection, the initiator device contacts the
   presence service which determines if the request is authorized and if
   so, returns the ticket and network endpoint information required to
   establish a connection.

Hallam-Baker             Expires 15 October 2021                [Page 9]
Internet-Draft         Reliable Datagram Protocol             April 2021

   For example, Bob's phone connects to the presence service and
   provides a ticket and network endpoint information to enable calls to
   be placed.  When Alice attempts to place a call, her device contacts
   the presence service, which checks that Bob has authorized Alice to
   interrupt her work.  Alice's device uses the information from the
   presence service to perform a forward secrecy operation against Bob's
   phone and thus achieve full end-to-end secure communication.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

          Figure 8: Alice contacts Bob through a presence service.

   Contrawise, when Suzy spammer attempts to contact Bob to tell him the
   warranty on his rocket ship is about to expire, the presence service
   notes that Suzy spammer is not in Bob's contact list and refuses to
   allow the interruption.  Bob's access control policy may allow Suzy
   spammer to make a contact exchange request, but it is rather likely
   that her reputation for wasting people's time will result in that
   request being rejected.

1.2.4.  NAT Transit

   The deployment of Network Address Translation (NAT) devices in the
   network represents a real world constraint that every modern network
   application has to work around if it is to be successful.  NAT
   devices may be broadly regarded as belonging to two distinct
   categories.

   Wide Cone NAT  When a device inside the network attempts to establish
      a UDP connection to a remote device, the NAT selects an outbound
      UDP source port for forwarding.  All inbound UDP packets
      specifying that port are forwarded to that device regardless of
      the source address.

   Narrow Cone NAT + Firewall NAT  All NAT devices that present a more
      restrictive policy.  These include enterprise firewalls that
      require devices inside the network to explicitly request
      forwarding from external UDP ports (pinhole routing).

   Since the protocols used to support NAT devices other than Wide Cone
   are typically proprietary, these are outside the scope of this
   specification.

   One of the many inconveniences of being required to support NAT is
   that the external port binding may change without notice.  In some
   cases, an external port is only kept open for as long as it is in use
   with timeouts of a second or less being common.

Hallam-Baker             Expires 15 October 2021               [Page 10]
Internet-Draft         Reliable Datagram Protocol             April 2021

   Enabling NAT transit during reconfiguration represents a special case
   of network agility.  The network endpoint can change but the stream
   identifiers remain constant.  A change to the NAT configuration
   causes inbound packets to be dropped temporarily but the stream is
   quickly re-established when an outbound packet is sent.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

                   Figure 9: Wide cone NAT configuration.

   The interaction of NAT transit with presence service presents a
   particular concern when interactions between the parties are
   infrequent.

   For example, consider the case in which a digital camera is connected
   to a photo archive on a remote host that is behind a NAT device.
   This would commonly occur in situations in which Alice wants
   photographs to be automatically uploaded to the file storage in her
   house as soon as they are captured.

   Rather than requiring the Archive device to maintain a constant RDP
   stream to every device that might possibly require access, the
   Archive device maintains a constant stream to the presence service
   which can then provide devices it has helped establish a connection
   with the necessary information to resume the stream:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

                      Figure 10: Brokered NAT transit.

   Another important concern is the interaction between network agility
   and NAT transit.  Mobile devices frequently operate inside and
   outside a NAT gated network.  Care is required to ensure that a
   device that establishes a direct connection to another device within
   the same NAT gated local area network can maintain that connection
   when it moves to a different network.

1.2.5.  IPv6 Agility

   RDP makes no distinction between IPv4 and IPv6 transport.  In normal
   circumstances, an application program does not need to be aware of
   either the initiator or receiver's address(es).

   RDP connections MAY be established against either or both
   simultaneously.  RDP is equally tolerant of 4-to-6 and 6-to-4
   transmission gateways.

Hallam-Baker             Expires 15 October 2021               [Page 11]
Internet-Draft         Reliable Datagram Protocol             April 2021

   In the interest of reducing the impact of IPv4 address exhaustion,
   public facing RDP services SHOULD provide discovery and service to
   initiators that only have connection to an IPv6 network.

1.2.6.  Tunneling

   Establishment of an IP tunnel connecting one device to another is
   required for applications such as onion routing and VPN access.

   While the broader requirements of these applications is outside the
   scope of RDP, consideration has been given for allowing this use case
   to be supported without causing 'packet inflation' in which every
   packet submitted as an input results in multiple packets being sent
   over the network.

   Provision for onion routing is likely to be of particular interest.
   The RDP packet format allows for every bit of the UDP payload to be
   either encrypted data or an opaque authentication tag.

   For example, an observer tapping the network at point A, point B or
   point C gains no information that allows them to determine that Alice
   is communicating with Bob. Even correlation of data from all three
   locations provides limited information through the timing of arrival
   and almost none that is likely to be of any benefit to the observer.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

                         Figure 11: RDP Tunnelling.

2.  Definitions

   This section presents the related specifications and standard, the
   terms that are used as terms of art within the documents and the
   terms used as requirements language.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  Defined Terms

2.3.  Related Specifications

Hallam-Baker             Expires 15 October 2021               [Page 12]
Internet-Draft         Reliable Datagram Protocol             April 2021

2.4.  Implementation Status

   The implementation status of the reference code base is described in
   the companion document [draft-hallambaker-mesh-developer].

3.  Architecture

   Data Encoding

   [This part of the specification describes the encodings to be used in
   the next release.  The data encodings in the current reference code
   used to generate the examples do not match.  These should be aligned
   with QUIC where appropriate.  ]

   Encoding at the packet level presents different requirements to those
   at higher levels.  These needs are better met by the compactness
   afforded by a place-value approach than the JSON/JSON-B Tag-Value
   encoding used in the upper layers of the Mesh specifications.

   As at the application layer, the use of nested length encodings is
   avoided on account of the risk that bounds overflow vulnerabilities
   are introduced into applications.

   Integer

   Integer values are presented using the same variable length encoding
   described in section 16 [draft-ietf-quic-transport]

   The first two most significant bits of the first byte are reserved to
   encode the base 2 logarithm of the integer encoding length in bytes.
   The integer value is encoded on the remaining bits, in network byte
   order.

         +=======+========+=============+=======================+
         | 2 Bit | Length | Usable Bits | Range                 |
         +=======+========+=============+=======================+
         | 00    | 1      | 6           | 0-63                  |
         +-------+--------+-------------+-----------------------+
         | 01    | 2      | 14          | 0-16383               |
         +-------+--------+-------------+-----------------------+
         | 10    | 4      | 30          | 0-1073741823          |
         +-------+--------+-------------+-----------------------+
         | 11    | 8      | 62          | 0-4611686018427387903 |
         +-------+--------+-------------+-----------------------+

                                 Table 1

Hallam-Baker             Expires 15 October 2021               [Page 13]
Internet-Draft         Reliable Datagram Protocol             April 2021

   Values do not need to be encoded on the minimum number of bytes
   necessary.

   String

   String values are Unicode strings encoded as a sequence of UTF-8
   bytes preceded by an integer length specifier.

   Binary data

   Binary data consists of a sequence of opaque bytes encoded as the
   sequence of byte values preceded by an integer length specifier.

   Packet Extension List

   Packet extensions MAY be specified in any data section of a datagram.

   Each extension is a tag-length-value sequence:

   Tag  A sequence of 1 to 16 octets, the leading octets of which are in
      the range 0-127 and the final octet of which is in the range
      128-255.

   Length  The number of octets in the Value encoded as an Integer.

   Value  An opaque sequence of the specified number of octets.

   The tag 255 is reserved to signal the end of the packet extension
   list.

   Stream Identifier

   Every RDP packet begins with a *stream identifier*. Stream
   identifiers consist of an opaque sequence of zero to 16 bytes.

   Stream identifiers are used to allow their issuer to distinguish
   packets arriving from different streams in circumstances where the
   stream cannot be inferred from the port.  Initiators and responders
   both issue stream identifiers for their own use during Connection
   Establishment.  Additional stream identifiers MAY be issued as a
   means of defeating some forms of traffic analysis attack.

   The semantics and encoding of stream identifiers including
   determining the length of the stream identifier is sole concern of
   the issuer which MUST ensure that it can correctly interpret the
   stream identifiers they issue for streams received on a specified
   port without ambiguity.

Hallam-Baker             Expires 15 October 2021               [Page 14]
Internet-Draft         Reliable Datagram Protocol             April 2021

   Stream identifiers are issued as binary data sequences specified in
   Connection Establishment packets and as Packet Extensions in Data
   Packets.

   Issuers MUST accept every stream identifier issued as a valid
   identifier for that stream for the lifetime of the connection in
   which the stream was created.

3.1.  Connections

   An RDP connection is a bidirectional relationship between two devices
   secured by a _Connection Shared Secret_ established through a key
   agreement between the devices.  Once established a connection MAY be
   persisted for as long as the devices are willing to assign memory
   resources at each end.  Unlike TCP connections, maintaining an RDP
   connection does not require communication overhead (but maintaining a
   NAT transit capability might).

3.2.  Ports

   An RDP port is a synonym for network endpoint.  Only ports at which
   traffic is received are of concern.

   Currently two port types are defined:

   HTTP Web Service Endpoint  A port type that is limited to supporting
      transactional streams

   UDP Network Endpoint  A network endpoint that receives Internet
      communications directed at a particular IP Address and Port.

   The collection of ports associated with a connection MAY change over
   time.  Connections MAY make use of multiple ports simultaneously.

   For example, a virtual reality streaming game might establish a
   single connection to a game coordination host and make use of
   separate ports to achieve the desired latency and bandwidth
   characteristics.

3.3.  Stream

   An RDP stream is an asymmetric bidirectional channel that transmits a
   sequence of datagrams according to a defined characteristic.  Two
   characteristics are currently defined:

   Transactional Stream

   Asynchronous Stream

Hallam-Baker             Expires 15 October 2021               [Page 15]
Internet-Draft         Reliable Datagram Protocol             April 2021

   The stream characteristic and cryptographic parameters of a stream
   are immutable for the lifetime of a stream.  To effect a forward
   secrecy exchange, a new stream is created and the existing stream
   closed.

   Each stream is separately identified by one or more Stream
   Identifiers at each end specified by the party that receives data at
   that end.

   Stream identifiers MUST be unique for the lifetime of a stream.
   Stream identifiers MAY be reused after the stream has been closed.

3.3.1.  Transactional stream

   Streams with a transactional characteristic are used to engage in a
   request/response communication pattern with a service specified
   during stream negotiation:

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

              Figure 12: Transactional stream characteristic.

   Each transactional stream is asymmetric, but a connection MAY contain
   separate transactional streams going in each direction.

   For example, in a notary application, two hosts might offer notary
   service to the other through the same connection but through separate
   streams.

3.3.2.  Asynchronous stream

   Streams with an asynchronous characteristic deliver a stream of
   datagrams created by the stream originator to the stream receiver.
   Datagrams carrying control information sent in the reverse direction
   MAY be used to control the flow.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

               Figure 13: Asynchronous stream characteristic.

   Asynchronous streams MAY be used for intermittent communications as
   well as real time streaming media.  For example, a network server
   might use an asynchronous stream to log transaction data to another
   machine.

Hallam-Baker             Expires 15 October 2021               [Page 16]
Internet-Draft         Reliable Datagram Protocol             April 2021

3.4.  Credentials

   RDP follows the Mesh approach of using separate credentials for
   devices and principals.

   For example, the service offered by provider (@provider) is delivered
   by a fault tolerant collection of three separate hosts.  Alice
   (@alice) can access those services through any one of her four
   personal devices.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

                 Figure 14: Mesh Layered Credential Model.

   RDP makes use of the keys specified in device credentials to perform
   key agreement and enables user and service credential(s) to be
   presented for authentication and authorization of the principals.

3.4.1.  Device

   An RDP device credential is a credential that specifies a public key
   of one of the supported key agreement algorithms.  Two forms of
   device credential are currently defined:

   *  Raw Key (e.g.  X.448 key)

   *  Mesh Device Connection Assertion.

   It might well be the case that it is more appropriate to pass the
   Device Connection Assertion as part of the Principal Credential.

3.4.2.  Principal

   Principal credentials are used to authenticate and authorize a device
   to act on behalf of the specified principal.

   Presentation of Principal Credentials MAY be performed at the
   application layer (i.e. by means of credentials carried in an RDP
   payload) or as an RDP Packet Extension when a *stream service
   binding* is requested.

   In either case, validation of Principal Credentials is an application
   concern and thus outside the scope of RDP.

Hallam-Baker             Expires 15 October 2021               [Page 17]
Internet-Draft         Reliable Datagram Protocol             April 2021

   Different streams MAY involve the use of different principal
   credentials.  Alice might be authenticated through her Mesh profile
   in one stream, a PKIX client cert bound to a smartcard in another and
   a SAML authorization token in a third.

3.5.  Datagram Format

   An RDP Datagram is by definition the smallest unit of payload data
   passed from the application layer to the presentation layer or vice
   versa.  A Datagram MAY be as large as a complete frame of 4K or 8K
   video or as small as a single key press or movement of a game
   controller.

   Use of HTTP ports places no upper limit on the size of an RDP
   Datagram but UDP Datagrams are limited to a maximum number of
   packets.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

                        Figure 15: Datagram format.

   Requests and Responses MAY be split into multiple Datagrams.  In this
   case every datagram except the final one is marked with the
   continuation flag.

   APIs MAY choose to present the individual datagrams to applications
   or reconstruct the complete datagram according to what best fits
   their circumstances.

3.5.1.  Stream Identifier

   A sequence of bytes as specified by the recipient during
   establishment of the connection or stream.

3.5.2.  Nonce

   The keys used to encrypt and authenticate each datagram are derived
   by applying a key derivation function to the Stream Primary Key, the
   Stream identifier and a nonce value specified in the datagram itself.

   The nonce is the value of a monotonically increasing datagram
   counter.

Hallam-Baker             Expires 15 October 2021               [Page 18]
Internet-Draft         Reliable Datagram Protocol             April 2021

3.5.3.  Ciphertext

   Ciphertext is the plaintext payload encrypted under a key derived
   from the active primary key and the initialization vector.  Keys are
   only used to encrypt a single Datagram or continuation Datagram.

   Plaintext of a data Datagram consists of a list of packet extension
   entries followed by a payload followed by zero padding.

3.5.4.  Authentication Tag

   Associated data is entire Datagram from the first byte to the start
   of the Initialization vector.

3.6.  Packet Format and Packetized Datagrams

   UDP provides unreliable transport of datagrams no larger than the
   maximum IP payload size of 64KB.  In practice the largest datagram
   payload is typically limited to no more than 1260 bytes because the
   Ethernet specification is stuck in the Middle Ages.  It is thus
   necessary to split large Datagrams into multiple packets and provide
   sufficient control information that the receiver can reassemble the
   packets in the right order and request any lost packets be re-sent.

   Similar constraints are imposed by a wide range of wireless and wired
   physical and network transports.

   When using Packetized Datagrams, each packet in the Datagram
   specifies the stream identifier and a packet identifier.  Only the
   last packet in the Datagram presents an authentication tag.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

         Figure 16: Datagram packetization across multiple packets.

   RDP Datagram packetization is analogous to IP packet fragmentation
   except that it actually works.

3.6.1.  Packet Header

   The packet header block appears immediately after the Stream
   identifier.  It specifies the information used to reassemble packets
   in order to form a complete datagram, to acknowledge packet receipt,
   and other control information.

   Datagram index  Integer counter beginning at 0 and incremented by 1
      for each partial or final datagram sent in the stream.

Hallam-Baker             Expires 15 October 2021               [Page 19]
Internet-Draft         Reliable Datagram Protocol             April 2021

   Packet count  Integer specifying the number of packets in the
      datagram

   Packet sent index  Integer counter beginning at 0 and incremented by
      1 for each packet sent wrapping at 15 bits.

   Retransmit index  Integer incremented each time a packet is resent.
      Since the resent data is identical, it is only necessary to
      acknowledge data once even if multiple copies are received.

   Continuation Datagram flag.  Integer containing flags information.
      The low order bit (0) is 0 for a partial datagram and 1 for a
      final datagram.

   Received index  Integer index of the first packet being acknowledged.

   Acknowledgements  Bitfield containing the value 1 for packets that
      have been received and 0 otherwise.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

                   Figure 17: Flow control packet header

3.6.2.  Flow Control

   TCP flow control is designed to meet the needs of the day.  Modern
   networks have very different needs.

   Congestion avoidance is still important and implementations MUST take
   steps to avoid overburdening network resources.

   May require additional packets that only contain flow control info.
   This MAY be used to communicate One time Stream IDs.

   Congestion control limits MAY be specified for the connection as a
   whole and for individual ports.  In situations where multiple
   Internet connections are available, applications MUST enforce flow
   control limits on each port.

   [Here describe the feedback characteristics determined through
   experimentation.]

Hallam-Baker             Expires 15 October 2021               [Page 20]
Internet-Draft         Reliable Datagram Protocol             April 2021

3.7.  Connection Datagrams

   Connection Datagrams are used during the key exchange used to
   establish a connection.  Unlike data Datagrams in which have a single
   data section, all of which is encrypted, connection Datagrams may
   contain three separate types of data section:

   Plaintext data  Unencrypted data section.  This is used to pass the
      information needed to perform the 'mezzanine' key exchange to the
      responder's credential and to present and respond to challenges.

   Mezzanine data  Data encrypted under 'mezzanine' key exchange
      authenticated by the responder's credential alone.  This is used
      to pass information related to the initiator credential.

   Ciphertext data  Data encrypted under the mutual key exchange
      authenticated to the credentials of the initiator and the
      responder.

   The "ClientCompleteDeferred" Datagram contains all three data
   sections.  The ciphertext data section is encapsulated inside the
   Mezzanine data section and is thus encrypted twice.  Only the
   Mezzanine section is padded.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

                   Figure 18: Connection Datagram Format.

   A connection Datagram MAY contain a payload.  This is always carried
   in the last data section.

   Connection Datagrams that only contain plaintext data MUST NOT
   contain confidential data.  This requirement may be enforced in a
   future revision of the specification by limiting use to a 'service
   discovery' protocol.

4.  Connection Establishment and Maintenance

4.1.  Key Exchange modes

   Three key exchange mechanisms are supported.  The choice of mechanism
   depending on whether the initiator knows the credentials of the host
   and on whether the host is willing to perform a key exchange
   operation without challenge:

   First Contact  The only key exchange mode supported when the client

Hallam-Baker             Expires 15 October 2021               [Page 21]
Internet-Draft         Reliable Datagram Protocol             April 2021

      does not know the responder credential.  This is a two-round
      exchange in which the payload of the first round is limited to
      plaintext data.

   Immediate  A key exchange in which the initiator knows the responder
      and offers a complete mutual key exchange in the first message.
      If accepted by the responder, this exchange requires only a single
      round which MAY carry ciphertext payload.

   Deferred  A variation of the zero round trip exchange in which the
      responder returns a plaintext challenge to the initiator instead
      of immediately accepting the key exchange.  This permits
      mitigation of denial-of-service attacks.

   Unlike other RDP interactions, the response to a connection
   establishment request MUST be returned to the network endpoint from
   which it was received.

   The "InitiatorHello" datagram and "InitiatorExchange" datagram are
   special in that they MUST be presented in a single packet and MUST
   use the Stream Identifier consisting of sixteen zero bytes.

4.1.1.  First Contact

   The first contact exchange comprises two round trips:

   "InitiatorHello"  [Plaintext] Stream ID, Payload

   "ResponderChallenge"  [Plaintext] Responder credential,

      [Plaintext] Set of responder ephemeral keys

      [Plaintext] Challenge

      [Plaintext] Stream ID, Payload

   "InitiatorComplete"  [Plaintext] Responder key identifier

      [Plaintext] Initiator Ephemeral

      [Plaintext] Response to Challenge

      [Mezzanine] Initiator Credential + Initiator key identifier

      [Encrypted] Stream ID, Payload

   "Data"  [Encrypted] Stream ID, Payload

Hallam-Baker             Expires 15 October 2021               [Page 22]
Internet-Draft         Reliable Datagram Protocol             April 2021

   For example...

   Key exchange example TBS

   Since the InitiatorHello and InitiatorComplete payloads are always
   sent _en clair_, these are only available for use in querying the
   public capabilities exposed by the responder.  For example, the set
   of services offered.

4.1.2.  Immediate

   The immediate exchange comprises a single round trip:

   "InitiatorExchange"  [Plaintext] Responder key identifier

      [Plaintext] Initiator Ephemeral

      [Mezzanine] Initiator Credential + Initiator key identifier

      [Mezzanine] Stream ID, Payload

   "ResponderComplete"  [Mezzanine] Initiator key identifier

      [Mezzanine] Responder Ephemeral

      [Encrypted] Stream ID, Payload

   Note that in this case the initial initiator payload is only
   encrypted, it is only authenticated to the responder since the
   responder has not contributed any form of challenge data to the
   initiator.

   For example...

   Key exchange example TBS

4.1.3.  Deferred Trip

   The deferred exchange is an alternative to the immediate exchange
   that is performed at the option of the responder.  Instead of
   accepting the connection request immediately, the initiator defers
   acceptance of the request until the initiator has given a correct
   response to a challenge:

   "InitiatorExchange"  (As for the Immediate case)

   "ResponderDefer"  [Plaintext] Responder credential,

Hallam-Baker             Expires 15 October 2021               [Page 23]
Internet-Draft         Reliable Datagram Protocol             April 2021

      [Plaintext] Set of responder ephemeral keys

      [Plaintext] Challenge

      [Plaintext] Stream ID, Payload

   "InitiatorComplete"  (As for the First Contact case)

   Key exchange example TBS

4.2.  Ticketed Connection

   For supporting presence and discovery services.

   Ticket specifies a shared secret, session ID, network end point.

   Example discovery, Alice's device connects to the provider's
   discovery service, is authenticated and receives a ticket to connect
   to a specific host.  This allows a connection to be established to
   that host without the need to perform a connection key exchange.

   Example presence, Alice wants to talk to Bob, contacts his discovery
   service, gets a ticket back allowing Bob to establish a direct,
   encrypted connection.

   In either case, a client SHOULD perform a rekey operation as
   indicated by requirements for perfect forward secrecy, security
   policy, yada yada.

4.3.  Connection Forward Secrecy Rekeying

   Rekeying is only necessary to provide forward secrecy.  The data
   encrypted under a single symmetric key is a small fraction of the
   maximum.  But a connection that persists for several years still
   represents a liability.

   [Should we reintroduce the mezzanine packet so we can use the
   remainder of a packet without rekeying?]

   [Packet extension contains the rekey data]

5.  Stream Establishment and Maintenance

5.1.  Stream Creation and Binding

   When a stream is created, it is typically bound to a service.

Hallam-Baker             Expires 15 October 2021               [Page 24]
Internet-Draft         Reliable Datagram Protocol             April 2021

   A host might offer Mesh, Callsign and Discovery services.  After
   connecting to the host, a device requests a stream to each of the
   services in turn.  Each stream MAY be separately authorized.

5.2.  Stream Close

   Streams MAY be closed when no longer needed.  This allows reuse of
   the stream identifier(s) associated with the stream provided that no
   ambiguity can arise.

5.3.  One Time Stream Identifier

   In cases where defeating traffic analysis is of particular
   importance, a recipient MAY assign multiple identifiers to a single
   stream.

   For example, a device connecting issues a set of three stream
   identifiers to a service.  The device receives two packets which are
   acknowledged together with a further three one-time use identifiers.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

               Figure 19: Use of one time Stream identifiers.

   A block cipher MAY be employed to construct one time IDs that require
   no state to interpret.  The issuer generates a fixed symmetric key.
   To create a new one time StreamID, the issuer encrypts a block
   containing a salt (e.g. a unique sequence number) and the stream ID
   to which the encrypted Id is to be mapped.

   To interpret a one time ID, the service simply decrypts the encrypted
   form to recover the original stream ID, the salt is ignored.

   Note that when using this approach it is absolutely critical that the
   cipher used is a block cipher and not a stream cipher or a block
   cipher used in a streaming mode (e.g.  AES-GCM).

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-rdp-00.html for artwork.)

        Figure 20: Use of a block cipher to create stateless stream
                                identifiers.

5.4.  Stream Rekey

   Rekeying the stream requires us to change the stream ID.  No other
   characteristics of the stream are changed.

Hallam-Baker             Expires 15 October 2021               [Page 25]
Internet-Draft         Reliable Datagram Protocol             April 2021

   Stream can rekey by specifying its own rekey data or say 'use the
   same keydata as this stream Id'.

   Thus, a connection with four separate streams only needs to perform
   one rekey to refresh the crypto for all four.

6.  Schema

6.1.  Connection Datagrams

6.2.  Packet Extensions

7.  Security Considerations

8.  IANA Considerations

   This document requires no IANA actions.

9.  Acknowledgements

10.  Normative References

   [draft-ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", Work in Progress, Internet-Draft,
              draft-ietf-quic-transport-34, 14 January 2021,
              <https://tools.ietf.org/html/draft-ietf-quic-transport-
              34>.

   [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/rfc/rfc2119>.

11.  Informative References

   [draft-hallambaker-mesh-developer]
              Hallam-Baker, P., "Mathematical Mesh: Reference
              Implementation", Work in Progress, Internet-Draft, draft-
              hallambaker-mesh-developer-10, 27 July 2020,
              <https://tools.ietf.org/html/draft-hallambaker-mesh-
              developer-10>.

Hallam-Baker             Expires 15 October 2021               [Page 26]