WFP ALE reauthorization: does a successful policy commit establish a barrier against previously authorized traffic?

Hello @Rayane ,

Thank you for the detailed and well scoped question. I checked the public WFP documentation (SDK and WDK) specifically for the synchronization point you describe. Below is what it does and does not establish.

The commit only guarantees that the policy is stored, not that existing flows are affected

The FwpmTransactionCommit0 reference only says the transaction "was committed successfully", and the Object Management topic describes ACID semantics for the BFE object store. Neither topic says anything about existing flows, about the kernel engine having finished applying the change, or about ordering between the commit return and subsequent classifications. So I cannot point you to any documentation that makes a successful return from FwpmTransactionCommit0 a barrier against traffic on already authorized ALE flows.

The only documented enforcement point for an existing flow is the reauthorization of its next packet

ALE Reauthorization states: "Once a policy change is detected, the first packet that traverses an ALE flow created at the affected layer will be specified for reauthorization to the layer." That classification carries FWP_CONDITION_FLAG_IS_REAUTHORIZE and, on Windows 7 and later, FWP_CONDITION_REAUTHORIZE_REASON_POLICY_CHANGE. TCP Packet Flows shows the failed case, where the segment goes to the ALE_AUTH_*_DISCARD layer, and notes that IPv6 follows the same pattern as IPv4, so everything here applies equally to ALE_AUTH_CONNECT_V4 and V6.

So the boundary is per flow and lazy. The phrase "once a policy change is detected" is the key one: the documentation does not state that kernel side detection completes before FwpmTransactionCommit0 returns to user mode, so I cannot tell you from the documentation that a packet classified in that interval will be reauthorized. To state it explicitly, since you asked for that: the public API does not expose a synchronization guarantee of this kind, and I did not find any API to wait for, or observe, that all existing flows have been re-evaluated against the new policy.

The race with a classification already in progress is not documented, except for the pended case

For a normal classification that returns permit after the commit, the documentation is silent. The one adjacent documented case is a pended ALE_AUTH_CONNECT classification: completing it with FwpsCompleteOperation0 triggers an immediate reauthorization, as described in Processing Classify Callouts Asynchronously.

The guarantee ends at the ALE classification point; queued data and offload are outside it

Reauthorization is a classification event at the ALE layer. Nothing in the documentation describes any effect on data already below that point: segments already through OUTBOUND_TRANSPORT / OUTBOUND_IPPACKET, NDIS or miniport queues, or hardware. The documentation confirms offload is outside inspection by design: FWPS_STREAM_ACTION_ALLOW_CONNECTION makes WFP attempt to offload the flow to the hardware such that no more inspection overhead is incurred. FWP_CONDITION_REAUTHORIZE_REASON_CHECK_OFFLOAD exists in the filtering condition flags list but has no descriptive text, so I cannot cite any behavior for it.

What you can observe is per flow and after the fact, and an active tear down requires a callout

• FwpmNetEventSubscribe classify drop events carry reauthReason (DROP2 on Windows 8 and later). They fire only when a packet actually arrives on the flow and is dropped; idle flows produce nothing.
• If you need to terminate flows at a moment you control, a callout can record FWPS_METADATA_FIELD_FLOW_HANDLE at ALE_AUTH_CONNECT / FLOW_ESTABLISHED and call FwpsFlowAbort0 on revocation (Windows 8 and later), or return FWPS_STREAM_ACTION_DROP_CONNECTION at the stream layer. Even then the documented guarantee is that the flow is aborted, not that bytes already handed to the NIC are not sent.

Everything above is what I can establish from the public documentation, and that is the limit of what I can provide on this Q&A forum. I do not have a channel to the WFP product group, so I cannot obtain, confirm, or relay a formal statement about the commit ordering, the in flight classification behavior, or the offload boundary, and I am not able to forward this question internally on your behalf. A support case is the channel where the product team can be engaged to give you an authoritative, version specific answer and, if warranted, update the documentation. You can open one through Windows developer support, or through Microsoft Support for business if you have a support contract. I would suggest including the exact wording of your question above, since it is already precisely scoped.

I hope this helps. If you have any further questions, please let me know. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.