A Forward-Compatible Extension and Capability-Negotiation Mechanism for the MVPS Bundle Format
draft-melegassi-ippm-mvps-extensions-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Leonardo Melegassi Costa | ||
| Last updated | 2026-05-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-melegassi-ippm-mvps-extensions-00
IPPM Working Group L. Melegassi
Internet-Draft Catellix
Updates: draft-melegassi-ippm-mvps-bundle-00 (if approved)
Intended status: Standards Track 28 May 2026
Expires: 29 November 2026
A Forward-Compatible Extension and Capability-Negotiation
Mechanism for the MVPS Bundle Format
draft-melegassi-ippm-mvps-extensions-00
Abstract
This document defines a forward-compatible extension point for the
Multi-Vantage Path Synchrony (MVPS) bundle format. The base format
already provides a schema version, a path-fingerprint version
prefix, and an IANA "MVPS Bundle Capability Flags" registry, but its
serialization is closed to unknown fields. This document adds a
single, typed, namespaced "extensions" object and a processing rule
(ignore-but-preserve), and specifies how extensions interact with
the canonical hash and the MVPS Proof Envelope.
The mechanism is designed so that an extension can never become a
tamper vector and can never alter the core coherence detector: the
detection statistic D^2 is, by construction, a function of the core
bundle only. Every property in this document is backed by a
machine-checkable numerical receipt.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
This Internet-Draft will expire on 29 November 2026.
Melegassi Expires 29 Nov 2026 [Page 1]
Internet-Draft MVPS Extensions May 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. What the Base Format Already Provides . . . . . . . . . . . 3
4. The "extensions" Object . . . . . . . . . . . . . . . . . . 4
5. Processing Rules (Ignore-but-Preserve) . . . . . . . . . . 4
6. Interaction with the Canonical Hash and Proof Envelope . . 5
7. Core-Detector Invariance . . . . . . . . . . . . . . . . . 5
8. Versioning: Minor vs Major . . . . . . . . . . . . . . . . 6
9. Capability Negotiation . . . . . . . . . . . . . . . . . . 6
10. Worked Properties (Numerical Receipt) . . . . . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . 7
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
"How is it versioned and extended?" is among the first questions a
reviewer asks of any wire format. The MVPS bundle format answers
the versioning half (a schema-version string and a fingerprint
version prefix) and reserves an IANA capability-flags registry, but
its JSON serialization sets "additionalProperties": false and is
therefore CLOSED to unknown fields. Three things were missing:
o a defined PLACE for an extension payload to live;
o a forward-compatibility PROCESSING RULE for consumers that do not
understand an extension; and
o a specification of how extensions interact with the canonical
hash and the MVPS Proof Envelope.
This document supplies all three with a single controlled open
point and proves that the result is deterministic, tamper-evident,
and safe with respect to the core coherence detector. It Updates
the bundle format when approved.
Melegassi Expires 29 Nov 2026 [Page 2]
Internet-Draft MVPS Extensions May 2026
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Core bundle: the bundle fields the detector reads (schema_version,
bundle_id, destination, coordination_window, snapshots).
Core projection: the bundle with the "extensions" member removed.
Extension: a namespaced member of the "extensions" object.
3. What the Base Format Already Provides
For the avoidance of doubt, the following already exist in the base
bundle format and are NOT introduced here:
o schema-version, a string matching "mvps-bundle-v[0-9]+";
o the path-fingerprint version prefix "v1|", with the rule that a
future fingerprint algorithm MUST use a different prefix;
o the IANA "MVPS Bundle Capability Flags" registry, with policy
Specification Required [RFC8126].
This document builds on those rather than replacing them.
4. The "extensions" Object
A bundle MAY contain one top-level member named "extensions" whose
value is a JSON object. Each member key MUST be either:
o a reverse-DNS namespace matching the regular expression
^[a-z0-9-]+(\.[a-z0-9-]+)+$ (e.g. "com.example.geo"); or
o the name of a capability registered in the IANA "MVPS Bundle
Capability Flags" registry.
Each member value is an opaque JSON value defined by the owning
namespace or registered specification. A producer MUST NOT place
extension data anywhere other than under "extensions"; the rest of
the bundle remains closed ("additionalProperties": false), so
"extensions" is the SINGLE admission point for new data.
The registry tells a consumer WHICH capabilities exist; the
"extensions" object tells it WHERE the corresponding payload is.
Melegassi Expires 29 Nov 2026 [Page 3]
Internet-Draft MVPS Extensions May 2026
5. Processing Rules (Ignore-but-Preserve)
A consumer that does not understand an extension namespace:
o MUST ignore that extension for the purpose of semantics (it MUST
NOT alter the consumer's decisions); and
o MUST preserve that extension byte-exactly if it re-serializes or
relays the bundle, so that the canonical hash and any Proof
Envelope binding remain valid.
A consumer MUST NOT reject a bundle solely because it carries an
unknown extension namespace, provided the bundle is otherwise valid
and the "extensions" keys satisfy Section 4.
Together these rules are the standard "ignore unknown, but preserve"
forward-compatibility discipline; their composition is a hash-stable
round-trip (Section 10).
6. Interaction with the Canonical Hash and Proof Envelope
Extensions ARE part of the canonicalized bundle. The canonical
form is computed with JCS [RFC8785] over the WHOLE bundle, including
"extensions"; the path-fingerprint of the base format is unchanged
(it is computed over hops, not over extensions).
Consequences:
o Editing or removing any extension changes the canonical bytes and
therefore the SHA-256 digest, so an extension cannot be silently
stripped or altered without detection.
o When a bundle is bound by the MVPS Proof Envelope
[I-D.melegassi-ippm-mvps-proof-envelope], its extensions are
inside the bound Merkle leaf and inherit the same tamper-evidence
and (optional) post-quantum signature protection.
A specification MAY define an extension as "fingerprint-affecting"
only by also updating the fingerprint version prefix per the base
format; absent that, extensions MUST NOT change the fingerprint.
7. Core-Detector Invariance
The coherence statistic D^2 is computed over the CORE PROJECTION of
the bundle only. Therefore:
D^2(bundle) = D^2(core projection of bundle)
for every possible "extensions" content. An extension -- even one
whose payload embeds a field named like a core field -- CANNOT move
the detector. This is a design invariant, not a convention: a
Melegassi Expires 29 Nov 2026 [Page 4]
Internet-Draft MVPS Extensions May 2026
conformant implementation MUST compute D^2 from the core projection
and MUST NOT read "extensions" into the detector input.
This property is what makes the open point safe: extensions are a
transport and audit feature, never a covert channel into a detection
decision.
8. Versioning: Minor vs Major
o MINOR change: adding or removing an extension while keeping
schema-version unchanged. Minor changes are forward-compatible
by Section 5 and 7; a v1 consumer continues to operate.
o MAJOR change: changing schema-version (still matching
"mvps-bundle-v[0-9]+"). A major change signals an
incompatibility a v1 consumer MAY reject. Major changes are the
mechanism for evolutions that the extension point cannot express
(e.g. a change to a core field or to the fingerprint algorithm).
Implementations MUST distinguish the two by the schema-version
string and MUST NOT treat a minor extension addition as a major
break.
9. Capability Negotiation
A deployment advertises support for a capability by its registered
flag; a bundle carries the corresponding data under the matching
"extensions" namespace. Two properties hold:
o NON-INTERFERENCE: distinct namespaces are distinct object keys,
so two extensions commute under JCS and cannot perturb each
other or the core.
o MONOTONICITY: enabling a capability can only ADD behavior under
its own namespace; an advertised capability whose namespace key
is absent from a given bundle is a no-op for that bundle.
Capability negotiation is therefore additive and order-free, which
keeps interoperability analysis tractable as the registry grows.
10. Worked Properties (Numerical Receipt)
The properties above are checked by
scripts/validate_extension_negotiation.py (exit 0, 7/7), with the
receipt at evidence/extension_negotiation_receipt.json:
T-EXT-CANON JCS over bundle+extensions is insertion-order
independent;
T-EXT-BIND editing or stripping an extension flips the
SHA-256 digest;
Melegassi Expires 29 Nov 2026 [Page 5]
Internet-Draft MVPS Extensions May 2026
T-EXT-CORE-INV D^2 is unchanged even under a malicious nested
"metrics" injection inside an extension;
T-EXT-IGNORE ignore-for-semantics + preserve-for-hash compose
to a stable round-trip;
T-EXT-GATE distinct namespaces commute; an unactivated flag
is inert;
T-EXT-VERSION minor vs major are syntactically distinguishable;
T-EXT-CLOSED the legacy closed schema rejects extensions; the
new schema admits only namespaced keys under
"extensions".
11. Security Considerations
The central security property is core-detector invariance
(Section 7): an extension cannot influence the coherence decision,
so a malicious or buggy extension cannot cause a false alarm or
suppress a real one through the detector. Extensions are inside the
canonical hash (Section 6), so they cannot be silently inserted,
altered, or stripped when the bundle is bound by the Proof Envelope.
An extension MAY carry sensitive data; producers SHOULD apply the
same privacy handling as for core fields, and a redaction-style
extension SHOULD commit to redacted content by hash rather than
omitting it, so that the canonical binding remains verifiable.
The "extensions" key policy (Section 4) constrains the open surface
to validated namespaces; implementations MUST reject bundles whose
"extensions" keys do not match Section 4, to prevent the open point
from degrading into an arbitrary free-form field.
12. IANA Considerations
This document adds no new registry. It clarifies that the existing
"MVPS Bundle Capability Flags" registry (Specification Required)
governs the names usable as keys of the "extensions" object, in
addition to reverse-DNS namespaces. Registrations SHOULD state the
namespace key, the payload schema, and whether the extension is
fingerprint-affecting (Section 6).
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
Melegassi Expires 29 Nov 2026 [Page 6]
Internet-Draft MVPS Extensions May 2026
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234,
May 2011.
13.2. Informative References
[I-D.melegassi-ippm-mvps-bundle]
Melegassi, L., "Multi-Vantage Path Synchrony Bundle
Envelope and Vector Algebra", Work in Progress.
[I-D.melegassi-ippm-mvps-proof-envelope]
Melegassi, L., "MVPS Proof Envelope with Post-Quantum
Protection", Work in Progress.
Author's Address
Leonardo Melegassi
Catellix
Brazil
Email: melegassi@catellix.com
Melegassi Expires 29 Nov 2026 [Page 7]