Delay-Tolerant Networking UDP Convergence Layer Protocol

1.3. Definitions Specific to the UDPCL Protocol

This section contains definitions specific to the UDPCL protocol.¶

UDPCL Entity:

This is the notional UDPCL application that initiates UDPCL transfers. This design, implementation, configuration, and specific behavior of such an entity is outside of the scope of this document. However, the concept of an entity has utility within the scope of this document as the container and initiator of transfers. The relationship between a UDPCL entity and UDPCL sessions is defined as follows:¶

• A UDPCL Entity MAY actively perform any number of transfers and should do so whenever the entity has a bundle to forward to another entity in the network.¶
• A UDPCL Entity MAY support zero or more passive listening elements that listen for transfers from other entities in the network, including non-unicast transfers.¶

These relationships are illustrated in Figure 2. For the remainder of this document, the term "entity" without the prefix "UDPCL" refers to a UDPCL entity.¶

UDP Conversation:

This refers to datagrams exchanged between two network peers, with each peer identified by a (unicast IP address, UDP port) tuple. Because UDP is connectionless, there is no notion of a conversation being "opened" or "closed".¶

Transfer:

This refers to the procedures and mechanisms for conveyance of an individual bundle from one entity to one or more destinations. This version of UDPCL includes a fragmentation mechanism to allow transfers which are larger than the allowable UDP datagram size.¶

Transmit:

This refers to a transfer outgoing from an entity as seen from that transmitting entity.¶

Receive:

This refers to a transfer incoming to an entity as seen from that receiving entity.¶

+----------------------------------------+
|              UDPCL Entity              |
|                                        |      +----------------+
|   +--------------------------------+   |      |                |-+
|   | Actively Initiated Transfer #1 +--------->| Other          | |
|   +--------------------------------+   |      | UDPCL Entity's | |
|                  ...                   |      | Passive        | |
|   +--------------------------------+   |      | Listener       | |
|   | Actively Initiated Transfer #n +--------->|                | |
|   +--------------------------------+   |      +----------------+ |
|                                        |       +-----------------+
|      +---------------------------+     |
|      | +---------------------------+   |      +----------------+
|      | | Optional Passive          |   |      |                |-+
|      +-| Listener(s)               +<---------+ Other          | |
|        +---------------------------+   |      | UDPCL Entity's | |
|                                 ^      |      | Active         | |
|                                 |      |      | Initiator(s)   | |
|                                 +-------------|                | |
+----------------------------------------+      +----------------+ |
                                                 +-----------------+

2.1. Convergence Layer Services

This version of the UDPCL provides the following services to support the over-laying Bundle Protocol agent. In all cases, this is not an API definition but a logical description of how the CL can interact with the BP agent. Each of these interactions can be associated with any number of additional metadata items as necessary to support the operation of the CL or BP agent.¶

Begin Transmission:

The principal purpose of the UDPCL is to allow a BP agent to transmit bundle data to one or more other entities. The receiver of each transfer is identified by an (destination) IPv4 or IPv6 address and a UDP port number (see Section 3 for details). The CL does not necessarily perform any transmission queueing, but may block while transmissions are being processed at the UDP layer. Any queueing of transmissions is the obligation of the BP agent.¶

Transmission Started:

The UDPCL entity indicates to the BP agent when a bundle transmission begins sending UDP datagrams. Once started, there is no notion of a UDPCL transmission failure; a BP agent has to rely on bundle-level status reporting to track bundle progress through the network. Because of potential queueing or DTLS setup time, this may be delayed from the BP agent providing the bundle-to-transmit.¶

Transmission Finished:

The UDPCL entity indicates to the BP agent when a bundle has been fully transmitted. This is not a positive indication that any next-hop receiver has either received or processed the transfer.¶

Reception Started:

The UDPCL entity indicates to the BP agent when a bundle transfer has begun, which may include information about the total size of a fragmented transfer.¶

Reception Success:

The UDPCL entity indicates to the BP agent when a bundle has been fully transferred from a peer entity. The transmitter of each transfer is identified by an (source) IP address and a UDP port number (see Section 3 for details).¶

Reception Failure:

The UDPCL entity indicates to the BP agent on certain reasons for reception failure, notably upon an unfinished transfer timeout (see Section 3.4.2).¶

Attempt DTLS Session:

The UDPCL allows a BP agent to preemptively attempt to establish a DTLS session with a peer entity (see Section 3.5). Each session attempt can send a different set of session negotiation parameters as directed by the BP agent.¶

Close DTLS Session:

The UDPCL allows a BP agent to preemptively close an established DTLS session with a peer entity. The closure request is on a per-session basis.¶

DTLS Session State Changed:

The UDPCL entity indicates to the BP agent when a DTLS session state changes. The possible DTLS session states are defined in [RFC6347].¶

2.2. PKIX Environments and CA Policy

This specification gives requirements about how to use PKIX certificates issued by a Certificate Authority (CA), but does not define any mechanisms for how those certificates come to be. The UDPCL uses the exact same mechanisms and makes the same assumptions as TCPCL in Section 3.4 of [I-D.ietf-dtn-tcpclv4].¶

2.3. Fragmentation Policies

It is a implementation matter for a sending entity to determine the path maximum transmit unit (MTU) to be used as a target upper-bound UDP datagram size. Some mechanisms to perform MTU discovery are defined in [RFC8899]. All IP packets sent by a UDPCL entity SHOULD have the "don't fragment" bit set to allow detection of path MTU issues.¶

The priority order of fragmentation is the following:¶

1. When possible, bundles too large to fit in one path-MTU-sized packet SHOULD be fragmented at the BP layer. Bundle payload fragmentation does not help a large bundle if extension blocks are a major contributor to bundle size, so in some circumstances BP layer fragmentation will not reduce the bundle size sufficiently. It is outside the scope of UDPCL to manage BP agent fragmentation policies; bundles are received from the BP agent either already fragmented or not.¶
2. Bundles too large to fit in one path-MTU-sized packet SHALL be fragmented as a UDPCL transfer (see Section 3.4.2). Fragmentation at this level treats bundle transfers as opaque data, so it is independent of bundle block sizes or counts.¶
3. All IP packets larger than expected path MTU SHALL be fragmented by the transmitting entity to fit within one path MTU. Because of the issues listed in Section 3.2 of [RFC8085], it is best to avoid IP fragmentation as much as possible.¶

A UDPCL entity SHOULD NOT proactively drop an outgoing transfer due to datagram size. If intermediate network nodes drop IP packets it is an implementation matter to receive network feedback.¶

3.3. UDPCL Messaging

The lower layer of UDPCL communication is individual-datagram messaging. For backward compatibility with [RFC7122], UDPCL has no explicit message type identifier. The message type is inferred by the inspecting the data contents according to the following rules:¶

The message type is inferred by the inspecting the data contents according to the following rules:¶

Keepalive:

Keepalive data SHALL be a total of four octets all with value 0x00. Data with a leading octet value of 0x00 SHALL be treated as keepalive.¶

Extension Map:

All UDPCL extensions SHALL be contained in a CBOR map in accordance with the definitions of Section 3.4. The encoded Extension Map SHALL NOT have any CBOR tags. Data with a leading octet value indicating CBOR map (major type 5) SHALL be treated as an Extension Map.¶

Unframed Bundle:

Bundles can be transmitted outside of a (fragmented or not) Transfer item. This provides backward compatibility with [RFC7122] and a allows a trivial use of UDPCL which is just embedding an encoded bundle in a UDP datagram. The encoded bundle is one of the following:¶

BPv6 Bundle:

All encoded BP version 6 bundles begin with the version identifier octet 0x06 in accordance with [RFC5050]. Data with a leading octet value of 0x06 SHALL be treated as a BPv6 bundle.¶

BPv7 Bundle:

All encoded BP version 7 bundles begin with a CBOR array head in accordance with [I-D.ietf-dtn-bpbis]. Data with a leading octet value indicating CBOR array (major type 4) SHALL be treated as a BPv7 bundle.¶

BPv7 bundles transmitted via UDPCL SHALL NOT include any leading CBOR tag. If the BP agent provides bundles with such tags the UDPCL entity SHALL remove them.¶

DTLS Record:

In addition to the UDPCL specific messaging, immediately after a DTLS Initiation (see Section 3.4.1) the DTLS handshake sequence will begin. Data with a leading octet value of 0x16 SHALL be treated as a DTLS handshake record in accordance with Section 4.1 of [RFC6347].¶

If the datagram with the DTLS Initiation extension is not received by an entity, the entity SHOULD still detect the DTLS handshake records and start the handshake sequence at that point. Data with a leading octet value of 0x17--0x19 SHALL be treated as a DTLS sequencing failure; DTLS non-handshake records should never be seen by the UDPCL messaging layer.¶

A summary of how a receiving UDPCL entity can interpret the first octet of a datagram is listed in Table 1. When inspecting using CBOR major types, the range of values is caused by the CBOR head encoding of [RFC8949].¶

3.4. UDPCL Extension Items

Extensions to UDPCL are encoded per-datagram in a single CBOR map as defined in Section 3.3. Each UDPCL extension item SHALL be identified by a unique integer (the Extension ID) used as a key in the Extension Map. Extension ID assignments are listed in Section 6.2.¶

Unless prohibited by particular extension type requirements, a single Extension Map MAY contain any combination of extension items. Receivers SHALL ignore extension items with unknown Extension ID and continue to process known extension items.¶

The following subsections define the initial UDPCL extension types.¶

3.5. UDPCL Security

This version of the UDPCL supports establishing a DTLS session within an existing UDP conversation. When DTLS is used within the UDPCL it affects the entire conversation.¶

Once established, the lifetime of a DTLS session SHALL be bound by the DTLS session ticket lifetime or either peer sending a Closure Alert record.¶

Subsequent DTLS session attempts to the same passive entity MAY attempt to use the DTLS session resumption feature. There is no guarantee that the passive entity will accept the request to resume a DTLS session, and the active entity cannot assume any resumption outcome.¶

5.3. Threat: Transport Security Stripping

When security policy allows non-DTLS messaging, UDPCL does not protect against active network attackers. It is possible for a on-path attacker to drop or alter packets containing Extension Map and/or DTLS handshake records, which will cause the receiver to not negotiate a DTLS session. This leads to the "SSL Stripping" attack described in [RFC7457].¶

When DTLS is available on an entity, it is strongly encouraged that the security policy disallow non-DTLS messaging for unicast purposes. This requires that the DTLS handshake occurs before any other UDPCL messaging, regardless of the policy-driven parameters of the handshake and policy-driven handling of the handshake outcome.¶

One mechanism to mitigate the possibility of DTLS stripping is the use of DNS-based Authentication of Named Entities (DANE) [RFC6698] toward the passive peer. This mechanism relies on DNS and is unidirectional, so it doesn't help with applying policy toward the active peer, but it can be useful in an environment using opportunistic security. The configuration and use of DANE are outside of the scope of this document.¶

The negotiated use of DTLS is identical behavior to STARTTLS use in [RFC2595], [RFC4511], and others.¶

5.5. Threat: Untrusted End-Entity Certificate

The profile in Section 3.5.2 uses end-entity certificates chained up to a trusted root CA. During DTLS handshake, either entity can send a certificate set which does not contain the full chain, possibly excluding intermediate or root CAs. In an environment where peers are known to already contain needed root and intermediate CAs there is no need to include those CAs, but this has a risk of an entity not actually having one of the needed CAs.¶

5.7. Threat: BP Node Impersonation

The UDPCL does not provide any guarantees of or binding to the source of transferred bundles.¶

One mitigation is to use the block integrity mechanisms defined in [I-D.ietf-dtn-bpsec] with a security context which provides node identity binding.¶

5.9. Mandatory-to-Implement DTLS

Following IETF best current practice, DTLS is mandatory to implement for all UDPCL implementations but DTLS is optional to use for a any given transfer. The recommended configuration of Section 3.4.1 is to always attempt DTLS, but entities are permitted to disable DTLS based on local configuration. The configuration to enable or disable DTLS for an entity or a session is outside of the scope of this document. The configuration to disable DTLS is different from the threat of DTLS stripping described in Section 5.3.¶

5.10. Alternate Uses of DTLS

This specification makes use of PKIX certificate validation and authentication within DTLS. There are alternate uses of DTLS which are not necessarily incompatible with the security goals of this specification, but are outside of the scope of this document. The following subsections give examples of alternate DTLS uses.¶

5.11. Predictability of Transfer IDs

The only requirement on Transfer IDs is that they are unique from the transmitting peer only. The trivial algorithm of the first transfer starting at zero and later transfers incrementing by one causes absolutely predictable Transfer IDs. Even when UDPCL is not DTLS secured and there is a on-path attacker altering UDPCL messages, there is no UDPCL feedback mechanism to interrupt or refuse a transfer so there is no benefit in having unpredictable Transfer IDs.¶

6.1. Port Number

Within the port registry of [IANA-PORTS], UDP port number 4556 has been previously assigned as the default port for the UDP convergence layer in [RFC7122]. This assignment to UDPCL is unchanged, but the assignment reference is updated to this specification. There is no UDPCL version indication on-the-wire but this specification is a superset of [RFC7122] and is fully backward compatible. The related assignment for DCCP port 4556 (registered by [RFC7122]) is unchanged.¶

6.2. UDPCL Extension Types

EDITOR NOTE: sub-registry to-be-created upon publication of this specification.¶

IANA will create, under the "Bundle Protocol" registry [IANA-BUNDLE], a sub-registry titled "Bundle Protocol UDP Convergence-Layer Extension Types" and initialize it with the contents of Table 3. For positive code points the registration procedure is Specification Required. Negative code points are reserved for use on private networks for functions not published to the IANA.¶

Specifications of new extension types need to define the CBOR item structure of the extension data as well as the purpose and relationship of the new extension to existing session/transfer state within the baseline UDPCL sequencing. Receiving entities will ignore items with unknown Extension ID, and that behavior needs to be considered by new extension types.¶

Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious).¶