Compartir a través de

3.2.5.2 Processing a Server-to-Client Slow-Path PDU

  • Artículo

The majority of server-to-client slow-path PDUs have the same basic structure (sections 5.3.8 and 5.4.4):

  • tpktHeader: TPKT Header ([T123] section 8)

  • x224Data: X.224 Class 0 Data TPDU ([X224] section 13.7)

    • mcsSDin: MCS Send Data Indication PDU ([T125] section 7, part 7)

      • securityHeader: Optional Security Header (section 2.2.8.1.1.2)

      • shareDataHeader: Share Data Header (section 2.2.8.1.1.1.2)

      • PDU Contents (see the section describing the PDU structure and fields in section 2.2)

If Enhanced RDP Security (section 5.4) is in effect, the External Security Protocol (section 5.4.5) being used to secure the connection MUST be used to decrypt and verify the integrity of the entire PDU prior to any processing taking place.

The embedded length fields within the tpktHeader ([T123] section 8) and mcsSDin ([T125] section 7, parts 7 and 10) fields MUST be examined for consistency with the received data. If there is any discrepancy, the connection SHOULD be dropped.

The embedded channelId field within the mcsSDin is used to route the PDU to the appropriate target channel.

The conditions mandating the presence of the securityHeader field, as well as the type of Security Header structure present in this field, are explained in the section describing the PDU structure and fields in section 2.2. If the securityHeader  field is present, the embedded flags field MUST be examined for the presence of the SEC_ENCRYPT (0x0008) flag (section 2.2.8.1.1.2.1), and, if it is present, the data following the securityHeader field MUST be verified and decrypted using the methods and techniques specified in section 5.3.6. If the MAC signature is incorrect, or the data cannot be decrypted correctly, the connection SHOULD be dropped. If Enhanced RDP Security is in effect and the SEC_ENCRYPT flag is present, the connection SHOULD be dropped because double-encryption is never used in this scenario.

The shareDataHeader field (which contains the Share Control Header and Share Data Header described in sections 2.2.8.1.1.1.1 and 2.2.8.1.1.1.2 respectively) MUST be examined to determine the PDU type (from the pduType and pduType2 fields), as well as the compression usage information (from the compressedType field). If the data following the Share Data Header is compressed, then decompression using the techniques specified in section 3.1.8.3 MUST be performed. The value of the totalLength field MUST also be examined for consistency with the received data. If there is any discrepancy, the connection SHOULD be dropped. The remaining Share Control Header and Share Data Header fields MAY be ignored.

Any remaining PDU fields MUST be interpreted and processed in accordance with the section describing the PDU structure and fields in section 2.2.