Why does Windows Filtering Platform apply reauthorization for EVERY single incoming multicast UDP packet?

Question

I am using iperf network testing tool and observe the following: if, on box A (Windows Server 2019), I have a single sender that posts to some multicast address/port, and 5 multicast receivers, joining same multicast group, on box B (also Windows Server 2019), there will be packet loss at certain packet rate, which does NOT happen in case of single receiver, so it is NOT sender or wire level loss

Exploring with xperf (stackwalk with DPC details) shows that there is some relevant activity in ntoskrnl.exy, but in netio.sys, it points to tcpip.sys!WfpAleReauthorizeConnection , which is called from tcpip.sys!TlShimOptionalReauthorizeConnection. The part "optional" feels like it's not something that HAS TO happen. Is there a way to control it and make it to not take that option?

Looking at the WFP performance counters, I see that counter "Reason:NewInboundMCastBCastPacket" (WFP Reauthorization counter group) value is exactly equal to the number of UDP datagram processed (input stream packet rate multiplied by 5, because 5 receivers). That tells me Reauthorization is indeed applied to every single packet. There has to be a way to control this. The issue is not limited to testing tool - we have an actual application, which is also "5 copies of multicast receivers" that is running into same exact issue.

Windows Defender Firewall is off, so, it is not something that it is doing. Switching network profile from "public" to "private". Adding a filter to explicitly permit all UDP traffic at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4 layer did not change anything - I am guessing I need to somehow adjust filtering engine to not even try to apply filtering, but WFP documentation is extremely vague , and there is NO mentioning of NewInboundMCastBCastPacket as a possible cause of WFP ALE reauthorization

Answer 1

Hello,

The Windows Filtering Platform is a network traffic processing platform that allows software to "hook" into the network stack and perform various actions on network traffic. It is possible that the WFP is applying reauthorization for every single incoming multicast UDP packet because it is designed to do so in order to ensure security and prevent unauthorized access.

Regards,

Zunhui

Answer 2

That would imply that such behavior can be disabled if the administrator of the system consider the environment to be "secure enough". So far, I did not find a way to do so. There are many extremely dangerous things that can be easily enabled/disabled, at will, by administrator (via secpol and such), but this one has no means of being controlled?

I do not understand what kind of "high performance networking" can people talk about when such expensive action cannot be disabled

At the least, I think I should be allowed to white-list my own application from this policy being applied (maybe application + port)

P.S. BTW, "5 receivers" is not a pre-requisite - same issue occurs with a single receivers. Multiple receivers just make the problem worse via "amplification", since reauthorization is done for each _copy_ of datagram for each receiver, not once for incoming datagram

Answer 3

On StackOverflow, I was pointed to https://support.microsoft.com/en-us/topic/datagram-loss-when-you-run-a-multicast-receiver-application-in-windows-8-and-in-windows-server-2012-0f7a55e3-5073-4cdd-d7a6-8a40e7fb92a5

The issue is still present in Windows Server 2019 (and 2022), but the functionality to add UDP port exceptions is now a part of Windows Server functionality (i.e. no need to install hotfix itself, only need to add UdpExemptPortRange key with needed values to registry, and reboot)

You would need to install hotfix on Windows Server 2012