BPv7 Secure Advertisement and Neighborhood Discovery

Internet-Draft	BPv7 SAND	August 2024
Sipos	Expires 16 February 2025	[Page]

Abstract

This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN).¶

SAND operates by each participating node keeping a persistent store of its enrolled underlayer networks, 1-hop neighbors, symmetric 2-hop neighbors along with attributes for each type of entity. These are used as the basis for outgoing SAND message contents and are updated as part of message reception processing.¶

3.1. Local Node Information Bases

This category of information is based on a participating node's knowledge of its own underlayer network (ULN) and PKI configuration. It exists as input to SAND processing and messaging and is unaffected by the results of processing or reception of messages.¶

The resource information of Table 1 is used to populate Resource Advertisement messages. The information in this table are general to the node as a whole and not for any specific interface, network, or CL.¶

Table 1: Local Resource Information
Name	Description
Validity Interval	This is the full time horizon for resource schedules in this information base.
Power Schedule	This represents a time-varying power state of the local node (as either "on" or "off") within the validity interval. A power schedule which indicates "always on" is a valid default.

The underlayer information described in Table 2 allows a participating node to define different profiles for different accessible networks (IP or otherwise). As defined in Section 6, when assembling and sending SAND messages much of the data can be filtered-down based on what is accessible via an interface (among other possible additional filtering, see Section 7.1).¶

Table 2: Local Interface Information Columns
Name	Description
Interface ID	This is the operating-system-specific unique identifier for a network interface.
Accessible Network Set	This is the set of IP addresses assigned to and associated IP subnetworks accessible to this node via the interface.
Link MTU	This is the configured or discovered maximum transmission unit (MTU) of the first-hop network link from the interface. Because this is a link MTU it excludes any network packet header overhead and is network-protocol-independent. This also represents a maximum outgoing size and not necessarily the maximum incoming size. This is not necessarily the same as a path MTU between any peers on this network, and a path MTU can be directional.
SAND Timer Configuration	This is the set of timers needed to configure SAND activities, as defined in Table 3.

The items in Table 3 represents the set of timer configuration needed to operate a participating node. As an information model, details such as specific units or encoding forms are left as an implementation matter. Because SAND uses the DTN time epoch and encoded form, SAND timer configuration SHOULD have a resolution down to at least one millisecond.¶

Table 3: SAND Timer Configuration
Name	Scope	Description
Minimum Time Interval	default and per-message-type	This represents the shortest time interval between sending messages of the same type on a particular interface or to a specific singleton destination.
Maximum Time Interval	default and per-message-type	This represents the longest time interval between sending messages of the same type on a particular interface or to a specific singleton destination. This is used as a timeout for Periodic Update messaging. The Maximum Time Interval MUST be longer than the Minimum Time Interval by some factor.
Validity Duration	default and per-message-type	This is embedded in messages optionally and used for SAND Bundle lifetimes. The Validity Duration MUST be longer than the Maximum Time Interval by some factor.

The Identity information of Table 4 is a logical table used both as a source for sending Identity Advertisement messages as well as for deriving BPSec policy used to send signed payloads and/or receive encrypted payloads.¶

Table 4: Local Identity Information Columns
Name	Description
Thumbnail	This is the `x5t` or `c5t` thumbnail of the encoded certificate, used as a selector.
Key Usage	This is the extracted Key Usage value, from Section 4.2.1.3 of [RFC5280], used as a selector.
Validity Time Interval	This is the extracted Validity interval, from Section 4.1.2.5 of [RFC5280], used as a selector.
Encoded Certificate	This is the DER-encoded X509 or encoded C509 certificate contents.

The trust anchor information of Table 5 is a logical table used for validating received peer certificates and for deriving BPSec policy used to receive signed payloads.¶

Table 5: Local Trust Anchor Information Columns
Name	Description
Subject Key Identifier	This is the extracted Subject Key Identifier, from Section 4.2.1.2 of [RFC5280], used as a selector.
Validity Time Interval	This is the extracted Validity interval, from Section 4.1.2.5 of [RFC5280], used as a selector.
Encoded Certificate	This is the DER-encoded X509 or encoded C509 certificate contents.

The convergence layer information of Table 6 is a logical table separated from the network information of Table 2 because many BP node deployments are expected to have CL instances that are bound to "any endpoint" addresses and can operate across multiple networks. Even in cases where a CL establishes persistent sessions which might be bound to a specific endpoint address or network, the CL instance as a whole can operate simultaneous sessions across many networks.¶

When used as a source for sending Convergence Layer Advertisement messages the advertised CL List is expected to be, but not required to be, filtered-down based on the interface/network on which the message will be sent. Besides being filtered-out for a specific network, a CL entry SHALL NOT be represented differently across different interfaces. TBD How to signal removal of a CL instance consistently across interfaces?¶

Table 6: Local Convergence Layer Information Columns
Name	Description
CL Type	This is the type of CL being represented, which need not be unique when there are multiple instances of a CL operating on a single node (with different parameters presumably).
Bind IP Addresses	This is the set of IP addresses to which the CL instance is bound (for either listening/receiving or connecting/sending). This includes both IPv4 and IPv6 addresses, and can include the "any endpoint" IPv4 and IPv6 addresses (`0.0.0.0` and `::` respectively).
Bind Port Number	This is the specific transport-layer port number to which the CL instance is bound. This includes the default port number for each CL type.
Transport Security	This indicates whether transport security is required, prohibited, or neither (meaning it can be opportunistic or conditional) by the CL instance.
Roles	This indicates the logical roles which this CL instance is able to perform among "active" or "passive" options. The definition of an active role is CL-specific, but is expected to involve initiating outgoing conversations/connections/sessions, while a passive role is expected to involve listening for incoming ones. A single CL instance can be capable of both roles.
Type-Specific Parameters...	Each CL type (see Section 5.4) able to be represented by SAND can have a set of parameters specific to that type.

3.2. Neighbor Information Bases

An information base for 1-hop neighbor existence and intrinsic properties is managed separately from other information bases which represent relationships between nodes. Neighbor information can be received from any number of interfaces and is aggregated together into these information bases. In some cases the original received interface is kept and in others it is discarded in order to have a single record representing the neighbor node.¶

The neighbor node information of Table 7 is a logical table of immediate neighbors of this node. Multiple sources of information are aggregated together into this table.¶

Table 7: Neighbor Node Information Columns
Name	Description
Node ID	This is the SAND Singleton EID for the node.
MPR Selection	TBD
Power Schedule	This represents a time-varying power state of the node (as either "on" or "off") as reported in Resource Advertisement messages.

An information base for 1-hop neighbor reachability in Table 8 is a logical table relating 1-hop neighbor nodes from Table 7 to specific local interfaces from Table 2 on which the node is reachable or on which messages have been received. Due to having multiple-network connectivity, it is possible to have multiple records identifying the same 1-hop Neighbor but each will have their own set of path metrics for a specific network.¶

Table 8: Neighbor Reachability Information Columns
Name	Description
Node ID	This is a cross-reference to the unique identifier from Table 7.
Interface ID	This is a cross-reference to the unique identifier from Table 2, the local network interface which has seen messages from the node.
Latest Timestamps	This is the latest bundle creation timestamp (Section 4.2.7 of [RFC9171]) for each SAND Message Type (Section 8.4) received from the neighbor on this interface, which is used to filter-out old, out-of-order messages in Section 4.5.
DNS Name Set	This is the set of DNS Names assigned to the neighbor node and accessible on the associated network.
IP Address Set	This is the set of IP addresses assigned to the neighbor node and accessible on the associated network.
Link MTU	This is the configured or discovered MTU of the first-hop link for the neighbor on the associated network. Similar to the local interface Link MTU, the actual Path MTU to and from this peer might be reduced from any one-hop Link MTU and might be directional.
Reachability	An indication of whether this neighbor has been only received from (HEARD), or if this node is present in that neighbor's own 1-hop peer list (SYMMETRIC), or if no messages have been received after some time (LOST).
Path Metrics	This is the set of network-level metrics for expected path delay, maximum data rate, and bit error rate in each direction.
Timeout	This is the absolute local-clock time when this record becomes invalid.

Table 9: Neighbor CL Information Columns
Name	Description
Node ID	This is the SAND Singleton EID for the node.
Interface ID	This is a cross-reference to the unique identifier from Table 2, the local network interface which has seen messages from the node.
CL Type	This is the type of CL being represented, which need not be unique when there are multiple instances of a CL operating on a single node-and-interface.
CL Parameters	These are the transport and network parameters (see Table 6), as reported in Convergence Layer Advertisement messages.

3.3. Network Information Bases

This category of information is about an individual node, or pairs of nodes, independent of the location of the node in the network topology relative to this node.¶

An information base for 2-hop neighbors is limited to only those which have symmetric reachability between that node and one of the 1-hop neighbors from Table 7. This information includes simplified path metrics between the 1-hop and 2-hop neighbors. Due to having multiple-network connectivity, it is possible to have multiple records identifying the same 2-hop Neighbor but each will have their own set of path metrics for a specific network.¶

Table 10: Peer Node Information Columns
Name	Description
Node ID	This is the SAND Singleton EID for the node.
Latest Timestamps	This is the latest bundle creation timestamp (Section 4.2.7 of [RFC9171]) for each SAND Message Type (Section 8.4) received from the node, which is used to filter-out old, out-of-order messages in Section 4.5.

TBD¶

Table 11: Peer Reachability Information Columns
Name	Description
Left Node ID	This is a cross-reference to a unique identifier from Table 10.
Right Node ID	This is a cross-reference to a unique identifier from Table 10.
Path Metrics	This is the set of network-level path metrics between the left and right node.

The Peer Certificate Information of Table 12 is used as way to store and cache certificates received via Identity Advertisement messages and validated in a time-independent way.¶

This means that certificates SHALL only be considered for caching by a node unless they have been part of a chain validated in accordance with the procedures of Section 6 of [RFC5280], up to a root CA from the Trust Anchor information of Table 5, while ignoring validity times. In addition to the base validation, all end-entity certificates SHALL only be considered for caching by a node if it conforms to the certificate profile of Section 4 of [I-D.ietf-dtn-bpsec-cose]. The Peer Certificate Information SHALL be de-duplicated from the Trust Anchor information of Table 5 by ignoring root CA certificates.¶

Table 12: Peer Certificate Information
Name	Description
Node ID	This is the SAND Singleton EID for the node.
Thumbnail	This is `x5t` or `c5t` thumbnail of the encoded certificate, used as a selector.
Subject Key Identifier	This is the extracted Subject Key Identifier, from Section 4.2.1.2 of [RFC5280], used as a selector.
Key Usage	This is the extracted Key Usage value, from Section 4.2.1.3 of [RFC5280], used as a selector.
Validity Time Interval	This is the extracted Validity interval, from Section 4.1.2.5 of [RFC5280], used as a selector.
Encoded Certificate	This is the DER-encoded X509 or encoded C509 certificate contents.

4. Message Transport

The SAND relies on BPv7 for end-to-end transport, one or more CL for one-hop transport, and BPSec for message security (both end-to-end and one-hop).¶

4.1. SAND Endpoints

Within BPv7, the SAND uses two types of well-known endpoint identifier (EID) used as source and/or destination for bundles transported between SAND participants.¶

SAND Singleton EID:: This identifies the SAND application on the participating node and is used as the Source EID for SAND Bundles from the node. The SAND Singleton EID uses either the DTN or IPN scheme with a well-known service part as registered in TBD and Section 8.2 respectively.¶
SAND Group EID:: This allows participating nodes to receive SAND Bundles without any pre-configuration. The SAND Group EID uses the interplanetary multipoint communication (IMC) scheme with a well-known group number TBA1 and service number TBA2 as registered in Section 8.1.¶

Beyond its necessary use as a bundle EID, the SAND Singleton EID also serves as a unique identifier for the participating node and a unique and stable correlator for the SAND information bases (Section 3).¶

4.2. SAND Bundle

For the remainder of this document a bundle with a source matching the SAND Singleton EID will be referred to as a SAND Bundle. A SAND Bundle will have a destination of either the SAND Group EID or another SAND Singleton EID. This is illustrated by the following EID Pattern of [I-D.sipos-dtn-eid-pattern].¶

imc:TBA1.TBA2|ipn:*.*.TBA3|dtn://**/TBA4

A SAND Bundle has the following basic characteristics:¶

The primary block of a SAND Bundle SHALL NOT be marked with the administrative flag, as the destination is not an administrative endpoint.¶
A SAND Bundle SHALL contain a Hop Count extension block Section 4.4.3 of [RFC9171] to control the scope of the message. A message set intended only for 1-hop neighbors uses a Hop Limit of 1. That doesn't prohibit a single outgoing message from being conveyed over multiple CLs (which is distinct from a single CL with multicast behavior).¶
A SAND Bundle which is being forwarded SHALL contain a previous node identification in accordance with Section 4.3 This is a more strict requirement than BPv7 itself because SAND processing handles 1-hop neighbors differently than more distant nodes.¶
A SAND Bundle SHALL be secured using BPSec blocks as defined in Section 4.4 in accordance with [RFC9172]. This document does not allow for an insecure use of SAND, although prototype implementations might use insecure transport as an intermediate step to full SAND compliance.¶
The payload block of a SAND Bundle SHALL contain a CBOR sequence of items. The sequence SHALL consist of SAND version number followed by one or more bstr items, each containing an encoded SAND Message as defined in Section 5.¶

; The actual ADU is the sequence ~sand-adu-seq, not array enveloped
sand-adu-seq = [
    version: 1,
    1* adu-item
]
adu-item = bstr .cbor sand-msg

Each encoded SAND Message SHOULD use CBOR core deterministic encoding requirements from Section 4.2.1 of [RFC8949]. Even if not using deterministic encoding the first item of each SAND Message map SHALL have key zero (the Message Type item). This will cause the Message Type item to be the first one in the encoded message, which will allow a SAND processor to quickly determine if the specific message is of interest and skip over it if not.¶

Because multiple SAND Messages can be sent in a single bundle to which a Hop Limit applies, all messages in a single bundle need to have the same restriction (or non-restriction) of Hop Limit.¶

4.3. Previous Node Identification

In order to properly handle an SAND Bundle, the previous-hop node needs to be positively identified. This occurs by using either an authenticated identity from the CL over which the bundle was received, if available, a Previous Node extension block Section 4.4.1 of [RFC9171], if present, or the Source Node ID from the Primary block Section 4.3.1 of [RFC9171].¶

A SAND Bundle which is forwarded over a CL which includes an authenticated identity SHOULD NOT contain a Previous Node extension block. Otherwise, a SAND Bundle which is forwarded but not sourced on a node SHALL contain a Previous Node extension block to indicate that the node sending it is not its source.¶

4.4. Bundle Security

All SAND Bundles SHALL contain a Block Integrity Block (BIB) which targets the payload block. If that BIB does not include the primary block as additional authenticated data (AAD) then the BIB SHALL also target the primary block. The BIB MAY target any other blocks in the SAND Bundle.¶

The BIB targeting the payload block SHALL have a Security Source identifying the same node as the bundle Source EID. Due to node and network security policy, the Security Source EID MAY be different than the bundle Source EID. For example, a bundle source of ipn:974848.10.3 might have an associated Security Source of ipn:974848.10.0 but both identify the same IPN node.¶

Any SAND Bundles which contain a Previous Node block SHALL also contain a BIB which targets that Previous Node block. If that BIB does not include the primary block as additional authenticated data (AAD) then the BIB SHALL also target the primary block. The BIB MAY target any other blocks in the SAND Bundle. Similar to the payload, any BIB targeting the Previous Node block SHALL have a Security Source identifying the same node as the Previous Node block.¶

Any BIB used by SAND SHALL authenticate the bundle source EID and provide proof-of-possession (PoP) of the private key bound to the bundle source EID via PKIX certificate. This could be done using a cryptographic signature as available in the COSE Context of [I-D.ietf-dtn-bpsec-cose] because the primary block Creation Timestamp functions as a unique nonce for PoP.¶

A SAND Bundle MAY contain a Block Confidentiality Block (BCB) which targets the payload block when being transported over an insecure CL to a known set of recipients. If the BCB acceptors are not using group keys or known individual-recipient keys, the SAND Bundle SHOULD NOT be transported over a multicast CL.¶

When BPSec blocks can contain either certificate contents or thumbprints, the use of thumbprints is RECOMMENDED along with the use of Identity Advertisement messages to convey identity between nodes. To avoid the bootstrapping issue described in Section 7.3, the requirements of that section need to be met by a participating node.¶

4.5. Superseding Messages

Like MANET discovery and routing protocols, all of the message types defined in this document contain the full set of data of a particular type from a source node. The processing of any one message does not rely on incremental changes caused by the message or processing of any preceding-in-time messages of the same type. This also makes SAND Message processing idempotent and immune to duplicate reception, which is an expected property of BPv7 transport.¶

Because of this, the reception of a message sent earlier than the last-received message of the same type from the same source can be completely ignored. This logic applies per-message-type so a single SAND Bundle can contain some messages which are superseded along with others which are not. This comparison logic below along with the BPv7 requirement of timestamp uniqueness provide a strict ordering of all bundles from a source.¶

After receiving and processing each SAND Message, a node SHALL record the Creation Timestamp from the bundle along with the bundle source and message type. After receiving but before fully processing each SAND Message, a node SHALL look up the latest processed Creation Timestamp based on the bundle source and message type. If the received message is identical to or earlier than the latest processed timestamp it SHALL be ignored by the application. The timestamp comparison SHALL be based on ordering of the DTN Time followed by the Sequence Number. Ignoring a superseded message SHALL NOT be considered a failure of processing the message, its containing ADU, or its containing bundle.¶

4.6. Default Convergence Layer

Part of the ability of the SAND to be a discovery protocol is the need for initial authenticated messaging without any pre-configuration of any participating node. This is accomplished by using the UDPCL with an IP multicast destination, either IPv4 or IPv6 or both as needed on each interface.¶

All SAND-participating nodes SHALL listen for UDPCL packets on default port 4556, defined in Section 6.2 of [I-D.sipos-dtn-udpcl], and by joining IP multicast group(s) defined in Section 6.1 of [I-D.sipos-dtn-udpcl] on all interfaces over which the entity is participating in discovery. Nodes MAY listen for UDPCL packets destined for other (unicast) addresses and/or on other ports as needed.¶

When sending SAND Bundles, participating nodes SHALL use this default convergence layer in accordance with the modes defined in Section 6, one of which uses the above multicast configuration. Because an IP multicast destination is used, the source node will need to condition certain UDP and IP parameters based on a specific network interface to send from.¶

To send bundles using the UDPCL on a specific interface:¶

An implementation-defined Redundancy Factor SHALL be used based on the specific interface.¶
The default UDP port 4556 SHALL be used as its destination.¶
The default UDP port 4556 SHOULD be used as its source.¶
If a specific destination IP address is given that SHALL be used as its destination. Otherwise, use one or more of the following:¶
- If the interface has an assigned IPv4 address, a UDPCL transfer SHALL be sent using the IPv4 multicast address for "All BP Nodes" as its destination and that assigned address as its source.¶
- If the interface has an assigned IPv6 address, a UDPCL transfer SHALL be sent using the IPv6 multicast address for "All BP Nodes" as its destination and that assigned address as its source.¶
Unless there is additional configuration available, the link MTU SHALL be assumed to be the path MTU for all nodes on that IP network. The sending node SHALL use CL segmentation as necessary to adapt the SAND Bundle size to the path MTU.¶

5. Message Structure and Types

A SAND Message is the top-level encoded structure exchanged between nodes. Messages are encoded according to the following requirements and the CDDL in Figure 2.¶

A SAND Message SHALL consist of a CBOR map containing at least one pair. All keys in the SAND Message map SHALL be CBOR int16 (unsigned or negative) items. This specification follows the pattern of CBOR [RFC8152] to use positive-valued map keys to indicate common parameters and negative-valued map keys to indicate type-specific parameters. This convention also applies to subordinate maps within SAND messages.¶

sand-generic-structure = {
    * label => value,
}
; Generic map label
label = int16
; Generic map value
value = any

; Signed integer that fits in 16-bit two's complement form
int16 = (-32768 .. 32767) .within int
; Positive part of int16 for common values
comm16 = uint .le 32767
; Negative part of int16 for private values
priv16 = nint .ge -32768

Figure 2: SAND Generic Structure CDDL

The message common parameters are listed below and correspond with the CDDL of Figure 3. These are also registered in the IANA registry defined in Section 8.3.¶

Message Type:

This pair uses key 0 and value of int16 identifying the type of message. The registry of message types is IANA-managed and defined in Section 8.4.¶

Reference Time:

This pair uses key 2 and value of dtn-time indicating the absolute time of the start of validity of this message in the DTN time epoch (see Section 4.2.6 of [RFC9171]). If no Reference Time is present, the message SHALL be treated as being valid from the containing bundle's Creation Timestamp. The Reference Time is also used as the epoch for any schedule structure in the same message, defined later in this section.¶

For nodes with low-fidelity timing needs or having a low-precision clock this value SHOULD be omitted. Otherwise, this value SHALL be present to avoid any difference between message creation time and the BPA-sourced Creation Timestamp.¶

Validity Duration:

This pair uses key 3 and value of time-duration indicating the validity-time of the message contents in milliseconds. If no Validity Duration is present, the message SHALL be treated as being valid through the containing bundle's Lifetime. The Validity Duration SHALL be interpreted as starting at the Reference Time from the same message, if present, or the bundle's creation timestamp.¶

For nodes with low-fidelity timing needs this value SHOULD be omitted. Otherwise, this value SHALL be sourced from the Validity Duration of Table 3.¶

Repetition Interval:

This pair uses key 4 and value of time-duration indicating the periodic interval of the message type in milliseconds. If no Repetition Interval is present, the message SHALL NOT be assumed to be sent at a fixed periodic interval.¶

Every SAND Message SHALL contain a Message Type pair. Every SAND Message MAY contain any combination of other pairs with positive keys. The remaining pairs with negative keys SHALL be interpreted according to the Message Type.¶

sand-msg = $sand-msg .within sand-generic-structure

; Generic for messages, where `val` is the Message Type value
msg-base<val> = (
    0: val .within int16,
)
$$msg-common-grp //= (
    ? ref-time,
    ? msg-validity,
    ? msg-interval,
)
ref-time = (
    2: dtn-time,
)
msg-validity = (
    3: time-duration,
)
msg-interval = (
    4: time-duration,
)

; Duration in DTN units of milliseconds
time-duration = uint

Figure 3: SAND Message Structure and Common Parameters

Some of the advertisements defined in this document associate an optional validity schedule with select data. Because the advertisements are expected to be sent by nodes periodically on the order of minutes, the form of this schedule is very simplified and focused only on a short-term time horizon using the Reference Time of the same message as its zero-offset epoch. When any schedule is present within a message the Schedule Reference Time item SHALL be present in the message and used as the schedule epoch time.¶

The schedule consists of pairs of duration values, with each pair representing an interval of time during which the schedule applies (and the gaps between intervals representing time during which the schedule does not apply).¶

schedule = [1* schedule-interval-pair]
schedule-interval-pair = (
  offset: time-duration,
  length: time-duration .gt 0,
)

Figure 4: Common Schedule CDDL

5.1. Data Solicitation

The Data Solicitation message type informs recipients that the sender desires specific types of SAND data from its peers. A peer entering a network SHOULD send a Data Solicitation message after an implementation defined time delay.¶

The Data Solicitation message SHALL be identified by message type 1. The message parameters are listed below and correspond with the CDDL of Figure 5.¶

Message Type List:: This pair uses key -1 and value of an array of Message Type values. The Message Type List SHALL contain at least one item. Each Message Type List item SHALL be unique. The order of items within the array SHALL NOT be treated as significant by the recipient.¶

Each Data Solicitation message SHALL contain a Message Type List. The Data Solicitation message SHALL NOT be used to request a Data Solicitation type.¶

$sand-msg /= solicit-msg
solicit-msg = {
    msg-base<1>,
    $$msg-common-grp,
    solicit-types,
}
solicit-types = (
    -1: [1* msg-type]
)
msg-type = int16

Figure 5: Data Solicitation Message CDDL

5.2. Identity Advertisement

The Identity Advertisement message contains PKIX certificates identifying the source node with key material for different security purposes.¶

Certificates in this message are sourced from the Identity Information Base of Table 4. The certificates themselves contain validity time intervals which have no strict relationship to the validity time of the containing advertisement message or the lifetime of the containing bundle, and do not relate to any SAND-form of schedule. The creator of an Identity Advertisement message MAY filter-in or filter-out certificates based on their validity time.¶

Certificates valid at the time of creation SHOULD be present. Some certificates MAY have validity time in the distant past or future. Those non-present-time certificates could be needed to verify old signatures or to pre-load future rollover keys respectively.¶

The Identity Advertisement message SHALL be identified by message type 2. The message parameters are listed below and correspond with the CDDL of Figure 6.¶

X509 Bag:: This pair uses key -1 and value COSE_X509 defined in [RFC9360].¶
C509 Bag:: This pair uses key -2 and value COSE_C509 defined in [I-D.ietf-cose-cbor-encoded-cert].¶

Each Identity Advertisement SHALL contain an X509 Bag, a C509 Bag, or both.¶

The Identity Advertisement message is populated in-part using the data identified in Table 4, part of the Local Node Information Base described in Section 3.1.¶

$sand-msg /= identity-msg
identity-msg = {
    msg-base<2>,
    $$msg-common-grp,
    ? x5bag,
    ? c5bag,
}
x5bag = (
    -1: COSE_X509  ; From [RFC 9360]
)
c5bag = (
    -2: COSE_C509  ; From I-D.ietf-cose-cbor-encoded-cert
)

Figure 6: Identity Advertisement Message CDDL

5.3. Interface Advertisement

The Interface Advertisement message contains information about the ULN interface on which the SAND Bundle has been sent, providing recipients information about communicating with the source node. When creating Interface Advertisement messages, the source node will populate it with parameters specific to the network on which the interface is an access point.¶

Each Interface Advertisement message SHALL be transported with a Hop Limit of 1. Only 1-hop neighbors are capable of using underlayer network parameters so there is no need to forward this to any other nodes in the network.¶

The Interface Advertisement message SHALL be identified by message type 8. The message parameters are listed below and correspond with the CDDL of Figure 7.¶

Validity Schedule:: This pair uses key -1 and value of a schedule item as defined in Figure 4. Each time at which the schedule is valid indicates when the interface or link is expected to be usable. If this parameter is absent the interface SHALL be treated as always valid (within the validity schedule of the node itself, see Section 5.5).¶
DNS Name List:: This pair uses key -2 and value of a single tstr or array of tstr from DNS names in accordance with [RFC1034]. If this parameter is absent the node SHALL be treated as not having a DNS name on the network.¶
IP Address List:: This pair uses key -3 and value of a single bstr or array of bstr from IPv4 or IPv6 addresses encoded as four-byte or 16-byte sequences respectively (consistent with untagged values of [RFC9164]). If this parameter is absent the node SHALL be treated as having only the IP address from which the containing bundle was sent.¶
Link MTU:: This pair uses key -4 and value indicating the link MTU, as seen by the interface of the source node, in units of octets. This value SHOULD adhere to the lower limit of 68 octets for IPv4 [RFC791] or 1280 for IPv6 [RFC8200]. If this parameter is absent then other means of configuring or estimating link or path MTU are needed.¶

$sand-msg /= interface-msg
interface-msg = {
    msg-base<8>,
    $$msg-common-grp,
    ? if-schedule,
    ? if-dns-name-list,
    ? if-ip-addr-list,
    ? if-mtu,
}
if-schedule = (
    -1: schedule,
)

if-dns-name-list = (
    -2: dns-name-ctr
)
dns-name-ctr = dns-name / [1* dns-name]
; Should agree with actual DNS restrictions in [RFC 1034]
dns-name = tstr .abnf ("subdomain" .det dns-name-syntax)
dns-name-syntax = '
    subdomain = label  *("." label)
    label = letter [[ldh-str] let-dig]
    ldh-str = let-dig-hyp *(let-dig-hyp)
    let-dig-hyp = let-dig / "-"
    let-dig = letter / digit
    letter = %x41-5A / %x61-7A
    digit = %x30-39
'

if-ip-addr-list = (
    -3: ip-addr-ctr
)
ip-addr-ctr = ip-address / [1* ip-address]
; Agrees with untagged bstr contents from [RFC 9164]
ip-address = ipv4-address / ipv6-address
ipv4-address = bstr .size 4
ipv6-address = bstr .size 16

if-mtu = (
    -4: mtu-size
)
mtu-size = uint .gt 0

Figure 7: Interface Advertisement Message CDDL

5.4. Convergence Layer Advertisement

The Convergence Layer Advertisement message indicates the CLA instances available on the source node interface sending the message, including both active and passive roles where applicable, and any parameters necessary for peers to make use of those instances. Each instance can also have an associated validity schedule.¶

Each Convergence Layer Advertisement message SHALL be transported with a Hop Limit of 1. Only 1-hop neighbors are capable of using CL data so there is no need to forward this to any other nodes in the network.¶

The Convergence Layer Advertisement message SHALL be identified by message type 3. The message parameters are listed below and correspond with the CDDL of Figure 8.¶

Convergence Layer List:: This pair uses key -1 and value of an array containing cl-recv items defined later in this section. Each Convergence Layer List SHALL contain at least one item. A Convergence Layer List item MAY have a non-unique CL Type parameter, indicating multiple instances of a particular CL.¶

Each Convergence Layer Advertisement SHALL contain a Convergence Layer List. Each item of the Convergence Layer List SHOULD be reachable via the interface over which the enveloping message is sent.¶

Each Convergence Layer Advertisement MAY contain any combination of DNS Name List, IP Address List, and Link MTU items. When present, the DNS Name List, IP Address List, and Link MTU values SHALL apply to all convergence layers in the message. Individual CLs MAY contain additional DNS names and/or IP addresses specific to that CL instance. Duplication between message-level DNS Name or IP Address and CL-level values SHOULD be avoided, but has no effect on the interpretation of the values.¶

$sand-msg /= cl-msg
cl-msg = {
    msg-base<3>,
    $$msg-common-grp,
    cl-list,
}
cl-list = (
    -1: [1* cl-recv]
)

Figure 8: CL Advertisement Message CDDL

Because different CLs are likely to have varying parameter sets, each CL is encoded as a CBOR map following the same conventions of SAND Message structure. There are several common CL parameters related to network- and transport-layer: a DNS name or IPv4/IPv6 address used to communicate with the node, and information about transport security policy.¶

It is also an important distinction that the CL parameterization is about the capability of delivering bundles to the advertising node. It is not about ability of the node to transmit bundles, which may in fact be more broad than its ability to receive. For example, in the situation where a node has an ephemeral IP address and no DNS name that node may not listen with any CL yet, because some CLs are bidirectional, it may have symmetric (BP layer) connectivity to some set of peer nodes. Even in that case there is still value in discovering the presence of the non-listening node because there is the potential for a contact (coming from that node) to allow bundle routes to other nodes "behind" that non-listening node.¶

The CL common parameters are listed below and correspond with the CDDL of Figure 9. These are also registered in the IANA registry defined in Section 8.5.¶

CL Type:

This pair uses key 0 and value of int16 identifying the type of CL being defined. Possible CL Type values are defined Section 8.6 where, similar to message types, positive values are for well-known CL types and negative values are for private or experimental types.¶

Bind Address List:

This pair uses key 3 and value of a single bstr or array of bstr from IPv4 or IPv6 addresses encoded as four-byte or 16-byte sequences respectively (consistent with untagged values of [RFC9164]). Each address represents a destination to which the CL is bound in order to receive traffic. If this parameter is absent, the CL SHALL bet treated as if it was bound to the "any endpoint" IPv4 and IPv6 addresses (0.0.0.0 and :: respectively). If a node has either IPv4 or IPv6 addresses assigned but is not listening on the associated address family, this list SHALL contain the associated "any destination" bind address on which it is listening.¶

Bind Port Number:

This pair uses key 4 and value of uint indicating the transport-layer port number to which the CL is bound. If this parameter is absent the default (i.e., IANA assigned) port number SHALL be used.¶

Transport Security Required:

This pair uses key 5 and value of bool indicating whether transport security is required (when true) or prohibited (when false). If this parameter is absent there is no information about the required policy.¶

Role:

This pair uses key 6 and value of uint containing flags indicating which CL-specific roles the source node can act as.¶

The role flag at bit 0 indicates that the node can act in an passive role. The role flag at bit 1 indicates that the node can act in an active role. If this parameter is absent it is assumed to be 0b11 (the node can be either role).¶

The definition of an "active role" is CL-specific but is expected to involve initiating outgoing conversations/connections/sessions rather than listening for incoming ones. Even when acting in the active role only, the CL MAY still be bound to a specific port number.¶

cl-recv = $cl-recv .within sand-generic-structure

; Generic for CLs, where `val` is the CL Type value
cl-base<val> = (
    0: val .within int16,
)
$$cl-common-grp //= (
    ? cl-bind-addr-list,
    ? cl-bind-port,
    ? cl-transport-sec-require,
    ? cl-role,
)

cl-bind-addr-list = (
    3: ip-addr-ctr,
)
cl-bind-port = (
    4: uint .lt 0xFFFF
)
; A hint about the security need, if any, for this CL
cl-transport-sec-require = (
    5: bool
)
; Indicate whether the entity can operate in CL-defined roles
cl-role = (
    6: uint .bits cl-role-flags
)
cl-role-flags = &(
    passive: 0,
    active: 1,
)

Figure 9: CL Structure and Common Parameters CDDL

If multiple values for DNS Name and/or IP Address are present for a CL it is an implementation matter to choose which one to attempt first, and whether multiple attempts are made sequentially or simultaneously. See [RFC8305] for detailed discussion of one possible algorithm for handling multiple network names/addresses.¶

5.4.1. TCPCLv4

This CL Type specifically refers to the TCPCL version 4 of [RFC9174].¶

If the Port Number parameter is absent, the default TCPCL port 4556 SHALL be used. The Transport Security Required parameter SHALL indicate both the Contact Header USE_TLS flag and the post-negotiation policy enforcement (i.e., when the session will be disallowed). The Role parameter SHALL indicate whether the the TCPCL entity on the node can function as either active or passive or both.¶

$cl-recv /= {
    cl-base<1>,
    $$cl-common-grp,
}

Figure 10: TCPCLv4 Parameters CDDL

5.4.2. UDPCLv2

This CL Type specifically refers to the UDPCL Version 2 of [I-D.sipos-dtn-udpcl].¶

If the Port Number parameter is absent, the default UDPCL port 4556 SHALL be used. The Transport Security Required parameter SHALL indicate the need for DTLS security when receiving CL messages.¶

$cl-recv /= {
    cl-base<2>,
    $$cl-common-grp,
}

Figure 11: UDPCLv2 Parameters CDDL

5.4.3. LTPCL

While there is no IETF specification for transporting BPv7 bundles over the Licklider Transport Protocol (LTP), the CCSDS profile of BPv7 includes a specification for this in Appendix B of [CCSDS-BPv7].¶

If the Port Number parameter is absent, the default LTP port 1113 SHALL be used. The BPv7 use of LTP does not specify a transport-layer security mechanism.¶

$cl-recv /= {
    cl-base<2>,
    $$cl-common-grp,
}

Figure 12: LTPCL Parameters CDDL

5.4.4. TCPCLv3

While there is no concrete specification for transporting BPv7 bundles over TCPCL version 3 [RFC7242], this specification makes an allocation to allow a node to advertise that it is using this combination of protocols.¶

If the Port Number parameter is absent, the default TCPCL port 4556 SHALL be used. The TCPCL version 3 does not specify a transport-layer security mechanism.¶

$cl-recv /= {
    cl-base<32766>,
    $$cl-common-grp,
}

Figure 13: TCPCLv3 Parameters CDDL

5.4.5. RFC 7122 UDPCL

While there is no concrete specification for transporting BPv7 bundles over the UDPCL as defined in [RFC7122], this specification makes an allocation to allow a node to express that it is using this combination of protocols.¶

$cl-recv /= {
    cl-base<32767>,
    $$cl-common-grp,
}

Figure 14: RFC 7122 UDPCL Parameters CDDL

5.5. Resource Advertisement

The Resource Advertisement message is used to indicates the node's resource forecast (power state and storage) for some near time horizon. This corresponds to a node-scope schedule of Section 2.3.1 of [I-D.ietf-tvr-requirements] and these resource relate to all of the CLs exposed in the Convergence Layer Advertisement message from the same node. Per the definitions in Section 5, each schedule applies within the Validity Duration of the message.¶

Resource Advertisement messages are populated using the data in Table 1, part of the Local Node Information Base described in Section 3.1.¶

The Resource Advertisement message SHALL be identified by message type 4. The message parameters are listed below and correspond with the CDDL of Figure 15.¶

Power State:: This pair uses key -1 and value of a schedule item as defined in Figure 4. Each time at which the schedule is valid indicates when the node is forecast to be powered-on.¶

$sand-msg /= resource-msg
resource-msg = {
    msg-base<4>,
    $$msg-common-grp,
    ? power-state,
}
power-state = (
    -1: schedule,
)
; More TBD

Figure 15: Resource Advertisement CDDL

5.6. Local Topology Advertisement

The Local Topology Advertisement message allows a participating node to enumerate the 1-hop neighbors with which the source node can communicate (via some unspecified CL or combined aggregate of CLs). Each neighbor is identified by it's SAND Singleton EID which is a unique across a BP network.¶

Each 1-hop neighbor (peer) is associated with a specific status and a set of communication metrics similar to the behavior of MANET NHDP [RFC6130]. The source of the metrics are not specified by this document, but might come from estimating based on SAND traffic exchanged with the peer. In addition, some of the data comprising the Local Topology Advertisement message is sourced from the Neighbor Information Base, such as Reachability and Path Metrics as discussed in Table 8.¶

The Local Topology Advertisement message SHALL be identified by message type 5. The message parameters are listed below and correspond with the CDDL of Figure 16.¶

Peer List:: This pair uses key -1 and value of an array of structures indicating the SAND Singleton EID and communication status of each 1-hop neighbor of the source node (see Section 5.6.1). Each Peer List SHALL contain at least one item. Each Peer List item SHALL have a unique Node ID parameter.¶

Each Local Topology Advertisement SHALL contain a Peer List.¶

$sand-msg /= localtopo-msg
localtopo-msg = {
    msg-base<5>,
    $$msg-common-grp,
    peer-list,
}
peer-list = (
    -1: [1* peer]
)

Figure 16: Local Topology Advertisement CDDL

5.6.1. Peer Items

Each item of the Peer List represents a combination of a 1-hop neighbor node and metrics associated with network traffic from and to that node.¶

The common peer parameters are listed below and correspond with the CDDL of Figure 17. These are also registered in the IANA registry defined in Section 8.7. Peer parameters with negative keys are reserved for private or experimental use.¶

Node ID:

This pair uses key 0 and value of eid from [RFC9171] representing the unique SAND Singleton EID for the neighbor node.¶

Reachability:

This pair uses key 2 and value of uint containing an enumerated value indicating the status of communication with the neighbor. The value is one of the following:¶

HEARD (1):: This means a message has been received from the peer but this node has not yet appeared in the local topology advertised by that peer.¶
SYMMETRIC (2):: This means that this node is present in the local topology advertised by the peer, so at least one message has been received in both directions between the nodes.¶
LOST (3):: This means that no message has been received from the peer within an implementation-defined timeout interval.¶

Validity Schedule:

This pair uses key 3 and value of a schedule item as defined in Figure 4. Each time at which the schedule is valid indicates when communication is expected to be available (in either direction). This is different than the resource schedule of the node itself, and represents availability of the shared network between the source node and this peer.¶

MPR Selection:

This pair uses key 10 and value of TBD representing the choice of this node as an MPR for the source node.¶

RX Delay:

This pair uses key 4 and value of time-duration indicating the expected one-way light time (OWLT) of traffic from the peer in milliseconds.¶

TX Delay:

This pair uses key 5 and value of time-duration indicating the expected OWLT of traffic to the peer in milliseconds.¶

RX Data Rate:

This pair uses key 6 and value of unsigned-fraction indicating the expected maximum data rate of traffic from the peer in octets per second.¶

TX Data Rate:

This pair uses key 7 and value of unsigned-fraction indicating the expected maximum data rate of traffic to the peer in octets per second.¶

RX Bit Error Rate:

This pair uses key 8 and value of unsigned-fraction indicating the expected bit error rate (BER) of traffic from the peer as a ratio.¶

TX Bit Error Rate:

This pair uses key 9 and value of unsigned-fraction indicating the expected BER of traffic to the peer as a ratio.¶

For conciseness of encoding, the unsigned-fraction values SHOULD limit the mantissa to less than 8 bits. This limits the precision of encoded values but because these are all rough estimates that should be sufficient for contact planning purposes.¶

There is no required combination of RX and TX parameters for any peer. Because these might be estimated from traffic or some kind of underlying discovery protocol (e.g., DLEP) it is possible to obtain estimates for some subset of these but not all of them.¶

For both RX and TX Data Rate values, the rate is averaged over the entire valid time, so it is actually average-of-maximum rate. Another way to think of it is that the sum-total valid time duration multiplied by the data rate value will yield a total data volume that is transferable from (or to) the peer within the validity duration.¶

peer = peer-base .within sand-generic-structure

peer-base = {
    peer-nodeid,
    peer-comm-status,
    $$peer-grp
}
$$peer-grp //= (
    ? peer-schedule
    ? peer-rx-delay,
    ? peer-tx-delay,
    ? peer-rx-datarate,
    ? peer-tx-datarate,
    ? peer-rx-ber,
    ? peer-tx-ber,
)

peer-nodeid = (
    0: eid ; From [RFC 9171]
)
peer-comm-status = (
    2: peer-comm-status-enum
)
peer-comm-status-enum = &(
    HEARD: 1,
    SYMMETRIC: 2,
    LOST: 3,
)

peer-schedule = (
    3: schedule
)
peer-rx-delay = (
    4: time-duration
)
peer-tx-delay = (
    5: time-duration
)
; Maximum data rate in bytes-per-second
peer-rx-datarate = (
    6: unsigned-fraction
)
peer-tx-datarate = (
    7: unsigned-fraction
)
; Estimated BER as a ratio
peer-rx-ber = (
    8: unsigned-fraction
)
peer-tx-ber = (
    9: unsigned-fraction
)

; Same structure as tag #4 "decimal fraction" but limited in domain
unsigned-fraction = [
    exp: (-20 .. 20) .within int,
    mantissa: uint,
]

Figure 17: Peer Structure and Parameters CDDL

5.7. Router Advertisement

The Router Advertisement message exposes parameters about the source node's willingness to route bundles with different categories of destination EIDs. Each willingness to associate with an EID pattern?¶

The Router Advertisement message SHALL be identified by message type 6. The message parameters are listed below and correspond with the CDDL of Figure 18.¶

Willingness for Singleton:: This pair uses key -1 and value of uint representing a willingness to route (see later definition) for bundles with a singleton destination EID. The absence of this pair SHALL be interpreted as a willingness of zero (not willing).¶
Willingness for Multipoint:: This pair uses key -2 and value of uint representing a willingness to route (see later definition) for bundles with a non-singleton destination EID. The absence of this pair SHALL be interpreted as a willingness of zero (not willing).¶
Routable Endpoints:: This pair uses key -3 and value of bstr containing an encoded eid-pattern from [I-D.sipos-dtn-eid-pattern]. The value contains the set of endpoints not participating in SAND but for which the source node is willing to route. The value MAY be an any-scheme pattern or contain an any-SSP pattern.¶

Each willingness value is an integer in the inclusive range from 0 through 6, where 0 indicates the node will never route for that type and the values 1 through 6 indicate an increasing level of willingness. In the absence of additional configuration, a node which is willing to route SHALL have a default willingness of 3 and include the associated message item.¶

The presence of a Routable Endpoints pattern allows a participating router to expose node information from a stub network setting "behind" the router. All of these endpoints SHALL be treated as having persistent and reliable connectivity to the router sending the message. More TBD¶

$sand-msg /= router-msg
router-msg = {
    msg-base<6>,
    $$msg-common-grp,
    ? will-route-singleton,
    ? will-route-multipoint,
    ? routable-endpoints,
}
will-route-singleton = (
    -1: will-route .default 0
)
will-route-multipoint = (
    -2: will-route .default 0
)
will-route = (0 .. 6) .within uint

routable-endpoints = (
    -3: bstr .cbor eid-pattern, ; From I-D.sipos-dtn-eid-pattern
)

Figure 18: Router Advertisement CDDL

5.8. Endpoint Advertisement

TBD¶

The Endpoint Advertisement message SHALL be identified by message type 7. The message parameters are listed below and correspond with the CDDL of Figure 19.¶

Endpoint List:: This pair uses key -1 and value of an array containing endpoint-defn items defined later in this section. Each Endpoint List SHALL contain at least one item. Each Endpoint List item SHALL have a unique Service ID parameter.¶

Each Endpoint Advertisement SHALL contain an Endpoint List. Each item of the Endpoint List SHOULD be reachable as a bundle destination on the node sending the message.¶

$sand-msg /= endpoint-msg
endpoint-msg = {
    msg-base<7>,
    $$msg-common-grp,
    endpoint-list,
}
endpoint-list = (
    -1: [1* endpoint-defn]
)

Figure 19: Endpoint Advertisement CDDL

Because different endpoints (and their applications) are likely to have varying parameter sets, each endpoint definition is encoded as a CBOR map following the same conventions of SAND Message structure. There are several common endpoint parameters related to validity schedule and information about security policy.¶

The common endpoint parameters are listed below and correspond with the CDDL of Figure 20. These are also registered in the IANA registry defined in Section 8.8. Endpoint parameters with negative keys are reserved for private or experimental use.¶

Service ID:

This pair uses key 1 and a value specific to the scheme of the Source EID of the SAND Bundle containing this message. Possible Service ID values are defined in Section 8.9.¶

The initial types for current schemes being: IPN service numbers as uint values and DTN service demux as tstr values.¶

Well-Known Service Number:

This pair uses key 2 and value of a uint item corresponding to one of the registered values from the "'ipn' Scheme URI Well-known Service Numbers for BPv7" registry within [IANA-BUNDLE]. If this parameter is absent and the Service ID itself is an IPN service number it SHALL be looked up as a Well-known Service Number.¶

Application State:

This pair uses key 3 and value of a schedule item as defined in Figure 4. Each time at which the schedule is valid indicates when an application is expected to be operating on the endpoint.¶

Payload Security Required:

This pair uses key 5 and value of uint containing flags indicating which aspects of payload security are required for communicating with this endpoint. If this parameter is absent there is no information about the required policy.¶

The security flag at bit 0 indicates that the payload SHALL be a target of a BIB that the node can accept. The security flag at bit 1 indicates that the payload SHALL be a target of a BCB that the node can accept. The security flag at bit 1 indicates that the any accepted security block SHALL bind to the primary block as AAD.¶

; Service ID is interpreted within the Source EID scheme
endpoint-defn = endpoint-base .within sand-generic-structure
endpoint-base = {
    0: $service-id,
    $$endpoint-common-grp,
    * priv16 => any,
}

; DTN service demux (path with no preceding slash)
$service-id /= tstr
; IPN or IMC service number
$service-id /= uint

$$endpoint-common-grp //= (
    ? ipn-well-known
    ? endpoint-schedule,
    ? endpoint-sec-require,
)

ipn-well-known = (
    2: uint
)
; An schedule for this endpoint validity
endpoint-schedule = (
    3: schedule
)
; A hint about the security need, if any, for this endpoint
endpoint-sec-require = (
    5: uint .bits endpoint-sec-flags
)
endpoint-sec-flags = &(
    need-bib: 0,
    need-bcb: 1,
    bind-primary: 2,
)

Figure 20: Endpoint Definition and Common Parameters CDDL

5.8.1. SAND Singleton Endpoint

Each participating node SHOULD register a singleton endpoint for the SAND application itself. This allows SAND Bundles to be transported with payload confidentiality to specific peer nodes. The endpoint SHOULD use the well-known service number from Section 8.2 when the Node ID uses the IPN scheme.¶

The Endpoint advertisement for the SAND singleton endpoint SHALL contain at least a Payload Security Required value.¶

8. IANA Considerations

Registration procedures referred to in this section are defined in [RFC8126].¶

8.1. Well-Known IMC Group and Service

Within the registry group of [IANA-BUNDLE], the registry titled "'imc' Scheme Well-known Group Numbers for BPv7" has been updated to include the following entry.¶

Table 13: 'imc' Scheme Well-known Group Numbers for BPv7
Value	Description	Reference
TBA1	SAND Participants	[This specification]

Within the registry group of [IANA-BUNDLE], the registry titled "'imc' Scheme Well-known Service Numbers for BPv7" has been updated to include the following entry.¶

Table 14: 'imc' Scheme Well-known Service Numbers for BPv7
Value	Description	Reference
TBA2	SAND Messaging	Section 4 of [This specification]

8.2. Well-Known IPN Service

Within the registry group of [IANA-BUNDLE], the registry titled "'ipn' Scheme URI Well-known Service Numbers for BPv7" has been updated to include the following entry.¶

Table 15: 'ipn' Scheme URI Well-known Service Numbers for BPv7
Value	Description	Reference
TBA3	SAND Messaging	Section 4 of [This specification]