Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2

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 segmentation 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, a UDP port number, and an optional local interface identifier (see Section 3 for details). The CL does not necessarily perform any transmission queueing (see Section 2.7), but might 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 can 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 can include information about the total size of a segmented 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 a (source) IP address, a UDP port number, and an optional local interface identifier (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.5 and Section 3.8). 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 [RFC9147].¶

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 [RFC9174].¶

2.3. UDP Conversation Stability

Unlike the loose UDPCL definition in [RFC7122], the requirements in this document ensure that traffic between two peers with stable IP addresses also use stable UDP port numbers. This enables the UDPCL to be more compatible with network address translation (NAT) middleboxes and, where necessary, enables the UDPCL to be used along with protocols such as Session Traversal Utilities for NAT (STUN) [RFC8489] and Interactive Connectivity Establishment (ICE) [RFC8445].¶

There is a trade-off between stability of UDP conversations and a possible need to protect from off-path data injection, as described in Section 5.8, so the conversation long-term stability (in Section 3.1 and Section 3.2) is recommended while specific cases of short-term consistency Section 3.5.2, Section 3.5.3, and Section 3.5.6 are required.¶

2.4. Path Characterization

The earlier UDPCL definition in [RFC7122] assumed that BP node operators had deep visibility into the IP networks over which bundles would be transferred, specifically that the IP paths between UDPCL sender and receiver had well-characterized parameters for: path maximum transmit unit (PMTU), one-way delay time, one-way throughput limit, and packet loss statistics (both due to congestion and to link errors).¶

In situations where node operators do not have prior information about those parameters, this version of the UDPCL supports mechanisms to measure or estimate them. These mechanisms are defined in detail under Section 3.7.¶

2.5. Fragmentation Policies

It is a implementation matter for a sending entity to determine the PMTU to be used as a target upper-bound UDP datagram size.¶

The priority order of fragmentation is the following:¶

1. When possible, bundles too large to fit in one PMTU-sized packet MAY 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; encoded bundles are received from the BP agent either already fragmented or not.¶
2. When a PMTU is available to a peer, bundles too large to fit in one PMTU-sized packet SHALL be segmented as a UDPCL transfer (see Section 3.6). Segmentation at this level treats bundle transfers as opaque data, so it is independent of bundle block sizes or counts. When a PMTU is available, IPv4 packets sent by a UDPCL entity SHOULD have the DF bit set to allow detection of PMTU issues.¶
3. All IPv6 packets and all IPv4 packets which do not have the DF bit set which are larger than the link MTU will be fragmented by the transmitting entity to fit within one link MTU. 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 Fragmentation Needed of [RFC792] or ICMPv6 Packet Too Big of Section 3.2 of [RFC4443]). The UDPCL itself provides no transfer acknowledgement mechanism or other protocol-level reception feedback other than the optional Packetization Layer Path MTU Discovery procedure, which is why an accurate PMTU for a peer is critical information.¶

2.6. Error Checking Policies

The core Bundle Protocol specification assumes that bundles are transferring over an erasure channel, i.e., a channel that either delivers packets correctly or not at all.¶

A UDP transmitter SHALL NOT disable UDP checksums. A UDP receiver SHALL NOT disable the checking of received UDP checksums.¶

Even when UDP checksums are enabled, a small probability of UDP packet corruption remains. In some environments, it could be acceptable for a BPA to occasionally receive corrupted input for some blocks. In general, however, a BPA is RECOMMENDED to ensure the a bundle's blocks are covered by a CRC so that next-hop receivers can verify the block contents.¶

2.7. Congestion Control Policies

The applications using UDPCL for bundle transport SHALL conform to the congestion control requirements of Section 3.1 of [RFC8085]. The application SHALL either perform active congestion control of bundles or behave as the Low Data-Volume application as defined in Section 3.1.3 of [RFC8085].¶

When nodes have bidirectional IP capability with a peer, the ECN marking and feedback mechanism of Section 3.7.4 can be used to provide Active Queue Management (AQM) of UDP traffic (and thus BP traffic) to the peer providing feedback. It is an implementation matter to ensure that traffic patterns which require UDPCL queuing and rate control are paired with a UDPCL entity capable of AQM and peers which provide requisite ECN feedback.¶

When nodes have bidirectional BP transfer capability, the bundle deletion reason code "traffic pared" can be used by a receiving agent to signal to the bundle source application that throttling of bundles along that BP path needs to occur.¶

3.1. IP Header

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

For each forwarding transfer the BP agent determines the mapping from destination EID to next-hop CL parameters, including next-hop destination address and source interface. Some EIDs represent singleton destinations and others non-singleton destinations as defined in Section 4.2.5.1 of [RFC9171]. The singleton-ness of an EID does not necessarily correspond with the unicast-ness of its forwarding, as some bundle routing schemes involve attempting multiple parallel paths to a singleton endpoint and some involve forwarding non-singleton-destination traffic to known individual BP neighbors along unicast paths.¶

For unicast transfers to a single node, the destination address SHALL be a non-multicast IPv4 or IPv6 address (which includes 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.8) 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 any number of nodes, the destination address SHALL be a multicast IPv4 [IANA-IPv4-MCAST] or IPv6 [IANA-IPv6-MCAST] address. The well-known multicast addresses defined in Section 6.1 SHALL be used as a default in the absence of any network-specific configuration. For multicast transfers, the source interface address MUST be supplied by the BP agent rather than inferred by the UDPCL entity. For multicast transfers the UDPCL does not define any security mechanism.¶

When supported by an implementation, the UDPCL SHOULD accept and provide information on the local interface from which a transmission is sent or to which a reception was received. For IPv6 this corresponds with the IPV6_PKTINFO ancillary data API of Section 6.1 of [RFC3542]; for IPv4 this is an implementation-specific detail supported by IP_PKTINFO ancillary data on some operating systems. Identifying an interface for transmission or reception allows a BPA to provide fine-grained control and visibility when UDPCL is used for IP multicast or when link-local addressing is in use.¶

The IPv4 header bit don't fragment (DF) is used as discussed in Section 2.5.¶

The IPv4 and IPv6 header field for Explicit Congestion Notification (ECN) is used as discussed in Section 2.7 and Section 3.7.4.¶

3.2. UDP Header

UDP port number 4556 has been assigned by IANA [IANA-PORTS] as the Registered Port number for the UDPCL and SHALL be used as a default for both source and destination. Other source or 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.¶

If the default source port is not used, 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. For feedback messaging, the passive entity SHALL respond to the same address-and-port that solicited the feedback and use the same source address-and-port which was listed on. Reusing source address-and-port allows simplifies network monitoring and analysis and also enables bi-directional messaging as defined in Section 3.5.3, Section 3.7.1, and Section 3.7.4.¶

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

DTLS Record:

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

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. Packets with a leading octet value of 0x14--0x1A or 0x20--0x3F SHALL be treated as a DTLS sequencing failure; DTLS non-handshake records SHOULD never be seen by the UDPCL messaging layer.¶

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

Bundle:

When sent outside of an explicit identified transfer (Section 3.6) an encoded bundle is treated as a separate message type. This is for compatibility with [RFC7122] but comes at the expense of the UDPCL not being able to de-duplicate any redundant transfers (Section 3.3.1).¶

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 [RFC9171]. 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.¶

A summary of how a receiving UDPCL entity can interpret the first octet of a UDPCL packet 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 which fits within a signed 16-bit integer. Extension ID assignments are listed in Section 6.3.¶

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 = ((-32768 .. 32767) .within int) .ne 0

The following subsections define the initial UDPCL extension types.¶

$$udpcl-ext-item //= (
    1: [ + ext-key ]
)

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

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

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

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

$$udpcl-ext-item //= (
    6: [
        nonce,
        seqno,
        confirm-delay
    ],
)
; A correlator nonce for confirmations
nonce = uint
seqno = uint
confirm-delay = uint

$$udpcl-ext-item //= (
    7: [
        nonce,
        seen-range
    ],
)
; Range of sequence numbers seen
seen-range = [ + seen-interval-pair ]
seen-interval-pair = (
  offset: uint,
  length: uint .gt 0,
)

$$udpcl-ext-item //= (
    8: [
        ect0: ecn-count,
        ect1: ecn-count,
        ce: ecn-count
    ],
)
; Wraps around at 32-bits
ecn-count = uint .size 4

3.6. Identified Transfers

This version of UDPCL supports CL-layer identification of bundles and segmentation of bundles larger than the PMTU would otherwise allow. Policies related to segmentation at or fragmentation above, or below the UDPCL layer are defined in Section 2.5. The entire segmented bundle is referred to as a Transfer and individual segments 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. Path Characterization Procedures

The procedures defined in this section allow pairs of UDPCL entities to characterize IP path parameters between them when those parameters are either unknown or for troubleshooting when actual network performance deviates from expectations.¶

These procedures not mandated to be used operationally, but when the associated characterization is desired these are the procedures which SHALL be used.¶

3.8. 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.8.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.8.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 is trusted to operate as a DTN Node.¶

5.8. Threat: Off-Path Packet Injection

As described in Section 5.1 of [RFC8085], when each endpoint of a UDP conversation uses a stable port number the conversation can be more easily snooped and off-path packets can be injected to spoof UDPCL traffic. When the requirements in Section 3.2 are followed UDPCL traffic will use predictable, well-known port numbers and will be subject to this threat.¶

One direct mitigation of this threat is to use DTLS to ensure that off-path attackers cannot inject packets without being discovered and those packets rejected at the destination.¶

Another mitigation is for a UDPCL entity to use the well-known UDPCL port for passive listening but choose an ephemeral port to bind to when acting as the active peer. This will enable some amount of obfuscation while maintaining stable UDP conversations, but could also make legitimate traffic analysis and troubleshooting more difficult.¶

5.9. Threat: Denial of Service

The behaviors described in this section all amount to a potential denial-of-service to a UDPCL entity. The denial-of-service could be limited to an individual UDPCL entity, or could affect all entities on a host or network segment.¶

An entity can send a large amount of data to a UDPCL entity, requiring the receiving entity to handle the data. The victim entity can block UDP packets from network peers which are thought to be incorrectly behaving within network.¶

An entity can also send only one segment of a seemingly valid transfer and never send the remaining segments, which will cause resources on the receiver to be wasted on transfer reassembly state. The victim entity can either block packets from network peers or intentionally keep a short unfinished transfer timeout (see Section 3.6.2).¶

The keepalive mechanism can be abused to waste throughput within a network link which would otherwise be usable for bundle transmissions.¶

5.10. 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.5 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.11. 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.12. 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. IP Multicast Addresses

This document allocates new routable multicast addresses for use with the UDPCL.¶

Within the IPv4 multicast address registry of [IANA-IPv4-MCAST], the sub-registry titled "Internetwork Control Block" has been updated to include the following address.¶

Within the IPv6 multicast address registry of [IANA-IPv6-MCAST], the sub-registry titled "Variable Scope Multicast Addresses" has been updated to include the following address.¶

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

Service Name:

dtn-bundle¶

Transport Protocol(s):

UDP¶

Assignee:

IESG <iesg@ietf.org>¶

Contact:

IETF Chair <chair@ietf.org>¶

Description:

DTN Bundle UDP CL Protocol¶

Reference:

[This specification]¶

Port Number:

4556¶

The related assignment for DCCP port 4556 (registered by [RFC7122]) is unchanged.¶

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