Months that I have not posted anything. So let's begin with some wishes for the new year, let's hope the Covid will be more quiet in 2021.

I'm currently working on implementing UDP support in FreeRDP, so let's have a serie of post on that subject. I'm gonna begin with an overview, how it works, implications and I'll certainly go more in the details in the next posts.

Overview of the UDP transport

Documentation and specifications

The UDP transport is described in multiple specifications:

• MS-RDPBCGR : the core RDP specification, we have some flags in GCC packets, and of course the description of multi-transport;
• MS-RDPEMT : this document describes multi-transport, that allows to install multiple transports at the same time;
• MS-RDPEUDP : the UDP transport itself;
• MS-RDPEUDP2 : the new version of the protocol;
• MS_RDPEDYC : dynamic channels specification;

General approach

Multi-transport allows to transport channel traffic over multiple-transport. An improvement is the possibility to have a lossy transport that allows to lose some packets in the channel traffic. Anyway it seems like this feature is not used a lot as in MS-RDPEUDP2 (the new version of the UDP transport) it is not present anymore.

Negotiating multi-transport is done with this workflow:

• the RDP client connects in TCP and starts negotiation;
• it negotiate multi-transport over the TCP connection;
• initiated by the server, one or more UDP transports are established;
• then the channels are migrated over UDP transports;

Let's have a look at the details.

Flags announce

In the first negotiation packet, it's a good idea for the client to put a correlationId, this way the server will be able to map an input UDP connection to it's master TCP connection. The strict association between the 2 connections is done with another mecanism, the correlationId is there just to have nicer logs before the UDP transport is established.

Then the client and server must announce multi-transport support by settings TS_UD_CS_MULTITRANSPORT and TS_UD_SC_MULTITRANSPORT in GCC packets.

Multi-transport Negotiation

Next in the negotiation steps, just after licensing, multi-transport negotiation itself starts. The steps are:

we have the Initiate Multitransport Request received by the client on the TCP connection (so multi-transport is initiated by the server). Then the RDP-UDP transport is established, and once done we can start transfering data over UDP. When UDP transport is established, this layer is secured by either TLS or DTLS depending if the transport is lossy or lossless. When the SSL handshake is completed, the transport is considered functional from the client point of view.

Over that UDP connection, the client will send a Tunnel Create Request so that the server will be able to map the UDP transport with the main TCP connection (sending back a secret present in the Initiate Multitransport Request packet at the first step). Then the client will reply on the TCP connection with a Initiate Multitransport Response to confirm that everything is operational, and then migration of channels to UDP transport can begin.

Conclusion

To be continued...