3.3.5.3.1 Processing X.224 Connection Request PDU

  • [アーティクル]

The structure and fields of the X.224 Connection Request PDU are specified in section 2.2.1.1.

The embedded length fields within the tpktHeader field ([T123] section 8) MUST be examined for consistency with the received data. If there is any discrepancy, the connection SHOULD be dropped. Other reasons for dropping the connection include:

  • The length of the X.224 Connection Request PDU is less than 11 bytes.

  • The X.224 Connection Request PDU is not Class 0 ([X224] section 13.7).

The Destination reference, Source reference, and Class and options fields within the x224Crq field SHOULD be ignored.

If the optional routingToken field exists, it MUST be ignored because the routing token is intended to be inspected and parsed by external networking hardware along the connection path (for more information about load balancing of Remote Desktop sessions and the routing token format, see [MSFT-SDLBTS] "Load-Balanced Configurations", "Revectoring Clients", and "Routing Token Format").

If the optional cookie field is present, it MUST be ignored.

If both the routingToken and cookie fields are present, the server SHOULD continue with the connection. Since the server does not process either the routingToken or cookie fields, a client violation of the protocol specification in section 2.2.1.1 is not an issue. However, including both the routingToken and the cookie fields will most likely result in problems when the X.224 Connection Request is inspected and parsed by networking hardware that is used for load balancing Remote Desktop sessions.

If the rdpNegData field is not present, it is assumed that the client does not support Enhanced RDP Security (section 5.4) and negotiation data MUST NOT be sent to the client as part of the X.224 Connection Confirm PDU (section 2.2.1.2). If the rdpNegData field is present, it is parsed to check that it contains an RDP Negotiation Request structure, as specified in section 2.2.1.1.1. If this is the case, the flags describing the supported security protocols in the requestedProtocols field are saved in the Received Client Data store (section 3.3.1.1).

Once the X.224 Connection Request PDU has been processed successfully, the server MUST send the X.224 Connection Confirm PDU to the client (section 3.3.5.3.2) and update the Connection Start Time store (section 3.3.1.12).