| Internet-Draft | HPE Secure Vector Routing (SVR) | May 2026 |
| Menon, et al. | Expires 9 November 2026 | [Page] |
This document describes Hewlett Packard Enterprise's Secure Vector Routing (SVR), an overlay inter-networking protocol that operates at the session layer. SVR conveys end-to-end network requirements that cannot be expressed in network-layer headers by carrying application-layer cookies in the first packet of a session, eliminating the need for tunnel encapsulation and for non-overlapping underlay address spaces. SVR traverses middleboxes and address translators between private networks, the IPv4 public Internet, and the IPv6 public Internet, and supports SD-WAN, multi-cloud, multicast, and dual-stack use cases while improving security at the routing plane.¶
This draft provides information for the Internet community. It does not specify an Internet standard that has IETF consensus, nor is this part of a standards track of the IETF. This document is being published for the purposes of interoperability. The authors request suggestions for improvement.¶
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 9 November 2026.¶
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.¶
IP routers need a way to communicate end-to-end network requirements and to select paths whose attributes meet those requirements. Applications increasingly need the same capability as workloads move to multiple public clouds. Standard practice today is to overlay a mesh of tunnels on top of the IP underlay; this addresses address-space and policy issues but at the cost of additional encapsulation, larger packets, fragmentation, and reduced bandwidth.¶
Secure Vector Routing (SVR) is proposed as an alternative to tunnels. SVR retains a single network layer, transports traffic securely with authentication and adaptive encryption, and expresses network requirements abstractly so that policy can be interworked between different networks and address spaces.¶
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.¶
An SVR router expresses a network requirement semantically and shares it with a peer as SVR Metadata, carried as an application-layer cookie in the first packet of a session. Every participating router holds session state and installs matching forward and reverse flows. Once the session is bidirectionally established, the cookie is omitted from subsequent packets, eliminating per-packet overhead.¶
Benefits of this approach include:¶
Section 3 describes how SVR works at a high level. Section 4 walks through a worked example. Section 4.7 details first-packet processing. Section 6 covers Peer Pathway management with BFD. Section 7 describes additional procedures. Section 8 and Section 9 cover multicast and IPv6. Section 10 defines the on-the-wire SVR Metadata format and TLV catalog.¶
The following terms are used throughout this document.¶
Provisioning and orchestration are out of scope for this document. This section sketches the minimum set of attributes that any orchestration mechanism MUST be able to deliver to a router in order to bring up an SVR peering relationship; it is neither exhaustive nor normative as to data-model organization.¶
Adjacency[]
port-range
peer[]
rekey-interval
Tenant[]
name
source-ip[]
SecurityPolicy[]
name
HMAC
mode
cipher
payload-encryption-cipher
adaptive-encryption
rekey-interval
Service[]
name
domain[]
ip-address[]
port[]
protocol[]
permit
Tenant[]
deny
Tenant[]
ServiceLevelAgreement
max-jitter
max-loss
max-latency
SecurityPolicy
SVR is a session-stateful routing protocol that runs at network edges, typically co-located with stateful NAT and multipath routing functions: branch routers, data-center edges, and public-cloud gateways. SVR maps local network requirements into administratively defined text strings with Authority-wide meaning, and signals them by inserting an SVR Metadata cookie directly into in-flight IP packets.¶
+-----------+
| Network 2 |
+-----------+ | | +-----------+
| SVR<---->+<--L3-IP-->+<----->SVR |
| | +-----------+ | |
| Network 1 | +-----------+ | Network 4 |
| SVR<--->SVR SVR<---->SVR |
+-----------+ | | +-----------+
| Network 3 |
+-----------+ | |
| Client SVR<--->SVR |
+-----------+ +-----------+
Figure 2 shows typical SVR deployment topologies. SVR may be deployed end-to-end (Network 1 to Network 4 across Network 3, the public Internet), in a chain (Network 1 to Network 3 to Network 4), or directly to SVR-capable clients attached to Network 3.¶
SVR Metadata is inserted directly after the L4 header (see Section 5.2). Metadata in the first packet of a session is used for path selection and security; subsequent packets MAY carry SVR Metadata to update networking requirements mid-session. Metadata lives in the packet payload to guarantee delivery between SVR routers.¶
SVR supports TCP, UDP (including UDP unicast), Multicast, MP-TCP, QUIC, point-to-point Ethernet, and ICMP. A session is bracketed by an initial packet with a unique 5-tuple and ends either when the L4 protocol indicates termination (TCP FIN/FIN-ACK or RST) or after a configured inactivity timeout.¶
Every SVR session has a direction: "forward" is from the sender of the first packet (the client) toward the responder (the server); "reverse" is the opposite. Direction is independent of network topology -- the same Peer Pathway carries forward sessions in both physical directions. Routing policy is expressed as Tenant (source) / Service (destination) pairs that match the forward direction.¶
SVR Metadata is similarly labeled "forward" (client-to-server) or "reverse" (server-to-client) throughout this document.¶
Processing of a packet at the first (ingress) SVR router proceeds as follows:¶
Processing at a subsequent SVR router differs only at the start: a first-packet arrival on a router-interface address from a known SVR Peer is interpreted as carrying SVR Metadata. The router decrypts and authenticates the metadata, and either restores the original addresses (if the next hop is non-SVR) or repeats steps 2-6 above with a new Peer Pathway selection.¶
SVR coexists with traditional routing and non-SVR traffic. Waypoint addresses MUST remain reachable via traditional networking for every Peer relationship. When the next hop returned by FIB lookup matches a known Peer's Waypoint, the router MAY insert SVR Metadata and apply session-stateful SVR; otherwise it forwards as a traditional IP router.¶
For each session, peers perform a metadata handshake to confirm that SVR Metadata has been received and understood. The initiating router inserts forward SVR Metadata into every packet it sends to the recipient until it receives a reverse packet that itself carries SVR Metadata. The recipient inserts reverse SVR Metadata into every packet until it receives a packet from the initiator that no longer carries SVR Metadata. Once both sides have observed metadata disappear from their counterpart's stream, the handshake is complete and subsequent packets travel without metadata overhead.¶
Middleboxes (firewalls, NATs, traffic-inspection devices) on a Peer Pathway may drop TCP SYNs that carry payload data, or invalidate TCP streams whose sequence numbers appear inconsistent due to inserted metadata (even though SVR does not change sequence numbers). Peers MAY probe their pathways to detect these conditions; BFD with BFD Metadata is used to detect NATs (see Section 6.1.2). Well-known NAT-traversal protocols -- STUN [RFC8489], TURN [RFC6062], ICE [RFC8445] -- are out of scope for this document.¶
When a NAT is detected, the affected SVR router records the pathway's externally observed Waypoint address as a pathway attribute and uses NAT keep-alives (see Section 7.3) to preserve the binding.¶
When a non-NAT middlebox is detected, the transmitting router MAY perform TCP-to-UDP transformation (changing the protocol octet from 0x06 to 0x11), with the receiving router restoring the original protocol. See Section 5.2.7 and Section 5.6.3.¶
Dynamic Waypoint addresses (DHCP, PPPoE) MAY change mid-session. For active sessions, the new address is detected by inspecting the source address on incoming packets and updating internal references. For idle pathways, BFD with SVR Metadata detects the change; see Section 6.1.3.¶
SVR Metadata MUST be removed before traffic is delivered to a non-SVR endpoint. A router can be certain that a downstream SVR peer will perform that removal only when the FIB next-hop address exactly matches a known Peer Waypoint address; reachability of the Peer SHOULD be confirmed via BFD (Section 6) before metadata insertion (see also Section 4). If the next hop is not a known reachable Peer, SVR Metadata insertion MUST NOT be performed. SVR Metadata MAY be sent end-to-end when both client and server support SVR.¶
To steer a packet to a specific peer, the destination address is rewritten to that Peer's chosen Waypoint and the source address is rewritten to the local egress Waypoint, ensuring symmetric return. The original 5-tuple is preserved in the Forward Context TLV (Section 10.4.1) and restored at egress. This is conceptually similar to IPv6 Segment Routing ([RFC8986]) or to LISP RLOCs ([RFC9300]), except that the original addresses live in SVR Metadata in the packet payload, not in the IP header.¶
Waypoint selection is implementation-specific. A FIB lookup typically returns one or more Waypoints; when multiple are returned, the router MAY apply pathway quality, session-layer load balancing, or other local logic to choose. See Section 4.¶
Session state, including translation rules for all five tuple fields in both directions, MUST be held on both the source and destination SVR routers. Once installed, this state replaces tunnel encapsulation/decapsulation -- a substantially cheaper operation than tunneling.¶
SVR Metadata carries textual Tenant and Service names alongside IP-level context. A FIB extended with Service-name entries permits policy and route selection based on those names; the egress SVR router typically applies destination NAT to a concrete instance. This is particularly useful for inter-cloud connectivity (e.g., AWS <-> Azure).¶
When clients support SVR, semantic routing can replace dynamic DNS for service location: the client requests the Service by name and the SVR network resolves and steers the session to the best instance. A local DNS server resolving Service names to a nearby SVR router achieves the same effect for legacy clients.¶
The ingress SVR router (client side) allocates both source and destination ports for the on-wire 5-tuple. Source ports MUST be even; destination ports MUST be odd. This convention guarantees uniqueness between any two peers without negotiation, and even when a reverse-direction session is allocated the same port pair, the swapped IP addresses keep the on-wire 5-tuple unique. Allocatable port ranges are provisioned per Peer Pathway; a port MUST be free before being reused.¶
With no NAT between Peers, this scheme provides 2^32 unique sessions per pathway (2^30 per direction); a source NAT reduces this to roughly 63,000 (2^16 minus 1024 reserved). Middleboxes may further restrict the usable range.¶
Because the original packet's DSCP and other QoS-related fields are preserved on the wire, underlay QoS continues to operate on a per-session basis.¶
Once the handshake is complete, every subsequent packet has all five tuple fields rewritten in both directions. Compared to IPsec, this transformation is significantly cheaper: no memory copies, no new header construction, no new checksums, and no mandatory encryption.¶
Every SVR router MUST maintain per-session state, including the original addresses and translation rules. This state allows peers to stop sending SVR Metadata after the handshake and to forward traffic akin to segment routing. State can be lost in three ways:¶
When state is lost, the affected peer MUST securely reacquire it. If neither peer holds state, the session is processed as a new first packet (see Section 4.7.1).¶
When NAT or a stateful firewall lies between Peers, the source address observed at the receiving SVR router may differ from the sender's Waypoint. Routers MUST store the actual on-wire Waypoint addresses received from each Peer (in addition to provisioned values).¶
For sessions traversing such middleboxes, the SVR router behind the middlebox SHOULD send periodic SVR Control Messages on idle sessions to keep pinholes open. The RECOMMENDED idle interval is 20 seconds. The Control Message uses the saved source/destination ports of the idle session; see Section 10.3.6 for the message format and Section 7.3 for an example.¶
BFD [RFC5880] is the RECOMMENDED mechanism for Peer Pathway management. It is used for reachability, NAT detection, Waypoint-address-change detection, MTU discovery, idle-pathway quality measurement, peer authentication, and key maintenance. Alternative mechanisms MAY be used by mutual agreement of the Peers.¶
Because standard BFD authentication fields are insufficient for SVR's needs, this document defines BFD Metadata: an extension appended to the end of a BFD control packet (in contrast to SVR Metadata, which follows the L4 header). Some BFD Metadata fields are encrypted. Protocol Buffers, rather than TLVs, are used to encode BFD Metadata for ease of processing. The full BFD Metadata definition is in Section 6.¶
The example below shows two SVR capable routers, peering with each other over multiple pathways.¶
Client
LAN
10.x.x.x
|
| +--------+ +---------+
| | | | |
| | | | |
+->] East [203.0.113.1<---MPLS---->203.0.113.89] West |
| SVR | | SVR |
| Router[198.51.80.2<--Inet-+--->198.51.80.8] Router |
| | | | |
| [192.0.2.1<-----LTE-+ | [<--+
| | | | |
+--------+ +---------+ |
<========= Peer Pathways ========> |
|
172.15.11.x
LAN
Servers
Note: The client, server, and MPLS network can support the private routes in 10.x.x.x and 172.15.11.x address spaces natively, but the internet and LTE networks do not. This is an example of using secure vectors to join networks together.¶
Peering proceeds in two steps. First, each router applies any local static L3 routes and exchanges routes via standard L3 protocols (BGP, OSPF, etc.) to build a FIB and confirm bidirectional Waypoint reachability. Second, each Peer Pathway between the two routers is authenticated; pathways SHOULD be authenticated bidirectionally before being used for SVR traffic.¶
Peer authentication is RECOMMENDED. Sending SVR Metadata without authentication is technically possible but discouraged; either Peer MAY require authentication and reject the relationship if it fails.¶
Authentication uses a Router Certificate: an X.509 certificate issued from a CSR containing the router's UUID and Authority, signed by a trusted CA. The UUID is administrator-assigned and persists across hostname changes, and avoids exposing router names (typically the hostname) in packet traces. Device registration, certificate signing, and secure installation are out of scope; see [RFC4210].¶
Elliptic Curve cryptography ([RFC8422]) is RECOMMENDED over RSA. The curve is administratively chosen and MUST be the same across all routers in an SVR network; NIST P-256 is RECOMMENDED.¶
Each Peer transmits a BFD packet with cleartext BFD Metadata carrying its X.509 Router Certificate in PEM format ([RFC5758]); see Section 6.1.7. The receiver verifies the certificate (chain to a trusted CA), confirms the certificate's common-name UUID matches a configured Peer, and stores the public key for use in subsequent keying (Section 4.1.2). To acknowledge receipt and stop further certificate transmission, the Peer sends a BFD packet without a certificate. A Peer MAY request retransmission (e.g., after reboot) by sending its own certificate again. Certificate updates trigger a repeat of this exchange; existing valid keys remain operational to avoid recertification outages.¶
In the example (Figure 3), the East-West Peer relationship has three authenticated Peer Pathways. Securely exchanging BFD between East and West requires a Peer Key. Because the Router Certificate's keypair is long-lived, the Peer Key is derived using ECDH-ES with the Concat KDF ([NIST_SP_800-56A]).¶
Concat KDF inputs are: a Salt from each Peer, the local private key, and both public keys. The resulting key is implicitly authenticated by the certificates, preventing man-in-the-middle attacks. Encrypted BFD Metadata fields then distribute SVR Metadata Keys; see Section 6.1.9.¶
A nonce in BFD Metadata, tracked at the receiver, prevents replay of old BFD packets. To bound nonce-table size, tracking SHOULD be rate-limited (e.g., one per minute -- ~1440 entries per Peer per day).¶
Either Peer MAY rekey at any time by re-running the same exchange with new Salt values. A single Peer Key is shared across all pathways between two Peers, which is efficient when many parallel pathways exist.¶
SVR routers may receive metadata-bearing packets on any interface, from any Peer, and source addresses can change due to NAT or rerouting. Each router therefore needs to know the cryptographic key for each Peer in advance.¶
Each SVR router generates (or obtains via a quantum-safe mechanism) a single SVR Metadata Key and distributes it to all Peers via encrypted BFD Metadata, along with a version identifier. All SVR Metadata sent from this router uses this key until rotation. See Section 6.1.9.¶
A Peer is declared operational and in service when at least one authenticated pathway exists and an Elliptic Curve Peer Key (ECPK) has been established. It is then ready to carry bidirectional traffic.¶
In service, East and West run BFD on each pathway to monitor operational status and measure jitter, latency, and packet loss. For the running example, assuming all pathways are healthy:¶
PEER: East -> West Authenticated/In Service Name Description Characteristics MPLS 203.0.113.1->203.0.113.89 20ms Lat, 0 Loss, 2 Jit Internet 198.51.80.2->198.51.80.8 30ms Lat, 0 Loss, 3 Jit LTE 192.0.2.1->198.51.80.8 50ms Lat, 0 Loss, 15 Jit PEER: West -> East Authenticated/In Service Name Description Characteristics MPLS 203.0.113.89->203.0.113.1 20ms Lat, 0 Loss, 2 Jit Internet 198.51.80.8->198.51.80.2 30ms Lat, 0 Loss, 3 Jit LTE 198.51.80.8->192.0.2.1 50ms Lat, 0 Loss, 15 Jit
BFD also runs on in-service Peer Pathways for MTU discovery, address-change detection, and idle-pathway quality monitoring.¶
Forwarding sessions onto an SVR Peer Pathway requires a route lookup that resolves to an SVR Peer (Waypoint) next-hop. Continuing the running example, assume servers in 172.15.11.0/24 sit behind West and West advertises the prefix to East over each pathway. East's FIB then contains:¶
East's Forward Information Base (FIB)
Route Next-Hop IP Addr
---------------- -----------------
172.15.11.0/24 203.0.113.89
172.15.11.0/24 198.51.80.8
....
[FIB Entries to reach Waypoints omitted]
Assume an Authority "example" defines Tenant "engineering" as 10.0.0.0/25 on VLAN 2 and Service "github.example" as 172.15.11.23 TCP/22. (Policy provisioning is out of scope.) When an engineering client initiates a session toward github at the East router, FIB lookup yields two next-hop Waypoints, which East cross-references against its Peer Pathway list to identify three usable pathways:¶
Possible Routes
MPLS 20ms Latency, 0 Loss, 2 Jitter
Internet 30ms Latency, 0 Loss, 3 Jitter
LTE 50ms Latency, 0 Loss, 15 Jitter
East selects a pathway based on quality SLAs and/or load-balancing policy, then constructs SVR Metadata, inserts it into the first packet, and forwards it down the chosen pathway to West. The running example uses a private LAN behind East with overlapping addresses (typical of branch deployments), so East applies source NAT.¶
Assuming MPLS is chosen, East performs first-packet processing (Section 4.7.1) and emits the packet on its MPLS interface with source 203.0.113.1 and destination 203.0.113.89 -- the MPLS pathway's Waypoint pair. The bidirectional session uses the same address pair (reversed for return); per-session uniqueness on the wire is provided entirely by the SVR-allocated source/dest ports.¶
Because SVR Metadata carries Service names as text, an SVR FIB MAY be extended with name-based entries to enable routing decisions on Service name rather than (or in addition to) CIDR. Two use cases motivate this:¶
An example FIB combining named and CIDR entries:¶
East's Extended SVR Forward Information Base (OPTIONAL)
Egress
Service Name Route Waypoint Action
-------------- -------------------- ------------ --------
github.example 172.15.11.23:TCP:22 203.0.113.89 FWD
github.example 172.15.11.23:TCP:22 198.51.80.8 FWD
logsvc.example 172.15.11.20:UDP:514 203.0.113.89 DNS
logsvc.example 172.15.11.20:UDP:514 198.51.80.8 DNS
https.example 172.15.11.24:TCP:443 203.0.113.89 DEST NAT
-196.168.1.1
-196.168.1.2
-196.168.1.3
[FIB Entries to reach Waypoints omitted]
Longest-prefix matching on destination address combined with exact protocol/port match is used at ingress to select the route. The Service name string (e.g., "github.example") then travels in SVR Metadata across the SVR network until egress. Implicit default-deny: in this example only SSH, Syslog, and HTTPS are permitted; everything else is dropped.¶
The egress action MAY be one of:¶
Named routes coexist with CIDR FIB entries; named routes are matched first, with CIDR as fallback.¶
An Authority MUST provision a common set of security parameters across its peers:¶
Other ciphers MAY be used, provided they produce fixed, well-known block sizes for both signing and encryption.¶
Per-session payload-encryption Security Policies are negotiated in the first-packet SVR Metadata. The example uses:¶
HMAC: (On, time-based, SHA256-128, ALL Packets)
SVR Metadata Encryption (On, AES256)
SVR uses Time-Based HMAC (per [RFC2104]) for authentication and integrity; see Section 5.5.1. The running example uses SHA256-128 (16-octet signature).¶
Every SVR Metadata transaction includes a Security ID header TLV (Section 10.3.2).¶
A unique Payload Key is used per session, for each direction. Keys are generated by the originating router and conveyed in the encrypted portion of metadata. Per-flow keying eliminates glare and simplifies key exchange. Payload Keys and IVs SHOULD be generated using a FIPS 140-3-approved DRBG.¶
Long-lived sessions MAY require rekey if their duration exceeds the configurable rekey interval. Rekey is performed by generating a new key, conveying it in mid-flow SVR Metadata, and applying it to all subsequent packets. Downstream SVR routers MUST monitor for mid-flow metadata and update their keying state accordingly.¶
The ladder diagram below shows the example github SSH session traversing the East and West routers.¶
Ladder Diagram for SSH Example:¶
Engineering Github
Client . . . . . . . . . . . . . . . . . . . . . Server
| |
| East Router West Router |
| | | |
|---SYN----->| | |
| |--SYN[w/MD]------------>| |
| | |--SYN----->|
| | | |
| | |<--SYN/ACK-|
| |<------SYN/ACK[w/RMD]---| |
|<--SYN/ACK--| | |
| | | |
|----ACK---->| | |
| |-----------ACK--------->| |
| | |---ACK---->|
| | | |
|<== Session Packets Flow with No SVR Metadata ==>|
East MUST construct and insert SVR Metadata into the first packet of the SSH session (the TCP SYN). West MUST remove the metadata, forward the SYN, and on receipt of the SYN/ACK insert reverse SVR Metadata into it. Once both directions have seen metadata from their counterpart, the handshake is complete; metadata is carried in existing packets when possible.¶
Detecting a first packet is protocol-specific: for TCP, a new 5-tuple with only the SYN flag set; for UDP, a new 5-tuple not currently active.¶
Assume the SSH packet arrives at East from the client LAN as shown:¶
Arriving Packet at East Router¶
Packet received on LAN side East Router
Engineer using SSH to access Github
+---------+---------------------+--------------+----------+
|L2 HDR | IP Header | TCP Header | PAYLOAD |
| VLAN=2 | SRC=10.0.1.1 | Sport=6969 | Data |
| | DST=172.15.11.23 | Dport=22 | (N/A) |
+---------+---------------------+--------------+----------+
A Tenant is a textual identifier for a group of source endpoints with common access policy (akin to a security zone). In the example, the "engineer" Tenant is mapped from VLAN 2 in the Authority "example". The attribute-to-Tenant mapping is implementation-specific; routers SHOULD associate a default Tenant with each logical interface.¶
Service identification is out of scope for this document but is the mechanism by which a session is bound to policy. Common techniques include IP/port ranges, TLS SNI, certificate Common Name, and HTTP URL extraction; SaaS vendors typically publish their CIDRs and ports. For the example, 172.15.11.23 TCP/22 is taken to be the "github" Service in Authority "example".¶
With Tenant and Service known, network requirements are looked up:¶
Example Network Requirements¶
SERVICE: github
Access Policies:
Tenants Allowed: engineering
Tenants Denied: release.engineering
Quality Policy: latency < 40ms
Security Policy: None
Access policies determine which tenants are allowed, and if any are specifically denied. The Quality policy defines the service level experience requirements. Secure Vector Routing exchanges tenants, services, and security policies using character strings in SVR Metadata. Access and quality policies are defined and used locally within a router and logically associated with the service. The implementation of quality and access policy controls are site specific. For example, VLAN based subnets may have different meanings at various locations. Also, QoS management schemes may be different for different network areas.¶
Of East's three reachable Peer Pathways, the 40 ms latency budget eliminates LTE. MPLS and Internet are both within SLA; MPLS is chosen for its lower latency.¶
Pathway selection criteria are implementation-specific and may include pathway utilization and capacity, cost (e.g., reserving LTE/5G for backup), and operator-defined load-balancing policies. The selection algorithm is out of scope for this document.¶
The example uses source NAT at the East router's MPLS interface so that overlapping branch address spaces can coexist. A NATing router may reuse the interface address with a new source port, or allocate from an IP pool. Either way, the chosen address is placed in SVR Metadata; the actual translation is applied at the egress (West) router.¶
The router allocates new source and destination ports for the session. Ports MUST NOT be currently in use and SHOULD NOT have been recently freed (to avoid middlebox state confusion); see Section 5.2. The allocatable range is provisioned per site to accommodate upstream firewall and middlebox restrictions. East has 8000-24000 available; the example uses source 8000 (even) and destination 8001 (odd). Both ports are allocated by the router that initiates SVR Metadata.¶
With requirements, pathway, and ports in hand, East creates session state (including a Session UUID for end-to-end tracking) and builds the SVR Metadata block. The table below maps state to SVR Metadata TLVs (full TLV definitions in Section 10):¶
Session State Table Entry¶
State Information & Mappings to SVR Metadata Fields
SVR Metadata TLV |------TLV------|
Category -Field VALUE Type Len Hdr
-------- ------------------ ----------------
Header 12
Header TLVs
Security ID 1 16 4 4
Path Metrics 26 10 4
-Tx Color 5
-Tx TimeValue 4200 MSecs
-Rx Color 3
-Rx TimeVlue 3950 MSecs
-Drop No
-Prev Color Count 950 Packets
--- ---
Total Header Length = 34 (26+8) 26 8
Payload TLVs
Forward Context 2 13 4
- Source IP Addr 10.0.0.1
- Dest IP Addr 172.15.11.23
- Protocol TCP
- Source Port 6969
- Dest Port 22
Tenant Name engineering 7 11 4
Service Name github 10 6 4
UUID e9b083df-d922..... 6 16 4
Source Router Name East Router 14 11 4
Source NAT Address 203.0.113.1 25 4 4
Security Policy NONE 15 4 4
Peer Path 19 22 4
- Source Addr 203.0.113.1
- Dest Addr 203.0.113.89
--- ---
Total Payload Length = 119 (87+32) 87 32
To West Fr West
Allocated Ports Router Router
-Source Port 8000 8001
-Dest Port 8001 8000
Session HMAC Key [Peer Key at session start]
The required first-packet TLVs are defined in Section 5.3.1: Security ID, Forward Context, Tenant Name, Service Name, Session UUID, Source Router Name, Security Policy, and Peer Pathway ID. The example also includes two optional TLVs: Path Metrics (Section 10.3.7) and IPv4 Source NAT Address (Section 10.4.13).¶
TLV order is arbitrary, but Header TLVs MUST precede Payload TLVs. A peer that receives an unknown TLV MUST ignore it. In this example the header (with two Header TLVs) is 34 octets and the eight Payload TLVs total 119 octets.¶
The Session HMAC Key is router-local state, conveyed between Peers in BFD Metadata, and used for the life of the session.¶
The Payload TLVs are encrypted per Section 5.4. The example provisioning uses AES-256, which has a 128-bit (16-octet) block size. With 119 octets of payload, 9 octets of padding bring the encrypted region to 128 octets; a 16-octet IV is appended. The full SVR Metadata block is 34 (header) + 128 (encrypted) + 16 (IV) = 178 octets:¶
SVR Metadata Block¶
+--------------+--------------+---------+----------------+
| SVR | SVR | | |
| Metadata | Metadata | Padding | Initialization |
| Header | Payload TLVs | | Vector |
| (Unecrypted) | | | |
| 34 Bytes | 119 Bytes | 9 Bytes | 16 Bytes |
+--------------+--------------+---------+----------------+
|<---Clear---->|<---Encrypted Portion-->|
|<--------------178 Byte SVR Metadata Block------------->|
The 178-octet block is inserted directly after the L4 header. Any existing payload data is shifted to make room:¶
SVR Metadata Added¶
Packet with SVR Metadata inserted
+---------------------+--------------+-----------+------------+
| IP Header | TCP Header | SVR | PAYLOAD |
| SRC=10.0.1.1 | Sport=6969 | Metadata | Data |
| DST=172.15.11.23 | Dport=22 | 178 Bytes | (optional) |
+---------------------+--------------+-----------+------------+
The transport addresses are then rewritten to the chosen Peer Pathway's Waypoints, and the SVR-allocated ports are installed:¶
Transport Addresses Updated¶
Final Transformed Packet with SVR Metadata inserted
+---------------------+--------------+-----------+------------+
| IP Header | TCP Header | SVR | PAYLOAD |
| SRC=203.0.113.1 | Sport=8000 | Metadata | Data |
| DST=203.0.113.89 | Dport=8001 | 178 Bytes | (optional) |
+---------------------+--------------+-----------+------------+
The packet is then HMAC-signed (Section 4.5) using the current SVR Metadata Key (Section 6.1.9). The signature is appended to the end of the packet, extending its length by the signature size (16 octets in this example). The IP header is excluded from the signed range.¶
HMAC Signature Added¶
Packet with SVR Metadata inserted
+-------------------+--------------+-----------+---------+-------+
| IP Header | TCP Header | Encrypted | PAYLOAD | HMAC |
| SRC=203.0.113.1 | Sport=8000 | SVR | Data | 16 |
| DST=203.0.113.89 | Dport=8001 | Metadata | | Bytes |
+-------------------+--------------+-----------+---------+-------+
| |
|<=========HMAC Signed Data=========>|
The IP length and checksum are recomputed and the packet is transmitted. East continues to include the same SVR Metadata in every outbound packet of the session until it sees a reverse packet carrying SVR Metadata (handshake complete). For TCP this is typically the SYN/ACK; thereafter no further metadata is inserted for the lifetime of the session unless a path-migration event occurs.¶
Client ----> TCP SYN w/SVR Metadata --------> Server
Client <---- TCP SYN-ACK w/SVR Metadata <---- Server
For UDP, metadata is inserted on every packet until a reverse packet carrying metadata is observed, except for unidirectional flows; see Section 4.7.7.¶
A packet arriving at West with West's own Waypoint as the IP destination (i.e., addressed to the router rather than transiting it) likely carries SVR Metadata and is processed as follows.¶
The packet MUST be validated before processing (Section 5.6.2). On authentication or validation failure, the packet MAY be dropped or returned with an ICMP Destination Unreachable. In the example, only three source addresses are valid:¶
Possible Source Addresses¶
203.0.113.1 MPLS Peer Pathway
198.51.80.2 Internet Peer Pathway
169.254.231.106 LTE Peer Pathway
The most efficient first test is checking for the SVR header magic number (Section 5.6.1). The HMAC signature is then verified (Section 5.5.1); on failure the packet is dropped and a security event recorded. The unencrypted portions of the SVR Metadata header MUST be sanity-checked (header and payload lengths must each be less than the total block size).¶
The metadata block is decrypted (Section 5.6.2.2); any decryption failure causes the packet to be dropped. The Payload TLVs are parsed and the resulting state and translation rules are installed; any parse failure causes the packet to be dropped. The SVR Metadata block and the HMAC signature are then removed from the packet.¶
The original 5-tuple is restored from the Forward Context TLV and the packet is processed recursively as if it were a new first packet (Section 4.7.1), with one difference: the Tenant, Service, Security Policy, and Session UUID are taken from the received metadata rather than locally derived. The packet may then traverse another Peer Pathway or be delivered via standard forwarding -- in the example, West delivers the packet to the server LAN.¶
When forwarding to another SVR Peer, Tenant, Service, Session UUID, Security Policy, and the original 5-tuple are cloned into the new metadata so that semantics remain consistent across multi-hop SVR paths. SVR Metadata MUST be decrypted and re-encrypted at every hop (because each hop uses different Waypoint addresses), but payload encryption is end-to-end -- applied at the first SVR router and decrypted at the last.¶
Because every SVR hop preserves the Session UUID, a looping first packet is trivial to detect: there MUST never be two sessions with the same UUID, and any duplicate MUST be dropped. Detecting the loop on the first packet allows subsequent packets to be dropped at ingress. SVR routers MUST also decrement TTL/Hop Limit so that loops not caught by SVR are still bounded by traditional IP forwarding rules.¶
A packet bearing SVR Metadata that arrives after the handshake is treated as an in-session update, not a loop. Updates may modify any attribute; most commonly they change the Peer Pathway for the session. See Section 7.1.¶
After East and West each process the first forward packet, both directions of forwarding state and any required translations are installed. Subsequent packets in either direction are matched on 5-tuple and forwarded without further routing-table consultation ("fast path").¶
Each SVR Router tracks the metadata-handshake status per session. If a forward packet arrives for a session whose handshake is incomplete, the router MUST insert SVR Metadata; it continues until it sees evidence (a reverse packet bearing metadata) that the peer received it. For TCP, the first reverse packet is normally the SYN/ACK. Reverse metadata serves to:¶
The reverse SVR Metadata for the example contains:¶
Reverse SVR Metadata Response¶
Reverse SVR Metadata Response
State Information & Mappings to SVR Metadata Fields
SVR Metadata TLV |------TLV------|
Category -Field VALUE Type Len Hdr
-------- ------------------ ----------------
Header 12
Header TLVs
Security ID 1 16 4 4
Path Metrics 26 10 4
-Tx Color 3
-Tx TimeValue 4100 msecs
-Rx Color 5
-Rx TimeVlue 4050 msecs
-Drop No
-Prev Color Count 1950 packets
--- ---
Total Header Length = 34 (26+8) 26 8
Payload TLVs
Reverse Context 4 13 4
- Source IP Addr 203.0.113.1
- Dest IP Addr 172.15.11.23
- Protocol TCP
- Source Port 7891
- Dest Port 6969
Peer Path 19 22 4
- Source Addr 203.0.113.89
- Dest Addr 203.0.113.1
--- ---
Total Payload Length = 43 (35+8) 35 8
To East From East
Allocated Ports Router Router
- Source Port 8001 8000
- Dest Port 8000 8001
Session HMAC Key [Peer key used by remote peer]
See Section 5.3 for required and optional reverse metadata TLVs. The example also includes the optional Path Metrics TLV (Section 10.3.7).¶
The Session HMAC Key is router-local state communicated to peers in BFD Metadata; its lifetime tracks the Peer Metadata key. The key is used for the life of the session.¶
The Forward and Reverse Contexts together give SVR end-to-end visibility of every session: pre-NAT 5-tuple at ingress, post-NAT 5-tuple at egress, and the Waypoint addresses/ports used on each pathway.¶
This SVR Metadata will be encrypted, inserted, and an HMAC checksum will be computed and attached as per the previous example. The reverse packet in this example will have 34 octets of header data, and 43 octets of payload data, 5 octets of padding, and a 16 octets initialization vector resulting in an SVR Metadata block that is 98 octets long.¶
A peer that receives a session packet without SVR Metadata treats the handshake as complete and stops inserting metadata in its own outbound direction. This applies symmetrically to East and West.¶
No SVR Metadata is exchanged on normal termination. For TCP, the router monitors FIN/ACK or RST and removes session state after a guard timer; a new SYN matching the same 5-tuple during that window immediately tears down the prior session. All protocols additionally have an inactivity timeout; a packet arriving after the timeout is treated as a new session.¶
When a flow is unidirectional or asymmetric (e.g., TCP sequence numbers advance with no observed reverse packets but end-to-end delivery is confirmed), the sender stops inserting SVR Metadata. For UDP asymmetry, the sender inserts metadata in at most ~20 packets; if no reverse packet appears in that window, the receiving peer generates a "disable metadata" packet to complete the handshake. The exact packet count is implementation-specific.¶
The diagram below illustrates a TCP session traversing three SVR routers:¶
Ladder Diagram for Session Initiation with SVR Metadata:¶
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| Router A Router B Router C |
| | | | |
|----SYN---->| | | |
| |--SYN[MD1]-->| | |
| | |--SYN[MD2]->| |
| | | |----SYN--->|
| | | | |
| | | |<--SYN/ACK-|
| | |<--SYN/ACK--| |
| |<--SYN/ACK---| [RMD2] | |
|<--SYN/ACK--| [RMD1] | | |
| | | | |
| | | | |
|<=== Session Packets Flow with No SVR Metadata ===>|
Each router builds metadata (MD1, MD2) for the next chosen Peer; on the first reverse packet each router inserts reverse metadata (RMD1, RMD2). Each router allocates its own Waypoints and ports. The Forward Context, Tenant, Service, and Session UUID are preserved across all hops, allowing consistent policy application end-to-end. The Session UUID is identical in MD1, MD2, RMD1, and RMD2.¶
A TCP teardown is similarly direct -- no SVR Metadata is required:¶
Ladder Diagram for Session Teardown SVR Metadata:¶
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| Router A Router B Router C |
| | | | |
|---FIN----->| | | |
| |-----FIN---->| | |
| | |----FIN---->| |
| | | |-----FIN-->|
| | | | |
| | | |<--FIN/ACK-|
| | |<--FIN/ACK--| |
| |<--FIN/ACK---| | |
|<--FIN/ACK--| | | |
| | | | |
| | | | |
No SVR Metadata is sent on session termination. Each router retains state for a configurable interval (covering FIN/ACK loss) before removing it.¶
This section provides the normative requirements for SVR Metadata.¶
SVR implementations MUST support TCP, UDP, and ICMP. SVR implementations SHOULD support UDP Unicast. A session is identified by a 5-tuple unique to the SVR router; it begins on the first packet and ends when either the L4 protocol signals completion (TCP FIN/FIN-ACK or RST) or after a protocol-specific inactivity timeout (UDP, ICMP, UDP Unicast, point-to-point Ethernet).¶
SVR is always OPTIONAL: implementations MAY choose per session whether to apply SVR, and SVR implementations MUST also support non-SVR traffic.¶
SVR implementations MUST insert SVR Metadata directly after the L4 header, even if doing so causes IP fragmentation. For Ethernet point-to-point and ICMP error messages, IP and L4 headers MUST be created; if associated with an existing session, the created packet MUST share the exact 5-tuple (Waypoints and Ports) of that session. SVR Metadata MUST appear in the very first packet of a new session (TCP or UDP bidirectional flow) to influence path selection or security. SVR Metadata SHALL be inserted in any subsequent packet in either direction to update networking requirements. Metadata is carried in the L4 payload to ensure end-to-end transparency. Packet lengths and L3/L4 checksums MUST be adjusted; TCP sequence numbers MUST NOT be adjusted.¶
A Peer Pathway MUST be selected before SVR Metadata is inserted. The pathway's Waypoint addresses serve as the L3 source/destination for every packet bearing SVR Metadata.¶
The originating SVR peer (client side) MUST allocate both source and destination ports. The ingress side MUST use even ports for the local (source) port and odd ports for the remote (destination) port, guaranteeing uniqueness between any peer pair without negotiation. The allocatable range is provisioned. Ports in use MUST be excluded from allocation; ports MUST be released when the session is removed; and a freed port MUST observe a 60-second guard time before reallocation.¶
An SVR implementation MAY need to send metadata to a peer when no data packets are flowing (see Section 7.3). In that case it MUST synthesize an IP packet matching the session's 5-tuple, marked to be dropped after processing; the directly adjacent peer MUST process and discard it without forwarding to any other SVR peer.¶
Existing IP Packet with SVR Metadata inserted +------------------+-----------------+----------+----------+------+ | Existing IP Hdr | Existing L4 Hdr | SVR | PAYLOAD | HMAC | | Source IP Addr | Source Port | Metadata | Data | | | Dest IP Addr | Dest Port | Block |(optional)| | +------------------+-----------------+----------+----------+------+ Generated IP Packet with SVR Metadata inserted +-------------------+------------------+----------+------+ | Created IP Hdr | Created L4 Hdr | SVR | HMAC | | Source IP Addr | Source Port | Metadata | | | Dest IP Addr | Dest Port | Block | | +-------------------+------------------+----------+------+ ICMP Packet with SVR Metadata inserted +-----------------+-----------------+----------+--------+------+ | Created IP Hdr | Created UDP Hdr | SVR | ICMP | HMAC | | Source IP Addr | Source Port | Metadata | MSG | | | Dest IP Addr | Dest Port | Block | | | +-----------------+-----------------+----------+--------+------+ Ethernet Packet with SVR Metadata inserted +-----------------+-----------------+----------+----------+------+ | Created IP Hdr | Created UDP Hdr | SVR | Ethernet | HMAC | | Source IP Addr | Source Port | Metadata | MSG | | | Dest IP Addr | Dest Port | Block | | | +-----------------+-----------------+----------+----------+------+
For UDP, the UDP header length field MUST be updated. The L4 checksum (TCP or UDP) MUST be recalculated. The IP total-length field MUST be updated to account for the inserted metadata block and the appended HMAC, and the IP header checksum MUST then be recomputed. For TCP, sequence numbers MUST NOT be modified.¶
Because SVR Metadata is carried in the L4 payload, an existing payload could coincidentally begin with the same 8-octet SVR magic number. False-positive logic prevents downstream routers from misinterpreting such payloads.¶
False positives SHALL NOT occur on first packets, since valid metadata is unconditionally inserted there. They can only arise on mid-session packets of an established SVR session.¶
When a mid-session packet's payload begins with the SVR magic number, the implementation MUST insert an empty SVR Metadata header (12 octets, zero TLVs). This establishes the contract that any appearance of the magic number on the wire indicates valid metadata that downstream routers MUST process and remove. The inserted header carries no TLVs and is not encrypted.¶
SVR Metadata Location¶
Received Midstream SVR Packet matching SVR Magic Number +-------+--------+--------------------------+ |IP Hdr | L4 Hdr | 0x4c48dbc6ddf6670c ..... | +-------+--------+--------------------------+ Midstream SVR Packet with False Positive SVR Metadata inserted +--------+--------+----------+---------------------------+ | | | SVR | | | IP Hdr | L4 Hdr | Metadata | 0x4c48dbc6ddf6670c ...... | | | | HDR | | +--------+--------+----------+---------------------------+
Header or payload TLVs MAY be added at the implementation's discretion; if added, standard processing rules apply (including encryption when payload TLVs are present).¶
When a middlebox blocks TCP packets that carry SVR Metadata, implementations transform the affected TCP session to UDP for the duration it crosses the middlebox and restore TCP at the egress. Pathway-test traffic typically detects the need for this. The transform proceeds as follows:¶
The IP protocol field MUST be changed from 0x06 (TCP) to 0x11 (UDP). The original TCP sequence number is preserved by copying it to the TCP checksum/urgent-pointer field before the UDP checksum overlays the sequence number location. TLV 12 (Section 10.4.9) MUST be added to the SVR Metadata to flag the transformation.¶
Once engaged, every packet of the session is transformed -- not just those carrying metadata. Restoration is described in Section 5.6.3.¶
The first forward SVR Metadata of a new session MUST contain:¶
Forward SVR Metadata MAY also include the following optional TLVs:¶
TLV order is arbitrary, but Header TLVs MUST precede Payload TLVs. A peer MUST ignore any TLV it does not recognize.¶
The first reverse packet of a new session MUST contain:¶
Reverse SVR Metadata MAY also include:¶
A returned ICMP error MUST contain:¶
It MAY also include:¶
SVR Metadata encryption uses block ciphers with a fixed block size. The cipher and its block size MUST be provisioned and known to peers in advance (provisioning is out of scope). The SVR Metadata Key is common to all Peer Pathways between two peers and is obtained via BFD with SVR Metadata (Section 6.1.9). Payload TLVs are zero-padded (0x00) up to a multiple of the block size, and a per-block IV makes decryption stateless.¶
SVR Metadata Block¶
Cipher Block Size IV Size
------- ------------------ --------
AES256 128 Bits(16 Bytes) 16 Bytes
AES128 128 Bits(16 Bytes) 16 Bytes
+----------+--------+---------+---------+----------------+
| SVR | | | | |
| Metadata | Header | Payload | Padding | Initialization |
| Header | TLVs | TLVs | | Vector |
+----------+--------+---------+---------+----------------+
|<------Clear------>|<--- Encrypted --->|
|<------------------ SVR Metadata Block ---------------->|
The required pad length is (block_size - (payload_len mod block_size)) mod block_size.¶
An SVR Authority MUST provision (out of scope here): whether HMAC signatures are used; whether Time-Based HMAC is used; and whether ALL packets are signed or only those carrying SVR Metadata. Time-Based HMAC on ALL packets is RECOMMENDED to mitigate replay attacks. The Session HMAC Key is conveyed between peers in BFD Metadata (Section 6.1.9) and is used for the life of the session.¶
SVR peers SHOULD sign all packets per [RFC2104] using the Session HMAC Key. When present, an IP packet MUST contain at most one HMAC signature, even if it is fragmented. For Time-Based HMAC, the implementation appends (current_epoch_seconds / 2) to the signed data; clocks MUST be synchronized accurately, with NTP ([RFC5905]) as a baseline. Disabling Time-Based HMAC in favor of standard HMAC is NOT RECOMMENDED.¶
The HMAC signature is appended to the end of the packet. Its length depends on the algorithm; supported algorithms include SHA1, SHA256-128, and SHA256.¶
Location of HMAC Checksum¶
SVR Packet with SVR Metadata inserted
+-----------+--------------+----------+----------+------+
| IP Header | L4 Header | SVR | PAYLOAD | HMAC |
| | | Metadata |(optional)| |
+-----------+--------------+----------+----------+------+
| |
|<======= HMAC Signed Data =========>|
Subsequent SVR Packet
+-----------+--------------+---------+------+
| IP Header | L4 Header | Payload | HMAC |
| | | | |
+-----------+--------------+---------+------+
| |
|<== HMAC Signed Data ==>|
HMAC TYPE LENGTH OF SIGNATURE
---------- -------------------
SHA1 20 Bytes
SHA256-128 16 Bytes
SHA256 32 Bytes
When HMAC signatures are in use, SVR implementations MUST verify and remove the signature on receipt. Verification provides both peer authentication and integrity protection across the previous hop. Provisioning rules (signatures present, Time-Based, ALL vs. metadata-only) are as in Section 5.5.1. Verification regenerates the signature locally and compares it byte-wise to the one in the packet, using the Session HMAC Key from the matching session state.¶
HMAC Signature Removed¶
SVR Packet with HMAC Signature
+-----------+--------------+----------+------+
| IP Header | L4 Header | PAYLOAD | HMAC |
| | |(optional)| |
+-----------+--------------+----------+------+
| |
|<== Signed Data ========>|
SVR Packet with HMAC Signature removed
+-----------+--------------+----------+
| IP Header | L4 Header | PAYLOAD |
| | |(optional)|
+-----------+--------------+----------+
For efficiency with Time-Based HMAC, implementations SHOULD compute the partial HMAC over the packet body once (excluding the IP header), then attempt finalization with the current time window; on mismatch, retry with the next window (current+2 seconds) and then the previous (current-2 seconds). The active window for a given peer SHOULD be cached and advanced as time progresses.¶
If no time window and no recently-issued key produces a match, the packet MUST be dropped and a security event recorded.¶
On match, the packet is authenticated; the HMAC signature MUST be removed, the IP total-length field MUST be updated, and the IP header checksum MUST then be recomputed.¶
SVR routers MUST process both SVR and non-SVR traffic and MUST track which sessions are using SVR. SVR-bearing traffic always uses Waypoint addresses, providing efficient ingress separation between SVR and non-SVR traffic. Packets arriving on a known Peer Pathway MUST be presumed to either contain SVR Metadata or belong to an established SVR session.¶
DPI MUST be used on every packet to detect SVR Metadata. For first packets, metadata is required and its absence causes the packet to be dropped. The HMAC verification step (above) MUST run before any further metadata processing, to prevent on-path tampering.¶
If the first 8 octets of the L4 payload (TCP or UDP) exactly match the SVR magic number (0x4c48dbc6ddf6670c), the packet MUST be treated as bearing SVR Metadata. If they do not match, the packet does not contain metadata; if it belongs to an existing session it SHOULD be routed (Section 5.6.4), otherwise it MUST be dropped and a security event recorded.¶
The SVR Metadata header is parsed (Section 10.1). If both the header length and payload length are zero, the metadata is simply removed and the packet forwarded -- this is the false-positive case (Section 5.2.6). The implementation then walks any header TLVs to validate them; with payload length zero, no decryption is required.¶
An unknown TLV SHOULD be skipped and MUST be forwarded unchanged. If any TLV value is unreasonable, the packet MUST be dropped and a security event recorded.¶
If the peers have been provisioned to encrypt SVR Metadata and the payload length is non-zero, the implementation MUST treat the payload region as an encrypted block. The pre-provisioned cipher, block size, and IV size, combined with the header's payload length, fully determine the block layout.¶
Encrypted SVR Metadata Block¶
Known in advance: Cipher, Block Size, IV size
From SVR Metadata Header: Payload TLV size
+----------+--------+---------+---------+----------------+--~~~
| SVR | Header | Payload | Padding | Initialization | Rest...
| Metadata | TLVs | TLVs | | Vector (IV) | of ...
| Header | | | | | Pkt ...
+----------+--------+---------+---------+----------------+--~~~
|<----- Clear ----->|<--- Encrypted --->|
|<---------------- SVR Metadata Block ------------------>|
The pad length is (block_size - (payload_len mod block_size)) mod block_size; the IV immediately follows the encrypted block.¶
If decryption fails, the packet MUST be dropped and a security event recorded. On success, the payload TLVs MUST be checked for completeness against Section 5.3; insufficient or unreasonable TLVs cause the packet to be dropped with an error recorded. The metadata block is then removed and the IP total-length and header checksum MUST be updated.¶
If the received metadata contains a TCP SYN Packet TLV (Section 10.4.9), the following MUST be performed on every packet of the session, in both directions (see Section 5.2.7):¶
The IP protocol field MUST be changed from 0x11 (UDP) back to 0x06 (TCP). The 32-bit value at the TCP checksum/urgent-pointer location is copied back to the sequence-number field; the urgent pointer is zeroed and its flag cleared. The TCP checksum MUST then be recomputed.¶
A packet whose source and destination addresses both map to a Peer Pathway is an SVR packet. Such packets without metadata are in-session traffic and MUST have matching session state; if no state exists, the packet MUST be dropped or session state MUST be restored (Section 3.11).¶
Ingressing in-session packets MUST be translated bidirectionally on all 5-tuple fields: source address to the local Waypoint, destination address to the chosen peer's Waypoint, ports to the allocated SVR ports, and protocol modified if UDP transformation applies (Section 5.2.7). Implementations SHOULD cache a single checksum delta per session, since the rewrite is identical for every packet.¶
Egressing in-session packets MUST have the original 5-tuple restored from saved session state (source/destination addresses, ports, and protocol -- with UDP-to-TCP restoration per Section 5.6.3 if applicable).¶
A provisioned SVR Policy SHOULD include both a Tenant and a Service. Absence of an applicable SVR Policy SHOULD prevent SVR session establishment; traditional IP routing MAY be used when no SVR policy applies.¶
A Service is a textual name for a set of CIDR blocks, protocols, and ports (e.g., "Zoom", "Office365").¶
Service Definition¶
Service Name
protocol: TCP/UDP
port ranges[]
CIDR Blocks[]
A packet arriving with SVR Metadata MUST carry the Service name in the first-packet metadata. A packet arriving without SVR Metadata is classified by destination address/port/protocol lookup; if that fails, application-recognition techniques (HTTP request inspection, TLS SNI, certificate Common Name) MAY be used. These techniques are out of scope for this document.¶
Services MAY have associated quality and security policies provisioned (out of scope here).¶
At SVR egress, the Service name MAY be used to forward to another SVR peer (in which case it MUST be carried unchanged) or to resolve to a final IP destination by one of:¶
Services SHOULD be provisioned with allow/deny lists of Tenants; these access controls are RECOMMENDED.¶
A Tenant is a period-delimited textual hierarchy, logically akin to a VLAN, CIDR subnet, or security zone. Policy match is performed right-to-left on full segments, with the longest segment match winning.¶
A Tenant SHOULD be paired with a Service to form a from-to vector (allowing ACLs to be tied directly to destinations). A provisioned SVR Policy SHOULD include both; absence of an applicable policy prevents session establishment. Default-deny is RECOMMENDED.¶
It is RECOMMENDED that Tenants be associated with physical and logical (VLAN) interfaces as defaults; CIDR-block-based Tenants SHOULD override these defaults; client self-asserted Tenants SHOULD override all other definitions.¶
Interface-based Tenant assignments are local to each SVR router; ingress and egress Tenant identities need not match, allowing heterogeneous segmentation across networks.¶
When payload encryption is required, a Security Policy specifies the agreed methods. The policy semantics MUST be valid and identical at the points of encryption and decryption (relevant for multi-hop SVR routes).¶
An SVR router generates a Payload Key locally on the first packet requiring encryption per the policy. Keys and IVs MUST be generated using a FIPS 140-3-approved DRBG; following NIST SP 800-90B for entropy is strongly RECOMMENDED (see [NIST_SP_800-90B]). OpenSSL's RAND_bytes() is one suitable option. The key is conveyed in the first encrypted packet's SVR Metadata. Future implementations MAY source key material from quantum entropy.¶
The metadata is forwarded hop-by-hop until SVR egress; the egress router MUST extract the Payload Key and store it in session state for decrypting all subsequent payload packets in that direction. The reverse direction uses an independently generated key, carried in reverse metadata. Asymmetric per-direction keying simplifies key management and avoids glare.¶
The originator MAY rekey at any time by inserting new SVR Metadata bearing a new key; the new key takes effect on the carrying packet.¶
The Security KEY TLV (Section 10.4.15) carries the encryption/decryption key in the first-packet metadata for each direction. End-to-end key conveyance is safe because SVR Metadata is encrypted hop-by-hop; payload decryption occurs only at the final SVR hop. Named Security Policies allow any cipher; the default is AES-256 with a 256-bit key.¶
Payload Encryption:¶
Peer A Peer B Peer C
| | |
fpkt--->| | |
| | |
Gen Key | |
Encrypt Payload | |
Add Key to MD | |
| | |
|--fpkt w/md--->| |
| Forward |
| |--fpkt w/md--->|
| | Save Key
| | |
| | |--fpkt->
| | |<-rpkt
| | |
| | Lookup Key
| | from session
| | |
| | Gen Key
| | Encrypt Payload
| | Add Key to MD
| |<--rpkt w/md---|
| Forward |
|<--rpkt w/md---| |
| | |
<-rpkt-| | |
<== ALL PAYLOAD PKTS ENCRYPTED =>
Peer Pathways are virtual transport links between routers, analogous to tunnels. SVR uses BFD for reachability, quality measurement, peer authentication, and key management.¶
It is RECOMMENDED that every configured or discovered Peer Pathway run a UDP BFD session for liveness and quality measurement.¶
BFD timers per pathway are administratively determined. Because BFD ([RFC5880]) does not natively support certificates or public-key exchange, SVR carries this information in BFD Metadata appended to BFD control messages. BFD Metadata is used to:¶
BFD Metadata is appended after the BFD control message; the IP, UDP, and BFD length fields MUST be adjusted accordingly.¶
BFD Metadata Location:¶
BFD Control Packet with BFD Metadata
+-----------+--------+---------+----------+
| IP Header | UDP | BFD | protobuf |
| | Header | Control | BFD |
| | | Packet | Metadata |
+-----------+--------+---------+----------+
| |
|<== BFD Pkt Len ==>|
All messages are BFD Control packets. "MeasureData" messages behave like BFD Echo packets and require Required Min Echo RX Interval ([RFC5880]) to be greater than zero.¶
BFD Metadata is encoded in protobuf as follows:¶
BFD Metadata Protobuf Definition:¶
syntax = "proto2";
package pb.bfd;
import "ip.proto";
message SessionData {
required ip.Tuple original_ipTuple = 1;
required ip.Tuple received_ipTuple = 2;
optional string peername = 3;
optional string routername = 4;
optional string routerID = 5;
}
message MeasureData {
message Request {
required uint32 transId = 1;
}
message Response {
required uint32 request_transId = 1;
required uint32 response_transId = 2;
}
oneof type {
Request request = 1;
Response response = 2;
}
optional bool mtu_discovery = 3;
}
message NodeInfo {
required uint32 id = 1;
required uint64 create_timestamp = 2;
optional uint64 time_value = 3;
optional string nonce = 4;
optional string public_key = 5;
optional uint32 salt = 6;
}
message Encrypted {
optional NodeInfo node_info = 1;
optional string metadata_key = 2;
optional uint32 metadata_key_index = 3;
optional string hmac_key = 4;
}
message Metadata {
optional SessionData sessionData = 1;
optional MeasureData measure = 2;
optional NodeInfo nodeInfo = 3;
optional Encrypted encrypted = 4;
}
SessionData carries the source address a remote peer observes for this router on a Peer Pathway. This is required for pathway establishment because configuration references router IDs rather than dynamic addresses; remote peers maintain a local resolution table (e.g., /etc/hosts) keyed by the configured hostname. This step can be combined with NAT detection (below).¶
Determination of Peer Received Address:¶
Router A Router B Local
[Addr A -> Addr B] DNS
| | |
|- BFD ---------------->| |
| original_ipTuple=A | |
| hostname="Router A" | |
| |- DNS Update---------->|
| | Router A: Address A |
| | |
| | |
Router B has hostname lookup for Router A
SessionData also detects NATs on a pathway, typically during initial peer establishment (and often combined with certificate exchange). Like STUN, the originating interface address is placed in SessionData.original_ipTuple; on receipt, a router stores the observed source address from the IP header in SessionData.received_ipTuple. Comparing the wire address against the peer's claimed original_ipTuple reveals any intervening NAT. The peername field MAY also be set.¶
BFD NAT Detection on Pathway:¶
Router A NAT Router B
Addr A Addr N Addr B
| | |
|- BFD ---------------->| |
| original_ipTuple=A | |
| | |
| |- BFD ---------------->|
| | original_ipTuple=N |
| | |
| | |
| |
| | NAT Detected
| | Router B gets N
| | address on the wire
| | and it doesn't match
| | original_ipTuple
| |
| | |
| | |
| |<---------------- BFD -|
| | original_ipTuple=B |
| | received_ipTuple=N |
|<---------------- BFD -| |
| original_ipTuple=B | |
| received_ipTuple=N | |
| | |
No NAT detected
Router A gets B's address
on the wire which matches
the original_ipTuple
When NAT is detected, the NAT-side address MUST be associated with the pathway to the far peer. Sessions traversing such a pathway may require NAT keep-alive processing (Section 7.3).¶
Branch routers commonly receive their addresses dynamically (DHCP, LTE, PPPoE) and the address may change unexpectedly (e.g., lease expiry or reconnection). Without intervention, peers using the old address would lose connectivity. SessionData BFD Metadata makes learning the new address and recovering connectivity fast.¶
BFD Detection on Router Address Change:¶
Router A DHCP Router B
[Addr A -> Server <- Addr B]
| | |
|- BFD ------------------------------------>|
| original_ipTuple=A | |
| received_ipTuple="" | |
| | |
|<------------------------------------ BFD -|
| | original_ipTuple=B |
| | received_ipTuple=A |
|- BFD ------------------------------------>|
| original_ipTuple=A | |
| received_ipTuple=B | |
Both routers have learned each other's IP Address
and have determined there are no NATs between them
|- DHCP Lease Exp --->| |
|<---- New Address C -| |
| | |
|- BFD ------------------------------------>|
| original_ipTuple=C | |
| received_ipTuple=B | |
|<------------------------------------ BFD -|
| | original_ipTuple=B |
| | received_ipTuple=C |
Both routers have the correct IP Address and
have determined there are no NATs between them
Knowing the pathway MTU lets routers fragment when necessary. After a pathway is established, BFD MeasureData packets of increasing size probe for the limit; the IP, UDP, and BFD length fields are adjusted to enlarge the BFD packet. A peer that receives a fragmented MeasureData request with mtu_discovery=TRUE simply does not respond, signaling that the size exceeds the path MTU.¶
Because networks change, MTU SHOULD be remeasured periodically.¶
BFD MeasureData for Determining Pathway MTU:¶
Router A Router B
[Addr A -> <-Addr B]
| |
|-BFD MeasureData (id=1, size 1200)-------------->|
|-BFD MeasureData (id=2, size 1250)-------------->|
|-BFD MeasureData (id=3, size 1300)-------------->|
|-BFD MeasureData (id=4, size 1350)-------------->|
|-BFD MeasureData (id=5, size 1400)-------------->|
|-BFD MeasureData (id=6, size 1450)-------------->|
|-BFD MeasureData (id=7, size 1500)-{fragmented}->|
| |
|<----(req_id=1, resp_id=1)-------BFD MeasureData-|
|<----(req_id=2, resp_id=2)-------BFD MeasureData-|
|<----(req_id=3, resp_id=3)-------BFD MeasureData-|
|<----(req_id=4, resp_id=4)-------BFD MeasureData-|
|<----(req_id=5, resp_id=5)-------BFD MeasureData-|
|<----(req_id=6, resp_id=6)-------BFD MeasureData-|
MTU Size = 1450
Once a pathway is operational, BFD MeasureData packets are used to measure latency, jitter, and loss. Either side MAY measure; burst size and frequency are configuration. Hub routers with many pathways often rely on spoke-side measurements rather than measuring themselves.¶
BFD-based measurement is useful only when a pathway is idle. For pathways carrying live sessions, SVR Path Metrics are used (Section 10.3.7).¶
The receiver responds to each request by echoing it with its own transaction ID. Each request and each response carry a transaction ID, eliminating any ambiguity between requests and responses.¶
BFD MeasureData for Measuring Pathway Quality:¶
Router A Router B
[Addr A -> <-Addr B]
| |
|-BFD MeasureData (req_id=1)------------------>|
|-BFD MeasureData (req_id=2)------------------>|
|-BFD MeasureData (req_id=3)------------------>|
.......
|-BFD MeasureData (req_id=n)------------------>|
| |
|<----(req_id=1, resp_id=1)----BFD MeasureData-|
|<----(req_id=3, resp_id=2)----BFD MeasureData-|
|<----(req_id=1, resp_id=3)----BFD MeasureData-|
......
|<----(req_id=N, resp_id=N-1)--BFD MeasureData-|
Latency = Sum of RTT(pkt 1-n)/(2*n)
Jitter = Std Dev RTT(pkt 1-n)
Packet Loss = 1-((Pcks_Sent - Pcks_recv)/Pkts_Sent)
The sender derives latency from the round-trip times of matching request/response IDs; missing responses count as packet loss; the distribution of RTTs gives jitter; MoS scores follow from latency, loss, and jitter together. Each direction is measured independently because network behavior may be asymmetric.¶
BFD NodeInfo carries a node ID (cluster member instance) and a peer start timestamp. Changes to either signal cluster failover or peer-side restart, allowing remote peers to react to redundancy events on the far side of a pathway. Inclusion of this information is OPTIONAL.¶
A router lacking a valid signed certificate MUST obtain one from a CA. The router generates an elliptic-curve key pair ([RFC8422]) -- elliptic curves are used to keep the X.509 certificate small -- and submits an X.509 CSR with the router's UUID as the Common Name. The CA returns an ECDSA-signed certificate. Detailed enrollment procedures are out of scope but SHOULD follow [RFC4210]. Certificates and public keys are stored locally in PEM format ([RFC7468]).¶
Router Authentication:¶
Router A
Certificate
Router A Authority
| |
+------+------+ |
|Cert Missing,| |
| Invalid | |
| or Expiring | |
+-------------+ |
| |
+-----+------+ |
| Create | |
| Curve-P256 | |
| Pub/Priv | |
| Key Pair | |
+------------+ |
| |
+-----+------+ |
| Create | |
| X.509 Cert | |
| CN=RouterA | |
+------------+ |
| |
+------CSR------>|
|
|<-X.509 Signed--+
The certificate is persisted on the router in PEM format. The associated private key SHOULD be created and stored in secure non-volatile storage such as a TPM.¶
During pathway establishment, peers authenticate using their UUIDs and public keys, then derive a symmetric Peer Key from their X.509 key material. UUIDs are used (rather than IP addresses) because router addresses commonly change (e.g., DHCP lease expiry on branch routers).¶
The diagram below shows two routers with two pathways each exchanging X.509 certificates in BFD NodeInfo public_key fields. Certificates are exchanged on every pathway but validated only once per peer.¶
Router Authentication:¶
Router A Router A Router B Router B
Peerpath 1 Peerpath 2 Peerpath 1 Peerpath 2
| | | |
=============ALL PEER PATHS ARE DISCONNECTED==========
| | | |
|--BFD w/X.509 Cert----->| |
| |--BFD w/X.509 Cert------>|
| | | |
....Delay between retransmissions .......
| | | |
|--BFD w/X.509 Cert----->| |
| | Router A |
| | Validated |
| | | |
| |--BFD w/X.509 Cert------>|
| | | |
|<----BFD w/X.509 Cert---| |
Router B | | |
Validated | | |
| |<-----BFD w/X.509 Cert---|
| | | |
=============ALL PEER PATHS ARE OPERATIONAL==========
| | | |
....Delay between retransmissions .......
| | | |
|----BFD---------------->| |
| |-------BFD-------------->|
|<-------------BFD-------| |
| |<-------------BFD--------|
A received certificate MUST be validated:¶
Validation runs once per peer; subsequent receipts of the same certificate on other pathways MAY use a cached result. After validation, the receiver extracts and stores the peer's public key for use in Peer Key/rekey authentication.¶
A router SHOULD renew its certificate using the same procedure before expiry.¶
A single Peer Key is used across all pathways between two router peers and remains valid until replaced. The key persists across network outages. If the key is lost or fails, a new key MUST be established before encrypted BFD traffic can resume.¶
To establish or replace a key, the initiator generates a salt and sends it in BFD NodeInfo; the peer responds with its own salt in BFD NodeInfo. With both salts, each side runs Concat KDF to derive a symmetric Peer Key.¶
Concat KDF ([NIST_SP_800-56A]) uses the routers' authenticated certificate private keys, providing man-in-the-middle resistance.¶
OpenSSL provides ConcatKDF() with the following parameters:¶
ConcatKDF Function (Part of OpenSSL):¶
Peer Key = ConcatKDF(SharedSecret,
AlgorithmID,
PartyUInfo,
PartyVInfo,
SuppPubInfo,
SuppPrivInfo,
KeyDataLen)
Here's what each parameter represents:
SharedSecret: The result of an ECDH calculation with the peer
AlgorithmID: "ECDH"
PartyUInfo: UUID of the Router
PartyVInfo: UUID of the Peer Router
SuppPubInfo: Initiator Salt Concatenated with Responder Salt
SuppPrivInfo: ""
KeyDataLen: 256
¶
SuppPubInfo is the initiator salt concatenated with the responder salt; SharedSecret is the result of an ECDH exchange ([ECDH_Key_Exchange]).¶
After a brief guard period (1-2 s) to allow both sides to complete their computation, the Peer Key is active across all pathways between the two peers and replaces any prior key.¶
The key MAY be used immediately to encrypt BFD Metadata.¶
Peer Key-Rekeying:¶
Router A Router A Router B Router B
Peerpath 1 Peerpath 2 Peerpath 1 Peerpath 2
| | | |
.......NO Current Peer Key Exists............
| | | |
Gen Salt | | |
| | | |
|--BFD Nodeinfo Req----->| |
| | | |
| | Gen Salt |
| | | |
|<----BFD Nodeinfo Req---| |
| | | |
Key | Key |
Computed | Computed |
| | | |
........Transition Guard Time..............
| | | |
......... 1st Peer Key Exists..............
| | | |
...........At Rekeying Interval............
| | | |
| Gen Salt | |
| | | |
| |--BFD NodeinfoReq------->|
| | | |
| | | Gen Salt
| | | |
| |<---BFD Node Info Req----|
| | | |
Key | Key |
Computed | Computed |
| | | |
..........Transition Guard Time.............
| | | |
........... 2nd Peer Key Exists.............
The Peer Key is symmetric and is used to encrypt the SVR Metadata Key exchange. Concat KDF (a form of ECDH-ES) yields a symmetric key only if there is no man-in-the-middle; if peers cannot decrypt each other's messages, an MITM is likely and the affected pathway SHOULD be removed from service.¶
If a BFD NodeInfo elicits no response, the sender retries periodically; after an extended interval (e.g., 1 hour) with no response, the pathway MAY be declared invalid and removed from service per administrative timers.¶
The SVR Metadata security association is not pathway-specific: multiple pathways may share an interface or source address (e.g., over the public Internet), so peer identity can only be established by decrypting the metadata. Each SVR router MUST therefore be able to decrypt SVR Metadata arriving on any interface.¶
SVR Metadata is encrypted for the chosen next-hop SVR router; no other router should be able to decrypt it. Senders MUST select the key associated with the chosen next-hop peer.¶
Keys are generated locally per the security policy using a FIPS 140-3-approved DRBG (NIST SP 800-90B for entropy is RECOMMENDED; see [NIST_SP_800-90B]). OpenSSL's RAND_bytes() is suitable for producing a 256-bit key.¶
The key and its index are distributed to all known peers in an Encrypted BFD NodeInfo message. The 256-bit SVR Metadata Key is encrypted with the current Peer Key, producing a 32-octet ciphertext plus a 16-octet IV (48 octets total). The key index is incremented on each rekey. Encryption follows the SVR Metadata encryption procedure (Section 4.7.1.8) but uses the Peer Key. SVR Metadata keys are asymmetric: forward metadata is encrypted with the destination router's key, reverse metadata with the originating router's key.¶
SVR Metadata Key/Rekeying:¶
Peer A Peer B Peer C Peer D
| | | |
...NO Current SVR Metadata Key Exists For A....
| | | |
Gen Key | | |
Inc Indx | | |
| | | |
|-BFD w/key->| | |
|<-BFD w/key-| | |
| | |
|--------BFD w/key------->| |
|<-------BFD w/key--------| |
| |
|----------------BFD w/key------------>|
|<---------------BFD w/key-------------|
| | | |
..........A updates SVR Metadata Key .........
| | | |
Gen New Key | | |
Inc Indx | | |
| | | |
|-BFD w/key->| | |
|<-BFD w/key-| | |
| | |
|--------BFD w/key------->| |
|<-------BFD w/key--------| |
| |
|----------------BFD w/key------------>|
|<---------------BFD w/key-------------|
The diagram shows Peer A distributing its key/index to Peers B, C, and D, then later rekeying. Each peer responds with its own current key/index, providing a handshake; this is also how a restarting router quickly acquires every key it needs. A router that needs to send SVR Metadata to a peer for which it lacks a key MAY use this procedure to obtain it. Whenever a peer rekeys, it MUST update all of its peers. Stored peer state pairs each shared key with its metadata_key_index; the Security ID field in incoming SVR Metadata identifies which key to use for decryption (Section 10.3.2).¶
A new certificate loaded onto the router triggers re-execution of the peer authentication procedure (Section 6.1.7). The mechanism for loading the certificate is out of scope.¶
If a system is compromised, its certificate SHOULD be revoked. The router's management platform SHOULD periodically check the CRL, or use OCSP to validate certificates directly. On revocation, the router consults configured policy to choose its behavior.¶
A policy SHOULD govern behavior on certificate expiry or revocation. The default SHOULD be fail-soft (signal that action is required). A fail-hard configuration MUST tear down all peering relationships, removing the router from SVR participation.¶
The following examples illustrate additional uses of SVR Metadata. They are not exhaustive.¶
Any SVR router MAY move an existing session onto a different Peer Pathway by re-emitting the session-establishment metadata of Section 4.7.1.7 on the new pathway while preserving the Session UUID. It simultaneously updates fast-path forwarding for the new Waypoints/ports; everything else about the session is unchanged. Both endpoints MUST then redo NAT detection on the new pathway and update wire addresses/ports as needed.¶
Old and new fast-path entries are kept for ~5 seconds to avoid dropping in-flight packets, after which the old state is removed.¶
Ladder Diagram for Existing Session Reroute with SVR Metadata:¶
RTR-A RTR-B RTR-C RTR-D
Client . . . . . . . . . . . . . . . . . . . . . . . . Server
| | | | | |
|--PUSH--->| | | | |
| |--PUSH-------------->| | |
| | | |--PUSH--->| |
| | | | |--PUSH--->|
| | | | |<---ACK---|
| | | |<---ACK---| |
| |<--------------ACK---| | |
|<---ACK---| | | | |
| | | | | |
......................RTR-C Fails.......................
|--PUSH--->| | | | |
| |--PUSH--->| | | |
| | [MD1] | | | |
| | |--PUSH[MD2]--------->| |
| | | | |--PUSH--->|
| | | | |<--ACK----|
| | |<-----ACK[RMD2]------| |
| |<--ACK----| | | |
|<--ACK----| [RMD1] | | | |
| | | | | |
|<==== Session Packets Flow without SVR Metadata =====>|
When Router C fails, Router B inserts MD1/MD2 in the next packet in either direction; RMD1/RMD2 confirm the move. For TCP this can be a PUSH (shown) or an ACK. The technique installs SVR session state on Router B even though it had no prior involvement in the session, and can equally be used to migrate a session between transports (e.g., MPLS to LTE). A move can be initiated by any router at any time.¶
Ladder Diagram for Session Reroute Between Peers with SVR Metadata:¶
+-------+ +--------+
| +-----MPLS-----+ |
Client--| Rtr-A | | Rtr-B +----Server
| +------LTE-----+ |
+-------+ +--------+
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
| | | |
|---PUSH---->| | |
| |---PUSH over MPLS-------->| |
| | |---PUSH--->|
................MPLS has Poor Quality ................
| | | |
|---PUSH---->| | |
| |---PUSH over LTE[MD]----->| |
| | |---PUSH--->|
| | |<---ACK----|
| |<---ACK over LTE[RMD]-----| |
|<---ACK-----| | |
| | | |
|<=== Session Packets Flow without SVR Metadata ===>|
The diagram shows an active TCP session migrated from MPLS to LTE by inserting metadata on any in-flight packet; reverse meta data on the reverse direction confirms the move.¶
Idle sessions and one-way flows (TCP pushes with bare ACKs) may not offer a packet into which metadata can be piggybacked.¶
If, after a move, no packets are seen for 1 second on an active session, the SVR router MUST emit an SVR Control Message to its peer.¶
Ladder Diagram for One Way Media Move with SVR Metadata:¶
+-------+ +--------+
| +-----MPLS-----+ |
Client--| Rtr-A | | Rtr-B +----Server
| +------LTE-----+ |
+-------+ +--------+
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
| | | |
| | |<---PUSH---|
| |<---PUSH over MPLS------->| |
|<---PUSH----| | |
|----ACK---->| | |
| |------ACK over MPLS------>| |
| | |---ACK---->|
| X RouterA MPLS FAILS | |
| X RouterB MPLS OK| |
| X | |
..............RouterA Moves Session to LTE..........
| | |<---PUSH---|
| X<---PUSH over MPLS------->| |
| | |<---PUSH---|
| X<---PUSH over MPLS------->| |
| | | |
.......NO Packets at Router A for Moved Session......
| | | |
| |-----[MD over LTE]------->| |
...............RouterB Moves Session to LTE..........
| | |<---PUSH---|
| |<--PUSH over LTE [RMD]--->| |
|<---PUSH----| | |
|----ACK---->| | |
| |------ACK over LTE------->| |
| | |---ACK---->|
|<======== Session Packets Continue flowing =======>|
The SVR Control Message uses the new Waypoint addresses and carries the standard first-packet TLVs plus an SVR Control Message TLV with drop reason "FLOW MOVED" and a Remaining Session Time TLV (so that intermediate routers age the session out roughly together). It is sent once per second for up to 5 seconds, or until reverse metadata arrives; if no reverse metadata arrives within 5 seconds, the session is torn down. For an idle flow the reverse metadata is itself a generated SVR Control Message:¶
Ladder Diagram for Quiescent Moved Session with SVR Metadata:¶
+-------+ +--------+
| +-----MPLS-----+ |
Client--| Rtr-A | | Rtr-B +----Server
| +------LTE-----+ |
+-------+ +--------+
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
| | | |
|<========== Quiescent Session Established ========>|
| | | |
| X RouterA MPLS FAILS | |
| X RouterB MPLS OK| |
| X | |
..............RouterA Moves Session to LTE..........
| | | |
| |-----[MD over LTE]------->| |
| | | |
...............RouterB Moves Session to LTE..........
| | | |
| |<-----[RMD over LTE]----->| |
| | | |
|<=========== Quiescent Session Continues =========>|
When a Peer Pathway has one or more NATs (Section 3.5), each side MUST refresh the NAT bindings for each active session by sending a keep-alive packet that matches the idle session's L4 header and carries SVR Metadata with TLV 24 and drop reason "Keep Alive".¶
Ladder Diagram for NAT Keep Alive with SVR Metadata:¶
RTR-A NAT RTR-B
Client . . . . . . . . . . . . . . . . . . Server
| | | | |
...................Existing SVR Session......
|--PUSH--->| | | |
| |--PUSH--->| | |
| | |---PUSH-->| |
| | | |--PUSH--->|
| | | |<---ACK---|
| | |<---ACK---| |
| |<--PUSH---| | |
|<--PUSH---| | | |
.........NO PACKETS EITHER DIRECTION FOR 20 SECS.......
| | | | |
| |--[MD1]-->| | |
| | |--[MD1]-->| |
| | | | |
.........NO PACKETS EITHER DIRECTION FOR 20 SECS.......
| | | | |
| |--[MD1]-->| | |
| | |--[MD1]-->| |
| | | | |
A keep-alive MUST contain:¶
This minimal set lets the receiver verify the session (by UUID) and update any NAT-state changes.¶
Unlike a tunnel, each SVR session is independent, so SVR can encrypt only those sessions that are not already encrypted by the application. With adaptive encryption every session begins unencrypted; by inspecting the first four packets, the router determines whether application-layer encryption is in use (e.g., a TLS Client Hello). If yes, no SVR encryption is applied; otherwise SVR encryption is enabled bidirectionally.¶
Ladder Diagram of Adaptive Encryption with Client Hello:¶
Client . . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
|---SYN----->| | |
| |----SYN[MD1]----->| |
| | |---SYN---->|
| | |<--SYN/ACK-|
| |<----SYN/ACK------| |
|<--SYN/ACK--| [RMD1] | |
|---ACK----->| | |
| |------ACK-------->| |
| | |---ACK---->|
|--Client--->| | |
| Hello |<== ENCRYPTION===>| |
| | Not Required | |
| | | |
| |-----Client------>| |
| | Hello |--Client-->|
| | | |
If the fourth packet does not indicate transport-layer encryption, the ingress and egress SVR routers MUST encrypt and decrypt the session bidirectionally, ensuring all data between SVR routers is encrypted.¶
Ladder Diagram of Adaptive Encryption with data:¶
Client . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
|---SYN----->| | |
| |--SYN[MD1]--->| |
| | |---SYN---->|
| | |<--SYN/ACK-|
| |<--SYN/ACK----| |
|<--SYN/ACK--| [RMD1] | |
|---ACK----->| | |
| |----ACK------>| |
| | |---ACK---->|
|---Data---->| | |
| |<==ENCRYPT===>| |
| | Required | |
| | | |
| |--Encrypted-->| |
| | Data |---Data--->|
Adaptive encryption is configured via Security Policy. Policies are bound to Services, so different Services may mandate, allow, or disallow encryption.¶
A fragmented packet arriving at an SVR router MUST be fully reassembled before processing, since HMAC and routing apply to the whole packet. The router then re-fragments as needed onto the Peer Pathway, copying the Peer Pathway's L4 header onto every fragment and inserting SVR Metadata identifying the fragment to the downstream peer. The Time-Based HMAC covers the entire packet and is appended to the last fragment.¶
Ladder Diagram Fragmented Packets:¶
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
| | | |
|--Frag 1--->| | |
|--Frag 3--->| | |
|--Frag 2--->| | |
| +---+----+ | |
| |Assemble| | |
| +---+----+ | |
| |----Frag 1[L4/MD]-------->| |
| | | |
| |----Frag 2[L4/MD]-------->| |
| | | |
| |----Frag 3[L4/MD]-------->| |
| | +--------+ |
| | |Assemble| |
| | +--------+ |
| | |--Frag 1-->|
| | |--Frag 2-->|
| | |--Frag 3-->|
Router A reassembles, recording the original ID and largest fragment size. It then transmits the reassembled jumbo packet, re-fragmenting onto the chosen Peer Pathway with the pathway's L4 header on each fragment. The fragment size is min(path-MTU, largest-fragment-seen). The SVR Metadata header and header TLVs are not encrypted; the per-fragment layout is:¶
SVR Packet Layout¶
Fragment 1
+------+------+----------+----------+----------+
| | | SVR | | |
| Peer | Peer | Metadata | Header | First |
| IP | L4 | Header | TLV-1,16 | Fragment |
| HDR | HDR | 12 Bytes | 22 Bytes | |
+------+------+----------+----------+----------+
Fragment 2
+------+------+----------+----------+----------+
| | | SVR | | |
| Peer | Peer | Metadata | Header | Second |
| IP | L4 | Header | TLV-1 | Fragment |
| HDR | HDR | 12 Bytes | 14 Bytes | |
+------+------+----------+----------+----------+
Fragment 3
+------+------+----------+----------+----------+-----------+
| | | SVR | | | |
| Peer | Peer | Metadata | Header | Third | PKT |
| IP | L4 | Header | TLV-1 | Fragment | HMAC |
| HDR | HDR | 12 Bytes | 14 Bytes | | SIGNATURE |
+------+------+----------+----------+----------+-----------+
The SVR Metadata Type 1 header gets its own extended ID, allowing the number of fragments between Router A and Router B to differ from the client/server fragmentation. Router B re-fragments to its egress MTU using the Largest Fragment Seen value carried in the metadata.¶
No other SVR Metadata fields are required; session state is keyed by the Peer Pathway 5-tuple. The fragmentation mechanics are otherwise standard IP fragmentation.¶
If a router itself needs to fragment a packet (e.g., to make room for SVR Metadata), it inserts SVR Metadata on the first fragment, duplicates the L4 header on the remaining fragments, and inserts SVR Metadata on each. In this case, Largest Fragment Seen and Original ID are left blank.¶
Ladder Diagram Fragmented Packets:¶
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
| | | |
|--Lg Pkt--->| | |
| |--------Frag 1[MD]------->| |
| | | |
| |----Frag 2[L4 Hdr|MD]---->| |
| | |--Lg Pkt-->|
| | | |
IPv6 fragments only at the source, so SVR routers perform no special handling. An oversized packet elicits an ICMPv6 "Packet Too Big" from the destination, which the routers forward back along the reverse flow.¶
Client . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
|--Lg Pkt--->| | |
| |----Lg Pkt--->| |
| | |--Lg Pkt--->|
| | |<--ICMPv6---|
| |<--ICMPv6-----| |
|<--ICMPv6---| | |
| | | |
ICMP messages fall into two categories. The first is session-associated network errors:¶
These carry the original IP header plus 8 octets ([RFC0792]) and MUST be returned to the session originator. The router parses the embedded IP header to identify the session, then forwards the ICMP message back across the SVR network as reverse SVR Metadata, with the destination set to the upstream peer's Waypoint. SVR Metadata Types 20/21 (Section 10.3.4, Section 10.3.5) carry the original ICMP source address hop-by-hop until the ingress router recreates the ICMP message with the correct source address.¶
SVR Fragment Packet Layout¶
+------------+------------+----------------+--------------+
| | | SVR | |
| IP HEADER | UDP HEADER | Metadata 20/21 | ICMP Packet |
+------------+------------+----------------+--------------+
ICMP over SVR for Network Failures¶
Client . . . . . . . . . . . . . . . . . . . . . . .No Network
| Found
| Router A Router B |
| | | |
|----PKT---->| | |
| |------PKT[MD]------------>| |
| | |<---ICMP-----|
| | | (Router B) |
| |<--UDP[ICMP[RMD]]---------| |
|<---ICMP----| | |
| (Client) | | |
| | | |
Router B receives the ICMP error, looks up the session, and forwards back to Router A's Waypoint; Router A recreates the ICMP message and delivers it to the client.¶
The second category is session-independent ICMP (e.g., ICMP Echo). SVR encapsulates these as UDP and creates a session keyed by the ICMP identifier and IP addresses:¶
ICMP over SVR for Information¶
Client . . . . . . . . . . . . . . . . . . . . . . . Target
| |
| RouterA RouterB |
| | | |
|--ICMP ECHO---->| | |
| |---UDP[ICMP ECHO]->| |
| | [MD1] | |
| | |---ICMP ECHO--->|
| | |<--ECHO RESP----|
| |<--UDP[ECHO RESP]--| |
| | [RMD1] | |
|<--ECHO RESP----| | |
The first Echo Request creates a UDP-encapsulated session at Router A; MD1/RMD1 establish the bidirectional path. Subsequent ECHO messages reuse the path without further metadata. Session state MUST be aged with an inactivity timer.¶
ICMPv6 is handled identically; only header sizes/types differ.¶
Session state can occasionally be lost. Most applications recover on their own, but long-lived idle sessions (e.g., SIP on idle handsets) may need explicit state recovery.¶
Every SVR session has at least one router holding full state. Recovery techniques include obtaining state from a peer or regenerating it from session-establishment metadata.¶
The simplest case is loss at the ingress router: a fresh session is created using the original parameters; first-packet metadata then reaches the egress, which updates state, restoring the bidirectional flow. The first-packet metadata is signed and encrypted, so this recovery is secure.¶
State Recovering Ingress Router with Active Session¶
Client . . . . . . . . . . . . . . . . . . . . . . . Server
| |
| Ingress Middle Egress |
| SVR BOX SVR |
| | | | |
<================Existing Bi-Directional Session=========>
| | | | |
| State | | |
| Lost | | |
| | | | |
|---PKT---->| | | |
| Create | | |
| New | | |
| Session | | |
| |--PKT[MD]->| | |
| | |--PKT[MD]--->| |
| | | Update |
| | | Existing |
| | | Session |
| | | |----PKT------->|
If the ingress loses state while the client is idle (server-side data cannot be delivered), the egress checks the client inactivity timer (default 5 s) on the next server packet, and if exceeded inserts Session Health Check metadata (Section 10.3.8). The ingress responds by generating a UDP packet matching the session's L3/L4 with an SVR Control Message (Section 10.3.6) carrying drop reason 6 ("delete session"). The egress then clears state, and the next server packet carries first-packet SVR Metadata, treated as a new session for state restoration.¶
State Recovering Ingress Router Client Inactive¶
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| Ingress Middle Egress |
| SVR BOX SVR |
| | | | |
<============== Existing Bi-Directional Session ======>
| | | | |
| State | | |
| Lost | | |
| | | |<----PKT-----|
| | | | |
| | | Client Inactivity |
| | | Timer Exceeded |
| | | | |
<---<--< SEND SESSION HEALTH CHECK METADATA <---<---<--
| | | | |
| | |<---PKT[MD]--| |
| |<--PKT[MD]---| | |
| No State | | |
| | | | |
>---->--->SEND SVR Control Metadata Drop=6 >--->---->-
| | | | |
| |-GenPKT[MD]->| | |
| | |-GenPKT[MD]->| |
| | | | |
| | | Clear State |
| | | | |
| | | Send First |
| | | PKT SVR Metadata |
| | | Next PKT |
| | | | |
<--<- ON NEXT PACKET SEND FIRST PACKET METADATA <---<--
| | | | |
| | | |<---PKT------|
| | |<--PKT[MD]---| |
| |<--PKT[MD]---| | |
| | | | |
| New Session State | | |
| | | | |
=======Treat as a new session from this point =========
If the egress loses state, it pulls state from a peer. The ingress recognizes the recovery condition when it receives a packet for a session the server has not responded to within the inactivity timer; it augments the next packet with Session Health Check metadata (Section 10.3.8). The egress MUST respond with a UDP packet carrying an SVR Control Message (Section 10.3.6) using drop reason 2 ("send metadata"). The client's next packet will carry full first-packet SVR Metadata, restoring egress state.¶
State Recovering Egress Router¶
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| Ingress Middle Egress |
| SVR BOX SVR |
| | | | |
<============ Existing Bi-Directional Session ========>
| | | | |
| | | State |
| | | Lost |
| | | | |
|---PKT---->| | |<----PKT-----|
| |----PKT----->| | |
| | |----PKT----->| |
| | | | |
| | | Pkts Dropped |
|---PKT---->| | | |
| Inactivity | | |
| Exceeded | | |
| | | | |
>--->---> SEND SESSION HEALTH CHECK METADATA >--->--->|
| | | | |
| |---PKT[MD]-->| | |
| | |--PKT[MD]--->| |
| | | No State |
| | | | |
<----<---- SEND SVR CONTROL MESSAGE TYPE=2 <----<----<-
| | | | |
| | |<-GenPKT[MD]-| |
| |<-GenPKT[MD]-| | |
|---PKT---->| | | |
| | | | |
-->---> SEND FIRST PACKET METADATA IN NEXT PACKET --->|
| | | | |
| |---PKT[MD]-->| | |
| | |--PKT[MD]--->| |
| | | Session |
| | | State Restored |
| | | |----PKT----->|
| | | | |
Middleboxes are the most common cause of state loss; they may stop forwarding in one or both directions, or silently rewrite ports.¶
Because the location of the loss is unknown, the router includes Session Health Check metadata in a packet of the session. SVR peers MUST respond; absence of a response indicates a middlebox or network problem.¶
Recovery is performed by clearing session state and treating the next packet as a first packet (full SVR Metadata exchange per Section 4.7.1). Both ingress and egress detect the matching 5-tuple and replace the existing session state.¶
State Recovering of Middlebox¶
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| Ingress Middle Egress |
| SVR BOX SVR |
| | | | |
<============ Existing Bi-Directional Session =======>|
| | | | |
| | State | |
| | Lost | |
| | | | |
|---PKT---->| | |<---PKT------|
| |----PKT----->| | |
| | |<---PKT------| |
| | Packets | |
| | Dropped | |
| Inactivty | | |
| Exceeded | | |
| | | | |
|---PKT---->| | | |
| | | | |
| | | | |
| |---PKT[MD]-->| | |
| | | | |
| No Response | | |
| | | | |
| Re Allocate Ports | | |
| Update Session State | | |
| | | | |
|---PKT---->| | | |
| | | | |
---> SEND FIRST PACKET METADATA, KEEP OLD SESSIONID -->
| | | | |
| |--PKT[MD]--->| | |
| | |--PKT[MD]--->| |
| | | Update |
| | | Session |
| | | |----PKT----->|
| | | | |
This section describes how SVR transports IPv4 and IPv6 multicast traffic across an SVR overlay. SVR's session model, designed for unicast TCP/UDP, is extended to multicast by treating each (S,G) flow as a long-lived, unidirectional SVR session whose set of egress peers is derived from receiver-side group membership.¶
SVR multicast is a hybrid distribution model:¶
A single (S,G) flow MAY use a mix of both modes simultaneously (e.g., native multicast on an MPLS pathway and ingress replication over the Internet) without coordination beyond what is described below.¶
Multicast control-plane interaction with hosts uses standard IGMPv2 ([RFC2236]), IGMPv3 ([RFC3376]), and MLDv2 ([RFC3810]) at the SVR edge only. SVR does NOT run PIM, MSDP, or any multicast routing protocol over Peer Pathways; receiver state is distributed inside the SVR control channel as described in Section 8.3.¶
When an LHR receives an IGMP/MLD Report or Done/Leave message that changes its receiver state for an (S,G), it MUST signal the change to every potential FHR using an SVR Control Message (Section 10.3.6) carrying a Multicast Group Context TLV (Section 10.4.16).¶
The set of potential FHRs for a group is determined by routing policy (typically, peers that advertise reachability to the source prefix in ASM, or to the explicit source in SSM). Distribution of this policy is outside the scope of this document.¶
An FHR maintains the Egress Set per (S,G) as the union of all LHRs that have signaled non-empty receiver interest and have not subsequently signaled withdrawal. Egress Set entries SHOULD be soft state, refreshed at an administratively configured interval (default 60 seconds, RECOMMENDED upper bound 240 seconds, to align with IGMPv3/MLDv2 query intervals).¶
When the FHR receives the first packet of an (S,G) flow whose Egress Set is non-empty, it MUST construct forward SVR Metadata identical in structure to a unicast first packet (see Section 4.7.1) with the following differences:¶
For each entry in the Egress Set, the FHR then chooses a Peer Pathway to that LHR using the same selection logic as for unicast (Section 4.7.1.4). If two or more chosen pathways share a common multicast-capable Waypoint, the FHR MAY transmit a single copy onto that Waypoint with a multicast destination address; this is the native-multicast optimization. Otherwise, the FHR transmits one unicast copy per chosen pathway (ingress replication).¶
An LHR that receives a multicast SVR packet:¶
Because multicast SVR sessions are unidirectional, the standard bidirectional handshake cannot be used to confirm receipt of SVR Metadata. Instead:¶
All multicast SVR packets MUST be authenticated with the same Time-Based HMAC mechanism as unicast SVR (Section 5.5.1). The Session HMAC Key is established from the Peer Key of the FHR-to-LHR Peer Pathway being used; when a single replicated copy traverses a native-multicast underlay to multiple LHRs, every LHR in the Egress Set MUST share a common Metadata Key derived as described in Section 6.1.9, and that key MUST NOT be reused outside the Egress Set.¶
Payload encryption (Section 7.4) for multicast uses a single Payload Key generated by the FHR and distributed to every LHR in the Egress Set inside the encrypted portion of the unicast SVR Metadata sent at session start (or at rekey). When native-multicast replication is in use, the Payload Key is additionally distributed to all LHRs out-of-band over their respective unicast Peer Pathways before it is first applied to the shared multicast packet stream.¶
LHR removal from the Egress Set MUST trigger a Payload Key rekey if payload encryption is in use; otherwise a departing receiver could decrypt traffic for which it is no longer authorized.¶
SVR is dual-stack by design. This section consolidates IPv6-specific behavior that applies in addition to, or in place of, the procedures described elsewhere for IPv4. Where an existing section is IP-version-agnostic it is referenced; where it is not, the IPv6 behavior is stated here.¶
An SVR Waypoint MAY be an IPv6 Global Unicast Address (GUA, [RFC4291]) or a Unique Local Address (ULA, [RFC4193]). Link-local addresses (fe80::/10) MUST NOT be used as Waypoints because they are not routable beyond a single link and therefore cannot anchor an SVR Peer Pathway. IPv4-mapped IPv6 addresses (::ffff:0:0/96) MUST NOT be used as Waypoints; an IPv4 Waypoint is configured as an IPv4 address.¶
A single SVR router MAY simultaneously expose IPv4 and IPv6 Waypoints on the same physical interface; each is treated as an independent Peer Pathway. A given SVR Peer relationship MAY span IPv4-only, IPv6-only, and dual-stack pathways; the Peer Pathway selected for a session (Section 4.7.1.4) determines the IP version of the encapsulating transport, independently of the IP version of the original packet.¶
Because the original 5-tuple is preserved in the Forward Context TLV and reconstructed at the egress SVR router, an SVR session whose original packet is IPv4 MAY traverse an IPv6 Peer Pathway, and vice versa. Concretely:¶
This behavior provides a NAT64-like service ([RFC6146]) for SVR-managed sessions without requiring a NAT64 gateway in the data plane: an IPv4-only client behind an SVR router can reach an IPv6-only server behind another SVR router, provided routing policy at the egress router resolves the destination Service to an IPv6 address and applies destination NAT as in Section 3.8. Stateful per-flow translation as described in [RFC6146] is the RECOMMENDED model for SVR egress when interworking address families.¶
SVR routers MUST NOT silently translate between IPv4 and IPv6 for non-SVR (transit) traffic; address-family interworking is provided only for sessions in which the FHR has constructed SVR Metadata.¶
SVR Metadata is inserted directly after the L4 (TCP or UDP) header (Section 5.2.1). For IPv6 packets, "directly after the L4 header" means after any chain of IPv6 extension headers ([RFC8200]) that precede the L4 header.¶
When building the transport IPv6 header for an SVR-encapsulated packet, an SVR router:¶
The original IPv6 header fields are preserved in SVR Metadata via the Forward and Reverse Context TLVs, and on egress are restored to their original values. On the SVR transport header, the following rules apply:¶
ICMPv6 ([RFC4443]) replaces ICMP for IPv6 SVR sessions. The ICMP procedures in Section 7.7 apply with the following IPv6-specific details:¶
BFD ([RFC5880]) and BFD Metadata (Section 6) operate identically over IPv6 Peer Pathways, with the encapsulation defined by [RFC5881] for single-hop and [RFC5883] for multihop. The BFD Metadata payload is unchanged. When a Peer Pathway uses an IPv6 Waypoint, BFD packets MUST use a matching IPv6 source address; IPv4 BFD MUST NOT be used to monitor an IPv6 pathway.¶
SVR Metadata consists of Header attributes and Payload attributes. Header attributes are always unencrypted, are router/pathway scoped (no forward/reverse distinction), and MAY be inspected by intermediate elements but MUST NOT be modified. Payload attributes are session scoped (with forward/reverse semantics) and MAY be encrypted by the sender. Each TLV defined below is exclusively either a header or payload attribute.¶
The SVR Metadata header begins with a well-known 8-octet "cookie" (0x4c48dbc6ddf6670c, network byte order) immediately following the L4 header, used by receivers to detect SVR Metadata. Normal IP traffic never targets a Waypoint address; any packet arriving at a Waypoint MUST either carry SVR Metadata or belong to an active SVR session (see Section 3.11 for state recovery).¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Header Length | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header TLVs ... | Payload TLVs ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Given that no octet sequence is truly unique in the payload of a packet, in the scenario where the original payload after the L4 header contained the same octet sequence as the cookie, false positive logic is enacted on the packet. If the SVR Metadata HMAC signature can't verify that the SVR Metadata is valid, then a false positive SVR Metadata header is added to the packet to indicate that the first eight octets of the payload matches the cookie.¶
The structure of a false positive SVR Metadata includes just a header of length 12 octets, with zero header TLVs and zero payload TLVs. The receiving side of a packet with false positive SVR Metadata will strip out the SVR Metadata header.¶
In the scenario where a router receives a false positive SVR Metadata header but intends to add SVR Metadata to the packet, the false positive SVR Metadata header is modified to contain the newly added attributes. Once attributes are added, the SVR Metadata header is no longer considered to be false positive.¶
Payload SVR Metadata attributes may be valid in the forward direction, the reverse direction, or both. If not valid, it is ignored quietly by the receiving side.¶
All SVR Metadata attributes are expressed as Tag Length Values or TLVs. This includes Header and Payload TLVs. It is recommended that Payload TLVs be encrypted, but not mandatory. When debugging networks, or if mid-stream routers need to consult the TLVs, they can be transmitted in clear text. The entire SVR Metadata block is signed, and thus the integrity of the data can be verified. No midstream router or middlebox can modify any aspect of the SVR Metadata. Doing so will invalidate the signature, and the SVR Metadata will be dropped.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Values ..... | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
When a packet is fragmented to insert SVR Metadata, a new fragmentation mechanism must be added to prevent fragmentation attacks and to support reassembly (which requires protocol and port information). If a packet is received that IS a fragment, and it must transit through an SVR Metadata signaled pathway, it must also have this SVR Metadata attached to properly bind the fragment with the correct session.¶
All fragments will have an SVR Metadata header and the fragment TLV added to the guaranteed unencrypted portion of the SVR Metadata header. If the original packet already has an SVR Metadata header on it, the fragment TLV will be added to it. See [RFC0791] for information about IP Fragmentation. For a detailed example of packet fragmentation in SVR please see Section 7.5¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original ID |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Largest Seen Fragment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field used for identifying fragment attributes. They are (in order, from most significant to least¶
A versioning identifier used to determine which security key version should be used when handling features dealing with security and authenticity of a packet.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 16 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Key Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An indication that forward SVR Metadata should be disabled. This is sent in the reverse SVR Metadata to acknowledge receipt of the SVR Metadata. This is the second part of the SVR Metadata handshake.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No other data is required. The specific session referenced is looked up based on the 5-tuple address of the packet. See SVR Metadata handshake in Section 3.4.¶
This is exclusively used to implement ICMP messages that need to travel backwards through SVR pathways. See Section 7.7 for more information. The IPv4 address of the source of the ICMP message is placed into SVR Metadata. This SVR Metadata travels in the reverse direction backwards to the originating SVR, which restores the information and sends an ICMP message to the originator of the packet.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 20 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is exclusively used to implement ICMP messages that need to travel backwards through SVR pathways. See Section 7.7 for more information. The IPv6 address of the source of the ICMP message is placed into SVR Metadata. This SVR Metadata travels in the reverse direction backwards to the originating SVR, which restores the information and sends an ICMP message to the originator of the packet.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 21 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SVR Control Message is used for protocol specific purposes that are limited to a single peer pathway. This message is sent by an SVR router to a peer. This SVR Metadata is always sent in a UDP message originating by the SVR control plane.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 24 | Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Drop Reason | +-+-+-+-+-+-+-+-+
Reason why this packet should be dropped.¶
This SVR Metadata type is used to allows peers to measure and compute inline flow metrics for a specific peer pathway and a chosen subset of traffic class. The flow metrics can include jitter, latency and packet loss. This is an optional SVR Metadata type.¶
When a peer sends this SVR Metadata, it provides the information for the period of time to the peer.¶
When a peer receives this SVR Metadata type 26, it responds with SVR Metadata type 26.¶
After several exchanges, each side can compute accurate path metrics for the traffic included. This SVR Metadata can be sent at any time, but is normally sent when SVR Metadata is being sent for other reasons. The SVR Metadata includes "colors" which represent blocks of packets. Packet loss and latency can be determined between routers using this in line method. Using colors to measure inline flow performance is outside the scope of this document. Please refer to [RFC9341]¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 26 | Length = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Co | Transmit TimeValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Co | Received TimeValue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Previous Rx Color Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This SVR Metadata is used to request a session state check by a peer. The peer responds upon receipt with a generated packet with SVR Metadata confirming presence of SVR Metadata. This SVR Metadata type can be included in an existing packet to check that the peer has session state. The peer will always respond with a generated packet that includes a forced drop SVR Metadata attribute. See Section 7.8 for an example.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 46 | Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | +-+-+-+-+-+-+-+-+
Payload attributes are used for session establishment and SHOULD be encrypted to provide privacy. Encryption can be disabled for debugging.¶
The context contains a five-tuple associated with the original addresses, ports, and protocol of the packet. This is also known as the Forward Session Key.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length = 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+
A five-tuple associated with the original addresses, ports, and protocol of the packet for IPv6.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length = 37 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+
Five-tuple associated with the egress (router) addresses, ports, and protocol of the packet. Forward context and reverse context session keys are not guaranteed to be symmetrical due to functions which apply source NAT, destination NAT, or both to a packet before leaving the router.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length = 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+
Five-tuple associated with the egress (router) addresses, ports, and protocol of the packet. Forward and reverse session keys are not guaranteed to be symmetrical due to functions which apply source NAT, destination NAT, or both to a packet before leaving the router.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length = 37 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | +-+-+-+-+-+-+-+-+
Unique identifier of a session. The UUID MUST be conformant to [RFC9562]. This is assigned by the peer that is initiating a session. Once assigned, it is maintained through all participating routers end-to-end.¶
The UUID is used to track sessions across multiple routers. The UUID also can be used to detect a looping session. The UUID SVR Metadata field is required for all session establishment.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + UUID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alphanumeric ASCII string which dictates what tenancy the session belongs to.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name (1 - n octets) .... | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
An alphanumeric string which dictates what service the session belongs to.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Name (1-n octets) ..... | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Indicates if the session is having its payload encrypted by the SVR router. This is different from having the SVR Metadata encrypted. The keys used for payload encryption are dependent on the Security Policy defined for a session.¶
This field is necessary because often traffic is already encrypted before arriving at an SVR router (making DPI a poor choice). Also in certain use cases, re-encryption may be required. This SVR Metadata TLV is always added when SVR encrypts the payload.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Indicates if the session is being converted from TCP to UDP to enable passing through middle boxes that are TCP session stateful. A SVR implementation must verify that SVR Metadata can be sent inside TCP packets through testing the Peer Pathway. If the data is blocked, then all TCP sessions must be converted to UDP sessions and restored on the destination peer.¶
Although this may seem redundant with the Forward Context that also has the same originating protocol, this refers to a specific peer pathway. In a multi-hop network, the TCP conversion to UDP could occur at the second hop. It's important to restore the TCP session as soon as possible after passing through the obstructive middlebox.¶
When TCP to UDP conversion occurs, no octets are changed other than the protocol value (TCP->UDP). Because the UDP message length and checksum overlap with the TCP Sequence Number, the Sequence number is overwritten. The Sequence number is saved by copying it to the TCP Checksum and Urgent Pointer portion of the packet. The Checksum is recalculated upon restoration of the packet. The urgent pointer is zeroed out and urgent flag is cleared.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: This type does not contain any value as its existence in SVR Metadata indicates a value.¶
An alphanumeric string which dictates which source router the packet is originating from. This attribute may be present in all forward SVR Metadata packets if needed.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 14 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Name (1-n octets) .... | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
An alphanumeric string containing the Security Policy to use for a particular session. This is used only when payload encryption is being performed. The Security Policy describes the specifics about ciphers used for payload encryption.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 15 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SECURITY POLICY | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
An ASCII string which dictates which router peer pathway has been chosen for a packet. This name is the hostname or IP address of the egress interface of the originating router. This can be used to determine the peer pathway used exactly when there may be multiple possibilities. This enables association of policies with specific paths.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 19 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Pathway Name (1-n octets) .... | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Routers may be provisioned to perform source NAT functions while routing packets. When a source NAT is performed by an SVR Peer, this SVR Metadata TLV MUST be included. When the far end router reconstructs the packet, it will use this address as the source address for packets exiting the SVR.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 25 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Source Nat Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
After a path failure, it may become necessary to transmit an SVR Control Message when there are one-way flows waiting for a packet to be transmitted. In these cases, the SVR Metadata includes an attribute defining the remaining session time so intermediate routers creating new session entries will expire the session at the correct time.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 42 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remaining Session Time (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alphanumeric string containing the cryptographic key to use for a payload encryption of a particular session. This is used only when payload encryption is being performed. The key is encrypted in SVR Metadata hop-by-hop through a network, preventing any party from obtaining the key. The router terminating the session utilizes this key to decrypt payload portions of packets. This prevents re-encryption penalties associated with multi-hop routing scenarios.¶
To rekey a session, this SVR Metadata can be included in any subsequent packet with the new key to use. When rekeying, the SVR that initiated the encrypted session must compute a new key, and include the key as SVR Metadata.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 46 | Length = variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SECURITY KEY | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Identifies the (Source, Group, Protocol) of a multicast SVR session. Used both in SVR Control Messages signaling group membership (Section 8.3) and as a payload TLV in the first packet of a multicast session. The address family field selects between IPv4 (lengths shown) and IPv6 (16-octet addresses).¶
Enumerates the LHRs currently in the Egress Set of a multicast SVR session. Carried in forward SVR Metadata sent by the FHR.¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
Packets carrying SVR Metadata are HMAC-signed to authenticate the sender and protect integrity. Any HMAC algorithm agreed by both peers MAY be used (e.g., SHA1, SHA256, SHA256-128). The signature covers the L4 payload and is appended to the end of the packet.¶
Time-Based HMAC on every packet is RECOMMENDED. It prevents in-stream tampering, supports egress state-loss detection (Section 3.11), and binds each signature to a time window to prevent replay. Provisioning of HMAC parameters is out of scope.¶
Payload encryption uses AES-CBC-128 or AES-CBC-256. Plaintext is padded to a 16-octet boundary; if the plaintext is already a multiple of 16, an additional 16-octet pad block is appended whose last octet indicates the pad length.¶
Any host can send packets to a Waypoint address. SVR routers MUST treat such packets as either bearing SVR Metadata or belonging to an established session/protocol; everything else is dropped.¶
Source-address ACLs SHOULD restrict accepted SVR traffic to provisioned peers. The 8-octet SVR cookie is checked first; on mismatch the packet is dropped. The HMAC is checked next; on failure the packet is dropped. Together these checks deflect DDoS attempts targeting Waypoint addresses.¶
This document is published as an Independent Submission and does not require IANA to create new top-level registries. The SVR Metadata Type code points used in this document are administered by the Authority that operates an SVR deployment (see Section 1.4) and are summarized below for implementer convenience. Type values are scoped separately for Header and Payload TLVs.¶
Header TLV Types currently defined: 1 (Fragment), 16 (Security ID), 18 (Disable Forward SVR Metadata), 20 (IPv4 ICMP Error Location), 21 (IPv6 ICMP Error Location), 24 (SVR Control Message), 26 (Path Metrics), 46 (Session Health Check).¶
Payload TLV Types currently defined: 2 (Forward Context IPv4), 3 (Forward Context IPv6), 4 (Reverse Context IPv4), 5 (Reverse Context IPv6), 6 (Session UUID), 7 (Tenant Name), 10 (Service Name), 11 (Session Encrypted), 12 (TCP SYN Packet), 14 (IPv4 Source NAT Address), 15 (Source Router Name), 19 (Peer Pathway ID), 25 (Remaining Session Time), 42 (Security Policy), 46 (Security Key), 50 (Multicast Group Context), 51 (Multicast Egress List).¶
Unassigned values in either space are available for future use. Implementations MUST ignore unknown TLVs as required by Section 5.6.2.1.¶
The authors would like to thank Anya Yungelson, Scott McCulley, and Chao Zhao for their input into this document.¶
The authors would like to thank Tony Li for his extensive support and help with all aspects of this document.¶
The authors want to thank Ron Bonica, Kireeti Kompella, and other IETFers at Hewlett Packard Enterprise (formerly Juniper Networks) for their support and guidance.¶