Security Policies
The Session Smart Router - or SSR, should have been called the SSSR for Secure Session Smart Router, but folks in tech love TLAs. By design, the SSR will only forward packets to a destination upon creation of a policy. Once a routed path exists within the network, it is important to ensure that the payload is encrypted to keep data safe. Even though more and more traffic is being natively encrypted, there is still content that is sent over untrusted networks without encryption, or without the additional layers of encryption necessary to thwart bad actors. The SSR offers a policy-driven approach to defining the level of encryption needed per service and per path.
While there are many aspects to security, the focus of this document is the security of payload and metadata encryption between SSRs.
Metadata is encrypted and decrypted between SSR routers, but payload encryption is performed end-to-end. This is illustrated in a multi-hop router deployment by the image below.
HMAC
HMAC signatures, appended to the end of a packet's payload, guarantee the contents of each packet have not been changed, and that the peering router is known and trusted by the receiver. While possible, it is not recommended to disable HMAC between SSRs, as it will prevent middle-man attempts to corrupt or impact active sessions.
Timed Based HMAC signatures can be used to protect SVR pathways against replay attacks. Upon initiation of every session, a Session HMAC Key is created. The Session HMAC Keys persist for the life of a session and deployments not change. Time-based HMAC signatures change at a specified interval.
Payload Encryption
The SSR uses industry hardened AES encryption ciphers that rely on the use of an encryption key and an initialization vector (IV). The IV is used to "prime the session" as a unique IV is generated per packet, allowing encryption to be stateless. When creating a new security policy within the SSR, the SSR will automatically generate random values for the key and IV and store them securely within the device. It is not recommended to manually supply values for these attributes as this may compromise the security of the network.
There are four locations where security policies can be defined:
- The security policy defined in the
service > security-policyserves to encrypt and decrypt the payload of packets within a session. The encryption keys and algorithms defined at the service are always symmetric between SSR nodes. - A security policy can be defined in
network-interface > inter-router-security. This security policy defines how metadata are decrypted for SVR traffic received on the respective interface. - A security policy can be defined on
network-interface > adjacency > inter-router-security. The security policy associated with the adjacency defines what keys and encryption algorithms are used for encrypting metadata (and hmac signing packets) sent to an SVR peer. - A security policy can be defined in
router > inter-node-security. This security policy defines the encryption of metadata (and hmac signing packets) for HA interfaces used for inter-node communication.
Best Practices
The SSR affords you the ability to provision a unique security policy per service. However, in a typical hub-and-spoke topology, a single security policy can be shared among all services, with a separate security policy used for metadata encryption and authentication.
HA interfaces between SSR nodes are directly connected between nodes and therefore pose no risk of interception. Given the additional computational cost of encrypting and decrypting traffic, it is recommended to apply a security policy to inter-node-security with encryption and hmac disabled for this purpose.
Example:
security encrypt-hmac-disabled
name encrypt-hmac-disabled
description "Encryption and message authentication disabled"
hmac-cipher sha256
hmac-key (removed)
encryption-cipher aes-cbc-128
encryption-key (removed)
encryption-iv (removed)
encrypt false
hmac-mode disabled
adaptive-encryption false
exit
Changing a Security Policy
Changing a security policy is a service impacting event as it is not possible to alter security keys and encryption ciphers for existing flows. Care must be taken to understand the blast radius of these changes. It goes without saying, you must understand the security policy that needs to change and how it is being used for services and peer paths. If altering the global security policy that is used for all services, all traffic will be impacted. Changing a security policy should always be performed during a maintenance window after fully understanding the overall impact to the environment. Due to the fact that sessions are not terminated on security policy change, the best course of action is to reboot all the routers where traffic flows through the SSR with a security policy change has been made.
The best approach to making any change to a security policy is to create a new policy, with a new name, and apply it to the respective service, interface, or adjacency. This affords network administrators the ability to readily identify sessions that may not have adopted the new policy. After applying the change, be sure to restart the SSR on any routers that share the same security policy to clear any active sessions. After the SSR has restarted, ensure that traffic is traversing the service as expected:
admin@node0.0200017bb97d# show service contains-service-name any
Wed 2023-11-15 17:25:55 UTC
✔ Retrieving service information...
========= =========== =========== ================ ================ ======= ========== ============== ==============
Service Prefixes Transport Tenant Allowed Service-Policy State Sessions Tx Bandwidth Rx Bandwidth
========= =========== =========== ================ ================ ======= ========== ============== ==============
any 0.0.0.0/0 - trusted-lan any-sp Up 119 23.56 kbps 23.59 kbps
Completed in 0.12 seconds
Identify that sessions are traversing the service.
shadmin@node0.0200017bb97d# show sessions service-name any
Wed 2023-11-15 17:27:06 UTC
Node: node0.0200017bb97d Page 1
====================================== ===== ========= ============= ========== ============ ====== ======= =============== ========== =============== =========== =============== =========== =========== ========= ================
Session Id Dir Service Tenant Dev Name Intf Name VLAN Proto Src IP Src Port Dest IP Dest Port NAT IP NAT Port Payload Timeout Uptime
Encrypted
====================================== ===== ========= ============= ========== ============ ====== ======= =============== ========== =============== =========== =============== =========== =========== ========= ================
48e2d02a-cd65-43b7-b3f5-621c91525426 fwd any trusted-lan ge-0-1 ge-0-1_400 400 TCP 172.16.1.11.2 62360 162.159.6.1.3 443 192.168.0.247 37993 False 677 0 days 0:21:11
48e2d02a-cd65-43b7-b3f5-621c91525426 rev any trusted-lan ge-0-0 ge-0-0 0 TCP 162.159.61.3 443 192.168.0.247 37993 0.0.0.0 0 False 1078 0 days 0:21:11
1fa9a14d-b216-4c4f-93da-efdaef25d61c fwd any trusted-lan ge-0-1 ge-0-1_400 400 TCP 172.16.1.11.2 62403 140.82.11.2.25 443 192.168.0.247 38028 False 670 0 days 0:20:30
1fa9a14d-b216-4c4f-93da-efdaef25d61c rev any trusted-lan ge-0-0 ge-0-0 0 TCP 140.82.112.25 443 192.168.0.247 38028 0.0.0.0 0 False 790 0 days 0:20:30
Sample some of the newly created sessions and confirm that the new security policy is in effect by examining the output of show sessions by-id.
Note the output of:
Forward Flows > Metadata Security Policy: This comes from the configuration of network-interface > adjacency > inter-router-security, which is the metadata encryption policy.
Payload Security Policy: This comes from the configuration service > security-policy, which is the payload encryption policy.
Reverse Flows > Decrypt Security Policy: This comes from the configuration network-interface > inter-router-security, which is the metadata decryption policy.
admin@conductor.site1# show sessions by-id router west-dc-router 30da8df9-2f91-42a2-b54c-cc66e5651714
Thu 2023-11-09 22:20:42 UTC
Retrieving session information...
===============================================================================================================================================================================================================================
west-dc-router.west-dc-01 Session ID: 30da8df9-2f91-42a2-b54c-cc66e5651714
===============================================================================================================================================================================================================================
Service Name: local-subnets
Service Route Name: N/A
Session Source: SourceType: INTER_NODE
Payload Security Policy: service-sec
Payload Encrypted: True
Forward Flows:
Decrypt Security Policy: encrypt-hmac-disabled
Attributes:
Metadata Security Policy: peer-sec
Reverse Flows:
Decrypt Security Policy: peer-sec
Attributes:
Metadata Security Policy: encrypt-hmac-disabled
========================================================================================================================================================
west-dc-router.west-dc-02 Session ID: 30da8df9-2f91-42a2-b54c-cc66e5651714
===================================================================================================================================================================================================
Service Name: local-subnets
Session Source: SourceType: PUBLIC
Inter Node: True
Payload Security Policy: service-sec
Payload Encrypted: True
Forward Flows:
Decrypt Security Policy: <empty>
Attributes:
Metadata Security Policy: encrypt-hmac-disabled
Reverse Flows:
Decrypt Security Policy: encrypt-hmac-disabled
Attributes:
Metadata Security Policy: <empty>
AES-GCM Encryption
AES-GCM encryption is available in SSR version 7.2.0 and above.
Overview
The SSR supports AES-GCM (Advanced Encryption Standard – Galois/Counter Mode) as an additional encryption option for session traffic. AES-GCM is an Authenticated Encryption with Associated Data (AEAD) cipher, meaning it provides both confidentiality and integrity protection in a single cryptographic operation, rather than combining a separate cipher and HMAC as with AES-CBC modes.
AES-GCM is applied per-packet after SSR session encapsulation. Both SSR metadata and session payload are independently protected, and authentication failures cause the packet to be silently discarded. No changes to routing, session establishment, or service policy behavior are introduced by enabling AES-GCM.
Behavior And Compatibility
| Property | Behavior |
|---|---|
| Confidentiality | Per-packet encryption of SSR metadata and payload. |
| Integrity | Authenticated; authentication failure causes immediate packet discard. |
| HMAC settings | Ignored when AES-GCM is selected — authentication is inherent to GCM. |
| Peer compatibility | If the remote peer does not support AES-GCM, the session falls back to the mutually supported cipher according to existing SSR negotiation behavior. |
| Mixed-version fabrics | Supported, provided peers negotiate a mutually supported cipher. |
| Platform requirement | Requires OpenSSL with GCM capability; supported on existing SSR hardware platforms. |
Configuring AES-GCM
AES-GCM is selected by setting the encryption-cipher field of a security policy to the appropriate AES-GCM value, either aes-gcm-128 or aes-gcm-256. The security policy is then applied in the same locations as any other cipher:
service > security-policy— payload encryption for sessionsnetwork-interface > inter-router-security— metadata decryption on received SVR trafficnetwork-interface > adjacency > inter-router-security— metadata encryption for SVR traffic sent to a peerrouter > inter-node-security— encryption for HA inter-node communication
configure authority security <policy-name>
encryption-cipher aes-gcm-256
encrypt true
hmac-mode disabled
Because AES-GCM provides built-in authentication, hmac-mode should be set to disabled. Any HMAC configuration is ignored at runtime when AES-GCM is the selected cipher.
Changing an encryption cipher is a service-impacting event. Existing sessions cannot be re-keyed in-place. Follow the guidance in Changing A Security Policy and perform the change during a maintenance window.
Verifying AES-GCM Is In Use
After applying the new policy, use show sessions by-id to confirm the cipher is active on new sessions. The Payload Security Policy and Metadata Security Policy fields identify which security policy is applied per flow. The Action List fields include the GCM encryption and decryption actions: AesGcmEncrypt, AesGcmDecrypt, AesGcmEncryptSvr2, and AesGcmDecryptSvr2. Confirm that the policy you configured with AES-GCM is listed for the expected flows.
admin@test1.combo1# sho sessions by-id 37ed5241-d5d5-4120-b168-884c619935a4
Thu 2026-05-14 12:00:14 UTC
Retrieving session information...
============================================================================================================================================================================
combo1.test1 Session ID: 37ed5241-d5d5-4120-b168-884c619935a4
============================================================================================================================================================================
Service Name: east
Service Route Name:
Session Source: SourceType: INTER_ROUTER
Session Type: HTTPS
Service Class: Standard
Source Tenant: red
Destination Peer Name: N/A
Source Peer Name: combo2
Inter Node: N/A
Inter Router: N/A
Ingress Source Nat: N/A
Payload Security Policy: aes1
Payload Encrypted: True
Common Name Info: N/A
Tcp Time To Establish: N/A
Tls Time To Establish: N/A
Domain Name: N/A
Uri: N/A
Category: N/A
Override Service Name: N/A
App Stats Tracking Key: N/A
Session Keys:
Forward Session Key: [discriminator 4294967297, tenant red, peer combo2, src ip 172.16.2.201, dest ip 172.16.1.201, src port 443, dest port 10000, proto 17]
Reverse Session Key: [discriminator 4294967297, tenant red, peer combo2, src ip 172.16.1.201, dest ip 172.16.2.201, src port 10000, dest port 443, proto 17]
State Info:
Session State: ESTABLISHED
Redundancy State: SYNCED
Time Info:
Start Time: 0 days 0:00:12
Ttl Duration For Database: 1900
Forward Flows:
Key: [src ip 172.16.3.2, dest ip 172.16.3.1, src port 16384, dest port 16385, proto 17, interface 2.0]
Direction: forward
Tcp State: N/A
Packets Received: 999
Packets Sent: 999
Bytes Received: 152563
Bytes Sent: 123876
Tcp Retransmission Count: N/A
Decrypt Security Policy: interfabric
Action List: Ingress AesGcmDecryptMetadata ForwardMetadataRemove AesGcmDecrypt TtlValidateIpv4 IpHeaderTransform EthernetHeaderTransform AppForward
Time To Live: 1897
Path Index: 5
Attributes:
Path Key: NextHop : 1-1.0=172.16.1.201, destination Ip 172.16.1.0/24
Arp Status: Valid
Waypoint Key: <empty>
Source Nat Key: <empty>
Metadata Security Policy: <empty>
Reverse Flows:
Key: [src ip 172.16.1.201, dest ip 172.16.2.201, src port 10000, dest port 443, proto 17, interface 1.0]
Direction: reverse
Tcp State: N/A
Packets Received: 995
Packets Sent: 995
Bytes Received: 123380
Bytes Sent: 151464
Tcp Retransmission Count: N/A
Decrypt Security Policy: <empty>
Action List: Ingress TtlValidateIpv4 IpHeaderTransform AesGcmEncrypt AppMetadataAdd AesGcmEncryptMetadata EthernetHeaderTransform AppForward
Time To Live: 1897
Path Index: 5
Attributes:
Path Key: NextHop : 1-2.0=172.16.3.2, destination Ip 172.16.3.2/32
Arp Status: Valid
Waypoint Key: <empty>
Source Nat Key: <empty>
Metadata Security Policy: interfabric
App Identification:
Application: east
Domain Name: N/A
Uri: N/A
Category: N/A
Subcategory: N/A
Override Service Name: N/A
App Stats Tracking Key: N/A
Completed in 0.07 seconds