Alright, last week I introduced SVR and discussed the benefits of SVR compared to Tunnel-based Protocols. This week I’m here to tell you how this whole operation works. This is the SVR Packet Walkthrough Feature Friday!
Detecting a new Session
The process starts when a client sends traffic to a server. For example, a user tries to access Outlook. If the client needs to access the server that is on the WAN, then it will need to send traffic to a router, in our case, that will be the Session Smart Router (SSR).
When the Session Smart Router sees the first packet of the session, it does a little inspection to determine:
- Have we seen this session before?
- Is this client allowed to access the server?
The SSR determines if it has seen the session before by looking at the 7-tuple:
- Source Address
- Source Port
- Destination Address
- Destination Port
- Transport Protocol
- VLAN
- Ingress Network Interface
The SSR does this look up to determine if it already knows the path to send the session, or if it needs to do further processing. If the SSR cannot tell if it has already seen the session, it will need to determine if the client is allowed to access the server. Here’s where Services and Tenants come in.
Services and Tenants
The Service represents the destination of your network traffic. The Tenant represents an Access Group on your network.
The SSR wants to determine which Tenant this session is coming from and it does that in one of four ways.
- From another SSR – through SVR. Remember, the Tenant is information that is included in the metadata.
- From the network-interface – this basically means per VLAN since you can have multiple network-interfaces per device-interface (physical interface), they just get separated by VLAN.
- By source sub-net – this involves adding a neighborhood to your LAN interface and then saying “if traffic comes from X.X.X.X/X, then it belongs to tenant X”
- Global tenant – this is the tenant that is assigned when there is no tenant assigned through the other means
Every session can only belong to one Tenant, so this is the order of precedence (if it gets a Tenant from one of the ways higher in the list, then it won’t look at the lower ones).
Once a Tenant is assigned, the SSR will do a look up in the FIB to determine if the client can access the server. The FIB table shows:
- Destination Address/Subnet
- Destination Port
- Transport Protocol
- Tenant
Service and Next-Hop
If there is a successful match, the SSR will return a Service and Next-Hop. The Service will have a Service Policy, which will tell us how we want to route (i.e., path preference by vector (cost), dynamic path selection based on SLA, load-balancing, etc.) and if we want to do any Traffic Engineering (Service Class). It basically tells us how we want to treat traffic headed to that application/Service.
The Next-Hop tells us where we are sending the traffic. This could be to another SSR (which is when we do SVR) or to a gateway or host.
Ok, let’s say the FIB lookup is a successful match and we are going to send traffic to another SSR. As I mentioned a sentence ago, it’s time to do Secure Vector Routing!
Metadata
The SSR will now take the information from the FIB table, encrypt and hash it using the Security Policy you assigned to the Service, and then add that to the front of the payload. This is the metadata. The metadata is only included in the beginning of a Session (for example, TCP SYN and SYNACK). Once there is acknowledgement from the receiving SSR, then there is no more metadata added to the following packets unless there is a need (for example, a path change).
The original source and destination addresses and ports are then replaced with the sending and receiving network-interface addresses and a port from the range of 16385-65533. This is what we call waypoints and wayports. You can learn more about those here. This is how the SSR performs NAT for SVR.
Receiving Packets
With all of this done, the SSR is ready to send the packet to the receiving SSR. When the receiving SSR receives the packet, it will do the exact same steps. If there are more SSRs along the path, then it will send it to those as SVR, if there are not, then it will restore the original information and send the packet to its destination. At this point, you could do some additional Source and Destination NAT if you like. We’ll go over how to do that in a future post.
When the server responds to the client, the response will take the same path back that the request came from. At this point, the session will be added to the Session Table and metadata will only be included in the first response (just to confirm “hey, I got your metadata”).
After that, every other message that comes out for that session will take the same path as the original request and not need to go through the same FIB lookup and metadata addition. We call this the Fast Lane.
Summary (TL: DR)
So, to sum it up, Session Smart Routers use Secure Vector Routing to securely route packets without the downfalls of tunnels. How it works:
- The Session Smart Router inspects the first packet of a session
- If it is not familiar with the session, then it determines the source of the session (Tenant)
- The SSR then looks at the FIB table to determine if the client has access to its destination
- If it has access, then the SSR will return a Service and Next-Hop and apply service and security policies
- Next, the SSR will package this information (metadata), and assign it only to the first packet in the session
- Finally, the last receiving SSR will restore the original information and send the packet to its destination
So yea, that’s Secure Vector Routing in a nutshell. Thanks for sticking with me, I know that was a long read! However, I want to discuss features that take SVR to the next level like BGP Over SVR and Ethernet Over SVR in future, so I figured let's all build that SVR foundation with this and the previous post.
As usual, we have some great additional resources for you to check out:
And we’d love to hear from you:
- Have you notices improved performance or bandwidth cost savings with SVR?
- Do you have other question on how SVR works?
- I'm still waiting on those firework suggestions...
Thanks again for reading! I am looking forward to speaking with you soon!
#FeatureFridays #SVR #SecureVectorRouting #service #tenant #metadata #tunnels
------------------------------
Justin Melloni
------------------------------