Secure Vector Routing (SVR)

1.1. Terminology

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

1.2. Overview

                   +---------+
                   |Network2 |
+----------+       |         |       +----------+
|         SVR<---->+<-L3-IP->+<---->SVR         |
|          |       +---------+       |          |
|Network1  |       +---------+       |Network 4 |
|         SVR<--->SVR       SVR<--->SVR         |
+----------+       |         |       +----------+
                   |Network3 |
+----------+       |         |
|Client SVR|<---->SVR        |
+----------+       +---------+

An SVR implementation describes a network requirement semantically and shares this as metadata with a routing peer. The requirement to a peer is conveyed by means of a cookie, often referred to as first packet 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 bi-flow (matching forward and reverse flows) based on the requirement. Once the session is established bi-directionally, the cookie is not sent in subsequent packets, resulting in elimination of additional overhead.¶

Benefits from this approach include:¶

• Tunnel Compression: The metadata contains information required to eliminate tunnel header information for established sessions. This can result in anywhere from 12% to 100% bandwidth savings when compared to IPSEC based tunnels depending on the original packet size.¶
• Elimination of Elephant Flow problems: Tunnels are very long lived and often contain large aggregates of inner flows. Tunnels are also often fixed on a specific network "hash" while each SVR session has a unique network hash.¶
• QoS support is per flow, not per packet: Because each SVR flow has a unique 5-tuple on the wire, standard MPLS routing and QoS techniques work seamlessly. Adding QoS to Tunnels requires QoS on entry to a tunnel, tunnel DSCP markings, and policies to copy/map inner packet DSCP to Tunnel Packet DSCP. In practice many core networks do not look at the DSCP markings once a fast path forwarding rules are established.¶
• Avoid Re-encryption: Tunnels often encrypt all traffic. Much of the traffic in the tunnel is already encrypted, thus there is a re-encryption penalty. SVR support adaptive encryption which performs encryption on only those sessions that require it.¶
• Firewalls and security proxies can intercept TLS sessions and perform decryption and encryption if they support SVR metadata. This is not possible with IPSEC tunnels by design.¶
• Scaling of software based encryption is much higher when session state is available. Encryption performance is limited to what is possible in a single processing core for a single session, and at the time of this document being written the limit is currently 1.5GigE for Tunnel termination.¶

1.3. Definitions

The following terms are used throughout this document.¶

Authority:

This defines the owner of an SVR namespace. Each namespace owner can allocate Tenant names (representing collections of network endpoints sharing common network enforcement policy), and Service names (representing accessible destinations and traffic treatment policy). Authority namespaces must be unique to permit internetworking. Claiming and resolving disputes about authority naming are outside the scope of this document.¶

Tenant(s):

This is a textual description defining network endpoints that share common access policy (allow lists or block lists to network destinations). These may be mapped using any known technique including source IP address mask, a VLAN tag, ingress interface, provided by an authentication system, or even client supplied, and this mapping is outside the scope of this document. Often these are location specific definitions, but the Tenant has global meaning within an authority. Tenant names can conform to domain name syntax, and be expressed as hierarchical structures (i.e., location.department.example).¶

Service(s):

This is a textual description of what server(s) can be accessed with this intent. Examples include Zoom, or Office365/Outlook. Although outside the scope of this document, these could be defined with any known technique, including URLs, IP address(es) protocol(s) and port(s), CIDR block(s), etc. Having a single text name to describe a network destination makes defining network requirements easier. Other Service specific network requirements including Quality Policies and Security Policies can be associated with Services in data models, but are not described in this document.¶

Context:

This is the original "5-tuple" of an IP packet, including source IP, source port, destination IP, destination port, and protocol. Optionally, Layer 2 information such as MAC Address or VLAN tags may be included for certain use cases if required.¶

Signature:

The metadata packets MUST be cryptographically signed using HMAC by the source router, and all packets traversing an SRV peer pathway SHOULD have an HMAC signature so the next hop router can authenticate the sender of the data and verify its integrity. The portion of the packet that is signed must not include the IP header, as it may go through a NAT or IPv4 to IPv6 conversion.¶

Direction:

This is inferred, and not a specific metadata field. The Direction represents the intended client to server direction. The initial network packet of a communication session indicates this direction. For example, a TCP SYN packet would travel from client to server, defining the direction of an service. Forward direction is always client to server, and reverse is always server to the client. These directions have nothing to do with a network topology (for example, hub and spoke), and a single network path could have forward sessions going bi-directionally -- traffic going from node A to node B may represent the forward direction for some sessions and the reverse direction for other sessions.¶

Peer:

An SVR Peer is a client, server, or router that supports the SVR protocol. The SVR Peer could be either directly adjacent, or reachable through an IP network. The SVR Peer should not be confused with BGP Peer. Since SVR Peers must be able to reach each other, and because SVR Peers are often deployed at network edges, SVR Peers can also be BGP Peers. In this document peer will always mean SVR Peer.¶

Waypoint:

A Waypoint is a reachable IP Address associated with an SVR Routers interface. Some physical interfaces may have multiple IP Addresses, and as such a single physical interface could represent multiple Waypoints. In some cases, routers use dynamically assigned addresses on interfaces. In these cases, a Waypoint address may change dynamically.¶

Peer Pathway:

An SVR Peer Pathway is a unique pair of Waypoint addresses that can reach each other. The path can be defined as either a pair of IP addresses or a pair of domain names that resolve to IP Addresses. Peer Pathways have attributes related to availability, performance (jitter, latency, packet loss) and cost. Techniques such as BFD [RFC5580].¶

2.1. Directionality

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

Metadata formats described in this document will be labeled as "forward" or "reverse". Forward metadata is inserted in packets going from client to server. Reverse metadata is inserted in packets that travel from server to client.¶

2.2. SVR with Other Traffic

SVR co-exists with traditional routing. 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 metadata MAY be inserted and session stateful SVR is performed. Otherwise, the packet is forwarded like any traditional IP router.¶

2.3. Metadata Handshake

To ensure the metadata is received and understood between peers, a handshake is performed. A router that supports SVR peer pathways inserts metadata for each packet flow in the following circumstances:¶

• It is a "forward" packet representing a new session and the ingress node has not yet received any reverse metadata from the recipient egress node.¶
• It is a "reverse" packet from the recipient egress node to the initiating ingress node and recipient egress node has not received forward packets from this session without metadata.¶

These two comprise what is known as the "metadata handshake" -- that is, the initiating router includes metadata in all packets it sends to the recipient router until it receives a reverse packet with metadata from that recipient. Likewise, the recipient continues to send metadata to the initiating router until it receives a packet without metadata. This is how two routers acknowledge receipt of metadata from their counterparts: the absence of metadata in a packet indicates that it has received metadata from its counterpart.¶

2.4. Pathway Obstructions

Firewalls and middleboxes that sit along a peer pathway may not propagate TCP SYN messages with data in the payload (Despite being valid), or may verify sequence numbers in TCP streams (which are invalidated due to the inclusion of SVR metadata). 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. 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 5.2.¶

If a middlebox is detected, the packets can be UDP-transformed i.e., the protocol byte 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 4.2.7 and Section 4.6.3 for more information.¶

2.5. Metadata removal

To prevent breaking any applications, there MUST be a 100% guarantee that metadata inserted by a participating SVR device is removed prior to the consumption of the data by the application service. If the client and server support metadata, then the network intent 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 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 metadata to the Waypoint address, the originating SVR router should determine the Peer reachability as exemplified in Section 3.1.¶

If the next-hop is not a known reachable peer, SVR metadata insertion MUST not be performed.¶

2.6. Modification of transport addresses

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 6.4.1) and can be recovered when needed. This is similar to IPv6 segment routing (see [RFC8986]) or a LISP (see [RFC6830]) RLOC with the exception that the original addresses are stored in metadata within the payload portion of the packet, and not the IP Network Header.¶

Selection of the Waypoint address to send 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 3.1 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 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.¶

2.7. Optional use of Tenants and Service names for Routing

The 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 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.¶

2.8. Unique 5-Tuples for Every Session

To avoid sharing a hash with all traffic, and 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 (65,536) 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 total 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.¶

2.9. Session Packets Post Metadata Exchange

After the metadata handshake has been completed. all subsequent packets are simply translated (all 5-tuples, bidirectionally). This is a very efficient process compared to IPSEC encapsulation which requires memory copies, new header creation, completely new packet checksums, and mandatory encryption.¶

2.10. Session State Requirements

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 metadata once it has been received by the peer. There are two possible scenarios for how state could be lost. Either the ingress of the SVR session (source peer) could lose state, or an intermediate (downstream peer) SVR peer could lose state.¶

Determining if an SVR router is an ingress verses a peer SVR router is based on the arriving packet's destination address. If the address is NOT the interface address of the router, it is an ingress SVR router. Alternatively, if the address matches the interface address of the router, there are two possibilities.¶

Packet is a legitimate SVR packet from a peer and State has been lost:

Every packet in an SVR session SHOULD have an HMAC checksum to prevent replay attacks. If a packet arrives at an SVR router, with the destination address of the router, and a source address of a known peer, the HMAC checksum can be verified. If verified, this is indeed, a case of lost state with a SVR Peer.¶

Packet is not a valid SVR Session Packet:

If either the source address of a packet does not map to a valid peer or the HMAC signature does not validate; the packet is invalid and MUST be dropped. This represents a security event and should be noted as such.¶

After determining if the router is an ingress or egress SVR router when there is a flow miss, the state recovery techniques for each type of lost state is listed below.¶

Ingress SVR Loses State:

The ingress router will treat this packet as a new session, allocate and insert metadata. The packet will be forwarded to the next SVR router. This upstream SVR peer may or may not have state for the existing session. By reviewing the metadata's forward context (original packet 5-tuples) the router can determine if there is a collision with an active SVR session. If so, the terminating SVR router will accept the new metadata, and adopt the new proposed addresses and UUID's, essentially merging the two sessions. If there is not a collision with an existing session, the packet is routed as a new session.¶

SVR Peer Loses State:

The peer router without state will create reverse metadata asking for the remote peer SVR (i.e., where the SVR packet was sent from) router to retransmit metadata for this session. The metadata request will be sent back to the peer router using the exact address and ports for the packet received without state, only reversed. Please see Section 6.3.6 for the reverse metadata sent. This reverse metadata request is sent on the peer pathway that sent the packet, with the source port and destination port matching the packet with missing state. The upstream router will include first packet metadata for the session in the next packet of the session.¶

2.11. NATs and Session Keep Alive

Each SVR router (peer) must statefully remember the source address that a session with metadata was received on. 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 metadata packets periodically on idle sessions to keep any firewall pinholes 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), then the SVR Peer should send an SVR Control Message on the peer path with the source and dest ports from the idle session's saved state. See Section 6.3.6 for more information and see Section 5.2 for an example.¶

3.1. SVR Multi-path Routing Description

The example below shows two SVR capable routing peers with multiple peer pathways.¶

 Client
  LAN
10.x.x.x
   |
   |  +--------+                                  +---------+
   |  |        |                                  |         |
   |  |        |                                  |         |
   +->] East  [172.15.0.1<----MPLS----->172.15.10.1] West   |
      | SVR    |                                  | SVR     |
      | Router[107.0.8.186<-Internet-+->52.42.68.58] Router |
      |        |                      |           |         |
      |       [192.0.2.1<-----LTE---/             |         [<--+
      |        |                                  |         |   |
      +--------+                                  +---------+   |
                <========= Peer Pathways ========>              |
                                                                |
                                                          172.15.11.x
                                                              LAN
                                                             Servers

Note: The client, server, and MPLS network support the private address space 172.15.x.x natively, but the internet and LTE networks do not. This is an example of using secure vectors to join networks together.¶

The first step is that routers would apply any locally defined static L3 routes, and begin advertising and receiving routes using L3 networking protocols (BGP, OSPF, etc.) from their IP peers to build a forward information base or FIB. This is required initially to ensure that the waypoints are reachable bidirectionally.¶

The second step is for both the East and West routers to establish their SVR peering. East and West independently attempt to communicate with BFD to each other's interfaces and measure path characteristics such as jitter, latency, and packet loss. In our example, assuming 100 percent success, the resulting peer pathways would be:¶

East's Peer Pathways
  Name      Description                    Characteristics
  MPLS      172.15.0.1->172.15.10.1        20ms Lat, 0 Loss,  2 Jit
  Internet  107.0.8.186->52.42.68.58       30ms Lat, 0 Loss,  3 Jit
  LTE       192.0.2.1->52.42.68.58         50ms Lat, 0 Loss, 15 Jit

West's Peer Pathways
  Name      Description                    Characteristics
  MPLS      172.15.10.1->172.15.0.1        20ms Lat, 0 Loss,  2 Jit
  Internet  52.42.68.58->107.0.8.186       30ms Lat, 0 Loss,  3 Jit
  LTE       52.42.68.58->192.0.2.1         50ms Lat, 0 Loss, 15 Jit

For this example, our assumption is that there are servers that are located inside 172.15.11.0/24 at the West location. West advertises this route to East on each path available to it. East's FIB will look like this:¶

  East's Forward Information Base (FIB)
     Route             Next-Hop IP Addr
     ----------------  -----------------
     172.15.11.0/24    172.15.10.1
     172.15.11.0/24    52.42.68.58
     ....
     [FIB Entries to reach waypoints omitted]

Additionally we will assume there exists a network policy created by the 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 pathway (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 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 metadata in the first packet (see Section 3.6.1) and send it out East's interface with a source address of 172.15.0.1 and a destination address of 172.15.10.1. 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.¶

3.2. Optional FIB Containing Service Names

SVR first packet metadata 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 might make sense:¶

Avoiding Dynamic DNS:

Dynamic DNS is used to augment network routing protocols by answering the question: What best IP Address is available and best for a session now? Dynamic DNS can be plagued by delays in real time updates and additonal complexity and cost. In private networks, path service state may not be reflected in Dynamic DNS responses.¶

Multi-Cloud Networking:

Public clouds run service instances on dynamically allocated private IP addresses. They provide very accurate and responsive DNS updates to help find IP addresses for networking. These DNS services are not available outside the cloud, making internetworking difficult. SVR Routers can use DNS resolution to find IP Addresses for named services.¶

Below is an example FIB that contains named services and traditional FIB entries. The next-hop addresses were changed to Waypoint Addresses to reflect the FIB is now an SVR fib containing service names, protocols, and ports.¶

  East's Extended SVR Forward Information Base (OPTIONAL)

                                                       Egress
  Service Name        Route                Waypoint    Action
  --------------     ------------------  ------------  --------
  github.example     172.15.11.23:TCP:22  172.15.10.1  FWD
  github.example     172.15.11.23:TCP:22  52.42.68.58  FWD
  logsvc.example     172.15.11.20:UDP:514 172.15.10.1  DNS
  logsvc.example     172.15.11.20:UDP:514 52.42.68.58  DNS
  https.example      172.15.11.24:TCP:443 172.15.10.1  DEST NAT
                                                       -196.168.1.1
                                                       -196.168.1.2
                                                       -196.168.1.3
     [FIB Entries to reach waypoints omitted]

Longest prefix matching (LPM), 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:¶

Forward Packet (Default):

Restore the IP Addresses and forward. If a source NAT is provided in the metadata, NAT the source address.¶

DNS:

Use DNS to resovle the service name locally. In this example DNS resolution procedures would be used on egress to resolve "logsvc.example".¶

DEST NAT:

NAT the destination address to one (or load balance to a pool of addresses). This is identical to load balancers.¶

These named routes can co-exist with traditional FIB entries shown above. SVR will always matched a named route first, and fall through to the generic routes second.¶

3.3. SVR Security Definitions

For basic SVR functionality to work between peers, there must be a Authority wide provisioned set of rules. These rules include:¶

HMAC Method:

This describes the method/technique for signing SVR packets. This could be SHA1, SHA256, or SHA256-128.¶

Use Time Based HMAC:

This is either YES or NO.¶

HMAC Metadata or ALL:

This is NONE, Metadata Only, ALL¶

Metadata Block Cipher:

This is either NONE, AES128, AES256.¶

SVR does not limit the use of ciphers and techniques to just those listed. The requirements for both signatures and encryption are that the results are fixed well known block sizes.¶

Security Policies are used during session setup to setup payload encryption specifically for individual sessions. These are exchanged in first packet metadata.¶

For this example will use the following SVR security definitions.¶

      HMAC: (On, time-based, SHA256-128, ALL Packets)
      Metadata Encryption (On, AES256)

3.4. Time Based HMAC Details

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 4.5.1.¶

In our example, we are using SHA256-128 with a size of 16 Bytes.¶

3.5. Security Rekeying Considerations

Every metadata transaction includes a security ID header TLV (see Section 6.3.2). Although key management is outside the scope of this document, managing which key version to use is an important aspect of this design.¶

Each SRV Router will have its initial key (version 1) and may have an updated key (version n) over time. The security key version is always sent in metadata to ensure the peer knows which key to use to decrypt the metadata just sent. If a peer only has version 1 of a key, and metadata arrives specifying it is now at version 2, the SVR router must obtain the new key before it can process any packets.¶

For networks that are large and actively performing key management, there may be multiple versions of a key active, and SVR routers MUST be able to utilize any key for a reasonable amount of time.¶

3.6. New Session Initiation Detailed

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[MD]-------------->|           |
      |            |                        |--SYN----->|
      |            |                        |           |
      |            |                        |<--SYN/ACK-|
      |            |<------SYN/ACK[RMD]-----|           |
      |<--SYN/ACK--|                        |           |
      |            |                        |           |
      |            |                        |           |
      |<==== Session Packets Flow with No Metadata ====>|

The East Router MUST construct and insert metadata[MD] in the first packet of the SSH session, which will be a TCP SYN packet. The West Router must remove the 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 metadata [RMD], and insert it into the SYN/ACK. This will create the metadata handshake for the SSH session. All forward and reverse 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 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's a new 5-Tuple packet (new flow) with the just the SYN flag set. For UDP, it's simply a new 5-Tuple packet not currently in active use.¶

      Packet received on LAN side East Router [1]
      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)   |
      +---------+---------------------+--------------+----------+

          SERVICE: github
            Tenants Allowed: engineering
            Tenants Denied: release.engineering
            Quality: latency < 40ms
            Payload Encryption:Not Required

State Information & Mappings to Metadata Fields

              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                 ABCDEFGHIJKLMNOP    6    16    4
               Source Router Name   East Router        14    11    4
               Source NAT Address   172.15.0.1         25     4    4
               Security Policy      NONE               15     4    4
               Peer Path                               19    22    4
               - Source Addr        172.15.0.1
               - Dest Addr          172.15.10.1
                                                            ---  ---
                         Total Payload Length = 119 (87+32)  87   32

                                 To West     Fr West
              Allocated Ports     Router      Router
               -Source Port        8000        8001
               -Dest Port          8001        8000

      +--------------+--------------+---------+----------------+
      | Metadata     | Metadata     |Padding  | Initialization |
      | Header )     | Payload TLVs |         |    Vector      |
      | (Unecrypted) | Payload TLVs |         |    Vector      |
      |  34 Bytes    | 119 Bytes    | 9 Bytes |  16 Bytes      |
      +--------------+--------------+---------+----------------+
      |<---Clear---->|<---Encrypted Portion-->|

      |<----------------178 Byte Metadata Block--------------->|

      Packet with metadata inserted
      +---------------------+--------------+----------+-----------+
      | IP Header           | TCP Header   |Metadata  |  PAYLOAD  |
      |    SRC=10.0.1.1     |   Sport=6969 |Block     |    Data   |
      |    DST=172.15.11.23 |   Dport=22   |178 Bytes | (optional)|
      +---------------------+--------------+----------+-----------+

      Final Transformed Packet with metadata inserted
      +---------------------+--------------+----------+-----------+
      | IP Header           | TCP Header   |Metadata  |  PAYLOAD  |
      |    SRC=172.15.0.1   |   Sport=8000 |Block     |    Data   |
      |    DST=172.15.10.1  |   Dport=8001 |178 Bytes | (optional)|
      +---------------------+--------------+----------+-----------+

    Packet with metadata inserted
    +-------------------+--------------+----------+---------+-----+
    |IP Header          | TCP Header   |Encrypted | PAYLOAD | HMAC|
    |  SRC=172.15.0.1   |   Sport=8000 | metadata |   Data  | 16  |
    |  DST=172.15.10.1  |   Dport=8001 |          |         |Bytes|
    +-------------------+--------------+----------+---------+-----+
                        |                                   |
                        |<=========HMAC Signed Data========>|

        Client ---->    TCP SYN w/Metadata  ----> Server
        Server <---- TCP SYN-ACK w/Metadata <---- Server

            172.15.0.1       MPLS Peer Pathway
            107.0.8.186      Internet Peer Pathway
            169.254.231.106  LTE Peer Pathway

          Reverse Metadata Response
State Information & Mappings to Metadata Fields

              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     172.15.0.1
               - Dest IP Addr       172.15.11.23
               - Protocol           TCP
               - Source Port        7891
               - Dest Port          6969
               Peer Path                               19    22    4
               - Source Addr        172.15.10.1
               - Dest Addr          172.15.0.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

        Client . . . . . . . . . . . . . . . . . . . . . . Server
          |                                                   |
          +         RouterA       RouterB      RouterC        |
          |            |             |            |           |
          +---SYN----->|             |            |           |
          |            |--SYN[MD1]-->|            |           |
          |            |             |--SYN[MD2]->|           |
          |            |             |            |--SYN----->|
          |            |             |            |           |
          |            |             |            |<--SYN/ACK-|
          |            |             |<--SYN/ACK--|           |
          |            |<--SYN/ACK---|   [RMD2]   |           |
          |<--SYN/ACK--|    [RMD1]   |            |           |
          |            |             |            |           |
          |            |             |            |           |
          |<===== Session Packets Flow with No Metadata =====>|

        Client . . . . . . . . . . . . . . . . . . . . . . Server
          |                                                   |
          +         RouterA       RouterB      RouterC        |
          |            |             |            |           |
          +---FIN----->|             |            |           |
          |            |-----FIN---->|            |           |
          |            |             |----FIN---->|           |
          |            |             |            |-----FIN-->|
          |            |             |            |           |
          |            |             |            |<--FIN/ACK-|
          |            |             |<--FIN/ACK--|           |
          |            |<--FIN/ACK---|            |           |
          |<--FIN/ACK--|             |            |           |
          |            |             |            |           |
          |            |             |            |           |

4.1. SVR Session Definitions and Types

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) 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.¶

4.2. SVR Metadata Insertion

   Existing IP Packet with metadata inserted
   +------------------+-----------------+---------+----------+----+
   | Existing IP Hdr  | Existing L4 Hdr |Metadata | PAYLOAD  |HMAC|
   |   Source IP Addr |   Source Port   |Block    |   Data   |    |
   |   Dest IP Addr   |   Dest Port     |         |(optional)|    |
   +------------------+-----------------+---------+----------+----+

   GeneratedIP Packet with metadata inserted
   +-------------------+------------------+---------+----+
   | Created  IP Hdr   | Created L4 Hdr   |Metadata |HMAC|
   |   Source IP Addr  |   Source Port    |Block    |    |
   |   Dest IP Addr    |   Dest Port      |         |    |
   +-------------------+------------------+---------+----+

   ICMP Packet with metadata inserted
   +-----------------+----------------+----------+--------+----+
   | Created IP Hdr  |Created UDP Hdr |Metadata  |  ICMP  |HMAC|
   |   Source IP Addr|   Source Port  |Block     |  MSG   |    |
   |   Dest IP Addr  |   Dest Port    |          |        |    |
   +-----------------+----------------+----------+--------+----+

   Ethernet Packet with metadata inserted
   +-----------------+----------------+---------+---------+----+
   | Created IP Hdr  |Created UDP Hdr |Metadata | Ethernet|HMAC|
   |   Source IP Addr|   Source Port  |Block    | MSG     |    |
   |   Dest IP Addr  |   Dest Port    |         |         |    |
   +-----------------+----------------+---------+---------+----+

   Received Midstream SVR Packet matching SVR Magic Number
   +-------+--------+-------------------------+
   |IP Hdr | L4 Hdr |0x4c48dbc6ddf6670c ..... |
   +-------+--------+-------------------------+

   Midstream SVR Packet with False Positive metadata inserted
   +--------+--------+--------+---------------------------+
   | IP Hdr | L4 Hdr |Metadata| 0x4c48dbc6ddf6670c ...... |
   |        |        |  HDR   |                           |
   +--------+--------+--------+---------------------------+

4.3. Required and Optional TLVs

4.4. Metadata Encryption

Encryption of metadata utilizes block mode ciphers. Cipher's MUST have a consistent block size. The cipher to use and its block size MUST be provisioned and communicated to peers in advance. The provisioning methodology is outside the scope of this document. The keys, and key rotation are also outside the scope of this document. When data is encrypted with block mode ciphers, the block will be padded with zeros (0x0's) to equal an increment of the block size used by the cipher. An initialization vector allows the decryption to be performed without any state.¶

Metadata Block¶

          Cipher      Block Size        IV Size
         -------   -----------------     -------
          AES256   128 Bits(16 Bytes)    16 Bytes
          AES128   128 Bits(16 Bytes)    16 Bytes

      +----------+--------+---------+--------+----------------+
      | Metadata | Header | Payload |Padding | Initialization |
      | Header   | TLVs   | TLVs    |        |    Vector      |
      +----------+--------+---------+--------+----------------+
      |<------Clear------>|<-- Encrypted --->|

      |<---------------------- Metadata Block ---------------->|

The padding can be computed as the length of the metadata payload TLVs MOD block size.¶

4.5. SVR Packet Authentication

    SVR Packet with metadata inserted
    +-----------+--------------+---------+----------+-------+
    |IP Header  |  L4 Header   |Metadata | PAYLOAD  | HMAC  |
    |           |              |         |(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

    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)|
    +-----------+--------------+----------+

4.6. Processing SVR Packets with Potential Metadata

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 metadata or be packets associated with existing SVR sessions..¶

        Known in advice: Cipher, Block Size, IV size
        From Metadata Header: Payload TLV size

   +----------+--------+-------+-------+----------------+--~~~
   | Metadata | Header |Payload|Padding| Initialization | Rest...
   | Header   | TLVs   |TLVs   |       |    Vector (IV) | of  ...
   |          |        |       |       |                | Pkt ...
   +----------+--------+-------+-------+----------------+--~~~
   |<------Clear------>|<- Encrypted ->|

   |<------------------ Metadata Block ---------------->|

            svc_name
                protocol:TCP/UDP
                port ranges[]
                CIDR Blocks[]

5.1. Moving a Session

To change the pathway of a session between two routers, any SVR Router simply reinserts the metadata described in section Section 3.6.1.7 and transmits the packet on a different peer path, but retains the same Session UUID of the existing session that is being moved.¶

• Update its fast path forwarding tables to reflect the new IP addresses and ports (waypoints) for transport. All other aspects of the session remains the same. The presence of middle boxes means that routers on both sides must once again perform NATP detection and update real transmit addresses/ports to ensure that sessions will continue.¶

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 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 Metadata =====>|

When router C fails, 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 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 Metadata:¶

                 +-------+              +--------+
                 |       +-----MPLS-----+        |
         Client--| Rtr-A |              | Rtr-B  +----Server
                 |       +------LTE-----+        |
                 +-------+              +--------+

        Client . . . . . . . . . . . . . . . . . . . . . . Server
          |                                                   |
          |         RouterA                    RouterC        |
          |            |                          |           |
          |---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 Metadata =====>|

The diagram shows moving an active TCP session from one transport network to another by injecting metadata [MD] into any packet that is part of the transport in either direction. Reverse metadata is sent on any packet going in the reverse direction to confirm that the move was successful [RMD].¶

5.2. NAT Keep Alive

If an SVR Router determines there is one or more NATs on a peer pathway (See Section 2.4, the SVR Peer must maintain the NAT bindings for each active session by sending keep alive 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 metadata type 24 with the drop reason set to Keep Alive.¶

Ladder Diagram for NAT Keep Alive with 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 metadata attributes that MUST be inserted in a keep alive for existing packet sessions includes:¶

• Header: SVR Control Message: see Section 6.3.6.¶

Because there are only header attributes, encryption is not required.¶

5.3. Adaptive Encryption

Unlike a tunnel where all packets must be encrypted, each session in SVR is unique and independent. Most of the modern applications 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 in 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.¶

5.4. Packet Fragmentation

When a fragmented packet is presented to a SVR Router, the packet must be completely assembled to be processed. The SVR Router routes IP packets, and as all SVR actions require the entire packet. 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 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 Metadata header and header TLV's are not encrypted. The packet construction looks like this:¶

SVR Fragment Packet Layout¶

     Fragment 1
    +-----+-----+----------+----------+---------+
    |Peer |Peer | Metadata | Header   | First   |
    |IP   |L4   | Header   | TLV-1,16 | Fragment|
    |HDR  |HDR  | 12 Bytes | 22 Bytes |         |
    +-----+-----+----------+----------+---------+

     Fragment 2
    +-----+-----+----------+----------+---------+
    |Peer |Peer | Metadata | Header   | Second  |
    |IP   |L4   | Header   | TLV-1    | Fragment|
    |HDR  |HDR  | 12 Bytes | 14 Bytes |         |
    +-----+-----+----------+----------+---------+

     Fragment 3
    +-----+-----+----------+----------+---------+----------+
    |Peer |Peer | Metadata | Header   | Third   | PKT      |
    |IP   |L4   | Header   | TLV-1    | Fragment| HMAC     |
    |HDR  |HDR  | 12 Bytes | 14 Bytes |         | SIGNATURE|
    +-----+-----+----------+----------+---------+----------+

The metadata type 1 inside the SVR fragment will have its own extended ID assigned. This allows a different number of fragments to be 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 RouterA and transmitted in Metadata to determine the proper size fragments to send, and the packet is fragmented and sent.¶

There are no other 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 standardly performed in IP fragmentation, exception for the full L4 headers and 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 metadata, the initiating router inserts metadata on the first packet and duplicates the L4 header (either TCP or UDP) on subsequent fragments and inserts metadata. In this case the Largest Fragment Seen and Original ID field in the metadata is left blank.¶

Ladder Diagram Fragmented Packets:¶

        Client . . . . . . . . . . . . . . . . . . . . . . Server
          |                                                   |
          |         RouterA                    RouterB        |
          |            |                          |           |
          |--Lg Pkt--->|                          |           |
          |            |--------Frag 1[MD]------->|           |
          |            |                          |           |
          |            |----Frag 2[L4 Hdr|MD]---->|           |
          |            |                          |--Lg Pkt-->|
          |            |                          |           |

5.5. ICMP and SVR

There are two types of ICMP messages. There are messages associated with specific packet delivery network errors. This includes:¶

• Type 3: Destination Unreachable¶
• Type 11: Time Exceeded (TTL)¶

These messages have information from the packet that generated the error by including the IP header + 8 bytes 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 metadata is applied by having its destination address changed to the waypoint addresses of the routers.¶

Metadata type 20 and 21 are used to send the source of the ICMP error backward through the networks. See Section 6.3.4 and Section 6.3.5 for information about these 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 metadata type 20 and 21.¶

SVR Fragment Packet Layout¶

    +------------+------------+----------------+--------------+
    |  IP HEADER | UDP HEADER | Metadata 20/21 | ICMP Packet  |
    +------------+------------+----------------+--------------+

ICMP over SVR for Network Failures¶

    Client . . . . . . . . . . . . . . . . . . . . . . .No Network
      |                                                  Found
      |         RouterA                    RouterB          |
      |            |                          |             |
      |----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 find the session, and forwards backwards to the correct waypoint for Router A. Router A recreates the ICMP message, and sends to the Client. The address of where the error was detected is in¶

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:¶

• Type 8:ECHO Request (Ping)¶

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. Metadata [MD1] is inserted just like any UDP session to establish the return pathway for the response. Reverse metadata is inserted into the ECHO Response, effectively creating an ICMP session. Subsequent identical ICMP messages will utilize this path without metadata being inserted. This session state MUST be guarded with an inactivity timer and the state deleted.¶

6.1. Metadata Header

The metadata header is shown below. A well-known "cookie" (0x4c48dbc6ddf6670c in network byte order byte order) is built into the header which is used in concert with contextual awareness of the packet itself to determine the presence of metadata within a packet. This is an eight-byte pattern that immediately follows the L4 header and is an indicator to a receiving router that a packet contains metadata. NOTE: Normal IP traffic will never have the Waypoint Address as its destination. If a packet arrives at a SVR Router Waypoint it has to have Metadata or be associated with an active SVR session. Please see Section 2.10 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 ...        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cookie (8 bytes):

The fingerprint of metadata. This value is used to determine the existence of metadata within a packet.¶

Version (4 bits):

Field representing the version of the metadata header. The current version of metadata is 0x1.¶

Header Length (12 bits):

Length of the metadata header including any added Header TLV attributes that are guaranteed to be unencrypted. When there are no Header TLVs, the value Header Length is 12 Bytes or OxC.¶

Payload Length (2 bytes):

Length of data following the metadata header, not including the size of the header. This data could be encrypted. The value of this field is the number of bytes in the Payload TLV's. If there are no TLV's the value is zero.¶

6.2. TLVs for Attributes

All metadata attributes are expressed as Tag Length Values or TLV's. 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 TLV's, they can be transmitted in clear text. The entire 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 metadata. Doing so will invalidate the signature, and the 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 .....                         |
  \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Type (2 bytes):

Type of data that follows. Each of different Header and Payload TLV's are defined below.¶

Length (2 bytes):

Number of bytes associated with the length of the value (not including the 4 bytes associated with the type and length fields).¶

6.3. Header Attributes

   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      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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                         +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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  |
  +-+-+-+-+-+-+-+-+

   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   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.4. Payload Attributes

Payload attributes are used for session establishment and SHOULD be encrypted to provide privacy. Encryption can be disabled for debugging.¶

   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    |
  +-+-+-+-+-+-+-+-+

   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    |
  +-+-+-+-+-+-+-+-+

   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    |
  +-+-+-+-+-+-+-+-+

   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    |
  +-+-+-+-+-+-+-+-+

   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                             +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 bytes) ....                       |
  \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

   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 bytes) .....               |
  \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

   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          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 bytes) ....                    |
  \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

   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       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        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 = 19          |       Length = variable       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Peer Pathway Name (1-n bytes) ....                 |
  \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

   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                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.1. HMAC Authentication

HMAC signatures are REQUIRED for the packets that contain 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.¶

7.2. Replay Prevention

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 2.10. 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.¶

7.3. Payload Encryption

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 bytes will be all 0s. If the actual payload is not divisible by 16, then the remaining data will be padded and the last byte will indicate the length.¶

7.4. DDoS and Unexpected Traffic on Waypoint Addresses

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 metadata OR be part of an existing established routing protocol.¶

Routers will only accept 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 metadata header is reviewed first. If the cookie isn't correct, the packet is dropped.¶

The HMAC signature is checked. If the signature validates, 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.¶