| Internet-Draft | Juniper's Secure Vector Routing (SVR) | November 2024 |
| Menon, et al. | Expires 8 May 2025 | [Page] |
This document describes Juniper's Secure Vector Routing (SVR). SVR is an overlay inter-networking protocol that operates at the session layer. SVR provides end-to-end communication of network requirements not possible or practical using network headers. SVR uses application layer cookies that eliminate the need to create and maintain non-overlapping address spaces necessary to manage network routing requirements. SVR is an overlay networking protocol that works through middleboxes and address translators including those existing between private networks, the IPv4 public internet, and the IPv6 public internet. SVR enables SD-WAN and multi-cloud use cases and improves security at the networking routing plane. SVR eliminates the need for encapsulation and decapsulation often used to create non-overlapping address spaces.¶
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 8 May 2025.¶
Copyright (c) 2024 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.¶
There exists a need to communicate network requirements between IP routers in order to provide an end-to-end experience. Selection of specific paths whose attributes meet or exceed the networking requirements are an objective of SVR. There is also a need for applications to communicate their requirements to networks. This need is increasing as workloads move to public clouds and the numbers of cloud locations increase. Standard practice today is to use an overlay network of tunnels to create a virtual network.¶
SVR is proposed as an alternative to using tunnels. SVR simplifies the network by virtue of having only one network layer. SVR securely transports traffic with authentication and adaptive encryption. The absence of tunneling overhead reduces bandwidth. Since SVR specifies requirements abstractly, it also has the capability to interwork policies between different networks and address spaces.¶
Many WAN networks are deployed with a virtual private network (VPN) across IP backbone facilities. VPNs have the significant disadvantage of carrying additional network layers, increasing packet size and leading to IP fragmentation as well as reduced bandwidth.¶
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 implementation describes a network requirement semantically and shares this as SVR Metadata with a routing peer. The requirement to a peer is conveyed by means of a cookie, often referred to as first packet SVR Metadata, which is placed in the first packet of a session that is targeted towards the SVR Peer. SVR requires session state on every participating SVR router and sets up a bidirectional flow (matching forward and reverse flows) based on the requirement. Once the session is established bidirectionally, the cookie is not sent in subsequent packets, resulting in elimination of additional overhead.¶
Benefits from this approach include:¶
This document is structured into six major sections. Section 2 provides a high-level theory of how SVR works. Section 3 presents an example of SVR in action. Section 4 describes the SVR message handling in detail. SVR Peer management is described in Section 5. Section 6 details some additional SVR procedures that may be required. Finally, Section 7 describes individual protocol messages.¶
The following terms are used throughout this document.¶
While provisioning and orchestration is outside the scope of this document, it is worth noting which aspects must be provisioned through some means of coordinated orchestration.¶
This is not intended to be a comprehensive list, nor define the organization, nor define input constraints, but to highlight the minimal attributes that would need to be provisioned in order to establish an SVR peering relationship between two routers.¶
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
Secure Vector Routing is a session stateful routing protocol that operates at the edges of networks where stateful NATing is normally performed. It is at these same locations where multi-path routing is being deployed. These locations include edge routers located at branches, data centers, and public clouds. SVR maps local network requirements into administratively defined text strings that have Authority wide meaning. These are communicated or signaled by insertion of a networking cookie called SVR Metadata directly into IP Packets in transit.¶
+-----------+
| Network 2 |
+-----------+ | | +-----------+
| SVR<---->+<--L3-IP-->+<----->SVR |
| | +-----------+ | |
| Network 1 | +-----------+ | Network 4 |
| SVR<--->SVR SVR<---->SVR |
+-----------+ | | +-----------+
| Network 3 |
+-----------+ | |
| Client SVR<--->SVR |
+-----------+ +-----------+
The above diagram shows typical places where SVR can be deployed. SVR can be deployed between Network 1 and Network 4, traversing Network 3. This is typical of a connection between a corporate site and a data center through the public internet. SVR can be deployed directly between Network 1 and Network 3, Network 3 and Network 4 to build a multi-network connectivity. Clients that support SVR are connected to Network 3, permitting full SVR based access to Networks 1, 3, and 4.¶
SVR Metadata is inserted into existing packets directly after the L4 header (see Section 5.2). The SVR Metadata in the first packet of a new session (TCP or UDP bidirectional flow) can be used for path selection and security. SVR Metadata can be inserted in any subsequent packet to change/update the networking requirements. The SVR Metadata is inserted into the payload portion of a packet to guarantee delivery between SVR routers.¶
Sessions supported by SVR include TCP, UDP, UDP Unicast, Multicast, MP-TCP, QUIC, point-to-point ethernet, and ICMP. Sessions are characterized by having an initial first packet that is unique to an SVR router. Often this is described as a unique 5-tuples as seen by the router. Sessions start when the first packet is processed and end when either the L4 protocol indicates the session is completed (TCP FIN/FIN/RST ACK) or there has been no activity for a length of time (UDP, ICMP, UDP Unicast, point-to-point ethernet).¶
SVR utilizes the concept of session direction. The direction of the session is what creates a Secure Vector. Routing policies include a Tenant (source) and Service (destination) pair that exactly match the direction of sessions. When describing SVR Metadata in this document, direction is either forward or reverse; it is not tied to network topology, but rather the direction of session establishment. For TCP, the forward direction is always the client side towards the server side. For UDP, the forward direction is from the sender of the first packet; reverse is the opposite direction. On a given pathway, Secure Vector Routes could be traversing on the same pathways with opposite directions.¶
SVR Metadata formats described in this document will be labeled as "forward" or "reverse". Forward SVR Metadata is inserted in packets going from client to server. Reverse SVR Metadata is inserted in packets that travel from server to client.¶
The basic order of operations when processing a packet upon arrival at the first SVR Router includes:¶
The basic order of operations for a subsequent SVR Router includes:¶
SVR co-exists with traditional routing and alongside non-SVR traffic. In fact, the router interface addresses known as Waypoints in this document MUST be reachable via traditional networking for every peer relationship. When packet routing is being decided in the router, should the route resolve to an SVR capable router (i.e., the next hop address returned in the route equals a known Waypoint address of an SVR Peer) then SVR Metadata MAY be inserted and session stateful SVR is performed. Otherwise, the packet is forwarded like any traditional IP router.¶
To ensure the SVR Metadata is received and understood between peers, a handshake is performed for each session.¶
A sender of SVR Metadata acknowledges its receipt of forward Metadata by receiving a subsequent backward SVR metadata from its peer. Senders must include metadata in every packet until they receive this confirmation. Once confirmed, the sender can stop sending metadata in subsequent packets.¶
A receiver of SVR metadata from a peer always responds by sending reverse SVR metadata in every subsequent packet of a session. This continues until a packet is received from the peer that no longer has metadata, signaling receipt.¶
These two comprise what is known as the "SVR Metadata handshake" -- that is, the initiating router includes SVR Metadata in all packets it sends to the recipient router until it receives a reverse packet with SVR Metadata from that recipient. Likewise, the recipient continues to send SVR Metadata to the initiating router until it receives a packet without SVR Metadata. This is how two routers acknowledge receipt of SVR Metadata from their counterparts: the absence of SVR Metadata in a packet indicates that it has received SVR Metadata from its counterpart.¶
Firewalls and other middleboxes that are deployed along a peer pathway may not propagate TCP SYN messages with data in the payload (despite being valid). Middleboxes may also verify sequence numbers in TCP streams - which would appear as invalid due to the inclusion of SVR Metadata (while not changing sequence numbers). The two devices that represent the peer pathway endpoints may determine, through testing, if there is a firewall, NAT, or other active middlebox between the two routers. The BFD protocol with BFD Metadata can be used to detect the presence of a NAT. See Section 6.1.2. Additional procedures like STUN [RFC8489], TURN [RFC6062], and ICE [RFC8445] are well-known, and not included in this document.¶
If a NAT is detected on the Peer Pathway, the SVR Router that determines its Waypoint address is being changed, saves this as an attribute of the pathway. The NAT will change the port address assignment, and require NAT keep-alives as exemplified in Section 7.3.¶
If a middlebox is detected, the packets can be UDP-transformed (i.e., the protocol octet can be changed from TCP to UDP) by the transmitting router and restored to TCP by the receiving router for packets flowing in both directions. See Section 5.2.7 and Section 5.6.3 for more information.¶
When routers use IP addresses that are dynamic, such as DHCP served addresses or PPPoE network attachments, it is possible to be assigned a new address during the lifetime of any given session traversing the router. If this happens, all existing sessions using that Waypoint address must be updated to use the new address. For existing sessions this can be performed in real time by reviewing the sending address. If the address has changed, internal references to the old address can be updated. For idle circuits, BFD with SVR Metadata is used to detect address changes. See Section 6.1.3 for details.¶
To prevent breaking any applications, there MUST be a 100% guarantee that SVR Metadata inserted by a participating SVR device is removed prior to the transmission of the data to the application. If the client and server support SVR Metadata, then SVR Metadata can be sent end-to-end. When a mid-stream packet router wants to insert SVR Metadata, it must guarantee that the packet is directed to a next hop device that will understand and remove the SVR Metadata.¶
A router can be certain an SVR capable router is on the path when the next-hop address returned from a FIB table exactly matches a known peer Waypoint address. Before sending the packet with SVR Metadata to the Waypoint address, the originating SVR router should determine the Peer reachability as exemplified in Section 4 and Section 6.¶
If the next-hop is not a known reachable peer, SVR Metadata insertion MUST NOT be performed.¶
To guarantee that the packet will go to a specific router, the destination address for the packet is changed to the Waypoint Address of the chosen peer. The original addresses are stored in the forward context (see Section 8.4.1) and can be recovered when needed. This is similar to IPv6 segment routing (see [RFC8986]) or a LISP (see [RFC9300]) RLOC with the exception that the original addresses are stored in SVR Metadata within the payload portion of the packet, and not the IP Network Header.¶
Selection of the Waypoint Address to direct sessions is implementation specific. In the general case, a standard FIB lookup returns one or more IP Address(es) (Waypoints) of the next SVR peer. When more than one Waypoint address is returned from the FIB, additional logic can be applied to select the best Waypoint based on observed peer pathway quality or session layer load balancing. See Section 4 for exemplary details.¶
To provide a return path for the return flow, the source SVR peer changes the source address to be its own egress Waypoint address. This provides a guarantee of a symmetric flow. The state of the session MUST be held in both the source SVR router and the destination SVR peer.¶
The address translation rules for the session become state information that is processed on every packet after the SVR Metadata handshake. All 5 tuples of addressing information are updated bidirectionally for the session. This action replaces tunnel encapsulation and decapsulation (tunnel compression), and is an order of magnitude simpler computationally.¶
SVR Metadata contains contextual IP Addresses (sources, destinations, and Waypoints) along with textual service names (i.e., Zoom, Office365, etc.). The SVR routers can apply policies and route sessions based on the textual names within SVR Metadata if they have a route information base that contains service names. When performing name-based routing, a destination NAT is often required when exiting the SVR network. The primary use case for this is networking between public clouds such as AWS and Azure.¶
With semantic based routing, the use of Dynamic DNS to locate a service can be eliminated if clients support SVR. Clients can simply request the service by name, and the SVR router can resolve the route, and deliver the session to the best location. The last SVR Router on egress performs a destination NAT for the chosen best instance of a service.¶
A local DNS server resolving service addresses to a nearby SVR router can also provide semantic based routing. This can eliminate the need to use dynamic DNS for locating services inside data centers.¶
To make sessions completely independent on peer pathways, the source port and destination port can be assigned any values that are unique by the source router. When there are no NATs between the two router interfaces, this permits 2^32 (4,294,967,296) different unique sessions on a peer pathway. If there are source NATs, this will be reduced to 2^16 (64,512 less 1024 reserved) different unique sessions. Ports can be reassigned if not in active use. It is also possible that middle boxes will limit what destination ports are permissible, reducing the number of possibilities. Due to all these reasons, range of ports that can be used on a peer pathway are provisioned by an administrator.¶
The ingress SVR peer (client side) assigns both source and destination ports, even ports for local (source port) and odd ports for remote (destination port). This provides uniqueness between any two peers, with no negotiation or collision possibilities. This reduces the number of sessions originating by a router to half of the total sessions (or 2^30). Think of the two ports as a Session Identification Tag. Even if a session traveling in the opposite direction was allocated the same exact ports, because the source address and destination addresses would be swapped, the 5-tuples on the wire remain unique.¶
This unique tuple per TCP/UDP session also allows any DSCP or QoS scheme to work properly. Those fields in the original packet were not modified and the underlay network routers will see those fields on a session-by-session basis.¶
After the SVR Metadata handshake has been completed, all subsequent packets are transformed (all 5-tuples, bidirectionally). Compared to IPSec encapsulation, packet transformation is very efficient as it does not require memory copies, new header creation, new packet checksums, and mandatory encryption.¶
Each participant (peer) in secure vector routing must maintain state for every active session. This includes the full set of original addresses and translations required. This allows participants to stop sending SVR Metadata once it has been received by the peer as well as directing traffic through a network akin to segment routing. There are three possible scenarios for how state could be lost. Loss of state can result in sessions that become stale.¶
Each SVR router (peer) must statefully remember the source address of a session with SVR Metadata. This may not be the same address the router sent a packet from due to a NAT or firewall in the pathway. Routers use both provisioned and learned Waypoint Addresses. Routers MUST store the actual Waypoint Addresses received on the wire from a peer.¶
When a firewall or middlebox is detected, the SVR router behind such a device must send SVR Metadata packets periodically on idle sessions to keep any firewall pinhole translations from being removed. For every UDP and TCP session that has seen no packets after a programmable length of time (20 seconds is recommended), the SVR Peer should send an SVR Control Message on the peer path with the source and destination ports from the idle session's saved state. See Section 8.3.6 for more information and see Section 7.3 for an example.¶
BFD [RFC5880] is used to verify Peer Pathways. BFD is used to determine reachability, presence of NATs, changes of Waypoint Addresses, determination of MTU size, current quality on idle circuits, authentication of peers, and maintenance of peer cryptographic keys. Alternative methods can be used for each of these if both peers agree. The use of BFD is included in this specification as a preferred technique for Peer Pathway management.¶
BFD Metadata is defined and required to measure quality, perform authentication, and maintain security keys because standard BFD authentication fields are insufficient. BFD Metadata is different than SVR Metadata because it is inserted at the very end of a BFD control packet, and not at the end of the layer 4 header. Some BFD Metadata is encrypted. To make processing easy, protobufs (Protocol Buffers) are used to transmit the BFD Metadata instead of TLVs. The specifics of BFD Metadata can be found 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.¶
The first step in peering SVR routers is to apply any locally defined static L3 routes and begin advertising and receiving routes using L3 networking protocols (BGP, OSPF, etc.) in order to build a forward information base. This is required initially to ensure that the Waypoints are reachable bidirectionally allowing SVR Peer Paths to be established.¶
The second step is for both the East and West routers to establish the authenticated peer pathways that make up the SVR Peer relationship. It is recommended that each peer pathway must be authenticated bidirectionally before the SVR pathway is used.¶
Authentication of peers is recommended. It is technically possible to send SVR Metadata and determine a key for peers without authentication, but this is discouraged. Either peer could require authentication, and declare the peer relationship invalid should authentication fail.¶
Authentication is based on a certificate signature request created by the router that contains its UUID and Authority that is signed by a trusted CA (The Router Certificate). A UUID is created and assigned to a router by and administrator. The UUID is used for several reasons. UUID's can be permanently assigned to a router, and if the router name changes, the certificate is still valid. There is also a desire to prevent router names (typically set to the hostname) and thus network topology from being discovered in packet traces. The device registration, creation, signing, and the secure installation of this certificate are omitted from this specification. Please refer to [RFC4210].¶
While RSA certificate cryptography can be used, Elliptical Curve encryption (see [RFC8422]) techniques are recommended for use in SVR. The NIST Curve that is to be used is defined by an administrator. It is recommended that NIST Curve P-256 be used for all SVR Metadata cryptography. All participating routers in an SVR network must use the same elliptic curve.¶
Each peer sends a BFD packet that contains BFD Metadata in clear text that contains an X.509 Router Certificate in PEM format (see [RFC5758]). See Section 6.1.7 for specifications. Upon receipt, this certificate is verified like any other X.509 certificate. The common name in the certificate provides the authenticated UUID of the peer router. The router must verify that the UUID identified in the certificate is a valid peer in its routing configuration. The certificate should have a locally verifiable chain to a trusted certificate authority (CA).¶
In the example above, there are three pathways. The BFD message with the X.509 certificate is sent by each side (East and West) on each pathway. Each side verifies the certificate, and then determines if the peer pathway is valid and should be used between peers. To communicate that the peer has received the certificate, and to stop sending it in subsequent BFD packets, a BFD packet without a certificate is sent. This defines the handshake for the local and remote peer. If a certificate is ever required (for example when a router reboots) a peer can request it be transmitted by sending its certificate.¶
The public key of the router is stored and saved to verify signatures used in subsequent keying procedures (see Section 4.1.2). If the router's certificate is updated, this process must be repeated. Any outstanding valid keys remain operational, preventing outages during recertification.¶
In the above example Figure 3 there is one peer relationship (East and West) that share three Peer Pathways. Assuming that all three pathways have been authenticated, the East West peer relationship has three usable transport pathways.¶
To securely exchange BFD traffic between East and West peers, a Peer Key is required. Because the Private Key/Public Key pair used by router is to be very long lived, a Key Derivative Function is used (ECDH-ES). The SVR protocol uses Concat KDF. See [NIST_SP_800-56A].¶
The Concat KDF process uses a Salt value, one from each peer. The Salt values, private key, and the two public keys are inputs to create a key that is derived from the certificate (essentially authenticated by the certificate). This prevents any man in the middle attacks. Encrypted fields in BFD Metadata are used to distribute keys for SVR Metadata encryption/decryption. Please see Section 6.1.9) for detailed description of how this works.¶
To prevent replay of BFD packets, a nonce is added to BFD Metadata which is then tracked to prevent reinjection of old BFD packets with out-of-date clock times. To avoid an unreasonably growing table size of nonces, the amount of BFD packets tracked with timestamps should be rate limited. Once per minute results in roughly 1440 nonces per peer in one day.¶
To rekey, at any time, either party can initiate the same sequence, only with new Salt values.¶
The same Peer Key is used for all pathways between peers. This is efficient when there are many parallel multi-path pathways.¶
SVR Routers can receive packets with SVR Metadata on any interface. Also, many remote Peers may share a single interface on an SVR Router. Because source addresses changes (NAT Updates) and packets will sometimes arrive on different interfaces due to network flaps, and routing changes, each SVR Router must know in advance what cryptographic key to use for each SVR Peer.¶
Each SVR router creates a key (or obtains a quantum safe key) that it shares with its peers. Any SVR metadata sent from any peer must use this SVR Metadata Key. BFD Encrypted Metadata is used to broadcast the Key to all peers and its version. See Section 6.1.9.¶
The SVR router will share the same Key with all Peers, therefore all SVR Metadata processed locally will have one key until it is rotated.¶
When a peer has at least one working authenticated pathway, and has calculated an Elliptical Curve Peer Key (ECPK), the SVR Peer is declared operational and in service and ready for transporting traffic bidirectionally.¶
When in service, East and West independently communicate using BFD to each other's interfaces to ensure operational status and measure path characteristics such as jitter, latency, and packet loss. In our example, assuming 100 percent success, the resulting peer pathways would be:¶
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 is also used on service Peer Pathways to determine MTU size and detect address changes, and monitor quality when session traffic is idle.¶
To route packets and sessions of packets onto SVR Peer Pathways, a route lookup must return an indication of either an SVR peer pathway, or an SVR peer.¶
In the example shown below, our assumption is that there are servers that are located inside 172.15.11.0/24 at the West location. West publishes or otherwise advertises this route to East on each path available to it. Subsequently East's FIB will look like this:¶
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]
Additionally, we will assume there exists a network policy created by the administrator of an Authority "example" that defines a Tenant "engineering" as 10.0.0.0/25 VLAN2, and "github.example" as 172.15.11.23 using TCP port 22. The provisioning and/or discovery of this policy is outside the scope of this protocol description.¶
A first packet from an engineering client with github as a destination received at the East SVR Router will result in a search of the FIB and result in two possible next-hop IP Addresses. East will consult its SVR Peer Pathway list and recognize that three of its peer pathways have an exact match of this next-hop IP Address. These represent the three possible pathways that may be used for routing this session. The resulting potential routes are:¶
Possible Routes
MPLS 20ms Latency, 0 Loss, 2 Jitter
Internet 30ms Latency, 0 Loss, 3 Jitter
LTE 50ms Latency, 0 Loss, 15 Jitter
The East router can now choose which Peer Pathway is desired for the specific session. If the East router has quality service levels to maintain, it can choose from any of the Peer Pathways based on their current quality metrics. If all things are equal, the East router could load balance using approaches like "least busy" or other techniques. Once a Peer Pathway is chosen, the first packet SVR Metadata is constructed, inserted into the first packet, and sent down the chosen pathway to the West peer router.¶
For this example, the private address space in the LAN supported by the East Router is different. This is often the case with large networks. This is illustrative of a branch router performing network address translation (NAT) on a source address to solve overlapping address problems.¶
In this specific case, assuming MPLS was chosen, East would perform first packet processing resulting in the insertion of SVR Metadata in the first packet (see Section 4.7.1) and send it out East's interface with a source address of 203.0.113.1 and a destination address of 203.0.113.89. These are the exact addresses of the MPLS Peer Pathway.¶
Both the East and West routers would use the same address pairs (only reversed) for the bidirectional session, using the allocated source and destination ports to recognize the specific session. All packets from all sessions on a peer path will have the same exact IP addresses, differentiated solely by their port numbers.¶
SVR Metadata in the first packet contains text strings that contain service names. SVR routing can route traffic by these names if the FIB contained text entries. There are some use cases where this is preferred over CIDR look-ups:¶
Below is an example FIB that contains named services and traditional FIB entries. The FIB is now an SVR FIB containing service names, protocols, and ports, with next-hop addresses changed to Waypoint Addresses.¶
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 (LPM) of the destination address, along with protocol and port will be used to match routes for packets intended for github on ingress to SVR. The text string "github.example" will be used by all other SVR routers until egress from SVR. The SVR FIB can be used to LPM match on IP addresses and exactly match protocol and ports. In the above illustrative example, only three protocols are supported (SSH, Syslog, and HTTPs). All other packets will be denied by default.¶
The egress action in the SVR FIB can be used to support three different egress actions:¶
These named routes can co-exist with traditional FIB entries shown above. SVR will always match a named route first, and fall through to the CIDR routes second.¶
For basic SVR functionality to work between peers, there must be an Authority wide provisioned set of rules. These rules include:¶
SVR does not limit the use of ciphers and techniques to those listed above. The requirements for both signatures and encryption are to use a cipher where the results are fixed, well-known, block sizes.¶
Security Policies are used during session setup to establish payload encryption for individual sessions. These are exchanged in first packet SVR Metadata.¶
For this example, the following SVR security definitions are used.¶
HMAC: (On, time-based, SHA256-128, ALL Packets)
SVR Metadata Encryption (On, AES256)
To positively authenticate and provide integrity for SVR session, SVR peers use Time-Based HMAC signatures. HMAC signatures are defined in [RFC2104]. Please see Section 5.5.1.¶
In our example, we are using SHA256-128 with a size of 16 Bytes.¶
Every SVR Metadata transaction includes a security ID header TLV (see Section 8.3.2).¶
Payload keys are asymmetric and are transmitted in the encrypted portion of metadata. A unique payload key is used for each flow of a session, bidirectionally.¶
Payload keys and IVs should minimally use FIPS 140-2 approved highly secure DRBG for generation.¶
Using a unique payload key per flow simplifies key exchange and complexity, avoiding the need to address glare conditions. Long-lived sessions may need to have their payload key rotated if the duration of the session exceeds the rekey-interval. When a new payload key is generated, it is inserted in mid-flow metadata update. The interval for rekey events should be configurable.¶
The originating router of the flow will always generate the payload key and insert it into metadata. The terminating router generates its own unique key for the reverse flow. As packets flow through the originating router, and a rekey event is triggered, mid-flow metadata is enabled, and the new key is populated into metadata and the packet is forwarded along.¶
Second/subsequent router(s) continue to monitor for mid-flow metadata, and if the key changes, it will update the key to be used for subsequent payload decryption. The key will be stored and used for all subsequent packets.¶
The diagram below shows the example github TCP session flowing between a client and server through the East and West routers in our example network.¶
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 ==>|
The East Router MUST construct and insert SVR Metadata (MD) in the first packet of the SSH session, which will be a TCP SYN packet. The West Router must remove the SVR Metadata, and forward the SYN packet, and wait for the server to respond with a SYN/ACK. Upon receipt of the SYN/ACK, the West Router will create reverse SVR Metadata (RMD), and insert it into the SYN/ACK. This will complete the SVR Metadata handshake for the SSH session. All forward and reverse SVR Metadata are inserted into existing packets if possible.¶
When a client or router detects that a new session is being established, the East Router will insert SVR Metadata into the first packet to communicate intent to the West Router. At both East and West Routers, the first packet will require specialized handling. Detecting a first packet for a session is protocol specific. For TCP, it is a new 5-Tuple packet (new flow) with the just the SYN flag set. For UDP, it is a new 5-Tuple packet not currently in active use.¶
Utilizing the same example, assume that the packet shown below arrives on the East Router from the Client LAN. The packet is the result of an engineer attempting to access a github service via SSH.¶
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) |
+---------+---------------------+--------------+----------+
The tenant is a text name which describes the routes and policies that are available for a group of source IP addresses. Tenants are like security zones. In our example, the "engineer" is based upon VLAN 2, and the tenant will be "engineer" as named by the Authority "example". The configuration and data models to map physical network attributes to named tenants is implementation specific. Associating a default tenant with every logical interface on an SVR Router is recommended.¶
There are multiple ways to determine the associated service for a new session. Application Identification technology is used that understands all popular SaaS offerings. These techniques include, but are not limited to, the use combinations of IP address ranges and ports, SNI fields in TLS, Common Name from Certificates, and extraction of URLs from HTTP requests. Most popular SaaS vendors today publish and frequently update their CIDR blocks and ports used by their services. The means of service identification are out of scope for this document, but importantly are the mechanism used to associate the session with a given policy.¶
We will assume for this document, that the address 172.15.11.23 is a well-known address for git servers in the network defined by Authority "example", and port 22 is known to be SSH.¶
Once the tenant and service have been determined, a lookup for network requirements can be determined.¶
Example Network Requirements¶
SERVICE: github
Access Policies:
Tenants Allowed: engineering
Tenants Denied: release.engineering
Quality Policy: latency < 40ms
Security Policy: None
The above definition for github defines an example network requirement. 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.¶
As stated previously, the East Router has three peer paths that can reach the destination based on L3 reachability. The next step is to apply the network requirements to see which of the peer paths are within the service level experience. Our policy requires latency to be less than 40 msecs, which eliminates East's LTE pathway from consideration. The remaining two pathways, MPLS and Internet, are both within SLA. We will choose MPLS as it has the lowest latency, offering the user the best experience.¶
Many different criteria can be used in selecting a peer pathway. In practice, how busy a peer path is and its capacity result in new sessions routing to 2nd best options. Often simple load balancing is used. In cases where there are higher costs (such as LTE or 5G networking), these may be held in reserve for backup or disaster recovery. The actual algorithms for picking peer pathways are outside the scope of this protocol.¶
In this github example, there is a source NAT at the East Router on the MPLS interface to the data center. This design allows all of the remote branch sites to use overlapping addresses, and is very common in larger networks. Routers that perform source NAT have two options: use the interface address and allocate a new source port, or use an IP address pool and allocate full IP addresses for each session. Either way, this allocated address only needs to be placed into SVR Metadata, as the existing packet address will be translated to Waypoint Addresses shortly. The egress SVR router will apply the source NAT.¶
The next step is to allocate new ports for the SVR session. The ports being allocated must not be in use, and should not have been used recently to avoid any issues with middleboxes. See Section 5.2.¶
The range of ports that can be used may be site specific and tied to policies that exist in upstream firewalls or middleboxes. For these reasons, the actual pool of available addresses is provisioned on every SVR router. The East router has ports 8000 to 24000 available for both the source and destination ports. In this example we will allocate an even source port of 8000, and an odd destination port of 8001. Note that both source and destination ports are allocated by the router that initiates SVR Metadata.¶
The router now has reached a point where it can forward the packet. It has valid network requirements, available peer paths, and has available SVR ports. The next step is to create and save all session state information for subsequent packet processing. A session UUID is created for end-to-end tracking of sessions. The table below refers to SVR Metadata TLVs and specific contents that are documented in Section 8.¶
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 SVR Metadata attributes that must be inserted in a first packet of a new sessions are defined in Section 5.3.1, include Security ID, Forward Context, Tenant Name, Service Name, Session UUID, Source Router Name, Security Policy, Peer Pathway ID.¶
Two optional SVR Metadata attributes Path Metrics and Source NAT Address are both included in this example. This is documented in Section 8.3.7 and Section 8.4.13.¶
The order of the TLVs is arbitrary, but header TLVs must be before any payload TLVs. If a TLV is received that is unknown to a peer, it MUST be ignored. In this example, the header length including the two header TLVs is 34, and the 8 payload TLVs total 119 octets in length.¶
The Session HMAC Key is state information retained by the router. The Session HMAC Key is communicated between SVR peers as part of BFD Metadata. This key is used for the life of a session.¶
The next step is to encrypt the SVR Metadata block as defined in Section 5.4. In our example, our provisioned security definitions include AES256 for SVR Metadata encryption. AES has a 128-bit block size for all key lengths. In our example, the SVR Metadata payload TLVs are 119 octets large. Padding is added during encryption to ensure the payload is 128 octets (or 9 octets of padding). In addition, to make the encrypted data stateless, we must also include a 16 octet initialization vector directly after the encrypted block. The resultant encrypted SVR Metadata block is 178 octets and looks like this:¶
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 SVR Metadata block is inserted into the packet directly after the L4 Header. The total length of this specific SVR Metadata block is 178 octets, 34 of which are header octets and 119 for payload TLVs. If there is data in the payload portion of the IP Packet, the payload data is moved down to make room for the SVR Metadata. The packet structure will now look like:¶
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 in the packet are updated to use the selected peer path.¶
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 containing SVR Metadata is now signed with a HMAC signature (See Section 4.5). The HMAC signature is placed at the very end of the packet, extending the packet size by the signature's length. The IP header is excluded from the signature. The current SVR Metadata Key is used (see Section 6.1.9) for signing and verifying the authenticity of the packet. In this case the HMAC is 16 octets.¶
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 packet length and checksum are corrected, and the packet is transmitted. The sending side will include the same exact SVR Metadata on every packet until a packet in the opposite direction (reverse direction) arrives with reverse SVR Metadata indicating a complete handshake. For TCP, the SYN packet contains SVR Metadata, and typically a SYN-ACK from the server side responds with SVR Metadata, and there is no further SVR Metadata inserted in a session that remains on the same path for its duration. Metadata is inserted mid-flow for a session during path migration events.¶
Client ----> TCP SYN w/SVR Metadata --------> Server
Client <---- TCP SYN-ACK w/SVR Metadata <---- Server
For UDP, SVR Metadata can be inserted in packets until there is a reverse flow packet with SVR Metadata, except for unidirectional flows as noted in Section Section 4.7.7¶
If a packet arrives at the West Router having the West Routers Waypoint (interface address) as a destination address (i.e., the packet was sent to the router, and not to a destination beyond the router) the packet may likely contain SVR Metadata. When this occurs, the following steps are taken.¶
Packets arriving on the routers must be validated before they are processed (see Section 5.6.2). These simple checks can eliminate any potential attack vectors. If the packet fails authentication or validation, the packet MAY be dropped or responded to with an ICMP Destination Unreachable packet.¶
In the example case we are using, there are only three source addresses that could be possible:¶
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 very first and most efficient test is to verify that the SVR Metadata is present is to look for the existence of SVR header magic number (see Section 5.6.1).¶
The next verification step is to check the HMAC signature (see Section 5.5.1). If the signature is invalid, the packet should be dropped and a security event noted. If valid, processing continues.¶
The unencrypted portions of the SVR Metadata header should be verified for reasonableness. The header length and payload length must be less than the SVR Metadata block size.¶
The next step is to decrypt the SVR Metadata (See Section 5.6.2.2). If there are any reasons why the SVR Metadata block cannot be decrypted, or the decryption fails, the packet is dropped.¶
The payload TLVs can now be parsed and the necessary state and translations loaded into memory. If there is a failure to parse all TLVs, the packet is dropped.¶
Next the SVR Metadata block and HMAC signatures are removed from the packet.¶
The SVR Metadata information is used to restore the original context to the packet. The packet is then recursively processed exactly like the first packet described in Section 4.7.1, with a few differences. The Context, Tenant, Service, Security Policy and Session UUID strings are used from the SVR Metadata (as opposed to locally determining them). These are then used for applying policy and routing decisions locally. The end result is the packet may go through another SVR Peer Pathway or be delivered via standard networking techniques. In this example, the West Router delivers the packet to the Server LAN.¶
When the packet is forwarded to another SVR Peer, there are some differences. The Tenant, Service, Session UUID, Security Policy and the original 5-tuple addresses are all cloned. This provides consistent data across a multi-hop SVR network. It should be noted that the SVR Metadata must be decrypted at every SVR Router and then re-encrypted because the Waypoint addresses are different for each selected peer pathway. Payload decryption however, is only encrypted at the first SVR router and decrypted at the last SVR router.¶
Because every hop between SVR Routers utilizes the same session UUID, a looping first packet is easy to detect. There MUST never be two sessions with the same UUID. Any session that loops must be dropped. By detecting looping packets during the first packet transmitted, subsequent packets can be dropped on ingress by the SVR Router that detected the looping behavior. SVR routers must also decrement the TTL and operate in all ways like a traditional router to prevent looping packets that are not detected by SVR.¶
When a packet arrives with SVR Metadata after the SVR Metadata handshake has been completed, it is assumed to be an update and not classified as looping. Updates can be used to change any attribute, but most commonly to change a peer pathway for a session. See Section 7.1.¶
After processing the first forward packet at both East and West routers, both the East and West routers have established packet forwarding rules and translations for both directions. This means that eastbound rules and westbound rules are all established and installed. The router is thus capable now of recognizing 5-tuples in either direction and acting on the packets without consulting routing tables. This is known as fast path processing.¶
On a session-by-session basis, SVR Routers must know the status of an SVR Metadata handshake. If a packet for a session arrives and the SVR Metadata handshake is not complete, the SVR Router must insert SVR Metadata for the session. This will continue until there is verification that the SVR Peer has received the information. As stated previously, for TCP SYN this is normally the first reverse packet which is a TCP SYN/ACK. The purpose of reverse SVR Metadata is:¶
In this example, the reverse SVR Metadata includes:¶
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 TLVs in reverse SVR Metadata.¶
One optional SVR Metadata attribute is included in this example for the pathway metrics. This is documented in Section 8.3.7.¶
The Session HMAC Key is state information retained by the router. The Session HMAC Key is communicated between SVR peers as part of BFD Metadata. The lifetime of the HMAC key typically follows the lifetime of the Peer Metadata key. This key is used for the life of a session.¶
One of the benefits of SVR is the complete tracking of sessions end-to-end. In this example, the SVR Metadata state located in the SVR router contains all addresses used. The forward context provides the egress SVR router with the addresses being used pre-NAT, and the source NAT information. The reverse context would likewise supply the ingress SVR destination NAT addresses. Knowing the Waypoint Addresses used along with the ports used provides complete end-to-end visibility of each session.¶
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.¶
As soon as an SVR peer receives a packet of a session from another SVR peer and there is no SVR Metadata, the SVR Handshake is complete, and it can stop sending SVR Metadata. This works for both the East Router and the West Router. Both will transmit SVR Metadata until they receive a packet without SVR Metadata.¶
No SVR Metadata is sent upon normal session termination. The router can monitor the TCP state machine and have a guard timer after seeing a FIN/ACK or RST exchange. After the guard timer, the session can be removed from the system. If a new session arrives during this period (a TCP SYN), then it will cause immediate termination of the existing session. All protocols also have an associated inactivity timeout, after which the session gets terminated if no packets flow in either direction. Should an existing session send a packet after the inactivity timeout, it will be processed as a new session.¶
When there are unidirectional flows, or path asymmetry (e.g., TCP sequence numbers advance with no reverse packets observed), and there is end-to-end communication, one can stop sending SVR Metadata. For UDP asymmetry, the sending router will send a maximum of 20 packets with SVR Metadata; if no reverse packets are seen during that time, the receiving peer router generates and sends a disable SVR Metadata packet to the originating router to complete the SVR Metadata handshake. The total number of packets sent with SVR Metadata without receiving a reverse packet is an implementation detail and is not a strict requirement.¶
The diagram below shows a typical TCP session flowing between a client and server through routers in a network.¶
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 constructs SVR Metadata for the next chosen peer in the routed pathway, as depicted by MD1 and MD2 in the above diagram. Upon receipt of the first reverse packet, reverse SVR Metadata RMD2 and RMD1 is inserted. Each router allocates its own transport addresses (Waypoints) for each session. The context, service name, tenant name, and session UUID sent are unchanged between all routers, and can be used for determining the application of routing policies. The session UUID is the same in MD1, MD2, RMD1, and RMD2 in the above diagram.¶
Likewise, the diagram below shows a session teardown sequence for a typical TCP session.¶
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 or required when sessions terminate. Each router keeps its state information for a programmed length of time in case a FIN/ACK is delayed or dropped, then the state information is removed.¶
This section provides the normative requirements for SVR Metadata to achieve interoperability.¶
SVR implementations MUST support TCP, UDP, and ICMP. SVR implementations SHOULD support UDP Unicast. Sessions are characterized by having an initial first packet that is a unique to an SVR router. Often this is described as a unique 5-tuples as seen by the router. Sessions start when the first packet is processed, and end when either the L4 protocol indicates the session is completed (TCP FIN/FIN ACK, RST) or there has been no activity for a length of time (UDP, ICMP, UDP Unicast, point-to-point ethernet).¶
SVR is always OPTIONAL. SVR implementations can choose when to use SVR on a session-by-session basis. SVR implementations MUST support non-SVR traffic.¶
SVR implementations MUST insert SVR Metadata into packets directly after the L4 header, even if the resulting increase in packet size would cause the packet to require fragmentation. For Ethernet point-to-point and ICMP error messages, IP Headers and L4 headers MUST be created. If associated with an existing session, the packet MUST share the exact transport 5-tuples (SVR Waypoints and Ports) as the session the ICMP error message. The SVR Metadata MUST be in the very first packet of a new session (TCP or UDP bidirectional flow) to have any role in path selection or security. SVR Metadata SHALL be sent in any subsequent packet in any direction to change or update the networking requirements. The SVR Metadata is inserted into the payload portion of a packet to guarantee it makes it unchanged through the network. Packet lengths and checksums MUST be adjusted accordingly. TCP sequence numbers MUST NOT be adjusted.¶
A prerequisite for SVR Metadata insertion is that a Peer Pathway MUST be selected for the purposes of routing a session. This is similar to choosing a tunnel between two networks. This Peer Pathway has IP addresses on either side (Waypoint Addresses), and these addresses will always be the transport IP addresses for packets containing SVR Metadata.¶
The SVR peer originating the session (client side) MUST allocate both source and destination ports. The ingress side MUST choose even ports for local (source port) and odd ports for remote (destination port). This provides uniqueness between any two peers, with no negotiation or collision possibilities. The range of ports to use for allocation is provisioned. Ports in use MUST be excluded from allocation. Ports MUST be unallocated when session state is removed. Ports MUST have a 60 second guard time before being reallocated.¶
SVR implementations MAY need to send SVR Metadata to a peer at a time when there are no packets flowing between client and server. See Section 7.3 for an example. In these cases an IP packet MUST be created and inserted into the appropriate existing session with an indication the packet should be dropped. The packet MUST be processed, interpreted, and dropped by the directly adjacent peer and not forwarded 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 | | | +-----------------+-----------------+----------+----------+------+
If UDP protocol, the UDP Header MUST be updated to have the correct packet length.¶
The Layer 4 header (TCP/UDP) MUST have its checksum recalculated per the appropriate procedures.¶
The IP Packet length field MUST be updated to reflect the number of octets added for the SVR Metadata block and the HMAC signature.¶
The IP Header Checksum MUST be updated after the IP Packet length is adjusted.¶
If TCP protocol, the TCP Sequence numbers MUST NOT be changed.¶
SVR Metadata is sent inside the payload portion of TCP and UDP packets. 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 SVR magic number, false positive logic is enacted on the packet. This guarantees downstream SVR routers will not confuse SVR Metadata magic number signatures.¶
False positives SHALL NOT occur when first packets are processed, since valid SVR Metadata will always be inserted regardless of the contents of the first 8 octets of the payload. False positive can only occur during existing valid SVR sessions between peers.¶
To implement false positive logic, SVR implementations MUST insert an empty SVR Metadata header (12-octet header with 0 TLVs). This creates a contract with downstream SVR routers that if the magic number is present, there MUST be valid SVR Metadata that requires processing and removal.¶
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 SVR router receiving a packet with false positive SVR Metadata will strip out the SVR Metadata header and any TLVs as is normally expected. The inserted SVR Metadata header has 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 | | +--------+--------+----------+---------------------------+
Insertion of header or payload TLVs is OPTIONAL and at the discretion of the implementation. If adding TLVs, standard procedures MUST be applied including encryption if payload TLVs are added.¶
TCP to UDP transformation is required when a middlebox blocks certain TCP packets that contain SVR Metadata. SVR implementations typically test Peer Pathways to ensure SVR Metadata insertion into TCP SYN packets will pass through any middleboxes. If TCP SYN packets with SVR Metadata are dropped by a middle box, then TCP packets are transformed to UDP for SVR processing, and restored when exiting SVR processing. The steps to transform TCP to UDP are:¶
The protocol field in the IP header MUST be changed from 0x06 (TCP) to 0x11 (UDP).¶
The UDP checksum will overwrite the sequence number. To save the sequence number, it is copied to the 32-bit checksum/urgent pointer location of the TCP header.¶
To positively communicate that TCP to UDP transformation has occurred, one must add TLV 12 to the SVR Metadata being transmitted. See Section 8.4.9.¶
The UDP transformation is for every packet in a session, not just the packets with SVR Metadata. The restoration process is depicted in Section 5.6.3.¶
The SVR Metadata TLVs that MUST be inserted in a first forward SVR Metadata packet of a new session include:¶
Optional SVR Metadata TLVs that MAY be included in forward SVR Metadata are:¶
The order of the TLVs is arbitrary, but header TLVs must be before any payload TLVs. If a TLV is received that is unknown to a peer, it MUST be ignored.¶
The SVR Metadata TLVs that MUST be inserted in a first reverse packet of a new session include:¶
Optional SVR Metadata TLVs that MAY be included reverse SVR Metadata are:¶
The SVR Metadata TLVs that MUST be inserted when returning an ICMP Error include:¶
Optional SVR Metadata TLVs that MAY be included reverse SVR Metadata are:¶
Encryption of SVR Metadata utilizes block mode ciphers. Ciphers MUST have a consistent block size. The cipher to use and its block size MUST be provisioned and known to peers in advance. The provisioning methodology is outside the scope of this document. The SVR Metadata Key used for encryption is specific to all Peer Pathways between any two peers and is obtained using BFD with SVR Metadata (see Section 6.1.9). When data is encrypted with block mode ciphers, the block will be padded with zeros (0x0s) to equal an increment of the block size used by the cipher. An initialization vector allows the decryption to be performed without any state.¶
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 ---------------->|
Padding can be computed as the length of the SVR Metadata payload TLVs MOD'ed by the block size.¶
Through provisioning (outside the scope of this document), an SVR Authority MUST define if HMAC signatures are to be used. An SVR Authority MUST also define if Time-Based HMAC is to be used. AN SVR Authority MUST determine if ALL packets are signed, or just packets containing SVR Metadata. Due to the possibility of replay attacks, it is RECOMMENDED that Time-Based HMAC signatures be used on ALL SVR packets. The Session HMAC Key is communicated between SVR peers as part of BFD Metadata. This key is used for the life of a session. (see Section 6.1.9).¶
SVR Peers SHOULD sign all packets with HMAC signatures defined in [RFC2104]. The Session HMAC Key should be used when creating an HMAC signature. When present there MUST be only one HMAC signature in an IP packet even if it fragments across multiple IP packets. Time-based HMAC signatures are RECOMMENDED. For time-based HMAC signatures, SVR routers append the current time since epoch (measured in seconds) divided by 2 to the data being signed. SVR routers MUST have clocks synchronized accurately. Methods for synchronizing clocks and measuring any differences or drifts are outside the scope of this document. Minimally NTP [RFC5905] should be implemented. In cases where the current time cannot be relied on, one may need to disable the time-based HMAC and use a standard HMAC, but this is NOT RECOMMENDED.¶
The HMAC signature is always added to the very end of a packet. The size of the HMAC signature depends on which signature is used. Well known HMAC types are used with SVR including 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
If HMAC signatures are present in an SVR implementation, SVR implementations MUST verify and remove the signature. Verification provides both authentication of the SVR router that sent the packet, and integrity that the packet has not been modified in any way intentionally, or through transmission errors between two SVR routers.¶
Through provisioning (outside the scope of this document), an SVR Authority MUST define if HMAC signatures are present. An SVR Authority MUST also define if Time-Based HMAC is to be used. AN SVR Authority MUST determine if ALL packets are signed, or just packets containing SVR Metadata. Due to the possibility of replay attacks, it is RECOMMENDED that Time-Based HMAC signatures be used on ALL SVR packets. The Session HMAC Key associated with the session state is used for all HMAC signatures and verification.¶
To verify the HMAC signature, a new signature is generated on the packet and bytewise compared to the signature transmitted in the packet.¶
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 reasons, when verifying a Time-Based HMAC signature, implementers SHOULD compute the HMAC on the packet (not including the IP header) and save the preliminary result. Then try updating the HMAC signature with the current window value. If this fails to match the signature, one must try updating the preliminary result using the next time window by adding 2 seconds (or previous by subtracting 2). If the time window is determined to be the next time window; it will remain that way for all packets received from a particular peer until it advances with clock time. Keeping an active time window per peer can make this process much more efficient.¶
If the signature does not match after checking adjacent time windows and newly issued keys, then the packet is dropped and a security event noted.¶
If the signature matches exactly the signature in the packet, then the packet has been authenticated as being sent by the previous SVR router, and assured that the packets integrity between the two routers is good. The HMAC signature MUST be removed from the packet.¶
The IP Packet length field MUST be updated to reflect the number of octets removed.¶
The IP Header Checksum MUST be updated after the IP Packet length is adjusted.¶
Routers MUST process SVR traffic and non-SVR traffic. SVR Routers MUST keep track of sessions that are using SVR. Only sessions setup with SVR may use the procedures described below. Traffic that is using SVR will always originate and terminate on Waypoint addresses (known peer pathways). This provides efficient separation of non-SVR traffic and SVR traffic.¶
Packets received on known Peer Pathways MUST be assumed to either have SVR Metadata or be packets associated with existing SVR sessions.¶
Any packet could arrive at any time with SVR Metadata. DPI MUST be used to scan for the presence of SVR Metadata on every packet. SVR Metadata MAY be expected and required for first packet processing, and the absence of SVR Metadata will result in dropped packets.¶
The HMAC verification step (defined above) MUST be performed prior to performing any other SVR Metadata verification steps. This prevents attacks by modifying packet on the wire.¶
If the first 8 octets of the payload (TCP or UDP) exactly matches the SVR magic number (0x4c48dbc6ddf6670c) it indicates that packet MUST have SVR Metadata. If the first 8 octets do not match, the packet does not contain SVR Metadata. If SVR Metadata is not present, the packet SHOULD be routed if part of an existing session (see Section 5.6.4). If not part of an existing session the packet MUST be dropped and a security event noted.¶
The SVR Metadata header is parsed (see Section 8.1). If the header length and payload length are both zero, the SVR Metadata is simply removed and the packet is forwarded. Please see Section 5.2.6 for description of false positive SVR Metadata header insertion. The next step is to walk the header TLVs to ensure they are reasonable. If the payload length is zero, then the SVR Metadata can be accepted and processed. Decryption of SVR Metadata is only required when there are payload TLVs.¶
If a TLV is sent that is unknown to the implementation, the TLV SHOULD be skipped and the TLV MUST be forwarded.¶
If the SVR Metadata TLVs are not reasonable, the packet MUST be dropped and security events noted.¶
If the peers have been provisioned to encrypt SVR Metadata with a specific cipher AND the payload length in the header is non-zero, then the SVR implementation MUST assume that an encrypted SVR Metadata block was transmitted.¶
To decrypt the encrypted SVR Metadata block, an SVR implementation MUST have the pre-provisioned cipher, block size, and initialization vector size. Once these are known, it is possible based on the payload length in the SVR Metadata header to determine the exact structure of the packet, and how to decrypt it.¶
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 padding is equal to the payload length from the header MOD'ed by the cipher block size. The "block" is then decrypted assuming that the octets following the "block" is the Initialization vector.¶
If the decryption fails, then the packet MUST be assumed invalid and dropped. When this happens a security event is noted.¶
Upon successful decryption, the payload TLVs MUST be reviewed for reasonableness and completeness. See Section 5.3 for minimum required TLVs. If there are insufficient TLVs present for the SVR implementation, the packets MUST be dropped and errors noted.¶
After review of the TLVs, the SVR Metadata is considered valid and accepted by the SVR implementation. The SVR Metadata block is removed from the packet, and the IP header length and checksum MUST be corrected. The packet signatures and decryption provide a very high degree of assurance that the SVR Metadata is authentic and has integrity.¶
If the received SVR Metadata block contains a TCP SYN Packet TLV (see Section 8.4.9) then the following procedures MUST be performed on EVERY packet of the session. This also signals to the SVR Router that packets flowing in the opposite direction MUST also be UDP transformed. See Section 5.2.7. The steps performed are:¶
The protocol field in the IP header MUST be changed from 0x11 (UDP) to 0x06 (TCP).¶
Copy the 32-bit integer in the checksum/urgent pointer location of the TCP header to the sequence number, effectively restoring it. The urgent pointer is zeroed out and urgent flag is cleared.¶
The TCP Checksum MUST be recalculated.¶
Any packet that is has a source and destination IP address that map to a Peer Pathway is an SVR packet. SVR Packets that do not have SVR Metadata are SVR session packets. Each of these MUST have corresponding known session state. If no session state exists, these packets MUST be dropped, or there must be an attempt to restore session state (see Section 3.11).¶
Packets ingressing to a peer pathway that are part of existing SVR sessions that do not contain SVR Metadata MUST be translated (all 5-tuples, bidirectionally). The source address MUST be replaced with the local Waypoint address associated with the peer pathway. The destination address MUST be replaced with the Waypoint of the SVR Peer chosen. The protocol either remains the same, or is modified if UDP Transformation is required (See Section 5.2.7). The source and destination port fields MUST be replaced with the ports allocated for this SVR session. For efficiency, implementers SHOULD save a single checksum delta as part of the session state because the address/protocol/port modifications will always be identical for each packet of a session.¶
Packets egressing from a peer pathway must have their addresses restored. SVR session state MUST contain the original packet context 5-tuples for every SVR session. The original Source IP Address MUST be restored. The original Destination IP Address MUST be restored. The original protocol must be restored, and if it is changes from UDP to TCP then one MUST follow the procedures defined in Section 5.6.3. The source port MUST be restored. The destination port MUST be restored.¶
A provisioned SVR Policy SHOULD include both a tenant and service. Absence of an applicable SVR policy SHOULD prevent SVR sessions from being established. Traditional IP routing can be used when SVR policies do not apply.¶
Services are textual names for sets of CIDR blocks, protocols, and ports. Services map directly to our human understanding of a network use case. Examples include "Zoom" or "Office365".¶
Service Definition¶
Service Name
protocol: TCP/UDP
port ranges[]
CIDR Blocks[]
When a packet arrives with SVR Metadata at an SVR Router, the name of the service MUST be in first packet SVR Metadata.¶
When a first packet arrives without SVR Metadata, the service must be determined through a lookup of the IP destination address, port, and protocol. The resultant string becomes the service name. If this fails to result in a service, the name of the service can be determined by using application recognition techniques. These are omitted from this document, but include HTTP Request Analysis, TLS SNI, and Common Names in certificates.¶
Services can have associated quality policies and security policies associated with them via provisioning, which are outside the scope of this document.¶
When egressing an SVR Peer Pathway, the service name can be used to route the packet to another SVR Peer, or to the final destination. If another SVR peer is chosen, the service name MUST be used as provided by the previous SVR peer. When exiting SVR and returning to traditional network routing, the textual service name MUST be resolved to an IP address. SVR supports several options:¶
Services SHOULD be provisioned to have lists of Tenants that are permitted to use a Service, and tenants that are denied using a service. These access controls are RECOMMENDED.¶
Tenant is a text string hierarchy delimited by periods. Tenants are logically similar to VLANs, CIDR block subnets, and Security Zones. The entire text string, including the full hierarchy is used to define a tenant, and for policy application, the tenant MAY match right to left in full segments (delimited by periods). The longest match will always be used (the most segments).¶
Tenants SHOULD be referenced and associated with Services to create a from-to vector. This has the benefits of associating ACLs directly with Destinations. A provisioned SVR Policy SHOULD include both a tenant and service. Absence of a applicable SVR policy prevents SVR sessions from being established. The deny by default approach is RECOMMENDED.¶
It is RECOMMENDED that a tenant be associated with physical interfaces and logical interfaces (VLANs) as a default for arriving sessions. CIDR block-based tenants SHOULD override these defaults. Tenant definitions directly from clients that self-assert their tenancy SHOULD override all other tenant definitions.¶
All network interface-based tenant definitions are local to an SVR router. The tenant definitions on ingress to SVR may not match those on egress from SVR. This permits the use of different segmentation techniques in different networks.¶
If payload encryption is required, a Security Policy is used to describe all aspects of the agreed upon methods. The Security Policy meaning must be valid and equal at the point of encryption and decryption in multi-hop use cases.¶
SVR routers generate a Payload Key locally when processing the first packet requiring encryption that conforms to the defined security policy. A FIPS 140-2 approved highly secure DRBG is used to generate keys and IV. It is also highly recommended that NIST SP800.90B be followed for ensuring proper entropy. See [NIST_SP_800-90B]. The OpenSSL function RAND_bytes() can be used to generate a key that is the current number of bits long and conforms to NIST SP-800-90B. This key is included in the first encrypted packet as SVR Metadata. In a post quantum world, the key could be generated from quantum sources.¶
The SVR Metadata is forwarded hop-by-hop through the network until the packet egresses SVR. The router that terminates the SVR routing MUST extract the Payload Key from the SVR Metadata, and store it as part of the session state information. This key will be used to decrypt all payload packets from this session.¶
Packets traversing the reverse pathway will use its own key, generated by the same methods described above, and transmitted in reverse metadata Payload encryption and decryption uses asymmetric keys. This simplifies key management and glare conditions for payload.¶
The originator of the session can re-key at any time by adding SVR metadata with the new key to a packet within the session. The payload will immediately be encrypted by the new key.¶
In the forward direction, the Security KEY TLV (see Section 8.4.15) contains the key for encryption/decryption in the first packet in each direction. This allows the key for decryption to go end-to-end in multi-hop router cases. The key is safe because SVR Metadata is encrypted hop-by-hop through the network. Thus, each payload encrypted packet is decrypted once at the end of the SVR route. Using a named Security Policy permits implementations to use whatever ciphers are required, as long as they can be named. The default cipher is AES256 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 similar to Tunnels insofar as they represent virtual transport pathways between routers. BFD is used to determine reachability, measure quality of a pathway, and to perform authentication and key management.¶
It is RECOMMENDED for every configured or discovered SVR Peer pathway, A UDP BFD session be used to monitor the state of the pathway, and through extensions, measure path quality.¶
BFD Control messages are sent by each router on each peer path. The BFD message is constructed with appropriate timers for the Peer Pathway which are administratively determined. BFD as defined in [RFC5880] does not support certificates or exchange of public keys. To overcome this, BFD Metadata is used.¶
BFD Metadata is inserted into existing BFD messages for the following purposes:¶
BFD Metadata is added to the end of the BFD packet when required. If BFD Metadata is added, the length field in the IP Header, UDP Header, and BFD Control message are all adjusted accordingly.¶
BFD Metadata Location:¶
BFD Control Packet with BFD Metadata
+-----------+--------+---------+----------+
| IP Header | UDP | BFD | protobuf |
| | Header | Control | BFD |
| | | Packet | Metadata |
+-----------+--------+---------+----------+
| |
|<== BFD Pkt Len ==>|
In all cases, BFD packets will be defined as BFD Control Packets. When sending "MeasureData" messages which behave like BFD Echo packets, the Required Min Echo RX Interval (see [RFC5880]) must be greater than zero.¶
BFD Metadata is described 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;
}
The SessionData message can be used to determine the source address of a remote peer router on a Peer Pathway. This is required to establish a peer path. Configuration will be associated with a router ID, and not a dynamic address associated with a hostname. Remote Peers will create a local address resolution table (i.e., /etc/hosts) to resolve the hostname in configuration to the dynamic IP address. This action can be performed simultaneously with detection of NAT between Peers 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
The SessionData message can optionally be used to detect NATs between two routing peers. Typically, this is performed during initial peer pathway establishment and often grouped together with sending Peer Authorization certificates. Similar to STUN, the IP address of the originating interface is stored in the field SessionData.original_ipTuple. If the router has received any BFD packets from its peer router, it will store the IP address of the received BFD packet in this field. When sending the SessionData BFD Metadata, a router OPTIONALLY places its own name in the peername field. Through the process of comparing addresses within the IP header with addresses used by the router's interfaces, one can detect when there is a NAT on a Peer Pathway.¶
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
If a NAT is detected in a Peer Pathway, care must be taken to associate address N with the Peer Pathway to Router A. Sessions that are traversing this Peer Pathway may require NAT Keep Alive processing. See Section 7.3.¶
Often routers at branch locations are connected to networks and receive their IP address dynamically from DHCP, LTE or PPPoE procedures. Although it is rare, sometimes these addresses change unexpectedly. This may be the result of a lease running out, or a router reestablishing connectivity after a failure. When this happens, any peer that was using the old address will lose connectivity to this peer. By including SessionData BFD Metadata, learning the address of the peer and recovery occur veryquickly.¶
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 MTU size on a path is important for routers so they can fragment packets when necessary. After a peer pathway is established, a series of BFD MeasureData packets that increase in size can help us find the limit of packet size between peers. To make the BFD packet larger, the lengths are adjusted in the IP header, UDP header, and BFD header. A peer receiving a fragmented BFD request with the MTU Discovery field equal to TRUE simply does not respond.¶
Often there is an entire network between peers. As such, the MTU size may change over time. It is recommended that MTU be measured routinely and updated, should it change.¶
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
After a Peer Pathway is authenticated and ready for use, BFD can be used to measure latency and packet loss. This is performed by sending BFD packets with BFD MeasureData Metadata. Both sides of a Peer Pathway can test for quality if desired. The number of packets in a burst is determined by configuration. The frequency of quality tests is also determined by configuration. Quite often routers with a large number of Peer Pathways (such as a data center hub router) may never perform quality tests, and rely solely on observations made by its peer spoke routers.¶
BFD-based quality measurements are only required when circuits are idle. When sessions are traversing a peer path, quality measurements can made for existing sessions using SVR Path Metrics (see Section 8.3.7).¶
The receiving side generates a response message by rewriting the BFD Metadata request and supplies information if requested. Each "request" generates a "response". Each request has a transaction ID, and so does each response. This solves a problem of exact symmetry where by a peer may not know if a message is a response or a request from a peer.¶
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)
Router B responds to each BFD MeasureData message it receives by responding to the original message and adding a serialized resp_id. To measure latency, the sending (measuring) side (Router A in this case) can measure the elapsed time between each req_id sent, and its response. Absence of a response counts as a packet lost. The variability in latency provides a method of calculating jitter, and MoS scores can be computed once latency, packet loss, and jitter are known.¶
Both Router A and Router B must send their own BFD MeasureData messages to produce their own quality measurements from their own specific point of view. The actual network quality between these two routers can vary based on direction.¶
If one side of a Peer Pathway fails and there exists a policy to choose an alternate path, BFD NodeInfo Metadata can be used to detect this event. Knowledge of a Peer Pathway failover may be required by routers in certain scenarios.¶
For redundancy, routers are often grouped into a cluster of active/active nodes. Responsibility for a Peer Pathway may change from one member of a cluster to another. When sending BFD with Metadata, by including the Node ID (instance number in a cluster) and a timestamp of when the Peer router started, one can detect redundancy events at the far end side of a Peer Pathway.¶
Inclusion of this information is optional. This data can be used by a remote peer to trigger actions where redundancy events impact them.¶
When a router is initialized, if it does not have a signed authentication certificate that is valid, it must obtain one from a certificate authority (CA). The router will create an elliptic-curve public/private key pair (see [RFC8422]). The public key is used to create an X.509 certificate signing request (CSR) with the common name field set to the router's UUID. Elliptic-curve is used to ensure the X.509 certificate is as small as possible. A certificate signing request is initiated to a known and trusted CA through a secure connection. The CA will digitally sign (ECDSA) the CSR and return it to the requesting router. The specific details of this process is omitted from this specification, but it is recommended that it follow the procedures and guidelines defined in [RFC4210]. Certificates and Public Keys are stored locally on each router in PEM format defined by [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 stored on the router persistently in PEM format. The private key associated with the certificate should be created and stored in a secure non-volatile storage, such as a Trusted Platform Module (TPM).¶
When establishing a peer pathway, the SVR Routers will authenticate with each other using their public key and UUID. The result will be a symmetric Peer Key derived from the router's private and public keys from the X.509 certificate above. UUIDs are used for authentication because router IP Addresses often change. This is true when transport addresses of branch routers are established using DHCP and leases expire.¶
The diagram below shows two routers, each with two peer pathways. BFD Messages with Nodeinfo are sent that contain the X.509 Certificate in the public_key field. The BFD Nodeinfo messages are sent by both routers on all pathways, but only need to be validated one time for each router 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--------|
When a certificate is received from a peer, it must be validated. The validation includes the following checks:¶
The validation for a peer only needs to be done one time. When a certificate is received from a peer on multiple peer paths, if the certificate is identical to a previously validated certificate, a cached validation response can be used.¶
When receiving a certificate from a peer router, after validation, the receiving router must extract the peer router's public key and save it. This will be used for validating Peer Key/rekey request's authenticity.¶
Each router should update its authentication certificate before the current certificate expires utilizing the same exact steps identified herein.¶
A single Peer Key is used for all paths between two router peers. The key is kept and considered valid until a new key is accepted as a replacement. This key continues to be used through network outages and path failures. If a key is lost, or doesn't appear to function correctly, a new key must be obtained before processing of encrypted BFD traffic.¶
Anytime a key replacement is desired, or a key is needed, a new salt value is created by the initiator and sent with BFD NodeInfo to a peer. The peer responds by generating a new salt value and responding with a BFD NodeInfo message. Once both salt values are obtained, the Concat KDF calculation can proceed resulting in a symmetric key value for both peering routers.¶
A Key Derivation Function called Concat KDF (See [NIST_SP_800-56A] is used to calculate an authenticated peer key. This key calculation utilizes the routers authenticated certificates private keys, and as such the key is safe from man in the middle attacks.¶
OpenSSL has a standard function called ConcatKDF() that can be called to compute this key in a FIPS compliant fashion. The parameters are:¶
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
¶
The Salt values are concatenated octet strings, with initiator salt first followed by responder's salt. For ECDH calculations, please see [ECDH_Key_Exchange].¶
After a short guard time (1-2 seconds) to allow both peers to complete their calculation, the Peer Key is ready for use and replaces any pre-existing key. The key is then valid on all peer paths between two peers. Once calculated on one peer path, it can be used immediately on all other paths with the same remote peer.¶
The key can be immediately used for encrypting 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 a symmetric key used to encrypt the delivery of the SVR Metadata Key. If the Peer Key is invalid, or expired, or can't be generated, the SVR Routers will not be able share their SVR Metadata Key, which will prevent the routers from functioning. The Concat KDF is a form of ECDH-ES that will only produce a symmetric key if there is no man-in-the-middle. If the keys fail to decrypt messages, it is likely a man-in-the-middle exists, and the route peers should remove the Peer Pathway from service.¶
If a peer sends a BFD NodeInfo to a peer, and there is no response, the peer continues to resend it at periodic intervals. If there is no response after a very long period of time (1 hour), the peer path can be declared invalid and removed from service based on administrative timers.¶
SVR Metadata requires a security association that is not Peer Pathway specific. The interface or source IP Address can not uniquely identify an SVR Peer. For example, there could be many Peer Pathways connected over the public internet. The only way to identify the peer positively is to decrypt the SVR Metadata and extract the peer ID. Each SVR router MUST be able to decrypt SVR Metadata arriving on any interface.¶
SVR Metadata is encrypted specifically for the chosen next-hop SVR router. No other SVR router should be able to decrypt the metadata. Thus when sending SVR Metadata, peers must select a key that is directly associated with the chosen next hop SVR router.¶
To distribute their keys, SVR routers generate a key locally that conforms to the defined security policy. A FIPS 140-2 approved highly secure DRBG is used to generate keys and IV. Its also highly recommended that NIST SP800.90B be followed for ensuring proper entropy. See [NIST_SP_800-90B]. OpenSSL function RAND_bytes() can be used to generate a key that is 256 Bits long and conforms to NIST SP-800-90B.¶
The key and its index are then shared with all known peers using an Encrypted BFD Metadata that contains NodeInfo. The current Peer Key is used to encrypt the 256 Bit SVR Metadata Key calculated above resulting in a 32 Byte Encrypted block and a 16 Byte IV, creating a 48 octet encrypted string. The key index is incremented. The encrypted key is then included in a BFD packet (NodeInfo message), and broadcast to all peers. The encryption technique is identical to SVR Metadata Encryption but uses the Peer Key as opposed to the SVR Metadata Key. (See Section 4.7.1.8). This also means that SVR Metadata keys are asymmetric. The forward SVR Metadata is encrypted with the Key of the destination router, while reverse SVR Metadata is encrypted with the Key or the originating router.¶
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 above diagram shows Peer A distributing its key and index to Peers B, C, and D followed by a subsequent rekey. Each peer responds with its current key and index to provide a handshake. This is also an efficient way for a router that is restarting to acquire all of its needed keys. If a router needs to send SVR Metadata to a peer and it does not have a key, this procedure can be used to acquire the missing key. Anytime a Peer decides to rekey, it must update all of its peers. When an SVR Metadata Key is shared via BFD, the metadata_key_index field number is extracted and is stored with the key for the peer. When SVR Metadata is to be decrypted, the Security ID field in the metadata provides the key index to use for decryption. Please see Section 8.3.2.¶
In the event that a router's certificate is about to expire, or needs to be replaced, a new certificate can be added to the system. Once a new certificate file has been loaded into the system, an event is triggered to restart the peer authentication Section 6.1.7 procedure again. The method of loading the certificate is out of the scope of this document.¶
In the event that a system has become compromised, it may be desirable to revoke its certificate so that it can no longer authenticate with its peers. The management platform of the router is responsible for periodically checking the CRL for any revocations, or OSCP can be used to check the validity of the certificate directly. A notification is sent to any router that has its certificate revoked. Upon receiving this revocation, the router will check its configuration to determine the appropriate behavior.¶
There SHOULD exist a policy to define the system behavior in the event that a certificate has expired or has been revoked. The default behavior SHOULD be to fail-soft (i.e., providing indication that the certificate is no longer valid and action needs to be taken). Alternatively, if the system is configured to fail-hard, it should remove all of its peering relationships and subsequently would no longer be able to participate in SVR.¶
SVR Metadata can be inserted and used to share network intent between routers. Below are examples for specific use cases. These examples are illustrative and the use of SVR Metadata is not limited to these use cases alone.¶
To change the pathway of a session between two routers, any SVR Router will reinsert the SVR Metadata described in section Section 4.7.1.7 and transmits the packet on a different peer path while retaining the same Session UUID of the existing session that is being moved.¶
After 5 seconds the old path state entries can be removed. By keeping the old and new fast path entries during this 5 second transition, no packets in flight will be dropped. The diagram below shows the sequence for moving sessions around a failed mid-pathway router.¶
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, SVR Metadata MD1, MD2 can be included in the very next packet being sent in either direction. Confirmation that the move was completed is confirmed with reverse SVR Metadata RMD2, RMD1. For established TCP sessions, this is either a PUSH (as shown) or an ACK (not shown). This can reestablish the SVR session state into a new router (Router B in this example) that previously did not have any involvement in the session. This technique can also be used to modify paths between two routers effectively moving TCP sessions from one transport (MPLS for example) to another (LTE). A session 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 moving an active TCP session from one transport network to another by injecting SVR Metadata (MD) into any packet that is part of the transport in either direction. Reverse SVR Metadata (RMD) is sent on any packet going in the reverse direction to confirm that the move was successful.¶
Certain sessions may be idle or packets may create a one-way information flow (TCP pushes) with one way acknowledgement (TCP ACKs). In these scenarios, insertion of SVR Metadata into existing packets may not be possible.¶
After moving a session, if an SVR router determines no packets are received or sent for an active session over an elapsed time of 1 second, the SVR router will generate an SVR Control Message to the 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 SVR router interface addresses (Waypoints) and contains the standard first packet SVR Metadata fields with the SVR Control Message TLV added to the header with drop reason "FLOW MOVED". Also added is a TLV attribute with the remaining session time. This is essential to ensure mid-stream routers remove sessions from their tables roughly at the same time. This message will be transmitted once every second for 5 seconds OR reverse SVR Metadata has been received. If no reverse SVR Metadata has been received in 5 seconds the session is torn down. For a quiescent flow, the RMD is a generated SVR Control Message as well as shown below:¶
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 =========>|
If an SVR Router determines there is one or more NATs on a peer pathway (see Section 3.5, the SVR Peer must maintain the NAT bindings for each active session by sending keep alive SVR Metadata in the direction of the NAT. For keep alive, SVR utilizes a packet that matches the L4 header of the idle session that includes SVR Metadata type 24 with the drop reason set to 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]-->| |
| | | | |
The SVR Metadata attributes that MUST be inserted in a keep alive for existing packet sessions includes:¶
With this minimum set of information, the receiver of this message can verify and update any modifications in a session NAT state. The Session UUID is used to verify all information positively.¶
Unlike a tunnel where all packets must be encrypted, each session in SVR is unique and independent. Most modern application sessions are already using TLS or DTLS. SVR Routers have the capability of encrypting only sessions that are not already encrypted. Below is an example of adaptive encryption. With adaptive encryption, every session begins unencrypted. By analyzing the first 4 packets, the router can determine that encryption is required or not. If the fourth packet is a TLS Client hello message, encryption is NOT required. Any sequence of packets that does not indicate TLS or DTLS setup would immediately toggle encryption on.¶
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 is not an indication that encryption will be performed by the transport layer, then the ingress SVR Routers must encrypt and the egress SVR router must decrypt the session bidirectionally. This ensures that any data between the 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 part of the security provisioning. Security policies are associated with services, and as such certain applications can mandate encryption; others may allow adaptive encryption, and still others may specify no encryption.¶
When a fragmented packet is presented to an SVR Router, the packet must be completely assembled to be processed. As such, the HMAC must be applied to the entire packet, and the entire packet must be routed as a whole. Each resulting fragment must be turned into an IP packet with 5-tuples that match the corresponding session to ingress and pass through an SVR. The SVR Router will simply use the same L4 header on all fragments from the session state table (peer pathway and transit ports). A time-based HMAC signature is created for the entire packet and appended to the last fragment. Each fragment must also have SVR Metadata inserted that clearly identifies the fragment to the SVR routing peer.¶
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-->|
In the diagram above, Router A collects all the fragments 1, 2, and 3. Reassembly is performed. Router A records two things from the inbound fragments: The Original ID, and the largest fragment size received. Router A then proceeds to send the jumbo packet by fragmenting it again, but this time sending each piece inside a packet with a newly created L4 which maps exactly to the peer pathway chosen with ports assigned from the session state table. The fragment size will be the lesser of the smallest MTU on the path OR the largest fragment seen, whichever is smaller. The SVR Metadata header and header TLVs are not encrypted. The packet construction looks like this:¶
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 inside the SVR fragment will have its own extended ID assigned. This allows a different number of fragments to be sent between Router A and B than the Client and Server have. It also allows independent fragmentation by SVR, should it be required. Router B will process the fragments from router A. Router B will look at its egress MTU size, and the largest fragment seen recorded by Router A and transmitted in SVR Metadata to determine the proper size fragments to send, and the packet is fragmented and sent.¶
There are no other SVR Metadata fields required. All information about the session state is tied to the 5-tuple peer pathway and transports ports.¶
The details on packet fragmentation are identical to what is performed in IP fragmentation, exception for the full L4 headers and SVR Metadata insertion.¶
If a packet traversing an SVR needs to be fragmented by the router for an SVR segment for any reason, including the insertion of SVR Metadata, the initiating router inserts SVR Metadata on the first packet and duplicates the L4 header (either TCP or UDP) on subsequent fragments and inserts SVR Metadata. In this case the Largest Fragment Seen and Original ID field in the SVR Metadata is left blank.¶
Ladder Diagram Fragmented Packets:¶
Client . . . . . . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
| | | |
|--Lg Pkt--->| | |
| |--------Frag 1[MD]------->| |
| | | |
| |----Frag 2[L4 Hdr|MD]---->| |
| | |--Lg Pkt-->|
| | | |
Since IPv6 fragments packets at the source node, the SVR router performs no special handing for IPv6 networks. If the packet is too large for the destination, the destination will respond with an ICMPv6 response indicating the message is too large, including the recommended MTU. The router returns this message back to the originator on its reverse flow.¶
Client . . . . . . . . . . . . . . . . . Server
| |
| RouterA RouterB |
|--Lg Pkt--->| | |
| |----Lg Pkt--->| |
| | |--Lg Pkt--->|
| | |<--ICMPv6---|
| |<--ICMPv6-----| |
|<--ICMPv6---| | |
| | | |
There are two types of ICMP messages. There are messages associated with specific packet delivery network errors. This includes:¶
These messages have information from the packet that generated the error by including the IP header + 8 octets in the ICMP message (see [RFC0792]. It is important to deliver the ICMP message back to the origin. For these ICMP messages, the router MUST determine what active session the ICMP message belongs to by parsing the IP header information inside the ICMP message. Once a session is found, the ICMP message is transported across the SVR and reverse SVR Metadata is applied by having its destination address changed to the Waypoint Addresses of the routers.¶
SVR Metadata type 20 and 21 are used to send the source of the ICMP error backward through the networks. See Section 8.3.4 and Section 8.3.5 for information about these SVR Metadata formats. This repeats until the ICMP packet arrives at the initial SVR router. At this point the ICMP packet is recreated and the source address is changed to the address communicated through SVR Metadata type 20 and 21.¶
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) | | |
| | | |
The first ICMP message is directed to Router B. Router B examines the ICMP error to locate the session and forwards the message back to the correct Waypoint for Router A. Router A recreates the ICMP message, and sends to the Client.¶
The second type of ICMP message is not related to any specific sessions. These types of messages include ICMP ECHO, for example. These are always encapsulated as UDP, and a session is created for the ICMP message. The identifier field in ICMP and the IP addresses are used as the 5-tuple session key. This includes:¶
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 ICMP message creates a session on Router A directed towards Router B. SVR Metadata MD1 is inserted just like any UDP session to establish the return pathway for the response. Reverse SVR Metadata is inserted into the ECHO Response, effectively creating an ICMP session. Subsequent identical ICMP messages will utilize this path without SVR Metadata being inserted. This session state MUST be guarded with an inactivity timer and the state deleted.¶
The aforementioned handling of ICMPv4 applies to ICMPv6 as well. The obvious notable difference is the size and different header types that are used between the two.¶
While rare, there are cases where session state can be lost. Well written applications generally self correct for any networking changes or interruptions. There are however applications with long lived nearly idle sessions (for example Session Initiation Protocol on idle handsets). In these situations, session state recovery is required.¶
Every SVR session has one or more SVR routers that have the full session state. Below is a set of techniques to obtain the session state either from a peer or through regeneration and replacement.¶
The simplest scenario is when the Ingress SVR router loses state. In this scenario, it simply creates a new session for the preexisting session but has the exact parameters of the original session. When this packet with first packet SVR Metadata reaches the egress SVR, the session state tables are updated, allowing two-way end-to-end packet processing.¶
This is secured against attack because the first packet SVR Metadata is both signed and encrypted.¶
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------->|
The next scenario is when the Ingress SVR loses session state, and the client application is idle. There is data from the server that can't be delivered. If a packet arrives from the server at the Egress SVR, the length of time the client has been inactive is reviewed. If longer than the defined inactivity timer (provisioned, but defaults to 5 seconds), Session Health Check (see Section 8.3.8), SVR Metadata will be inserted into the packet. The Ingress SVR responds by generating a packet (UDP) with the same L3 and L4 information as the session and adds SVR Control Message to respond (see Section 8.3.6). If the Ingress SVR needs state for the session, it sets the drop reason in SVR Metadata to type=6, delete session. This causes the very next packet from the server to include first packet SVR Metadata. The session will be treated as a new session. This data is used to restore all aspects of the session.¶
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 an Egress router loses state for a session, it must obtain the state from a peer. In the example shown below, the Ingress SVR detects the request for recovery upon receipt of a packet that the server has not responded for more than the inactivity timer. The packet that arrived is then augmented with Session Health Check SVR Metadata (see Section 8.3.8). The egress router MUST reply to the session health check by generating a UDP packet with SVR Control Message SVR Metadata (see Section 8.3.6). If it requires state, it must set the drop reason to a type=2, indicating SVR Metadata needs to be sent. The next packet from the client will include all of the first packet SVR Metadata which is used to restore the mission state information.¶
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----->|
| | | | |
The most likely loss of state occurs in middle boxes. Often the middle box will either stop routing packets in one direction, both directions, or modify the UDP or TCP ports without notice.¶
In this instance, we do not know for certain where the state was lost, so we attempt to recover it from our SVR peer by including Session Health Check SVR Metadata in a packet of the session. SVR Peers must respond to this packet, so no response indicates there is a middle box or network problem.¶
To restore the session, the session state is cleared and the next packet is treated as a first packet. A full SVR Metadata exchange between peers is completed as documented in Section 4.7.1. Both Ingress and Egress SVRs can detect that there is an existing session with the exact same addresses and ports and simply replace the 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----->|
| | | | |
The format of SVR Metadata has both Header attributes as well as Payload attributes. Header attributes are always guaranteed to be unencrypted. These headers may be inspected by intermediate network elements but cannot be changed. Header attributes do not have a forward or reverse direction. Header attributes are used for router and peer pathway controls.¶
Payload attributes optionally can be encrypted by the sender. Payload attributes are associated with sessions, and as such have a forward and reverse direction. Each SVR attribute defined will indicate whether it is a header attribute (unencrypted) or payload attribute (optionally encrypted). There are no attributes that can exist in both sections.¶
The SVR Metadata header is shown below. A well-known "cookie" (0x4c48dbc6ddf6670c in network byte order) is built into the header which is used in concert with contextual awareness of the packet itself to determine the presence of SVR Metadata within a packet. This is an eight-octet pattern that immediately follows the L4 header and is an indicator to a receiving router that a packet contains SVR Metadata. NOTE: Normal IP traffic will never have the Waypoint Address as its destination. If a packet arrives at an SVR Router Waypoint, it must have SVR Metadata or be associated with an active SVR session. Please see Section 3.11 for a discussion of state recovery techniques.¶
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 | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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".¶
HMAC signatures are REQUIRED for the packets that contain SVR Metadata to guarantee the contents were not changed, and that the router sending it is known to the receiver. Any HMAC algorithm can be used, from SHA128, or SHA256 as long as both sides agree. HMAC is always performed on the layer 4 payload of the packet. The signature is placed at the end of the existing packet.¶
Optional HMAC signatures are RECOMMENDED for every packet. This prevents any mid-stream attempts to corrupt or impact sessions that are ongoing. This also helps detect and correct lost state at egress SVR routers. See Section 3.11. The signature must include all of the packet after Layer 4, and include a current time of day to prevent replay attacks. The signature is placed at the end of the existing packet.¶
Both the sending and receiving routers must agree on these optional HMAC signatures, details of which are outside the scope of this document.¶
Payload encryption can use AES-CBC-128 or AES-CBC-256 ciphers which can be configured. Since these are block-ciphers, the payload should be divisible by 16. If the actual payload length is divisible by 16, then the last 16 octets will be all 0s. If the actual payload is not divisible by 16, then the remaining data will be padded and the last octet will indicate the length.¶
Waypoint addresses could be addressed by any client at any time. IP packets that arrive on the router's interface will be processed with the assumption that they MUST contain SVR Metadata or be part of an existing established routing protocol.¶
Routers will only accept SVR Metadata from routers that they are provisioned to speak with. As such, an ACL on incoming source addresses is limited to routers provisioned to communicate. All other packets are dropped.¶
When a packet is received the "cookie" in the SVR Metadata header is reviewed first. If the cookie isn't correct, the packet is dropped.¶
The HMAC signature is checked. If the signature is valid, the packet is assumed to be good and processing continues. If the HMAC fails, the packet is dropped.¶
These methods prevent distributed denial of service attacks on the Waypoint Addresses of routers.¶
This document does not require any IANA involvement.¶
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 Juniper Networks for their support and guidance.¶