1.3.1.1 Connection Sequence
The goal of the RDP Connection Sequence is to exchange client and server settings and to specify common settings to use for the duration of the connection so that input, graphics, and other data can be exchanged and processed between client and server. The RDP Connection Sequence is described in following figure. All of the message exchanges in this diagram are strictly sequential, except where noted in the text that follows.
Figure 1: Remote Desktop Protocol (RDP) connection sequence
The connection sequence can be broken up into ten distinct phases:
Connection Initiation: The client initiates the connection by sending the server a Class 0 X.224 Connection Request PDU (section 2.2.1.1). The server responds with a Class 0 X.224 Connection Confirm PDU (section 2.2.1.2).
From this point, all subsequent data sent between client and server is wrapped in an X.224 Data Protocol Data Unit (PDU) (1).
Basic Settings Exchange: Basic settings are exchanged between the client and server by using the MCS Connect Initial PDU (section 2.2.1.3) and MCS Connect Response PDU (section 2.2.1.4). The Connect Initial PDU contains a Generic Conference Control (GCC) Conference Create Request, while the Connect Response PDU contains a GCC Conference Create Response.
These two GCC packets contain concatenated blocks of settings data (such as core data, security data, and network data) which are read by client and server.
Figure 2: MCS Connect Initial PDU
Figure 3: MCS Connect Response PDU
Channel Connection: The client sends an MCS Erect Domain Request PDU (section 2.2.1.5), followed by an MCS Attach User Request PDU (section 2.2.1.6) to attach the primary user identity to the MCS domain. The server responds with an MCS Attach User Confirm PDU (section 2.2.1.7) containing the User Channel ID. The client then proceeds to join the user channel, the input/output (I/O) channel, and all of the static virtual channels (the I/O and static virtual channel IDs are obtained from the data embedded in the GCC packets) by using multiple MCS Channel Join Request PDUs (section 2.2.1.8). The server confirms each channel with an MCS Channel Join Confirm PDU (section 2.2.1.9). (RDP 4.0, 5.0, 5.1, 5.2, 6.0, 6.1, 7.0, 7.1, 8.0, 10.2, 10.3, 10.4, and 10.5 clients send a Channel Join Request to the server only after the Channel Join Confirm for a previously sent request has been received. RDP 8.1, 10.0, and 10.1 clients send all of the Channel Join Requests to the server in a single batch to minimize the overall connection sequence time.)
From this point, all subsequent data sent from the client to the server is wrapped in an MCS Send Data Request PDU, while data sent from the server to the client is wrapped in an MCS Send Data Indication PDU. This is in addition to the data being wrapped by an X.224 Data PDU.
RDP Security Commencement: If Standard RDP Security mechanisms (section 5.3) are being employed and encryption is in force (this is determined by examining the data embedded in the GCC Conference Create Response packet) then the client sends a Security Exchange PDU (section 2.2.1.10) containing an encrypted 32-byte random number to the server. This random number is encrypted with the public key of the server as described in section 5.3.4.1 (the server's public key, as well as a 32-byte server-generated random number, are both obtained from the data embedded in the GCC Conference Create Response packet). The client and server then utilize the two 32-byte random numbers to generate session keys which are used to encrypt and validate the integrity of subsequent RDP traffic.
From this point, all subsequent RDP traffic can be encrypted and a security header is included with the data if encryption is in force. (The Client Info PDU (section 2.2.1.11) and licensing PDUs ([MS-RDPELE] section 2.2.2) are an exception in that they always have a security header). The Security Header follows the X.224 and MCS Headers and indicates whether the attached data is encrypted. Even if encryption is in force, server-to-client traffic cannot always be encrypted, while client-to-server traffic will always be encrypted (encryption of licensing PDUs is optional, however).
Secure Settings Exchange: Secure client data (such as the username, password, and auto-reconnect cookie) is sent to the server by using the Client Info PDU (section 2.2.1.11).
Optional Connect-Time Auto-Detection: During the Optional Connect-Time Auto-Detection phase, the goal is to determine characteristics of the network, such as the round-trip latency time and the bandwidth of the link between the server and client. This is accomplished by exchanging a collection of PDUs (specified in section 2.2.14) over a predetermined period of time with enough data to ensure that the results are statistically relevant.
Licensing: The goal of the licensing exchange is to transfer a license from the server to the client. The client stores this license and on subsequent connections sends the license to the server for validation. However, in some situations the client cannot be issued a license to store. In effect, the packets exchanged during this phase of the protocol depend on the licensing mechanisms employed by the server. Within the context of this document, it is assumed that the client will not be issued a license to store. For details regarding more advanced licensing scenarios that take place during the Licensing phase, see [MS-RDPELE] section 1.3.
Optional Multitransport Bootstrapping: After the connection has been secured and the Licensing phase has run to completion, the server can choose to initiate multitransport connections ([MS-RDPEMT] section 1.3). The Initiate Multitransport Request PDU (section 2.2.15.1) is sent by the server to the client and results in the out-of-band creation of a multitransport connection using messages from the RDP-UDP, TLS, DTLS, and multitransport protocols ([MS-RDPEMT] section 1.3.1). The client sends the Multitransport Response PDU (section 2.2.15.2) to the server if the multitransport connection could not be established or if the server indicated support for Soft-Sync in the Server Multitransport Channel Data (section 2.2.1.4.6)
Capabilities Exchange: The server sends the set of capabilities it supports to the client in a Demand Active PDU (section 2.2.1.13.1). The optional Monitor Layout PDU (section 2.2.12.1) is sent by the server after the Demand Active PDU. The client responds to the Demand Active PDU with its capabilities by sending a Confirm Active PDU (section 2.2.1.13.2).
Connection Finalization: The client and server exchange PDUs to finalize the connection details. The client-to-server PDUs sent during this phase have no dependencies on any of the server-to-client PDUs; they can be sent as a single batch, provided that sequencing is maintained.
The Client Synchronize PDU (section 2.2.1.14) is sent after transmitting the Confirm Active PDU.
The Client Control (Cooperate) PDU (section 2.2.1.15) is sent after transmitting the Client Synchronize PDU.
The Client Control (Request Control) PDU (section 2.2.1.16) is sent after transmitting the Client Control (Cooperate) PDU.
The optional Persistent Key List PDUs (section 2.2.1.17) are sent after transmitting the Client Control (Request Control) PDU.
The Font List PDU (section 2.2.1.18) is sent after transmitting the Persistent Key List PDUs or, if the Persistent Key List PDUs were not sent, it is sent after transmitting the Client Control (Request Control) PDU (section 2.2.1.16).
The server-to-client PDUs sent during the Connection Finalization phase have dependencies on the client-to-server PDUs.
The Server Synchronize PDU (section 2.2.1.19) is sent in response to the Confirm Active PDU.
The Server Control (Cooperate) PDU (section 2.2.1.20) is sent after transmitting the Server Synchronize PDU.
The Server Control (Granted Control) PDU (section 2.2.1.21) is sent in response to the Client Control (Request Control) PDU.
The Font Map PDU (section 2.2.1.22) is sent in response to the Font List PDU.
Once the client has sent the Confirm Active PDU, it can start sending mouse and keyboard input to the server, and upon receipt of the Font List PDU the server can start sending graphics output to the client.
Besides input and graphics data, other data that can be exchanged between client and server after the connection has been finalized includes connection management information and virtual channel messages (exchanged between client-side plug-ins and server-side applications).