Network Working Group                                   Prasad Kulangara
Internet-Draft					      Persistent Systems                                              
Intended status: Standards Track                      	 20 January 2026     
Expires: July 2026
Universal Tunnel-less SSE Signaling and SD-WAN Direct Switchover (DST)
Extension for Spoke-to-Spoke Traffic
draft-kulangara-zero-sse-dst-00

Persistent Systems
Email: prasad_k1@persistent.com



Abstract

   This document specifies a universal, tunnel-less mechanism for Secure
   Service Edge (SSE) steering based on a new SSE Identification Header
   (SSE-ID). The architecture enables endpoints, OS network stacks, and
   enterprise SD-WAN edge devices to signal the intent for traffic to be
   routed to an SSE provider without using GRE or IPsec tunnels.

   This document also defines an SD-WAN extension called the Direct
   Switchover Token (DST). DST provides a vendor-agnostic mechanism
   enabling SD-WAN spokes to establish direct, encrypted, spoke-to-spoke
   paths for traffic that does not require SSE inspection. DST is issued
   by a central controller after initial packets reach a hub or the
   controller and after evaluating policy and SSE requirements.

   Additionally, this document introduces (a) a Participating ISP
   routing model using an SSE-Only Public Pool (SOPP) and an SSE POP ID
   (SPID) to locate and route to SSE edges on SSE-enabled circuits, and
   (b) a Merger & Acquisition (M&A) access mode that allows two
   enterprises to access resources via the SSE cloud using Enterprise
   IDs; in this mode, traffic is spliced inside the SSE fabric by EID,
   with address-domain isolation to avoid IP conflicts.

   Together, SSE-ID and DST—augmented with SOPP/SPID and M&A mode—
   provide a unified, interoperable, and tunnel-less architecture for
   SSE integration, SD-WAN optimization, inter-domain routing, and
   enterprise-to-enterprise access.

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), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   https://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   https://www.ietf.org/shadow.html

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.  Terminology
   3.  Problem Statement and Motivation
   4.  Tunnel-less SSE Architecture
   5.  SSE Identification Header (SSE-ID)
   6.  SSE-ID Carriage Methods
   7.  Onboarding and Authorization
   8.  Data Plane Operation
   9.  SD-WAN Direct Switchover Extension (DST)
     9.1  DST Motivation
     9.2  DST Architecture
     9.3  DST Format
     9.4  Controller Procedures
     9.5  Spoke Behavior
     9.6  Interaction Between DST and SSE-ID
   10. Participating ISP Routing with SOPP and SPID
     10.1 Concept and Scope
     10.2 SOPP Semantics and Constraints
     10.3 SPID: SSE POP Identification
     10.4 Routing and Policy Rules for Participating ISPs
     10.5 Operational Guidance
   11. Enterprise-to-Enterprise (M&A) Access Mode
     11.1 Objectives and Use Cases
     11.2 M&A Control Plane and Identity Model
     11.3 In-Cloud Splicing and Address-Domain Isolation
     11.4 M&A Data Plane Behavior
     11.5 Error Handling and Rollback
   12. Error Handling (General)
   13. Security Considerations
   14. Privacy Considerations
   15. IANA Considerations
   16. Examples
   17. References
   Appendix A.  Non-Normative YANG Tree
   Appendix B.  Example Controller API
   Appendix C.  Example State Machine
   Author's Address
   Expires

1.  Introduction

   Current Secure Service Edge (SSE) deployments rely heavily on GRE or
   IPsec tunnels between enterprise edge devices and cloud SSE providers.
   This design introduces operational overhead, lacks flexibility for
   mobile endpoints, creates path inefficiencies, and increases
   onboarding complexity and cost.

   To address these issues, this document defines a universal and
   tunnel-less mechanism for SSE steering using a new SSE Identification
   Header (SSE-ID). The SSE-ID enables endpoints, operating systems, and
   SD-WAN spokes to signal traffic that must be routed to a designated
   SSE provider. The SSE-ID contains identity and policy metadata,
   including an Enterprise ID, Tenant ID, Application ID, and optional
   attributes.

   This document also defines an SD-WAN extension, the Direct Switchover
   Token (DST). DST provides vendor-agnostic authorization for SD-WAN
   spokes to migrate traffic from hub-routed to direct spoke-to-spoke
   encrypted paths when SSE inspection is not required. DST integrates
   with the SSE-ID identity and policy model.

   Two deployment extensions are included. First, a Participating ISP
   model defines how ISPs may carry an SSE-Only Public Pool (SOPP) and
   use an SSE POP ID (SPID) to locate participating SSE edges; the SOPP
   is exclusively routed across SSE-enabled circuits, and traffic from
   the SSE provider to the public Internet does not originate from this
   pool. Second, a Merger & Acquisition (M&A) access mode allows two
   enterprises to interconnect via SSE using Enterprise IDs; the SSE
   cloud splices traffic using those identities and isolates address
   domains to avoid IP conflicts.

2.  Terminology

   SSE: Secure Service Edge.
   SSE-ID: SSE Identification Header.
   EID: IANA-assigned Enterprise ID.
   TID: Tenant ID.
   AID: Application ID.
   DST: Direct Switchover Token.
   Spoke: SD-WAN edge device.
   Hub: Central SD-WAN aggregation or policy node.
   Controller: Central policy engine.
   Participating ISP: An ISP that implements SOPP/SPID handling as in
     Section 10.
   SOPP: SSE-Only Public Pool. A provider-allocated prefix or set of
     prefixes routed only across SSE-enabled circuits and not used for
     SSE egress to the public Internet.
   SPID: SSE POP ID. A unique identifier for an SSE Point of Presence.
   M&A Access Mode: A policy mode enabling cross-enterprise access via
     SSE, with identity-spliced traffic and address-domain isolation.
   Peer-EID: The Enterprise ID of the remote enterprise in M&A mode.
   ADID: Address-Domain ID. An identifier that scopes overlapping IP
     spaces per enterprise within the SSE fabric.

3.  Problem Statement and Motivation

   SSE adoption is increasing across enterprises. However, steering
   traffic to SSE providers still relies heavily on tunnel-based
   architectures that are operationally complex, inefficient for
   endpoints, and limited in mobility scenarios.

   Meanwhile, SD-WAN direct routing remains vendor-specific and lacks a
   standard method for secure, authorized spoke-to-spoke direct paths.

   In addition, enterprises struggle with (a) consistent, policy-based
   routing behavior across ISP underlays toward SSE edges, and (b)
   seamless, low-friction interconnection during mergers and acquisitions
   when address spaces overlap.

   This specification addresses all three issues by defining:
   * A universal, tunnel-less SSE signaling mechanism (SSE-ID).
   * A vendor-neutral SD-WAN extension for direct spoke-to-spoke
     communication (DST).
   * A Participating ISP model for routing to SSE edges using SOPP/SPID.
   * An M&A access mode with identity-based splicing and address-domain
     isolation to avoid IP conflicts.

4.  Tunnel-less SSE Architecture

   The tunnel-less SSE architecture uses the SSE-ID header to signal
   enterprise identity and SSE routing intent. Endpoints insert SSE-ID
   metadata into flows that require SSE routing. SD-WAN spokes or
   enterprise gateways detect SSE-ID and steer traffic based on policy.
   SSE providers use the SSE-ID to authenticate and authorize flows.

5.  SSE Identification Header (SSE-ID)

   The SSE-ID header contains:
   * Version, Flags, Header Length.
   * Enterprise ID (EID).
   * Tenant ID (TID).
   * Application ID (AID).
   * Nonce/Flow Token.
   * Signature or MAC.
   * Optional TLVs (SSE provider target, device class, geofence, etc.).

   New TLVs introduced by this document (see also Section 15):
   * SSE-POP-ID (SPID) TLV: carries a provider-scoped or global ID that
     identifies the target SSE POP for admission and localization.
   * SOPP-Indicator TLV: indicates that the packet’s next-hop resolution
     is expected via the SOPP routing context on SSE-enabled circuits.
   * Access-Mode TLV: indicates M&A when set accordingly.
   * Peer-Enterprise-ID TLV: carries a Peer-EID for cross-enterprise
     access in M&A mode.
   * Address-Domain-ID (ADID) TLV: indicates the address domain
     associated with the originating enterprise to resolve IP overlaps.

6.  SSE-ID Carriage Methods

   The SSE-ID may be carried through:
   * IPv6 Destination Options.
   * TCP Options.
   * QUIC Transport Parameters.
   * HTTP Structured Header.
   * UDP First-Packet Shim (fallback for NAT environments).

   When present, SPID, SOPP-Indicator, Access-Mode, Peer-EID, and ADID
   TLVs MUST be preserved end-to-end to enable the behaviors in Sections
   10 and 11.

7.  Onboarding and Authorization

   Enterprises obtain an Enterprise ID from IANA. Devices are provisioned
   with credentials via enterprise onboarding systems. Endpoints sign the
   SSE-ID. SSE providers validate signatures and apply policy. For M&A
   mode, both enterprises authorize the relationship by exchanging trust
   anchors and policy scopes at the SSE control plane.

8.  Data Plane Operation

   An endpoint inserts SSE-ID metadata into outbound flows that require
   SSE. SD-WAN devices detect the SSE-ID and forward traffic to the
   nearest SSE POP. SSE POPs validate authenticity and enforce policy.

   When SOPP-Indicator is set, participating ISPs apply the SOPP routing
   policy (Section 10). When Access-Mode is M&A, SSE POPs splice traffic
   by EID and enforce ADID isolation (Section 11).

9.  SD-WAN Direct Switchover Extension (DST)

9.1  DST Motivation

   Certain flows, such as internal application access, VOIP, OT
   communication, or branch-to-branch data transfer, do not require SSE
   inspection. Today, spoke-to-spoke direct path features are proprietary
   to individual SD-WAN vendors. DST defines a universal, multi-vendor
   mechanism for authorizing spoke-to-spoke direct routing.

9.2  DST Architecture

   * Initial packets of a flow reach the Hub or are exported as metadata.
   * The Controller evaluates enterprise policy and SSE-ID.
   * If SSE inspection is not required, the Controller issues a DST to
     both spokes.
   * Both spokes validate and establish a direct encrypted adjacency
     using a supported suite (IKEv2, DTLS, QUIC, SRv6-TE).

9.3  DST Format

   DST includes:
   * Version, Flags, Token ID.
   * Issue Time and Expiry.
   * Source and Destination Spoke IDs.
   * Traffic Selectors.
   * Crypto Suite ID.
   * Optional TLVs: App Class, Region, Posture Level, QoS Class.
   * Controller Signature.

9.4  Controller Procedures

   The Controller:
   * Receives first-packet metadata.
   * Determines whether SSE-ID requires SSE.
   * Issues DST if direct path is allowed.
   * Supports revocation and rekey.

9.5  Spoke Behavior

   Spokes:
   * Validate DST signature, time, and policy.
   * Establish secure adjacency.
   * Migrate flow to direct path.
   * Revert to hub if adjacency fails.

9.6  Interaction Between DST and SSE-ID

   * If SSE-ID Flags indicate "Require SSE", DST MUST NOT be issued.
   * DST is only used for flows classified as "SSE not required".
   * Identity and policy fields from SSE-ID may inform DST decisions.

10. Participating ISP Routing with SOPP and SPID

10.1 Concept and Scope

   Participating ISPs can provide deterministic and policy-aligned
   reachability to SSE edges by routing a dedicated SSE-Only Public Pool
   (SOPP) of addresses and honoring an SSE POP ID (SPID) locator. SOPP
   routes exist only on SSE-enabled circuits and within participating
   ISP/partner domains. They are not used by the SSE provider for egress
   toward public Internet destinations.

10.2 SOPP Semantics and Constraints

   * SOPP is a dedicated public IP prefix or set of prefixes assigned to
     the SSE provider for service ingress from enterprises and
     participating ISPs.
   * Packets destined to SOPP addresses terminate at SSE POPs; they MUST
     NOT be sourced by the SSE provider for outgoing Internet traffic.
   * SOPP routes MUST be advertised and accepted only over SSE-enabled
     circuits and participating ISP interconnects.
   * Non-participating networks SHOULD NOT receive SOPP advertisements.

10.3 SPID: SSE POP Identification

   * SPID uniquely identifies an SSE POP. It MAY be globally unique or
     provider-scoped.
   * SPID can guide selection among multiple POPs when several SOPP
     prefixes are available; it can also serve as a hint for SLA, policy
     region, or regulatory constraints.

10.4 Routing and Policy Rules for Participating ISPs

   * When SOPP-Indicator TLV is present, participating ISPs SHOULD steer
     traffic to the nearest or policy-compliant SOPP next-hop derived
     from their routing system and MAY use SPID for tie-breaking or
     region enforcement.
   * SOPP routes MUST NOT be used by the SSE provider to originate
     traffic to the public Internet; such egress MUST use normal
     (non-SOPP) provider addresses.
   * Filtering policies MUST ensure SOPP leakage to the general Internet
     does not occur. Route-policy SHOULD tag SOPP with a distinctive
     community or attribute (out of scope for this document).
   * ISPs MAY participate without inspecting SSE-ID payloads if they
     rely solely on destination SOPP reachability. If SSE-ID is
     available, SPID can augment selection.

10.5 Operational Guidance

   * Capacity planning and DDoS controls SHOULD be applied at SOPP
     borders.
   * Outage handling SHOULD prefer alternate SOPP paths, then revert to
     non-participating default routing where enterprise edges steer
     directly to SSE as needed.

11. Enterprise-to-Enterprise (M&A) Access Mode

11.1 Objectives and Use Cases

   M&A Access Mode enables two enterprises to interconnect via SSE
   without renumbering or complex bilateral overlays, and without IP
   conflicts. Typical uses include staged integration, shared services,
   and selective application access during post-merger periods.

11.2 M&A Control Plane and Identity Model

   * Access-Mode TLV is set to M&A in SSE-ID for flows that require
     cross-enterprise access.
   * The initiating enterprise includes a Peer-Enterprise-ID (Peer-EID)
     TLV naming the remote enterprise.
   * Each enterprise’s address space is scoped by an Address-Domain ID
     (ADID) so that overlapping IPs can coexist.
   * Both enterprises must onboard with the SSE provider and authorize a
     bilateral policy scope. Trust anchors and policy exchanges occur in
     the SSE control plane.

11.3 In-Cloud Splicing and Address-Domain Isolation

   * At the SSE POP, traffic is spliced between the two enterprises
     based on (EID, Peer-EID, Access-Mode=M&A) and confined to an
     M&A-scope policy context.
   * ADID scoping isolates address domains; overlapping RFC1918 or other
     private prefixes are disambiguated by ADID rather than renumbering.
   * The SSE fabric MAY implement per-flow NAT, translation, or VRF-like
     segmentation keyed by (EID, ADID) while preserving connectivity and
     auditability.

11.4 M&A Data Plane Behavior

   * Endpoints include SSE-ID with Access-Mode=M&A, Peer-EID, and ADID.
   * Enterprise edges forward to SSE per normal SSE-ID behavior.
   * The SSE POP enforces bilateral policy and performs in-cloud splicing.
   * Return traffic follows the same identity context; no site
     renumbering is required.

11.5 Error Handling and Rollback

   * If M&A authorization is absent or expired, the SSE POP MUST drop or
     reroute traffic per enterprise policy, and SHOULD signal the
     condition via telemetry.
   * Conflicting ADID assignment MUST be rejected with a clear error for
     operator remediation.

12. Error Handling (General)

   * Malformed SSE-ID: drop and log.
   * Invalid DST: ignore and revert to hub.
   * Expired DST: tear down direct path.
   * Unsupported carriage: fall back to defined alternative.
   * SOPP route leakage detected: withdraw and alarm.
   * SPID unknown: select default SOPP policy or nearest POP.
   * M&A authorization failure: drop or splice-deny and alert.

13. Security Considerations

   * Integrity via signatures or MAC; POPs validate.
   * Replay protection via Nonce and Expiry.
   * Zero trust alignment: controller-issued DST; explicit M&A consent.
   * Participating ISPs MUST treat SOPP as service ingress only; egress
     to public Internet MUST use non-SOPP space to prevent spoofing or
     reflection abuse.
   * M&A traffic MUST remain segmented by (EID, ADID); only authorized
     applications are exposed across enterprises.

14. Privacy Considerations

   * SSE-ID avoids user identifiers.
   * DST uses opaque device identifiers.
   * SPID reveals only POP selection hints.
   * ADID confines address metadata to SSE scope; avoid exposing ADID on
     the open Internet.

15. IANA Considerations

   This document requests the creation of the following registries:

   * SSE-ID TLV Types:
     - 0x01 SSE-Target
     - 0x02 Policy Class
     - 0x03 Device Class
     - 0x04 Geofence Hint
     - 0x05 Expiry
     - 0x06 Attestation Evidence
     - 0x07 Enterprise Attribute
     - 0x08 SSE-POP-ID (SPID)            [NEW]
     - 0x09 SOPP-Indicator               [NEW]
     - 0x0A Access-Mode                  [NEW]
     - 0x0B Peer-Enterprise-ID           [NEW]
     - 0x0C Address-Domain-ID (ADID)     [NEW]
     - 0xFE Experimental
     - 0xFF Padding

   * Access-Mode Values:
     - 0x00 Default
     - 0x01 Require-SSE
     - 0x02 M&A                          [NEW]

   * DST TLV Types (initial set unchanged unless aligned with M&A).

   * New codepoints for SSE-ID carriage:
     - IPv6 Destination Option Type (SSE-ID)
     - TCP Option Kind (SSE-ID compressed)
     - QUIC Transport Parameter ID (sse_id)

16. Examples

   * Internet-bound traffic with SSE-ID (Require-SSE): normal SSE
     handling; SOPP unrelated.
   * Enterprise traffic to SSE via Participating ISP:
     destination is SOPP; SPID guides POP choice; egress to Internet
     from SSE uses non-SOPP addresses.
   * M&A mode:
     Enterprise A (EID=123) to Enterprise B (EID=456), overlapping
     10.0.0.0/8. SSE-ID carries Access-Mode=M&A, Peer-EID=456, ADID=A.
     SSE splices flows at the POP; ADID enforces isolation and resolves
     conflicts without renumbering.

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

Appendix A.  Non-Normative YANG Tree

   (Omitted for brevity)

Appendix B.  Example Controller API

   POST /dst/issue
   POST /dst/revoke

Appendix C.  Example State Machine

   INIT -> POLICY_PENDING -> DIRECT_NEGOTIATION -> DIRECT_ACTIVE

Author's Address

   Prasad Kulangara
   Email: prasad_k1@persistent.com

Expires: July 2026
