2.2.15.1 Server Initiate Multitransport Request PDU

The Initiate Multitransport Request PDU is sent by the server to the client and is used to bootstrap the creation of a sideband channel ([MS-RDPEMT] section 1.3). Upon receiving and successfully decoding the Initiate Multitransport Request PDU, the client SHOULD create the requested channel using the specified transport protocol ([MS-RDPEUDP] sections 1.3.2.1 and 3.1.5.2) and then secure the channel using TLS or DTLS ([MS-RDPEMT] sections 1.4 and 5.1). After the channel has been successfully created and secured, the client MUST send the Tunnel Create Request PDU ([MS-RDPEMT] section 2.2.2.1) to the server over the newly created channel ([MS-RDPEMT] section 1.3.1).

This PDU MUST only be sent over the MCS message channel. The ID of the message channel is specified in the Server Message Channel Data (section 2.2.1.4.5).


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

tpktHeader

x224Data

mcsSDin (variable)

...

securityHeader (variable)

...

requestId

requestedProtocol

reserved

securityCookie (16 bytes)

...

...

tpktHeader (4 bytes): A TPKT Header, as specified in [T123] section 8.

x224Data (3 bytes): An X.224 Class 0 Data TPDU, as specified in [X224] section 13.7.

mcsSDin (variable): A variable-length PER-encoded MCS Domain PDU (DomainMCSPDU) that encapsulates an MCS Send Data Indication structure (SDin, choice 26 from DomainMCSPDU), as specified in [T125] section 11.33 (the ASN.1 structure definitions are given in [T125] section 7, parts 7 and 10). The userData field of the MCS Send Data Indication contains a Security Header, ID, transport protocol, and a security cookie.

securityHeader (variable): Security header. The format of the security header depends on the Encryption Level and Encryption Method selected by the server (sections 5.3.2 and 2.2.1.4.3). This field MUST contain one of the following headers:

  • Basic Security Header (section 2.2.8.1.1.2.1) if the Encryption Level selected by the server is ENCRYPTION_LEVEL_NONE (0) or ENCRYPTION_LEVEL_LOW (1) and the embedded flags field does not contain the SEC_ENCRYPT (0x0008) flag.

  • Non-FIPS Security Header (section 2.2.8.1.1.2.2) if the Encryption Method selected by the server is ENCRYPTION_METHOD_40BIT (0x00000001), ENCRYPTION_METHOD_56BIT (0x00000008), or ENCRYPTION_METHOD_128BIT (0x00000002) and the embedded flags field contains the SEC_ENCRYPT (0x0008) flag.

  • FIPS Security Header (section 2.2.8.1.1.2.3) if the Encryption Method selected by the server is ENCRYPTION_METHOD_FIPS (0x00000010) and the embedded flags field contains the SEC_ENCRYPT (0x0008) flag.

If the Encryption Level is set to ENCRYPTION_LEVEL_CLIENT_COMPATIBLE (2), ENCRYPTION_LEVEL_HIGH (3), or ENCRYPTION_LEVEL_FIPS (4) and the flags field of the security header does not contain the SEC_ENCRYPT (0x0008) flag (the PDU is not encrypted), then the field MUST contain a Basic Security Header.

The flags field of the security header MUST contain the SEC_TRANSPORT_REQ (0x0002) flag (section 2.2.8.1.1.2.1).

requestId (4 bytes): A 32-bit unsigned integer that specifies a unique ID that the server MUST use to associate this Initiate Multitransport Request PDU with the Tunnel Create Request PDU ([MS-RDPEMT] section 2.2.2.1) sent by the client after the transport has been established.

requestedProtocol (2 bytes): A 16-bit unsigned integer that specifies the protocol to use in the transport.

Value

Meaning

INITITATE_REQUEST_PROTOCOL_UDPFECR

0x01

RDP-UDP Forward Error Correction (FEC) reliable transport ([MS-RDPEUDP] sections 1 to 3).

INITITATE_REQUEST_PROTOCOL_UDPFECL

0x02

RDP-UDP FEC lossy transport ([MS-RDPEUDP] sections 1 to 3).<42>

reserved (2 bytes): A 16-bit unsigned integer. This field is unused and reserved for future use. It MUST be set to zero.

securityCookie (16 bytes): A 16-element array of 8-bit unsigned integers that contains randomly generated data. This array MUST be retransmitted by the client in the Tunnel Create Request PDU ([MS-RDPEMT] section 2.2.2.1) after the channel has been created and is used by the server to validate the channel setup ([MS-RDPEMT] section 3.2.5.1).