Added additional clarity for tcp-state-enforcement

docs/bcp_service_and_service_policy_design.md

@@ -620,7 +620,16 @@ The MOS value for a given path is a composite metric, computed based on loss, la
 
 ### Transport State Enforcement
 
-Within the service-policy configuration is the [transport-state-enforcement](config_reference_guide.md#service-policy) parameter, which governs the behavior of the SSR's TCP state machine for processing inbound TCP packets. As a stateful networking device, the SSR's default behavior is to reject any mid-flow TCP packets (i.e., packets without the SYN flag set) unless it – or its paired node in a dual node HA router – participated in the TCP three-way handshake for that session. There are deployments where this behavior may be undesirable. 
+Within the service-policy configuration is the [transport-state-enforcement](config_reference_guide.md#service-policy) parameter, which governs the behavior of the SSR's TCP state machine for processing inbound TCP packets. As a stateful networking device, the SSR's default behavior is to reject any mid-flow TCP packets (i.e., packets without the SYN flag set) unless it – or its paired node in a dual node HA router – participated in the TCP three-way handshake for that session. There are deployments where this behavior may be undesirable.
+
+The four available values provide escalating levels of enforcement:
+
+| Value | Behavior |
+| --- | --- |
+| `allow` | Permits non-SYN first packets and packets that do not conform to the TCP state machine. Use in environments such as [dual-router HA](config_dual_router_ha.md) deployments where mid-flow packets may arrive from a router that did not participate in the original three-way handshake. |
+| `block` | Silently discards non-SYN first packets and packets that do not conform to the TCP state machine. The sender receives no notification. |
+| `reset` *(default)* | Sends a TCP RST to the sender for non-SYN first packets; drops packets that do not conform to the TCP state machine. |
+| `strict` | Provides the highest level of enforcement. Sends a TCP RST for non-SYN first packets, drops packets that do not conform to the TCP state machine, and additionally drops any packets whose sequence numbers fall outside the expected receive window. Recommended for security-sensitive deployments and required for Common Criteria compliance. Introduced in SSR 6.2. |
 
 For example, when an environment includes systems that are deployed in a [*dual router HA*](config_dual_router_ha.md) configuration, any services used to send traffic to or from the dual router HA must reference a service-policy that has `transport-state-enforcement` set to `allow`.
 

docs/config_reference_guide.md

@@ -2488,7 +2488,7 @@ These are policy parameters that may be applied to service traffic to affect its
 | required-qp | uint32 | The required number of Quality Points for this service. Interfaces not meeting this threshold are not considered as valid next hops. |
 | service-class | reference | A reference to a configured service-class. |
 | session-resiliency | enumeration | Valid values: none, failover, revertible-failover, packet-duplication. Default: none. This governs how the SSR provides resilience for sessions in the event of network issues that would cause it to choose a new path for active traffic processing. The default "none" will take no action in the event of failure. The value "failover" will cause the SSR to seek another path for traffic when a failure is detected. The value "revertible-failover" will seek another path, but return to the previous path when the disruption is deemed to be restored. The value "packet-duplication" causes the SSR to generate two sets of packets and sends them on multiple, distinct paths to the destination -- where the recipient SSR filters the duplicates out prior to forwarding the traffic. |
-| transport-state-enforcement | enumeration | Valid values: allow, block, reset. Default: reset. This governs the behavior of a router's TCP state machine when receiving unexpected packets. When set to 'reset', if a router receives a TCP packet that does not match any session-in progress and the SYN flag is not set, or it receives a packet that does match a session in progress but it does not conform to the router's TCP state machine (e.g., the sequence number is outside the expected window), the router will send a RST back to the sender. Setting this field to 'allow' causes the router to pass non-SYN first packets and non-conforming packets (per the TCP state machine's expectations). The 'block' setting causes the router to silently discard non-SYN first packets and non-conformant packets (again, per the state machine). |
+| transport-state-enforcement | enumeration | Valid values: allow, block, reset, strict. Default: reset. Controls the behavior of the SSR's TCP state machine when receiving unexpected or non-conforming TCP packets. Unexpected packets can indicate TCP Reset attacks or session hijacking attempts. The four values provide escalating levels of enforcement: **`allow`** — Permits non-SYN first packets and packets that do not conform to the TCP state machine. Intended for environments such as dual-router HA deployments where mid-flow packets may arrive from a router that did not participate in the original three-way handshake. **`block`** — Silently discards (without notifying the sender) non-SYN first packets and packets that do not conform to the TCP state machine. **`reset`** *(default)* — Sends a TCP RST to the sender for non-SYN first packets; drops packets that do not conform to the TCP state machine. **`strict`** — Provides the highest level of TCP enforcement. Sends a TCP RST for non-SYN first packets, drops packets that do not conform to the TCP state machine, and additionally drops any packets whose sequence numbers fall outside the expected receive window. This enforces strict sequence number checking, preventing TCP injection and out-of-window reset attacks. Recommended for security-sensitive deployments and required for Common Criteria compliance. |
 | vector | sub-element | The vector sub-element is where administrators assign costs to vector labels (which are associated with neighborhoods on egress interfaces), to assist in choosing the most appropriate path for traffic that references this service-policy. Each service-policy can independently assign costs to these vector variables, and therefore the same topology of SSRs can route distinct service traffic uniquely. |
 
 #### Version History:
@@ -2499,6 +2499,7 @@ These are policy parameters that may be applied to service traffic to affect its
 | 3.0.0 | Added *session-resiliency* | 
 | 3.1.0 | Added *min-mos* |
 | 3.2.0 | Added *vector* |
+| 6.2.0 | Added `strict` value for *transport-state-enforcement* |
 
 ## service-route