Embryo Space Inc.

Brownsville TX United States of America embryospace@gmail.com

Internet Delay/Disruption Tolerant Networking DTN BPv7 custody receipt extension block This document defines the Custody Receipt Block, a Bundle Protocol Version 7 (BPv7) extension block that carries a chain of signed custody receipts inside the bundle those receipts describe. Each node that chooses to act as a custodian appends one receipt stating that it held the bundle, which node it received it from, and when it received and forwarded it. Nodes that do not implement the block forward it unchanged and are never required to read the payload or to sign anything. A verifier holding the custodians' public keys can check the chain after the fact and can report, rather than infer, any part of the route for which no receipt exists. The receipts are evidence for accounting and dispute resolution between operators. They are not Bundle Protocol administrative records and they do not replace or modify custody transfer signalling. About This Document An open reference implementation (Apache-2.0), test vectors and live interoperability results are at . The implementation uses block type 224 from the private and experimental range pending any assignment.

Introduction In a delay/disruption tolerant network, a bundle may be held for minutes to hours by nodes run by different operators before it reaches its destination. When something goes wrong (a bundle arrives late, is lost, or arrives altered), each operator holds only its own local logs. Those logs are not portable evidence: another party cannot verify them without trusting the operator that wrote them. BPv7 does not include custody transfer; reliable hop-by-hop transfer is addressed separately . Custody transfer answers "who is responsible for retransmission now". This document addresses a different question: "who can prove they held this bundle, and when". The mechanism is a signed receipt that travels with the bundle and can be verified by any party, at any later time, without contacting the nodes that produced it. The design follows the end-to-end argument : forwarding nodes do nothing beyond normal BPv7 block processing. Only nodes whose operators choose to act as custodians produce receipts, and after the first custodian none of them need to parse the payload. A verifier at the destination, or any later auditor, does the checking. This document is published as Experimental so that the format can be evaluated in multi-operator deployments. It reflects version 1 of an implementation that has been run through four independent BPv7 implementations; see .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Custodian:

A node whose operator has chosen to sign receipts for bundles it holds. Being a custodian in this sense is independent of custody transfer and implies no retransmission responsibility.

Forwarder:

Any BPv7 node that is not acting as a custodian for a given bundle. A forwarder may or may not implement this specification.

Origin:

The first custodian for a bundle. It establishes the subject identifiers that later receipts repeat.

Custody receipt (receipt):

A signed statement by one custodian that it held one bundle, defined in . A receipt is not a BPv7 administrative record ().

Receipt chain:

The ordered list of receipts carried in one Custody Receipt Block.

Uncustodied transit gap (gap):

A part of the route, visible to a verifier, for which no receipt exists.

Custody Receipt Format

Canonical Encoding Version 1 receipts are JSON objects . The canonical form of a receipt is its JSON serialization with the keys of every object sorted recursively by UTF-16 code unit, no insignificant whitespace, and standard JSON string escaping. Implementations MUST reject nesting deeper than 32 levels. The content identifier of a receipt is the string "0x" followed by the lowercase hexadecimal SHA-256 digest of the UTF-8 canonical form of the receipt with the members "claimId", "sig" and "signerPub" removed.

Members Custody receipt members

Member	Type	Meaning
kind	string	"custody/1"
payloadId	string	Identifier of the application data unit the bundle belongs to, set by the origin
bundleId	string	Subject identifier for this bundle, set by the origin ()
prevHop	string	EID of the node this custodian received the bundle from
thisHop	string	EID of this custodian
receivedAt	integer	Reception time, milliseconds since 1970-01-01T00:00:00Z
forwardedAt	integer	Forwarding time, same unit
claimId	string	The content identifier ()
sig	string	Base64 Ed25519 signature over the UTF-8 bytes of claimId
signerPub	string	Base64 DER SubjectPublicKeyInfo of the signing key

The member names are those of the deployed version 1 format and are retained unchanged so that existing receipts remain verifiable. A custodian SHOULD take prevHop from the Previous Node block () when one is present. An encoded receipt is about 530 octets.

Subject Identifiers The origin sets payloadId and bundleId. Every later custodian MUST copy both values from the first receipt in the block and MUST NOT need to parse the payload to do so. This is what allows a custodian to treat the application data unit as opaque, including when the payload is encrypted with a Block Confidentiality Block . A false subject identifier cannot pass verification, because the verifier derives the expected bundleId from the payload it receives (). The derivation is application specific. The reference implementation carries a payload split into chunks under a Merkle root and uses the content identifier of {payloadId, index, leafHex} for the chunk carried by the bundle.

The Custody Receipt Block

Block Format The block-type code is TBD1 (). Implementations of this version use 224, from the private and experimental range, until a code point is assigned. The block-type-specific data is a CBOR array of text strings. Each text string is the canonical form of one signed receipt, in the order the receipts were appended. Carrying the canonical form as an opaque string means signatures verify over the exact octets carried, with no re-serialization. custody-receipt-block-data = [ + tstr ] ; canonical JSON receipts A bundle MUST NOT contain more than one Custody Receipt Block.

Block Processing Control Flags The block MUST have "Block must be replicated in every fragment" set, and MUST have "Delete bundle if block can't be processed" and "Discard block if it can't be processed" clear. A node that does not implement this specification therefore retains the block and forwards it unchanged (). A CRC-32C is RECOMMENDED.

Processing

Custodian Behavior A custodian that holds a bundle and chooses to sign for it:

1. If no Custody Receipt Block is present, acts as the origin: determines payloadId and bundleId and adds the block.
2. Otherwise copies payloadId and bundleId from the first receipt.
3. Appends its own signed receipt to the array and recomputes the block CRC. It MUST NOT alter or reorder earlier receipts.

Which bundles a node signs for is local policy (for example, by source, destination, service agreement or the presence of the block). No new naming scheme is needed.

Forwarder Behavior A forwarder performs normal BPv7 processing. It does not read the payload, does not sign, and need not implement this specification.

Verification A verifier MUST derive bundleId from the payload it received, never from the receipts. It then checks every receipt: the content identifier MUST equal claimId; the signature MUST verify under signerPub; bundleId MUST equal the derived value; and signerPub MUST equal a key the verifier obtained independently for the EID in thisHop. A receipt that fails any of these checks is a verification failure. Two modes are defined:

Pinned route:

The verifier knows the expected ordered list of custodians. The number of receipts MUST equal the length of the list, each thisHop MUST match its position, and each prevHop after the first MUST equal the previous receipt's thisHop.

Audit:

The verifier knows the custodians' keys but not the route. Wherever a receipt's prevHop differs from the previous receipt's thisHop (or from the expected origin), and wherever the node that delivered the bundle (from its Previous Node block) differs from the last receipt's thisHop, the verifier MUST report a gap naming the last signed hop, the next signed hop, and the unsigned node observed. A result with any gap MUST NOT be reported as complete.

A missing receipt is reported as missing and is never inferred. A receipt that is present but invalid is a failure, not a gap.

Interaction with BPSec Because every custodian modifies the Custody Receipt Block, a Block Integrity Block MUST NOT target it. Receipts carry their own signatures. A BIB that targets the payload or the primary block is unaffected by appending receipts, since appending changes neither. A Block Confidentiality Block MUST NOT target the Custody Receipt Block, because later custodians must read the first receipt.

Implementation Status Note to the RFC Editor: please remove this section before publication, as described in . One implementation exists: dtn-custody-demo, Embryo Space Inc., Apache-2.0, JavaScript (Node.js) with no third-party dependencies, . It includes its own BPv7 codec, which was checked byte for byte against the uD3TN project's Python library. In live runs the block was carried byte-identical across a scheduled contact gap by uD3TN, NASA HDTN, JPL ION and Aalyria Hardy, none of which implement it. The BIB-HMAC-SHA2 code reproduces the RFC 9173 Appendix A vectors byte for byte. A payload BIB was carried through the same four implementations and verified before and after custodians appended receipts. Results and commands are in the repository (transport/bpv7/RESULTS.md). Testing against JPL ION as a BIB acceptor and signer found that ION builds the integrity-protected plaintext for a payload target from the whole serialized block rather than from the block-type-specific data as a byte string (), and omits the SHA variant parameter while signing with HMAC 256/256. The reference implementation interoperates with ION through an optional mode and uses the RFC 9173 construction by default. This is noted because the two constructions cannot verify each other's BIBs.

Open Issues

• Encoding. A CBOR receipt signed with COSE_Sign1 would fit BPv7 better than canonical JSON and would be much smaller. Version 1 keeps JSON for compatibility with receipts already produced.
• Subject identifier. Binding receipts to the BPv7 bundle identity (source EID, creation timestamp and, for fragments, offset) in addition to an application identifier would let verifiers without application knowledge check the binding.
• Fragmentation. Receipts describe the whole bundle. Behavior for a custodian that holds only some fragments is not yet defined.
• Growth. The block grows by one receipt per custodian. Batching receipts per contact under a Merkle root, as the reference implementation does outside the block, may be preferable on long routes.

Security Considerations Key distribution. Receipts are only as meaningful as the binding between a custodian EID and its key. Verifiers MUST obtain keys independently of the receipts and MUST NOT trust signerPub on its own. Stripping. Any forwarder can remove the block or truncate the array and recompute the CRC. This cannot be prevented by the block itself; it is detected because the removed custodians appear as gaps. A verifier MUST treat a gap as absence of evidence, not as evidence of absence. Replay. A receipt copied to another bundle fails verification because bundleId is derived from the received payload. False times. A custodian can sign false receivedAt and forwardedAt values. Receipts bind a custodian to its claims; they do not prove the claims are true. Inconsistent times across adjacent receipts can be flagged by the verifier. Denial of service. Verification cost and block size grow linearly with the number of receipts. A verifier SHOULD bound the number of receipts it will process. Privacy. Receipts reveal the custodians on a route and their timing to anyone who can read the bundle.

IANA Considerations IANA is requested to assign one value (TBD1) in the "Bundle Block Types" registry of the "Bundle Protocol" registry group:

Value	Description	Reference
TBD1	Custody Receipt Block	This document

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. National Institute of Standards and Technology Informative References This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations. These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. IPNGROUP Spatiam Corporation SAIC University of Bologna This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence layer" protocol that tunnels BP "bundles" through encapsulating bundles. The services provided by the BIBE convergence-layer protocol adapter encapsulate an outbound BP "bundle" in a BIBE convergence-layer protocol data unit for transmission as the payload of a bundle. Security measures applied to the encapsulating bundle may augment those applied to the encapsulated bundle. The protocol includes a mechanism for recovery from loss of an encapsulating bundle, called Bundle Retransmission Methods (BRM). This mechanism is adapted from the custody transfer procedures described in the experimental Bundle Protocol (version 6) specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050.