MVPS Maritime and Tactical-Edge Profile: Coherence Monitoring under Disconnected, Intermittent, Limited Connectivity and GNSS-Denied Holdover
draft-melegassi-ippm-mvps-maritime-edge-00

Network Working Group                                       L. Melegassi
Internet-Draft                                                  Catellix
Intended status: Informational                              28 May 2026
Expires: 29 November 2026

            MVPS Maritime and Tactical-Edge Profile: Coherence
            Monitoring under Disconnected, Intermittent, Limited
                  Connectivity and GNSS-Denied Holdover
                draft-melegassi-ippm-mvps-maritime-edge-00

Abstract

   This document defines a deployment profile of Multi-Vantage Path
   Snapshot (MVPS) for fleets and fixed installations operating in
   Disconnected, Intermittent, Limited (DIL) environments where Global
   Navigation Satellite System (GNSS) time may be denied -- for example
   naval and maritime critical infrastructure and other tactical-edge
   networks.  The profile is DEFENSIVE: it concerns detection of
   coherence anomalies in the network and timing telemetry (cyber
   intrusion, comms tampering, and positioning/timing (PNT) spoofing).
   It defines no navigation, targeting, or kinetic function.

   MVPS promotes its detection theorems to any surface satisfying its
   five axioms.  At sea only one axiom is at risk: A1, the bounded
   joint-clock-skew requirement, because oscillators drift under GNSS
   denial and links are intermittent.  This document proves A1 still
   holds on an enlarged coherence tick under explicit datasheet-grounded
   budgets, after which the core theorems inherit verbatim via the MVPS
   Architecture-Invariance Theorem.  The closed-form result shows the
   binding constraint is store-and-forward latency, not clock drift. All
   properties are validated by scripts/validate_maritime_edge.py (7/7
   PASS, exit 0) and recorded in evidence/maritime_edge_receipt.json.

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.

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.  Code Components extracted from this
   document must include Revised BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Defensive Scope and Non-Goals . . . . . . . . . . . . . .   3
     1.2.  Which Axiom Is at Risk  . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The DIL Joint-Skew Model  . . . . . . . . . . . . . . . . . .   5
   4.  Re-establishing Axiom A1 (Lemma L-MAR-1)  . . . . . . . . . .   6
   5.  Maximum Tolerable GNSS Denial (Lemma L-MAR-2) . . . . . . . .   6
   6.  Store-and-Forward Tick Assignment (Lemma L-MAR-4) . . . . . .   7
   7.  Inheritance of the Core Theorems  . . . . . . . . . . . . . .   8
   8.  Byzantine and Destroyed Vantages  . . . . . . . . . . . . . .   8
   9.  PNT/GNSS Spoofing (Conjecture C-MAR-1)  . . . . . . . . . . .   9
   10. Operational Logging . . . . . . . . . . . . . . . . . . . . .   9
   11. Numerical Receipt . . . . . . . . . . . . . . . . . . . . . .  10
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     14.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Worked Budgets (Normative) . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   MVPS detects network-propagating anomalies by measuring the COHERENCE
   of an observed state across multiple spatially independent vantages.
   Its theorems are surface-independent: they hold where the five MVPS
   axioms hold, by the Architecture-Invariance Theorem
   [I-D.melegassi-iab-mvps-architecture].

   Maritime/tactical-edge deployments are exactly the critical, high-
   stakes environments MVPS was built for, but they stress the timing
   assumptions: ships and remote nodes lose connectivity for long
   stretches (Disconnected), regain it briefly (Intermittent) and at low
   rate (Limited), and may operate with GNSS time denied by jamming or
   spoofing.  This profile shows MVPS still applies, by re-establishing
   the one axiom that DIL puts at risk and inheriting the rest.

1.1.  Defensive Scope and Non-Goals

   This profile is strictly DEFENSIVE.  It concerns the detection of
   anomalies in network and timing telemetry: coordinated intrusion,
   communications tampering, and positioning/timing (PNT) spoofing.

   This document does NOT define and MUST NOT be claimed to define:

   o  any navigation, guidance, fire-control, or targeting function;

   o  any kinetic capability;

   o  any output other than coherence-anomaly detection and audit logs.

   The mathematics here is identical in kind to the terrestrial and
   broadband-mesh profiles; only the timing budget differs.

1.2.  Which Axiom Is at Risk

   MVPS rests on axioms A1..A5.  A2 (bundle), A3 (coherence axes), A4,
   and A5 (Byzantine-tolerant aggregator) are structural and carry over
   to sea unchanged.  Only A1 -- the requirement that the joint clock
   skew across vantages stay below the coherence tick -- is stressed
   by GNSS denial (oscillator drift) and intermittency (store-and-
   forward delay).  Sections 3-6 re-establish A1; Section 7 inherits the
   theorems.

2.  Terminology

   DIL:  Disconnected, Intermittent, Limited connectivity.

   Holdover:  free-running operation of a local oscillator while GNSS or
      PTP discipline is unavailable.

   eps_sync:  residual time-sync error at last GNSS/PTP contact.

   rho:  holdover fractional-frequency drift rate (s/s).

   Delta_d:  maximum GNSS-denied (disconnect) interval before re-sync.

   tau_store:  maximum store-and-forward delivery latency for a source-
      timestamped bundle.

   T_tick_eff:  the enlarged coherence tick chosen for the deployment.

   The key words "MUST", "MUST NOT", "SHOULD", "MAY" in this document
   are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]
   when, and only when, they appear in all capitals.

3.  The DIL Joint-Skew Model

   A vantage that loses GNSS runs on a holdover oscillator that
   accumulates time offset bounded by rho * Delta_d over a denial
   interval Delta_d (datasheet OCXO ~ 1e-8 s/s; TCXO ~ 1e-6 s/s).  A
   bundle is timestamped at the SOURCE and forwarded later; ordering is
   recovered from the source timestamp.  The effective joint skew is

      skew_eff = 2 * ( eps_sync + rho * Delta_d ) + tau_store .

   The factor 2 covers two vantages drifting in opposite directions; the
   tau_store term covers the worst-case delivery delay absorbed by the
   tick window (Section 6).

4.  Re-establishing Axiom A1 (Lemma L-MAR-1)

   Axiom A1 holds on tick T_tick_eff iff

      skew_eff = 2*(eps_sync + rho*Delta_d) + tau_store  <  T_tick_eff.

   For representative budgets (eps_sync = 1 ms, tau_store = 5 s,
   T_tick_eff = 60 s):

      OCXO  (rho 1e-8, Delta_d 24 h): skew_eff = 5.0037 s  < 60 s
      TCXO  (rho 1e-6, Delta_d  1 h): skew_eff = 5.0092 s  < 60 s
      stress(rho 1e-5, Delta_d 24 h, tau_store 50 s): 51.748 s < 60 s

   All satisfy A1 (validator check L-MAR-1).

5.  Maximum Tolerable GNSS Denial (Lemma L-MAR-2)

   Solving skew_eff = T_tick_eff for the denial interval gives the
   closed-form tolerance

      Delta_d_max = ( T_tick_eff - tau_store - 2*eps_sync ) / ( 2*rho ).

   For the TCXO budget above, Delta_d_max ~ 318 days.  The practical
   reading is important and honest: with any reasonable oscillator the
   BINDING constraint on A1 is the store-and-forward latency tau_store,
   not clock drift.  The sea problem is the LINK, not the clock.

6.  Store-and-Forward Tick Assignment (Lemma L-MAR-4)

   A source-timestamped bundle delivered after tau_store is assigned to
   its correct tick window (index floor(source_ts / T_tick_eff)) iff

      tau_store  <  T_tick_eff.

   If tau_store >= T_tick_eff, a delayed bundle can land in the wrong
   window and the joint observation breaks; the operator MUST then
   enlarge T_tick_eff.  The validator confirms a feasible budget is
   accepted and that an infeasible budget (tau_store = 70 s,
   T_tick_eff = 60 s; skew_eff = 70.009 s) is correctly rejected.

7.  Inheritance of the Core Theorems

   If A1 holds (Section 4) and the compromised-vantage fraction f < 1/2,
   then by the Architecture-Invariance Theorem
   [I-D.melegassi-iab-mvps-architecture] the core results inherit
   verbatim on the maritime surface:

      T1   multi-vantage D^2 dominates per-vantage max-z;
      T2   Phi_D concentration under the null;
      T3'  empirical-quantile false-alarm calibration;
      T9   Byzantine robustness of the geometric-median aggregator.

   No core theorem is re-derived; the profile only supplies the A1
   premise (validator check A-MAR-INHERIT).

8.  Byzantine and Destroyed Vantages

   A maritime fleet must assume some vantages are compromised, lying, or
   physically lost.  For f < 1/2 the geometric-median aggregator has
   finite max-bias b(f) = C * f/(1-2f) (after [Minsker]; MVPS imported
   result I12), diverging only as f -> 1/2.  A vantage that goes silent
   is treated as missing, not as zero, preserving the bound (validator
   check B-MAR-1: b(0.2)=0.333, b(0.4)=2.000).

9.  PNT/GNSS Spoofing (Conjecture C-MAR-1)

   It is plausible that coordinated GNSS spoofing injects a rank-low,
   correlated clock-offset signature across vantages that the multi-
   vantage detector flags before any single vantage alarms.  This is
   stated as a CONJECTURE, not a theorem, with a falsification protocol
   (observable: cross-vantage correlated offset vs per-vantage max-z;
   data: fleet PTP/GNSS telemetry plus a controlled spoofing testbed;
   test: Wilson 95% lower bound on detection-time gain > 0; blocker:
   access to a controlled spoofing range).  The profile's guarantees do
   NOT depend on this conjecture.

10.  Operational Logging

   Deployments SHOULD log events using the MVPS operational log format
   [I-D.melegassi-opsawg-mvps-logging]: append-only, hash-chained, and
   anchored opportunistically whenever connectivity returns. Because the
   link is intermittent, the anchoring cadence of that format maps
   naturally onto re-connection events; records between anchors retain
   edit/reorder/delete evidence and gain truncation evidence at the next
   anchor.

11.  Numerical Receipt

   scripts/validate_maritime_edge.py evaluates seven checks (L-MAR-1..4,
   A-MAR-INHERIT, B-MAR-1, C-MAR-1) over the budgets above and writes
   evidence/maritime_edge_receipt.json with per-scenario skew values,
   the closed-form denial tolerance, the inherited theorem list, the
   explicit defensive non-claims, and a SHA-256 of its own canonical
   body.  All seven checks PASS (exit 0).

12.  Security Considerations

   The profile is a detection and audit capability; no kinetic or
   targeting surface.  Its security value is the early, coherent
   detection of intrusion, comms tampering, and timing manipulation
   across a contested fleet, with a tamper-evident audit trail
   (Section 10).

   GNSS denial is treated as an operating condition, not merely a fault:
   the holdover budget (Section 4) and the closed-form denial tolerance
   (Section 5) make the time assumptions explicit, auditable. Spoofing
   detection itself is a conjecture (Section 9) and MUST NOT be relied
   upon as a guarantee. Quantum-era integrity of logs/anchors follows
   the Proof Envelope [I-D.melegassi-ippm-mvps-proof-envelope].

13.  IANA Considerations

   This document has no IANA actions.

14.  References

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

   [I-D.melegassi-iab-mvps-architecture]
              Melegassi, L., "MVPS Architecture Invariance",
              draft-melegassi-iab-mvps-architecture-00, 2026.

14.2.  Informative References

   [I-D.melegassi-opsawg-mvps-logging]
              Melegassi, L., "The MVPS Operational Log Format",
              draft-melegassi-opsawg-mvps-logging-00, 2026.

   [I-D.melegassi-ippm-mvps-proof-envelope]
              Melegassi, L., "MVPS Proof Envelope", draft-melegassi-
              ippm-mvps-proof-envelope-00, 2026.

   [Minsker]  Minsker, S., "Geometric median and robust estimation in
              Banach spaces", Bernoulli 21(4), 2015.

Appendix A.  Worked Budgets (Normative)

   Three budgets of Section 4 (OCXO, TCXO, stress) and the infeasible
   control of Section 6 are the normative vectors. An implementation
   claiming conformance MUST reproduce, for each, the skew_eff value and
   the A1 verdict emitted by scripts/validate_maritime_edge.py.

Author's Address

   Leonardo Melegassi
   Catellix
   Brazil
   Email: melegassi@catellix.com