You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See the [draft IETF](https://datatracker.ietf.org/doc/html/draft-banks-quic-cibir) for CIBIR.
6
+
7
+
When CIBIR is used, rather than programming [XDP](./XDP.md) to filter and demux packets based on on address and port number,
8
+
XDP with CIBIR will instead filter and de-mux packets based on address, port number, and QUIC connection ID.
9
+
10
+
What CIBIR allows for is 2 or more separate server processes to share a single
11
+
port on the same machine, as long as their CIBIR ID is different.
12
+
13
+
## CIBIR port sharing logic
14
+
- Applications must provide a well-known local port for server sockets when using CIBIR and XDP.
15
+
-**IMPORTANT:** MsQuic will **NOT** reserve an OS port for server sockets when both CIBIR and XDP is enabled and available.
16
+
- Client sockets can never share ports, so MsQuic will reserve an OS port in that scenario.
17
+
- The responsibility of book-keeping shared ports and ensuring robust protection for those shared ports is delegated to the application.
18
+
19
+
20
+
## Port protection recommendations for shared ports
21
+
22
+
### Option 1: Persistent port reservations (Recommended)
23
+
24
+
MsQuic strongly recommends applications leverage the Windows [persistent port reservations API](https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-createpersistentudpportreservation) to secure shared CIBIR ports prior to serving multi-process CIBIR traffic on a shared port.
25
+
- One time setup by a system admin to create the persistent reservation.
26
+
- A good option for book-keeping persistent port reservations is via registry keys.
27
+
- Persistent port reservations survive reboots, allowing for robust protection in the event of crashes.
28
+
- Having a persistent reservation makes sure CIBIR ports are taken out of the ephemeral port pool and forbids sockets from binding to it unless it is associated with a persistent reservation token, which can only happen in an elevated process.
29
+
- This way, an unsuspecting application process won't get accidently assigned an ephemeral port that collides with a CIBIR port.
30
+
31
+
### Option 2: WFP ALE (Application Layer Enforcement) filters
32
+
33
+
As an alternative, applications can use the [Windows Filtering Platform (WFP)](https://learn.microsoft.com/en-us/windows/win32/fwp/windows-filtering-platform-start-page) to create ALE filters that block unauthorized bind attempts to CIBIR ports.
34
+
35
+
ALE filters operate at the [bind and connect authorization layers](https://learn.microsoft.com/en-us/windows/win32/fwp/ale-layers) (`FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4/V6`, `FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V4/V6`). A filter can be configured to block any process from binding to a specific UDP port unless it matches an allowed application path or security descriptor.
Copy file name to clipboardExpand all lines: docs/QTIP.md
+19-2Lines changed: 19 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,24 @@ This setting can be overridden per client connection, allowing you to create som
24
24
> [!IMPORTANT]
25
25
> Crucial information necessary for users to succeed.
26
26
27
-
Using QTIP will initialize a TCP socket and attempt to bind to your listener's local address. This is to reserve a TCP port for your listener to ensure
28
-
XDP does not steal any TCP traffic from your other processes later. That also means you need to ensure no other processes are listening on the same TCP port as your listener's local address prior
27
+
Listeners with QTIP enabled will initialize a TCP and UDP socket and attempt to bind to your listener's local address. This is to reserve a TCP/UDP port for your listener to ensure
28
+
XDP does not steal any traffic from other sockets later. That also means you need to ensure no other processes are listening on the same port as your listener's local address prior
29
29
to starting your listener, otherwise the OS will throw a socket access denied / address in use error,
30
30
and your listener will fail to initialize.
31
+
32
+
**Client connections with different QTIP enablements CAN exist on the same local port.**
33
+
34
+
MsQuic connections over XDP/UDP creates an OS UDP socket only, and relies on the OS to assign the app an ephemeral UDP port to reserve it. XDP will be configured to intercept UDP packets on that port.
35
+
36
+
MsQuic connections over XDP/QTIP creates an OS TCP socket only, and relies on the OS to assign the app an ephemeral TCP port to reserve it. XDP will be configured to intercept TCP traffic on that port.
37
+
38
+
Since apps can create many client connections with different QTIP enablements, sometimes the OS assigns
39
+
the same TCP and UDP port number. If using client connections with and without QTIP enabled simultaneously, the application should not assume 4-tuples uniquely identify a connection and also track the QTIP state.
40
+
41
+
42
+
**Listeners with different QTIP enablements shall NOT be able to exist on the same local port.**
43
+
44
+
A QTIP-enabled listener will reserve both UDP/TCP ports equal to the local port of the listener
45
+
and configure XDP to intercept UDP/TCP packets on that local port. A non-QTIP listener will just reserve a UDP port
46
+
and have XDP intercept UDP packets on that port. To avoid conflicting traffic, we disallow 2 listeners with the same
47
+
local port but different QTIP enablements to exist.
0 commit comments