Delay-Tolerant Networking UDP Convergence Layer Protocol

1.4. 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" and some conversations are uni-directional.¶

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 |--------->|                | |
|   |                                |          |                | |
|   |         Sender Listen          |<---------|                | |
|   +--------------------------------+   |      +----------------+ |
|                                        |       +-----------------+
|      +---------------------------+     |
|      | +---------------------------+   |      +----------------+
|      | | 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.5.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.1 and Section 3.7). 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].¶

Begin Sender Listen:

The UDPCL allows a BP agent to indicate when packets on a particular address-and-port is listened for (see Section 3.5.3). The Sender Listen interval is configurable for each peer address-and-port.¶

End Sender Listen:

The UDPCL allows a BP agent to indicate when packets on a particular address-and-port are no longer be accepted.¶

Sender Listen Received:

The UDPCL entity indicates to the BP agent when a Sender Listen extension has been received from a peer. The Sender Node ID, if present, is part of this indication.¶

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 (PMTU) to be used as a target upper-bound UDP datagram size. Some techniques 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 PMTU issues.¶

The priority order of fragmentation is the following:¶

1. When possible, bundles too large to fit in one PMTU-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 PMTU-sized packet SHALL be fragmented as a UDPCL transfer (see Section 3.6). 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 PMTU SHALL be fragmented by the transmitting entity to fit within one PMTU. Because of the issues listed in Section 3.2 of [RFC8085] and [RFC8900], 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 (e.g. ICMP Packet Too Big).¶

3.1. IP Addressing

The earlier UDPCL specification in [RFC7122] did not include guidance on IP addressing, interface sourcing, or potential use of multicast, though the architecture of [RFC4838] explicitly includes multicast and anycast as expected network modes.¶

The BP agent determines the mapping from destination EID to next-hop CL parameters, including transfer destination address and transfer source interface. Some EIDs represent unicast destinations and others non-unicast destinations as defined in Section 4.2.5.1 of [I-D.ietf-dtn-bpbis]. The unicast-ness of an EID does not necessarily correspond with the unicast-ness, as some bundle routing schemes involve attempting multiple parallel paths to a unicast endpoint.¶

For unicast transfers to a single node, the destination address SHALL be a non-multicast IPv4 or IPv6 address (which does include link-local addresses). For unicast transfers, the source interface address MAY be supplied by the BP agent or otherwise determined by the operating system IP routing. When performing unicast transfers, a UDPCL entity SHOULD require DTLS use (see Section 3.7) or restrict the network to one protected by IPsec or some other under-layer security mechanism (e.g., a virtual private network).¶

For multicast transfers to one or more nodes, the destination address SHALL be a multicast IPv4 [IANA-IPv4-MCAST] or IPv6 [IANA-IPv6-MCAST] address. For multicast transfers, the source interface address MUST be supplied by the BP agent rather than inferred by the UDPCL entity.¶

3.2. UDP Header

Destination port number 4556 has been assigned by IANA [IANA-PORTS] as the Registered Port number for the UDP convergence layer and SHALL be used as a default. Other destination port numbers MAY be used per local configuration. Determining a passive entity's destination port number (if different from the registered UDPCL port number) is up to the implementation.¶

Any source port number MAY be used for UDPCL transfers. Typically an operating system assigned number in the UDP Ephemeral range (49152-65535) is used. For repeated messaging to the same destination address-and-port, the active entity SHOULD reuse the same source address-and-port. Reusing source address-and-port allows simplifies network monitoring and analysis and also enables bi-directional messaging as defined in Section 3.5.3.¶

3.3. UDPCL Packets

The lowest layer of UDPCL communication are individual-datagram packets. To exchange UDPCL data, an active entity SHALL transmit a UDP datagram to a listening passive entity in accordance with [RFC0768], typically by using the services provided by the operating system. For backward compatibility with [RFC7122], UDPCL has no explicit message type identifier.¶

Each UDP datagram SHALL contain one or more UDPCL message as defined in Section 3.4. Each type of message defines additional restrictions on how it may be used in a packet.¶

The following are special cases of UDPCL packet uses.¶

Unframed Transfer:

An unframed transfer packet SHALL consist of a single encoded BPv6 or BPv7 bundle with no padding. 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.¶

Keepalive

A keepalive packet SHALL consist of exactly four octets of padding with no preceding message. This behavior maintains backward compatibility with [RFC7122].¶

3.4. UDPCL Messages

The middle layer of UDPCL communication are unframed, but self-delimited, messages. Specific message types MAY be concatenated together into a single packet, each message type indicates any restrictions on how it can be used within a packet.¶

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:¶

BPv6 Bundle:

All encoded BP version 6 bundles begin with the version identifier octet 0x06 in accordance with [RFC5050]. A message with a leading octet value of 0x06 SHALL be treated as a BPv6 bundle. Multiple BPv6 Bundles SHOULD NOT be present in one UDPCL packet to maintain compatibility with [RFC7122].¶

BPv7 Bundle:

All encoded BP version 7 bundles begin with a CBOR array head in accordance with [I-D.ietf-dtn-bpbis]. A message 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 transmitting UDPCL entity SHALL remove them.¶

Extension Map:

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

Padding:

Padding data SHALL be a sequence of octets all with value 0x00. A message with a leading octet value of 0x00 SHALL be treated as padding.¶

Padding is used to ensure a UDP datagram is exactly a desired size. Because padding has no intrinsic length indication, if present it SHALL be the last contents of any UDPCL packet. A receiving UDPCL entity SHALL ignore all padding, including any trailing non-zero octets.¶

DTLS Record:

In addition to the UDPCL specific messaging, immediately after a DTLS Initiation (see Section 3.5.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.5. UDPCL Extension Items

Extensions to UDPCL are encoded per-datagram in a single CBOR map as defined in Section 3.4. Each UDPCL extension item SHALL be identified by a unique Extension ID used as a key in the Extension Map. Extension ID values SHALL be a CBOR int item no longer than 16-bits. 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.¶

; Map structure requiring non-zero-int keys.
; CDDL cannot enforce type-specific requirements about other items
; being present (or not present) in the same map.
udpcl-ext-map = $udpcl-ext-map .within udpcl-ext-map-structure
$udpcl-ext-map = {
    * $$udpcl-ext-item
}
udpcl-ext-map-structure = {
    * ext-key => any
}
ext-key = (int .size 2) .ne 0

The following subsections define the initial UDPCL extension types.¶

$$udpcl-ext-item //= (
    5: null
)

$$udpcl-ext-item //= (
    2: [
        transfer-id: uint .size 4,
        total-length: uint .size 4,
        fragment-offset: uint .size 4,
        fragment-data: bstr,
    ]
)

$$udpcl-ext-item //= (
    3: time-duration,
)
time-duration = uint

$$udpcl-ext-item //= (
    4: nodeid,
)
nodeid = tstr

3.6. Explicit Transfers

This version of UDPCL supports CL-layer fragmentation of bundles larger than the PMTU would otherwise allow. Policies related to fragmentation at, above, or below the UDPCL layer are defined in Section 2.3. The entire fragmented bundle is referred to as a Transfer and individual fragments of a transfer are encoded as Transfer extension items in accordance with Section 3.5.2.¶

This mechanism also allows a bundle transfer to be transmitted along with additional extension items, which the unframed bundle-in-datagram data does not. This specification does not define any extension items which augment an associated transfer.¶

3.7. 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. There is no concept of a plaintext message being sent in a conversation after a DTLS session is established.¶

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.¶

         Entity A                             Entity B
        active peer                         passive peer

+-------------------------+
|    Initiate DTLS Ext.   | ->
+-------------------------+
+-------------------------+         +-------------------------+
|     DTLS Negotiation    | ->   <- |     DTLS Negotiation    |
|       (as client)       |         |       (as server)       |
+-------------------------+         +-------------------------+

           DNS-ID and IPADDR-ID authentication occurs.
               Secured UDPCL messaging can begin.

+-------------------------+
|   Sender Listen Ext.    | ->
|   Sender Node ID Ext.   |
+-------------------------+

                  NODE-ID authentication occurs.
         DTLS session is established, transfers can begin.

+-------------------------+
|    Unframed Transfer    | ->      +-------------------------+
+-------------------------+      <- |    Unframed Transfer    |
+-------------------------+         +-------------------------+
|    Unframed Transfer    | ->
+-------------------------+

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.7.4 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 certificates exchanged by DTLS enable authentication of peer DNS name and Node ID, but it is possible that a peer either not provide a valid certificate or that the certificate does not validate either the DNS-ID/IPADDR-ID or NODE-ID of the peer (see Section 2.2). Having a CA-validated certificate does not alone guarantee the identity of the network host or BP node from which the certificate is provided; additional validation procedures in Section 3.7.3 bind the DNS-ID/IPADDR-ID or NODE-ID based on the contents of the certificate.¶

The DNS-ID/IPADDR-ID validation is a weaker form of authentication, because even if a peer is operating on an authenticated network DNS name or IP address it can provide an invalid Node ID and cause bundles to be "leaked" to an invalid node. Especially in DTN environments, network names and addresses of nodes can be time-variable so binding a certificate to a Node ID is a more stable identity.¶

NODE-ID validation ensures that the peer to which a bundle is transferred is in fact the node which the BP Agent expects it to be. In circumstances where certificates can only be issued to DNS names, Node ID validation is not possible but it could be reasonable to assume that a trusted host is not going to present an invalid Node ID. Determining when a DNS-ID/IPADDR-ID authentication can be trusted to validate a Node ID is also a policy matter outside of the scope of this document.¶

One mitigation to arbitrary entities with valid PKIX certificates impersonating arbitrary Node IDs is the use of the PKIX Extended Key Usage key purpose "id-kp-bundleSecurity" of [IANA-SMI]. When this Extended Key Usage is present in the certificate, it represents a stronger assertion that the private key holder should in fact be trusted to operate as a DTN Node.¶

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.5.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).¶