



Routing Area Working Group                                    J. E. W. V
Internet-Draft                               Department of the Air Force
Updates: draft-conduit-tunnel-fabric (if                19 February 2026
         approved)                                                      
Intended status: Standards Track                                        
Expires: 23 August 2026


                      Underlay for IPsec Transport
                 draft-willman-rtgwg-conduit-tunnels-01

Abstract

   This document specifies CONDUIT, a tunnel fabric management protocol
   for tactical and enterprise networks operating over heterogeneous
   Wide Area Network (WAN) links.  CONDUIT automates the lifecycle
   management of IPsec tunnels, monitors tunnel health through active
   probing, and publishes quality metrics to enable Segment Routing over
   IPv6 (SRv6) based traffic engineering.

   CONDUIT follows a strict separation of concerns: it manages the
   underlay tunnel fabric while delegating all traffic engineering
   decisions to SRv6.  This architecture simplifies network operations,
   enables rapid adaptation to changing WAN conditions, and leverages
   standard SRv6 capabilities including Flexible Algorithm (Flex-Algo)
   and Topology-Independent Loop-Free Alternate (TI-LFA).

   The protocol is fully programmable via gRPC and mandates compliance
   with Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)
   cryptographic requirements.

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 23 August 2026.




V                        Expires 23 August 2026                 [Page 1]

Internet-Draft        Underlay for IPsec Transport         February 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Design Philosophy . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   5
     1.4.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   6
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  System Overview . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Tunnel Fabric Concept . . . . . . . . . . . . . . . . . .   8
     3.3.  Separation of Concerns  . . . . . . . . . . . . . . . . .   9
   4.  Cryptographic Requirements  . . . . . . . . . . . . . . . . .  10
     4.1.  CNSA 2.0 Compliance . . . . . . . . . . . . . . . . . . .  10
     4.2.  Mandatory Algorithms  . . . . . . . . . . . . . . . . . .  10
     4.3.  Prohibited Algorithms . . . . . . . . . . . . . . . . . .  11
     4.4.  IPsec Profile . . . . . . . . . . . . . . . . . . . . . .  12
     4.5.  Certificate Requirements  . . . . . . . . . . . . . . . .  12
     4.6.  TLS Requirements  . . . . . . . . . . . . . . . . . . . .  13
   5.  Tunnel Fabric Management  . . . . . . . . . . . . . . . . . .  13
     5.1.  Tunnel Lifecycle States . . . . . . . . . . . . . . . . .  13
     5.2.  Tunnel Establishment Policy . . . . . . . . . . . . . . .  14
     5.3.  Tunnel Naming Convention  . . . . . . . . . . . . . . . .  15
     5.4.  Full Mesh Fabric  . . . . . . . . . . . . . . . . . . . .  15
   6.  Health Monitoring . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Probe Mechanism . . . . . . . . . . . . . . . . . . . . .  16
     6.2.  Probe Packet Format . . . . . . . . . . . . . . . . . . .  16
     6.3.  Metrics Calculation . . . . . . . . . . . . . . . . . . .  18
       6.3.1.  Round-Trip Time . . . . . . . . . . . . . . . . . . .  18
       6.3.2.  Jitter  . . . . . . . . . . . . . . . . . . . . . . .  19
       6.3.3.  Packet Loss . . . . . . . . . . . . . . . . . . . . .  19



V                        Expires 23 August 2026                 [Page 2]

Internet-Draft        Underlay for IPsec Transport         February 2026


     6.4.  Probe Scheduling  . . . . . . . . . . . . . . . . . . . .  19
     6.5.  Tunnel State Determination  . . . . . . . . . . . . . . .  20
   7.  Metric Publishing . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Publishing Methods  . . . . . . . . . . . . . . . . . . .  20
     7.2.  Interface Metric Calculation  . . . . . . . . . . . . . .  21
     7.3.  IGP TE Extensions . . . . . . . . . . . . . . . . . . . .  21
     7.4.  Flex-Algo Integration . . . . . . . . . . . . . . . . . .  22
     7.5.  SRLG Assignment . . . . . . . . . . . . . . . . . . . . .  23
   8.  Control Protocol  . . . . . . . . . . . . . . . . . . . . . .  23
     8.1.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  23
     8.2.  Message Header  . . . . . . . . . . . . . . . . . . . . .  24
     8.3.  Message Types . . . . . . . . . . . . . . . . . . . . . .  25
     8.4.  HELLO Message . . . . . . . . . . . . . . . . . . . . . .  25
     8.5.  WAN Descriptor  . . . . . . . . . . . . . . . . . . . . .  26
     8.6.  Message Authentication  . . . . . . . . . . . . . . . . .  28
     8.7.  Anti-Replay Protection  . . . . . . . . . . . . . . . . .  29
   9.  SRv6 Integration  . . . . . . . . . . . . . . . . . . . . . .  29
     9.1.  Tunnel Interfaces as SRv6 Adjacencies . . . . . . . . . .  29
     9.2.  Flex-Algo Tunnel Assignment . . . . . . . . . . . . . . .  30
     9.3.  Traffic Steering  . . . . . . . . . . . . . . . . . . . .  31
   10. High Availability . . . . . . . . . . . . . . . . . . . . . .  31
     10.1.  HA Architecture  . . . . . . . . . . . . . . . . . . . .  31
     10.2.  Synchronized State . . . . . . . . . . . . . . . . . . .  32
     10.3.  Failover Behavior  . . . . . . . . . . . . . . . . . . .  32
   11. gRPC API  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
     11.1.  Service Overview . . . . . . . . . . . . . . . . . . . .  33
     11.2.  Authentication and Authorization . . . . . . . . . . . .  33
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  33
     12.1.  Cryptographic Security . . . . . . . . . . . . . . . . .  33
     12.2.  Threat Mitigations . . . . . . . . . . . . . . . . . . .  34
     12.3.  Operational Security . . . . . . . . . . . . . . . . . .  34
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
     13.1.  UDP Port Allocation  . . . . . . . . . . . . . . . . . .  35
     13.2.  WAN Type Registry  . . . . . . . . . . . . . . . . . . .  35
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     14.2.  Informative References . . . . . . . . . . . . . . . . .  36
   Appendix A.  WAN Type Characteristics . . . . . . . . . . . . . .  37
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  37
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

1.1.  Problem Statement

   Modern tactical and enterprise networks increasingly operate over
   diverse Wide Area Network (WAN) links with varying characteristics:




V                        Expires 23 August 2026                 [Page 3]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Satellite Communications (SATCOM): Both Geostationary (GEO) with
      approximately 600ms round-trip latency and Low Earth Orbit (LEO)
      with 20-40ms latency, limited bandwidth, and weather sensitivity.

   *  Line-of-Sight (LOS) Radio: Low latency, high mobility, but
      terrain-dependent coverage.

   *  Cellular Networks (LTE/5G): Variable quality, broad coverage, but
      may traverse untrusted infrastructure.

   *  High Frequency (HF) Radio: Very low bandwidth but extended range
      with atmospheric effects.

   *  Wired Connections: When available at fixed installations.

   Managing IPsec tunnels across these heterogeneous links presents
   significant operational challenges:

   1.  Links appear and disappear as network elements move or
       environmental conditions change.

   2.  Link quality varies dramatically and unpredictably.

   3.  Multiple paths to each destination may exist simultaneously.

   4.  Failover must complete within sub-second timeframes to maintain
       voice and command-and-control (C2) applications.

   5.  All traffic must be encrypted using approved cryptographic
       algorithms.

   Existing approaches typically couple tunnel management with traffic
   engineering decisions, creating unnecessary complexity and limiting
   interoperability with standard routing protocols.

1.2.  Design Philosophy

   CONDUIT adheres to a strict separation of concerns:

   *  SRv6 Traffic Engineering Layer: Responsible for all path selection
      decisions, including Flexible Algorithm computation, fast reroute
      via TI-LFA, traffic class steering, and load balancing across
      equal-cost paths.

   *  CONDUIT Tunnel Fabric Layer: Responsible for tunnel lifecycle
      management (creation, maintenance, deletion), health monitoring
      through active probing, metric publication to enable SRv6-based
      decisions, and IPsec security association management.



V                        Expires 23 August 2026                 [Page 4]

Internet-Draft        Underlay for IPsec Transport         February 2026


   This separation ensures that CONDUIT does not duplicate functionality
   available in standard SRv6 implementations while providing essential
   tunnel management capabilities that SRv6 requires but does not
   natively provide.

1.3.  Design Goals

   The following quantitative goals guide CONDUIT's design:

    +=====================+===========================================+
    | Parameter           | Requirement                               |
    +=====================+===========================================+
    | Tunnel Scale        | Support for 1000+ tunnels per node        |
    +---------------------+-------------------------------------------+
    | Failover Detection  | Less than 500ms to detect tunnel failure  |
    +---------------------+-------------------------------------------+
    | Metric Publish Rate | 1 Hz default, 10 Hz burst capability      |
    +---------------------+-------------------------------------------+
    | Cryptographic Suite | Full CNSA 2.0 compliance                  |
    +---------------------+-------------------------------------------+
    | API Coverage        | 100% of functionality accessible via gRPC |
    +---------------------+-------------------------------------------+
    | Probe Overhead      | Less than 1% of available bandwidth       |
    +---------------------+-------------------------------------------+

                                  Table 1

1.4.  Scope

   This document specifies:

   *  Tunnel lifecycle management procedures

   *  Health monitoring through active probing

   *  Metric calculation and publishing mechanisms

   *  Control protocol message formats

   *  Integration requirements for SRv6-based traffic engineering

   *  Cryptographic requirements for CNSA 2.0 compliance

   This document does not specify:

   *  SRv6 data plane operations (covered by [RFC8986])





V                        Expires 23 August 2026                 [Page 5]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Flexible Algorithm computation (covered by draft-ietf-lsr-flex-
      algo)

   *  IPsec key exchange procedures (covered by [RFC7296])

   *  IGP extensions for traffic engineering (covered by [RFC8570])

2.  Conventions and Terminology

2.1.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Definitions

   Node:  A device implementing the CONDUIT protocol.


   Peer:  A remote node with which tunnels are established.


   WAN:  A Wide Area Network interface, either physical or virtual,

    capable of carrying IP traffic to remote peers.

   Tunnel:  An IPsec-protected communication path between two WAN

    interfaces on different nodes.

   Fabric:  The complete set of tunnels managed by a CONDUIT node.


   Probe:  A measurement packet transmitted through a tunnel to assess

    its quality characteristics.

   Metric:  A quantitative measure of tunnel quality, such as latency,

    jitter, or packet loss.

   Locator:  The SRv6 locator block assigned to a node, typically a /48

    IPv6 prefix.




V                        Expires 23 August 2026                 [Page 6]

Internet-Draft        Underlay for IPsec Transport         February 2026


2.3.  Abbreviations

   CNSA:  Commercial National Security Algorithm Suite


   ECMP:  Equal-Cost Multi-Path


   ESP:  Encapsulating Security Payload


   Flex-Algo:  Flexible Algorithm


   GEO:  Geostationary Earth Orbit


   gRPC:  gRPC Remote Procedure Call


   HMAC:  Hash-based Message Authentication Code


   IGP:  Interior Gateway Protocol


   IKE:  Internet Key Exchange


   LEO:  Low Earth Orbit


   LOS:  Line-of-Sight


   mTLS:  Mutual Transport Layer Security


   RTT:  Round-Trip Time


   SA:  Security Association


   SPI:  Security Parameter Index


   SRLG:  Shared Risk Link Group



V                        Expires 23 August 2026                 [Page 7]

Internet-Draft        Underlay for IPsec Transport         February 2026


   SRv6:  Segment Routing over IPv6


   TE:  Traffic Engineering


   TI-LFA: Topology-Independent Loop-Free Alternate

3.  Architecture

3.1.  System Overview

   A CONDUIT deployment consists of the following components:

   *  SDN Controller (Optional): Provides centralized policy management,
      SRv6 policy configuration, and network-wide optimization.
      Communicates with CONDUIT nodes via gRPC.

   *  SRv6 Data Plane: Executes traffic engineering decisions using
      standard SRv6 mechanisms including IS-IS or OSPFv3 with SRv6
      extensions, Flexible Algorithm for constraint-based path
      computation, and TI-LFA for sub-50ms fast reroute.

   *  CONDUIT Daemon: Manages the tunnel fabric, comprising the Tunnel
      Lifecycle Manager for creating and deleting tunnels, Health
      Monitor for probing tunnel quality, Metric Publisher for feeding
      metrics to SRv6/IGP, and the gRPC API Server for external control.

   *  IKEv2/IPsec Subsystem: Handles cryptographic operations and
      security association management.  CONDUIT interfaces with this
      subsystem but does not implement cryptographic operations
      directly.

   *  WAN Interfaces: Physical or virtual interfaces connecting to
      various transport networks.

3.2.  Tunnel Fabric Concept

   CONDUIT creates tunnels between WAN interfaces according to the
   configured tunnel policy.  In a full mesh configuration with N local
   WANs and M remote WANs to a given peer, CONDUIT establishes up to N x
   M tunnels.

   For example, consider a node with three WAN interfaces (SATCOM, LOS
   Radio, and LTE) connecting to a peer also having three WAN
   interfaces.  A full mesh fabric would comprise nine tunnels:

   *  SATCOM to SATCOM



V                        Expires 23 August 2026                 [Page 8]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  SATCOM to LOS

   *  SATCOM to LTE

   *  LOS to SATCOM

   *  LOS to LOS

   *  LOS to LTE

   *  LTE to SATCOM

   *  LTE to LOS

   *  LTE to LTE

   Each tunnel becomes a distinct interface visible to the SRv6 data
   plane and IGP.  The IGP sees multiple adjacencies to the same peer,
   each with potentially different metrics based on tunnel quality.

3.3.  Separation of Concerns

   CONDUIT explicitly delegates the following functions to SRv6:

     +========================+======================================+
     | Function               | Mechanism                            |
     +========================+======================================+
     | Path Selection         | SRv6 Flex-Algo, IGP SPF computation  |
     +------------------------+--------------------------------------+
     | Traffic Classification | SRv6 Policy color matching           |
     +------------------------+--------------------------------------+
     | Load Balancing         | IGP ECMP across equal-metric tunnels |
     +------------------------+--------------------------------------+
     | Fast Reroute           | TI-LFA pre-computed backup paths     |
     +------------------------+--------------------------------------+
     | QoS Marking            | SRv6 Traffic Class field             |
     +------------------------+--------------------------------------+

                                  Table 2

   CONDUIT is responsible for:










V                        Expires 23 August 2026                 [Page 9]

Internet-Draft        Underlay for IPsec Transport         February 2026


     +=====================+========================================+
     | Function            | Mechanism                              |
     +=====================+========================================+
     | Tunnel Creation     | Automatic based on WAN availability    |
     +---------------------+----------------------------------------+
     | Tunnel Deletion     | Automatic when WAN becomes unavailable |
     +---------------------+----------------------------------------+
     | Health Monitoring   | Active probing with configurable rates |
     +---------------------+----------------------------------------+
     | Metric Calculation  | RTT, jitter, loss measurement          |
     +---------------------+----------------------------------------+
     | Metric Publishing   | Interface metrics, IGP TE extensions   |
     +---------------------+----------------------------------------+
     | IPsec SA Management | Via IKEv2 with CNSA 2.0 parameters     |
     +---------------------+----------------------------------------+

                                 Table 3

4.  Cryptographic Requirements

4.1.  CNSA 2.0 Compliance

   CONDUIT implementations MUST comply with the Commercial National
   Security Algorithm Suite 2.0 (CNSA 2.0) as specified by the National
   Security Agency for protection of classified information.

   Implementations intended for use in environments not requiring CNSA
   2.0 compliance MAY support additional algorithms but MUST default to
   CNSA 2.0 algorithms and MUST provide configuration options to enforce
   CNSA 2.0-only operation.

4.2.  Mandatory Algorithms

   The following algorithms are REQUIRED:

















V                        Expires 23 August 2026                [Page 10]

Internet-Draft        Underlay for IPsec Transport         February 2026


   +======================+==============+============================+
   | Function             | Algorithm    | Parameters                 |
   +======================+==============+============================+
   | Symmetric Encryption | AES-256-GCM  | 256-bit key, 96-bit IV,    |
   |                      |              | 128-bit authentication tag |
   +----------------------+--------------+----------------------------+
   | Key Exchange         | ECDH         | P-384 curve (secp384r1)    |
   +----------------------+--------------+----------------------------+
   | Digital Signature    | ECDSA        | P-384 curve (secp384r1)    |
   +----------------------+--------------+----------------------------+
   | Hash Function        | SHA-384      | 384-bit output             |
   +----------------------+--------------+----------------------------+
   | Message              | HMAC-SHA-384 | 384-bit output             |
   | Authentication       | [RFC4868]    |                            |
   +----------------------+--------------+----------------------------+
   | Pseudo-Random        | HMAC-SHA-384 | Per [RFC4868]              |
   | Function (IKEv2)     |              |                            |
   +----------------------+--------------+----------------------------+
   | Key Derivation       | HKDF-SHA-384 | Per [RFC5869]              |
   +----------------------+--------------+----------------------------+

                                 Table 4

4.3.  Prohibited Algorithms

   CONDUIT implementations MUST reject configuration of the following
   algorithms and MUST NOT negotiate their use:

   *  AES with key sizes less than 256 bits (AES-128, AES-192)

   *  Triple DES (3DES) and DES

   *  SHA-1 and SHA-256 for authentication or integrity

   *  MD5

   *  RSA with key sizes less than 3072 bits

   *  Diffie-Hellman groups with less than 3072-bit modulus

   *  ECDH or ECDSA with curves smaller than P-384

   *  ChaCha20-Poly1305 (not approved for CNSA)

   Implementations MUST generate a configuration error and refuse to
   operate if prohibited algorithms are specified.





V                        Expires 23 August 2026                [Page 11]

Internet-Draft        Underlay for IPsec Transport         February 2026


4.4.  IPsec Profile

   CONDUIT implementations MUST configure IPsec with the following
   parameters:

   IKEv2 Parameters:

   *  Version: IKEv2 only (version 1 MUST NOT be used)

   *  Encryption: AES-256-GCM with 16-octet ICV (aes256gcm16)

   *  PRF: HMAC-SHA-384 (prf-hmac-sha384)

   *  Diffie-Hellman Group: 20 (384-bit random ECP, P-384)

   *  Authentication: ECDSA with SHA-384 using P-384 certificates

   ESP (Child SA) Parameters:

   *  Encryption: AES-256-GCM with 16-octet ICV

   *  Extended Sequence Numbers: Enabled

   *  Traffic Selectors: As required for overlay traffic

   Lifetime Parameters:

   *  IKE SA Lifetime: 86400 seconds (24 hours) maximum

   *  Child SA Lifetime: 28800 seconds (8 hours) maximum

   *  Child SA Volume Limit: 1 TiB maximum

4.5.  Certificate Requirements

   Node certificates MUST meet the following requirements:

   *  Format: X.509 version 3

   *  Key Algorithm: ECDSA with P-384 curve

   *  Signature Algorithm: ecdsa-with-SHA384

   *  Key Usage: digitalSignature, keyAgreement

   *  Extended Key Usage: serverAuth, clientAuth, IPsecIKE





V                        Expires 23 August 2026                [Page 12]

Internet-Draft        Underlay for IPsec Transport         February 2026


   Certificate Authority certificates MUST use ECDSA with P-384 and
   SHA-384 signatures.

   Certificate validation MUST include revocation checking via CRL or
   OCSP when network connectivity permits.

4.6.  TLS Requirements

   The gRPC API MUST be protected using TLS with the following
   configuration:

   *  Minimum Version: TLS 1.3 (TLS 1.2 and earlier MUST NOT be used)

   *  Cipher Suite: TLS_AES_256_GCM_SHA384 only

   *  Certificate Type: ECDSA with P-384 curve

   *  Client Authentication: Required (mutual TLS)

   Implementations MUST reject TLS connections that do not meet these
   requirements.

5.  Tunnel Fabric Management

5.1.  Tunnel Lifecycle States

   Each tunnel exists in one of the following states:

   DISCOVERED:  A peer has been discovered but tunnel establishment has

      not begun.  Entry: peer discovery.  Exit: initiate IKEv2.

   INITIATING:  IKEv2 negotiation is in progress.  Entry: IKEv2

      initiation.  Exit: IKE_SA and CHILD_SA established, or timeout/
      failure.

   ESTABLISHED:  The tunnel is operational and probes are succeeding

      within acceptable thresholds.  Entry: successful IKEv2 completion
      or recovery from DEGRADED.  Exit: metrics degrade, probe failures
      accumulate, or rekey initiated.

   DEGRADED:  The tunnel is operational but metrics exceed preferred

      thresholds.  Entry: metrics exceed degradation thresholds.  Exit:
      metrics recover or probe failures accumulate.




V                        Expires 23 August 2026                [Page 13]

Internet-Draft        Underlay for IPsec Transport         February 2026


   REKEYING:  Security association rekeying is in progress.  Entry:

      rekey initiated (time or volume based).  Exit: rekey success or
      failure.

   DOWN:  The tunnel has failed and is not currently usable.  Entry:

      consecutive probe failures exceed threshold or IKE failure.  Exit:
      probes succeed or WAN becomes unavailable.

   DELETED:  The tunnel is marked for removal.  Entry: WAN unavailable

      or administrative deletion.  Exit: cleanup complete.

   State transitions MUST be reported via the gRPC API event stream and
   SHOULD be logged for operational visibility.

5.2.  Tunnel Establishment Policy

   CONDUIT supports three fabric modes:

   Full Mesh:  Create tunnels for all combinations of local and remote

      WAN interfaces.  This mode maximizes path diversity but increases
      resource consumption.

   Primary Only:  Create tunnels only between designated primary WAN

      interfaces on each node.  This mode minimizes resource consumption
      but limits path diversity.

   Custom:  Apply a rule-based policy to determine which tunnel

      combinations to establish.  Rules may specify:

      *  Local WAN type (e.g., SATCOM, LOS, cellular)

      *  Remote WAN type

      *  Action (create or skip)

      *  Priority (affects establishment order)

   The tunnel policy SHOULD be configurable via the gRPC API and SHOULD
   support runtime modification without service interruption.






V                        Expires 23 August 2026                [Page 14]

Internet-Draft        Underlay for IPsec Transport         February 2026


5.3.  Tunnel Naming Convention

   Tunnel interfaces SHOULD be named according to the following
   convention to facilitate operational identification:

      tun-<peer>-<local_wan>-<remote_wan>

   Where:

   *  <peer> is a short identifier for the remote node

   *  <local_wan> is a short identifier for the local WAN interface

   *  <remote_wan> is a short identifier for the remote WAN interface

   Example names:

   *  tun-hq-sat-sat (to headquarters, SATCOM to SATCOM)

   *  tun-hq-los-lte (to headquarters, LOS radio to LTE)

   *  tun-fwd1-hf-hf (to forward unit 1, HF to HF)

5.4.  Full Mesh Fabric

   When operating in full mesh mode, the number of tunnels T to a single
   peer is:

      T = L x R

   Where L is the number of local WAN interfaces and R is the number of
   remote WAN interfaces on the peer.

   The total tunnels across all peers is:

      Total = sum(L x R_i) for each peer i

   Implementations MUST support configurable limits on:

   *  Maximum tunnels per peer

   *  Maximum total tunnels

   When limits would be exceeded, implementations SHOULD prioritize
   tunnel creation based on configured policy and WAN type preferences.

6.  Health Monitoring




V                        Expires 23 August 2026                [Page 15]

Internet-Draft        Underlay for IPsec Transport         February 2026


6.1.  Probe Mechanism

   CONDUIT monitors tunnel health through active probing.  Each tunnel
   is independently probed to measure:

         +=================+==============+=====================+
         | Metric          | Unit         | Collection Method   |
         +=================+==============+=====================+
         | Round-Trip Time | Microseconds | Timestamp echo      |
         +-----------------+--------------+---------------------+
         | Jitter          | Microseconds | [RFC3550] algorithm |
         +-----------------+--------------+---------------------+
         | Packet Loss     | Percentage   | Sequence tracking   |
         +-----------------+--------------+---------------------+
         | Availability    | Percentage   | Probe success rate  |
         +-----------------+--------------+---------------------+

                                 Table 5

6.2.  Probe Packet Format

   CONDUIT probe packets use the following format:





























V                        Expires 23 August 2026                [Page 16]

Internet-Draft        Underlay for IPsec Transport         February 2026


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Magic (0x434E4454)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Type      |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    TX Timestamp (64-bit)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    RX Timestamp (64-bit)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      HMAC-SHA-384                             +
   |                        (384 bits)                             |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     Padding (variable)                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Field descriptions:

   Magic (32 bits):  Fixed value 0x434E4454 ("CNDT" in ASCII).  Used to

      identify CONDUIT probe packets.

   Version (8 bits):  Protocol version.  This specification defines

      version 1.

   Type (8 bits):  Probe type:

      *  0x01: Echo Request




V                        Expires 23 August 2026                [Page 17]

Internet-Draft        Underlay for IPsec Transport         February 2026


      *  0x02: Echo Reply

      *  0x03: Timestamp Request

      *  0x04: Timestamp Reply

   Flags (16 bits):  Reserved for future use.  MUST be set to zero on

      transmission and ignored on receipt.

   Sequence Number (32 bits):  Monotonically increasing sequence number

      used for loss detection and RTT matching.

   TX Timestamp (64 bits):  Transmission timestamp in microseconds since

      the Unix epoch.  Set by the sender.

   RX Timestamp (64 bits):  Reception timestamp in microseconds since

      the Unix epoch.  Set by the responder in reply packets; zero in
      request packets.

   HMAC-SHA-384 (384 bits):  Message authentication code computed over

      all preceding fields.  Provides probe authenticity and integrity.

   Padding (variable):  Optional padding to achieve desired probe size

      for bandwidth estimation or MTU testing.

6.3.  Metrics Calculation

6.3.1.  Round-Trip Time

   RTT is calculated as:

      RTT = T_local_rx - T_local_tx

   Where T_local_rx is the local time when the reply was received and
   T_local_tx is the local time when the request was sent.

   For more accurate one-way delay measurement when nodes have
   synchronized clocks:

      OWD_forward = T_remote_rx - T_local_tx
      OWD_reverse = T_local_rx - T_remote_tx




V                        Expires 23 August 2026                [Page 18]

Internet-Draft        Underlay for IPsec Transport         February 2026


6.3.2.  Jitter

   Jitter is calculated using the algorithm specified in [RFC3550]:

      D(i) = (R(i) - R(i-1)) - (S(i) - S(i-1))
      J(i) = J(i-1) + (|D(i)| - J(i-1)) / 16

   Where:

   *  R(i) is the receive timestamp of probe i

   *  S(i) is the send timestamp of probe i

   *  J(i) is the jitter estimate after probe i

6.3.3.  Packet Loss

   Packet loss is calculated over a sliding window:
      Loss% = ((Probes_sent - Probes_received) / Probes_sent) x 100

   The default window size is 100 probes.  Implementations SHOULD make
   this configurable.

6.4.  Probe Scheduling

   The base probe interval is configurable, with a default of 100ms.

   The effective probe interval SHOULD be adjusted based on tunnel
   state:

            +=============+============+======================+
            | State       | Multiplier | Rationale            |
            +=============+============+======================+
            | Established | 1.0        | Normal monitoring    |
            +-------------+------------+----------------------+
            | Degraded    | 0.5        | Increased monitoring |
            |             |            | of troubled tunnel   |
            +-------------+------------+----------------------+
            | Recovering  | 0.25       | Rapid assessment     |
            |             |            | during recovery      |
            +-------------+------------+----------------------+
            | Down        | 2.0        | Reduced load on      |
            |             |            | failed path          |
            +-------------+------------+----------------------+

                                  Table 6





V                        Expires 23 August 2026                [Page 19]

Internet-Draft        Underlay for IPsec Transport         February 2026


   To prevent probe synchronization across tunnels, implementations
   SHOULD add random jitter of +/- 10% to each probe interval.

6.5.  Tunnel State Determination

   Tunnel state transitions are triggered by threshold crossings:

   Degraded Thresholds:

   *  RTT increases by more than 50% above baseline

   *  Packet loss exceeds 1%

   *  Jitter increases by more than 100% above baseline

   Down Thresholds:

   *  Five or more consecutive probe failures

   *  Packet loss exceeds 25%

   Thresholds SHOULD be configurable via the gRPC API.

7.  Metric Publishing

7.1.  Publishing Methods

   CONDUIT publishes tunnel metrics through multiple mechanisms to
   enable SRv6-based traffic engineering:

      +====================+==================+=====================+
      | Method             | Target           | Use Case            |
      +====================+==================+=====================+
      | Interface Metrics  | Operating system | Simple deployments  |
      +--------------------+------------------+---------------------+
      | IGP TE Extensions  | IS-IS / OSPF     | Distributed TE      |
      +--------------------+------------------+---------------------+
      | gRPC Streaming     | SDN Controller   | Centralized TE      |
      +--------------------+------------------+---------------------+
      | Flex-Algo Affinity | IGP Flex-Algo    | Constraint-based TE |
      +--------------------+------------------+---------------------+

                                  Table 7

   Implementations MUST support interface metric publishing.
   Implementations SHOULD support IGP TE extensions and gRPC streaming.





V                        Expires 23 August 2026                [Page 20]

Internet-Draft        Underlay for IPsec Transport         February 2026


7.2.  Interface Metric Calculation

   CONDUIT calculates an interface metric from tunnel quality
   measurements using the following formula:

      Metric = Latency_component + Loss_component + Jitter_component

   Where:

   *  Latency_component = RTT_ms (1 ms = 1 metric unit)

   *  Loss_component = Loss% x 100 (1% loss = 100 metric units)

   *  Jitter_component = Jitter_ms x 10 (1 ms jitter = 10 metric units)

   The resulting metric MUST be clamped to the range 1-65535.

   Example calculations:

            +==============+========+======+========+========+
            | Tunnel Type  | RTT    | Loss | Jitter | Metric |
            +==============+========+======+========+========+
            | GEO SATCOM   | 600 ms | 0.1% | 10 ms  | 710    |
            +--------------+--------+------+--------+--------+
            | LOS Radio    | 5 ms   | 0%   | 0.5 ms | 10     |
            +--------------+--------+------+--------+--------+
            | LTE Cellular | 50 ms  | 0.5% | 5 ms   | 150    |
            +--------------+--------+------+--------+--------+

                                 Table 8

   The SRv6 data plane, seeing these metrics, will naturally prefer the
   LOS tunnel (metric 10) over LTE (metric 150) over SATCOM (metric 710)
   when computing shortest paths.

7.3.  IGP TE Extensions

   When IGP TE metric publishing is enabled, CONDUIT advertises the
   following per-tunnel attributes:

   *  TE Metric: Calculated as described in Section 7.2

   *  Maximum Link Bandwidth: Configured WAN bandwidth

   *  Available Bandwidth: Estimated available capacity

   *  Unidirectional Link Delay: Measured one-way delay per [RFC8570]




V                        Expires 23 August 2026                [Page 21]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Unidirectional Delay Variation: Measured jitter per [RFC8570]

   *  Unidirectional Packet Loss: Measured loss per [RFC8570]

   *  Shared Risk Link Groups: Assigned SRLG values

   *  Administrative Group: For Flex-Algo affinity matching

   For IS-IS, these attributes are advertised using the extensions
   defined in [RFC8570].  For OSPF, the equivalent extensions from
   [RFC7471] apply.

7.4.  Flex-Algo Integration

   CONDUIT assigns tunnels to Flexible Algorithm groups based on
   measured characteristics and configured constraints.

   A Flex-Algo definition specifies:

   *  Algorithm ID: An integer in the range 128-255

   *  Metric Type: IGP metric, minimum delay, or TE metric

   *  Constraints: Maximum delay, minimum bandwidth, SRLG exclusions

   CONDUIT evaluates each tunnel against each Flex-Algo definition and
   sets the appropriate affinity bits in IGP advertisements.

   Example Flex-Algo definitions for tactical networks:

   Flex-Algo 128 (Low Latency):

   *  Metric Type: Minimum Delay

   *  Constraint: Maximum delay 100 ms

   *  Use: Voice, real-time C2

   Flex-Algo 129 (High Bandwidth):

   *  Metric Type: IGP

   *  Constraint: Minimum bandwidth 1 Mbps

   *  Use: Video, bulk transfer

   Flex-Algo 130 (Resilient):




V                        Expires 23 August 2026                [Page 22]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Metric Type: IGP

   *  Constraint: Exclude SRLG "satcom"

   *  Use: Critical C2 requiring terrestrial diversity

   With these definitions, the SRv6 data plane automatically steers
   voice traffic over low-latency tunnels (LOS radio), video over high-
   bandwidth tunnels (possibly ECMP across multiple), and critical C2
   over tunnels not sharing SATCOM failure modes.

7.5.  SRLG Assignment

   Shared Risk Link Groups identify tunnels that share common failure
   modes.  CONDUIT assigns SRLG values based on:

   *  WAN Type: All tunnels using SATCOM share a "satcom" SRLG

   *  Physical Path: Tunnels using the same physical link share an SRLG

   *  Provider: Tunnels using the same carrier share an SRLG

   *  Geographic: Tunnels transiting the same geographic area may share
      an SRLG

   SRLG assignment enables SRv6 TI-LFA to compute backup paths that
   avoid shared failure modes and Flex-Algo to exclude entire failure
   domains.

8.  Control Protocol

8.1.  Transport

   CONDUIT control messages are transported via UDP.  Two ports are
   used:

   *  Port 4794: Control messages (HELLO, WAN_UPDATE, etc.)

   *  Port 4795: Probe packets

   Control messages are transmitted through established IPsec tunnels
   when available.  For initial peer discovery before tunnel
   establishment, messages may be sent via the underlying WAN with HMAC
   authentication.







V                        Expires 23 August 2026                [Page 23]

Internet-Draft        Underlay for IPsec Transport         February 2026


8.2.  Message Header

   All CONDUIT control messages share a common header:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Type      |            Flags              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Node ID                               +
   |                         (64 bits)                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                      Timestamp (64 bits)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      HMAC-SHA-384                             +
   |                        (384 bits)                             |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Field descriptions:

   Version (8 bits):  Protocol version.  This specification defines

      version 1.

   Type (8 bits):  Message type as defined in Section 8.3.


   Flags (16 bits):  Message-specific flags.


   Length (16 bits):  Total message length in octets, including header.




V                        Expires 23 August 2026                [Page 24]

Internet-Draft        Underlay for IPsec Transport         February 2026


   Reserved (16 bits): Reserved for future use.  MUST be zero.

   Node ID (64 bits):  Unique identifier of the sending node.


   Sequence Number (32 bits):  Per-peer monotonically increasing

    counter for anti-replay protection.

   Timestamp (64 bits):  Message creation time in microseconds since

    Unix epoch.

   HMAC-SHA-384 (384 bits):  Message authentication code computed over

    the entire message with the HMAC field set to zero.

   Total header size: 72 octets.

8.3.  Message Types

     +=======+===============+======================================+
     | Value | Name          | Description                          |
     +=======+===============+======================================+
     | 0x01  | HELLO         | Peer discovery and WAN advertisement |
     +-------+---------------+--------------------------------------+
     | 0x02  | HELLO_ACK     | Response to HELLO                    |
     +-------+---------------+--------------------------------------+
     | 0x03  | WAN_UPDATE    | WAN availability change notification |
     +-------+---------------+--------------------------------------+
     | 0x04  | TUNNEL_STATE  | Tunnel state change notification     |
     +-------+---------------+--------------------------------------+
     | 0x05  | KEEPALIVE     | Peer liveness check                  |
     +-------+---------------+--------------------------------------+
     | 0x06  | KEEPALIVE_ACK | Response to KEEPALIVE                |
     +-------+---------------+--------------------------------------+
     | 0x0F  | ERROR         | Error notification                   |
     +-------+---------------+--------------------------------------+

                                 Table 9

8.4.  HELLO Message

   The HELLO message is used for peer discovery and WAN capability
   advertisement:






V                        Expires 23 August 2026                [Page 25]

Internet-Draft        Underlay for IPsec Transport         February 2026


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Num WANs    |   Reserved    |         Capabilities          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Hold Time (sec)        |        Max Tunnels            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    SRv6 Locator (48 bits)                     +
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      WAN Descriptors                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Field descriptions:

   Num WANs (8 bits):  Number of WAN Descriptors following.


   Capabilities (16 bits):  Bitmask of supported capabilities.


   Hold Time (16 bits):  Time in seconds the receiver should consider

    the sender reachable without further messages.

   Max Tunnels (16 bits):  Maximum tunnels this node can establish to

    a single peer.

   SRv6 Locator (48 bits):  The node's SRv6 locator prefix.


8.5.  WAN Descriptor

   Each WAN interface is described by a WAN Descriptor:












V                        Expires 23 August 2026                [Page 26]

Internet-Draft        Underlay for IPsec Transport         February 2026


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    WAN ID     |   WAN Type    |     State     | Addr Flags    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Bandwidth (Kbps)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              MTU              |     Typical Latency (ms)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  IPv6 Address (if flag set)                   +
   |                        (128 bits)                             |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  IPv4 Address (if flag set)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            SRLG ID            |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   WAN Type values:






























V                        Expires 23 August 2026                [Page 27]

Internet-Draft        Underlay for IPsec Transport         February 2026


            +=======+===============+=========================+
            | Value | Name          | Typical Characteristics |
            +=======+===============+=========================+
            | 0x01  | SATCOM_GEO    | 600ms RTT, 2-10 Mbps    |
            +-------+---------------+-------------------------+
            | 0x02  | SATCOM_LEO    | 30ms RTT, 50-200 Mbps   |
            +-------+---------------+-------------------------+
            | 0x03  | LOS_RADIO     | 5ms RTT, 10-100 Mbps    |
            +-------+---------------+-------------------------+
            | 0x04  | TROPOSCATTER  | 10ms RTT, 5-20 Mbps     |
            +-------+---------------+-------------------------+
            | 0x05  | HF_RADIO      | 50ms RTT, 9.6-64 Kbps   |
            +-------+---------------+-------------------------+
            | 0x06  | CELLULAR_LTE  | 30ms RTT, 10-100 Mbps   |
            +-------+---------------+-------------------------+
            | 0x07  | CELLULAR_5G   | 10ms RTT, 100-1000 Mbps |
            +-------+---------------+-------------------------+
            | 0x08  | WIRE_ETHERNET | 1ms RTT, 1-100 Gbps     |
            +-------+---------------+-------------------------+
            | 0x09  | WIRE_FIBER    | 1ms RTT, 1-100 Gbps     |
            +-------+---------------+-------------------------+
            | 0x0A  | WIFI          | 5ms RTT, 50-500 Mbps    |
            +-------+---------------+-------------------------+

                                  Table 10

   Address Flags:

   *  Bit 0: IPv4 address present

   *  Bit 1: IPv6 address present

   *  Bit 2: Behind NAT (IPv4)

   *  Bit 3: Behind NAT (IPv6)

8.6.  Message Authentication

   All CONDUIT control messages MUST be authenticated using HMAC- SHA-
   384.

   The authentication key is derived from the IKEv2 SA when
   available:








V                        Expires 23 August 2026                [Page 28]

Internet-Draft        Underlay for IPsec Transport         February 2026


      AUTH_KEY = HKDF-SHA-384(
         IKM = SK_d,
         salt = "CONDUIT-v1-auth",
         info = Node_ID_local || Node_ID_remote,
         length = 48
      )

   For initial HELLO messages before IKEv2 SA establishment, a pre-
   shared key MAY be used.  Unauthenticated HELLO messages MUST NOT be
   accepted in production deployments.

8.7.  Anti-Replay Protection

   Each peer maintains anti-replay state consisting of:

   *  Expected sequence number (next expected value)

   *  Window bitmap (received sequences within window)

   *  Window size (default 64)

   *  Maximum timestamp skew (default 60 seconds)

   Message acceptance rules:

   1.  If sequence >= expected: Accept and update expected

   2.  If sequence < expected - window_size: Reject (too old)

   3.  If sequence in window and bit set: Reject (replay)

   4.  If sequence in window and bit clear: Accept and set bit

   5.  If timestamp differs from local time by more than maximum skew:
       Reject

9.  SRv6 Integration

9.1.  Tunnel Interfaces as SRv6 Adjacencies

   Each CONDUIT tunnel is presented to the SRv6 data plane as a distinct
   interface.  From the perspective of IS-IS or OSPFv3, each tunnel
   represents a separate adjacency to the peer node.

   This design enables:

   *  Independent metrics per tunnel based on measured quality




V                        Expires 23 August 2026                [Page 29]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  ECMP load balancing across multiple tunnels to the same peer

   *  Flex-Algo differentiation based on tunnel characteristics

   *  TI-LFA backup path computation considering tunnel diversity

   For example, a node with three tunnels to a peer (via SATCOM, LOS,
   and LTE) would advertise three adjacencies in IS-IS, each with its
   own metric.  The IGP SPF computation naturally prefers lower-metric
   paths.

9.2.  Flex-Algo Tunnel Assignment

   CONDUIT evaluates each tunnel against configured Flex-Algo
   definitions and assigns appropriate affinities.

   A tunnel qualifies for a Flex-Algo if:

   *  Measured delay is less than the maximum delay constraint (if
      specified)

   *  Configured bandwidth meets the minimum bandwidth constraint (if
      specified)

   *  Tunnel SRLG membership does not intersect with excluded SRLGs (if
      specified)

   Assignment is dynamic: as tunnel metrics change, Flex-Algo membership
   is re-evaluated and IGP advertisements are updated accordingly.

   Example assignment for a deployment with three Flex-Algos:

   +===========+====================+====================+=============+
   | Tunnel    | Algo 128 (Low Lat) | Algo 129           | Algo 130    |
   |           |                    | (High BW)          | (Resilient) |
   +===========+====================+====================+=============+
   | SATCOM    | Excluded           | Included           | Excluded    |
   | (600ms)   |                    |                    |             |
   +-----------+--------------------+--------------------+-------------+
   | LOS Radio | Included           | Included           | Included    |
   | (5ms)     |                    |                    |             |
   +-----------+--------------------+--------------------+-------------+
   | LTE       | Included           | Included           | Included    |
   | (50ms)    |                    |                    |             |
   +-----------+--------------------+--------------------+-------------+

                                  Table 11




V                        Expires 23 August 2026                [Page 30]

Internet-Draft        Underlay for IPsec Transport         February 2026


   The SATCOM tunnel is excluded from Flex-Algo 128 (delay exceeds 100ms
   threshold) and Flex-Algo 130 (SRLG "satcom" is excluded).

9.3.  Traffic Steering

   With CONDUIT providing tunnel metrics and Flex-Algo assignments,
   traffic steering is accomplished through standard SRv6 mechanisms:

   *  SRv6 Policy Color: Traffic matching a policy with a specific color
      is steered to paths computed using the associated Flex-Algo

   *  DSCP Mapping: DSCP values can be mapped to SRv6 policy colors

   *  BGP Communities: BGP communities can signal desired Flex-Algo

   Example mapping for tactical traffic:

        +==============+===========+==========+===================+
        | Traffic Type | DSCP      | SR Color | Flex-Algo         |
        +==============+===========+==========+===================+
        | Voice        | EF (46)   | 100      | 128 (Low Latency) |
        +--------------+-----------+----------+-------------------+
        | Video        | AF41 (34) | 200      | 129 (High BW)     |
        +--------------+-----------+----------+-------------------+
        | Critical C2  | CS6 (48)  | 300      | 130 (Resilient)   |
        +--------------+-----------+----------+-------------------+
        | Best Effort  | BE (0)    | 0        | Default (SPF)     |
        +--------------+-----------+----------+-------------------+

                                  Table 12

10.  High Availability

10.1.  HA Architecture

   CONDUIT supports high availability through active-standby or active-
   active node pairs sharing a virtual IP address.

   In active-standby mode:

   *  Primary node handles all tunnel management and peer communication

   *  Standby node maintains synchronized state and pre-established
      tunnels

   *  Failover occurs when primary failure is detected

   In active-active mode:



V                        Expires 23 August 2026                [Page 31]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  Both nodes actively manage tunnels

   *  Anycast addressing distributes peer connections

   *  State synchronization ensures consistency

10.2.  Synchronized State

   The following state is synchronized between HA peers:

     +===============+==================+===========================+
     | Data          | Sync Method      | Purpose                   |
     +===============+==================+===========================+
     | Peer List     | Periodic + Event | Both nodes know all peers |
     +---------------+------------------+---------------------------+
     | Tunnel State  | Event-driven     | Enable fast failover      |
     +---------------+------------------+---------------------------+
     | Metrics       | Periodic (1 Hz)  | Consistent path costs     |
     +---------------+------------------+---------------------------+
     | Configuration | Event-driven     | Policy consistency        |
     +---------------+------------------+---------------------------+

                                 Table 13

   IKEv2 Security Associations are NOT synchronized.  Each node
   maintains independent SAs with peers.  This simplifies implementation
   and avoids complexities of SA state transfer.

10.3.  Failover Behavior

   Upon detecting primary node failure:

   1.  Standby assumes the virtual IP address

   2.  Standby's pre-established tunnels become active

   3.  SRv6 reconverges via TI-LFA (sub-50ms for pre-computed backups)

   4.  Traffic flows through standby's tunnels

   Target failover time is less than 3 seconds for complete recovery,
   with TI-LFA providing sub-50ms forwarding continuity for traffic with
   pre-computed backup paths.

11.  gRPC API






V                        Expires 23 August 2026                [Page 32]

Internet-Draft        Underlay for IPsec Transport         February 2026


11.1.  Service Overview

   CONDUIT exposes all functionality through a gRPC API comprising three
   services:

   TunnelFabric Service:  Primary interface for tunnel management,

      including node configuration, WAN interface management, peer
      discovery and management, tunnel lifecycle operations, tunnel
      policy configuration, and metric publishing configuration.

   Telemetry Service:  Provides access to operational metrics, including

      current tunnel metrics, real-time metric streaming, historical
      metric queries, and fabric statistics.

   HighAvailability Service:  Manages HA operations, including HA status

      and configuration, synchronization status, and manual failover
      triggers.

   The complete Protocol Buffer definitions for these services are
   available in a companion document.

11.2.  Authentication and Authorization

   All gRPC connections MUST use mutual TLS (mTLS) with certificates
   meeting the requirements of Section 4.5.

   Implementations SHOULD support role-based access control (RBAC) for
   API authorization.  Recommended roles include:

   *  Administrator: Full access to all operations

   *  Operator: Read access plus tunnel state changes

   *  Monitor: Read-only access to status and metrics

12.  Security Considerations

12.1.  Cryptographic Security

   CONDUIT's security relies on the strength of its cryptographic
   foundations.  The mandatory use of CNSA 2.0 algorithms provides
   protection appropriate for classified information.

   Key security properties:




V                        Expires 23 August 2026                [Page 33]

Internet-Draft        Underlay for IPsec Transport         February 2026


   *  All tunnel traffic is protected by AES-256-GCM, providing
      confidentiality and integrity

   *  All control messages are authenticated using HMAC-SHA-384

   *  Key exchange uses ECDH with P-384, providing forward secrecy

   *  Node authentication uses ECDSA with P-384 certificates

12.2.  Threat Mitigations

   CONDUIT addresses the following threats:

    +=====================+===========================================+
    | Threat              | Mitigation                                |
    +=====================+===========================================+
    | Probe Spoofing      | HMAC-SHA-384 authentication on all probes |
    +---------------------+-------------------------------------------+
    | Replay Attacks      | Sequence numbers and timestamp validation |
    +---------------------+-------------------------------------------+
    | Man-in-the-Middle   | IPsec with certificate-based auth         |
    +---------------------+-------------------------------------------+
    | Unauthorized API    | Mutual TLS with certificate validation    |
    +---------------------+-------------------------------------------+
    | Tunnel Manipulation | Authenticated control protocol messages   |
    +---------------------+-------------------------------------------+
    | Denial of Service   | Rate limiting on control plane            |
    +---------------------+-------------------------------------------+

                                  Table 14

12.3.  Operational Security

   Deployments SHOULD implement the following operational security
   measures:

   *  Certificates should be rotated at least annually

   *  Private keys should be stored in hardware security modules (HSM)
      where available

   *  All tunnel state changes should be logged for audit purposes

   *  Rate limiting should be applied to control plane message
      processing

   *  Network segmentation should isolate CONDUIT management traffic




V                        Expires 23 August 2026                [Page 34]

Internet-Draft        Underlay for IPsec Transport         February 2026


13.  IANA Considerations

13.1.  UDP Port Allocation

   This document requests allocation of two UDP ports:

           +======+=================+==========================+
           | Port | Name            | Description              |
           +======+=================+==========================+
           | 4794 | conduit-control | CONDUIT control messages |
           +------+-----------------+--------------------------+
           | 4795 | conduit-probe   | CONDUIT probe packets    |
           +------+-----------------+--------------------------+

                                  Table 15

13.2.  WAN Type Registry

   This document requests creation of a "CONDUIT WAN Types" registry
   with the following initial values:

   +-------+----------------+-------------------------+
   | Value | Name           | Reference               |
   +-------+----------------+-------------------------+
   |  0x00 | Reserved       | This document           |
   |  0x01 | SATCOM_GEO     | This document           |
   |  0x02 | SATCOM_LEO     | This document           |
   |  0x03 | LOS_RADIO      | This document           |
   |  0x04 | TROPOSCATTER   | This document           |
   |  0x05 | HF_RADIO       | This document           |
   |  0x06 | CELLULAR_LTE   | This document           |
   |  0x07 | CELLULAR_5G    | This document           |
   |  0x08 | WIRE_ETHERNET  | This document           |
   |  0x09 | WIRE_FIBER     | This document           |
   |  0x0A | WIFI           | This document           |
   | 0x0B-0xEF | Unassigned |                         |
   | 0xF0-0xFF | Private Use | This document          |
   +-------+----------------+-------------------------+

   New values in the range 0x0B-0xEF require Standards Action.

14.  References

14.1.  Normative References







V                        Expires 23 August 2026                [Page 35]

Internet-Draft        Underlay for IPsec Transport         February 2026


   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
              D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
              2019, <https://www.rfc-editor.org/info/rfc8570>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

14.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
              384, and HMAC-SHA-512 with IPsec", RFC 4868,
              DOI 10.17487/RFC4868, May 2007,
              <https://www.rfc-editor.org/info/rfc4868>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <https://www.rfc-editor.org/info/rfc7471>.





V                        Expires 23 August 2026                [Page 36]

Internet-Draft        Underlay for IPsec Transport         February 2026


Appendix A.  WAN Type Characteristics

   The following table provides typical characteristics for each WAN
   type.  Actual values vary based on specific equipment, configuration,
   and environmental conditions.

   +===============+=========+===============+=========================+
   | WAN Type      | Latency | Bandwidth     | Notes                   |
   +===============+=========+===============+=========================+
   | SATCOM_GEO    | 600ms   | 2-10 Mbps     | Weather sensitive       |
   +---------------+---------+---------------+-------------------------+
   | SATCOM_LEO    | 20-40ms | 50-200 Mbps   | Handover during orbit   |
   +---------------+---------+---------------+-------------------------+
   | LOS_RADIO     | 5ms     | 10-100 Mbps   | Terrain dependent       |
   +---------------+---------+---------------+-------------------------+
   | TROPOSCATTER  | 10ms    | 5-20 Mbps     | Over-horizon capability |
   +---------------+---------+---------------+-------------------------+
   | HF_RADIO      | 50ms    | 9.6-64 Kbps   | Atmospheric effects     |
   +---------------+---------+---------------+-------------------------+
   | CELLULAR_LTE  | 30ms    | 10-100 Mbps   | Coverage dependent      |
   +---------------+---------+---------------+-------------------------+
   | CELLULAR_5G   | 10ms    | 100-1000      | Limited coverage        |
   |               |         | Mbps          |                         |
   +---------------+---------+---------------+-------------------------+
   | WIRE_ETHERNET | <1ms    | 1-100 Gbps    | Fixed installations     |
   +---------------+---------+---------------+-------------------------+
   | WIRE_FIBER    | <1ms    | 1-100 Gbps    | Fixed installations     |
   +---------------+---------+---------------+-------------------------+
   | WIFI          | 5ms     | 50-500 Mbps   | Short range             |
   +---------------+---------+---------------+-------------------------+

                                  Table 16

Acknowledgements

   The authors thank the members of the tactical networking community
   for their input on operational requirements and deployment
   considerations.

Author's Address

   John Edward Willman V
   Department of the Air Force
   1800 Air Force Pentagon
   Washington, DC 20330
   United States of America
   Phone: +1 786 994 3023
   Email: john.willman.1@us.af.mil



V                        Expires 23 August 2026                [Page 37]

Internet-Draft        Underlay for IPsec Transport         February 2026


   URI:   https://www.linkedin.com/in/johnewillmanv


















































V                        Expires 23 August 2026                [Page 38]
