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;
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.
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.
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.
To be continued...