Compartilhar via

1.3.1 Messages and Intersection with Other Protocols

  • Artigo

Bootstrapping, creating, securing and finalizing a multitransport connection uses messages from a number of protocols. The following sequence diagram presents an overview of these messages and protocols.

Messages used by multitransport connections

Figure 1: Messages used by multitransport connections

The RDP server initiates a multitransport connection by sending an Initiate Multitransport Request PDU ([MS-RDPBCGR] section 2.2.15.1) to the RDP client over the main RDP connection. Upon receiving the Initiate Multitransport Request PDU the client initiates the creation of the requested transport (reliable or lossy UDP) as described in [MS-RDPEUDP] sections 1.3.2 and 1.3.2.1.

After the transport has been successfully set up, the connection is secured by using Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) to set up a secure channel. TLS ([RFC2246], [RFC4346] and [RFC5246]) is used to secure reliable UDP transport connections, while DTLS ([RFC4347]) is used to secure lossy UDP transport connections.

Once the secure channel has been established, the client finalizes the creation of the multitransport connection by sending a request ID and a security cookie to the server in the Tunnel Create Request PDU (section 2.2.2.1); this PDU is sent over the newly created and secured multitransport connection. The data sent in the Tunnel Create Request PDU has to be identical to the data that the client received over the main RDP connection as part of the Initiate Multitransport Request PDU. The server compares the data in the Tunnel Create Request PDU to the data that was sent over the main RDP connection in the Initiate Multitransport Request PDU. This comparison allows the server to match the incoming multitransport connection request to an existing main RDP connection and to authenticate the connection based on the security cookie. If the security check succeeds, the server indicates to the client that it was able to successfully initialize the multitransport connection by sending the Tunnel Create Response PDU (section 2.2.2.2) over the multitransport connection. The server and client can then start transferring data over the multitransport connection.

If Soft-Sync ([MS-RDPEDYC] section 3.1.5.3) is supported by the server and client, the Initiate Multitransport Response PDU ([MS-RDPBCGR] section 2.2.15.2) is sent to the server after each transport is created, and the multitransport connections are not used to send or receive dynamic virtual channel data until Soft-Sync negotiation is completed.

All data is transferred over the multitransport connection in message mode. The Tunnel PDU Header (section 2.2.1.1) includes the size of the message that the multitransport protocol data unit (PDU) contains; the client assembles the entire message before delivering it to the upper layers.