Compatibility of SPDM-EMU with DSP0287 (SPDM over TCP) --trans TCP

[midas7912]

Description: The current implementation of SPDM-EMU, specifically the payload format used in spdm_emu/spdm_emu_common/command.h (build 2021/5/1), appears to be tailored for SPDM communication via socket. The payload format is as follows:

spdm_emu/spdm_responder_emu/spdm_responder_emu.c/main() {

    if (m_use_transport_layer == SOCKET_TRANSPORT_TYPE_TCP) {
        /* The **IANA** has assigned port number **4194** for SPDM */
        result = platform_server_routine(TCP_SPDM_PLATFORM_PORT);
    }
    else {
        result = platform_server_routine(DEFAULT_SPDM_PLATFORM_PORT);
    }
}
pdm_emu/spdm_emu_common/command.h   #build 2021/5/1 as below
/* Client->Server/Server->Client  
 *   command/response: 4 bytes (big endian)
 *   transport_type: 4 bytes (big endian)
 *   PayloadSize (excluding command and PayloadSize): 4 bytes (big endian)
 *   payload (SPDM message, starting from SPDM_HEADER): PayloadSize (little endian)*/ 

Given the assignment of port number 4194 by IANA for SPDM, and the announcement of DSP0287 (SPDM over TCP) by DMTF, it is necessary to update the payload format to ensure compatibility with DSP0287.

Steps to Reproduce:
Clone the SPDM-EMU repository.
Attempt to use the --trans TCP option with the current payload format.
Expected Behavior: The payload format should be updated to align with DSP0287 standards for SPDM over TCP. (TBD)
Actual Behavior: The current payload format is specific to SPDM-EMU via socket and does not comply with DSP0287 standards. it's make sense since DSP0287 is just updated.

References:
*

• IANA 4194 : https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=194
• https://www.dmtf.org/sites/default/files/standards/documents/DSP0287_1.0.0.pdf annonce by 2024/09/03.
  payload format:
  `Byte offset | Field | Size (bytes) | Description

0 | PayloadLen | 2: Shall be the length of the SPDM message that follows the header.
2 | BindingVer | 1: Shall be 0x01 for this version of the binding specification.
3 | MessageType | 1: Shall indicate the message type.
0x05: Out-of-Session Message. An SPDM message follows the header.
0x06: In-Session Message. An SPDM message follows the header.
0xBF: Role-Inquiry Message. No SPDM message follows the header.
0xC0 to 0xFF: Error messages. No SPDM message follows the header. See Table 2.
other values: reserved.`

Would you agree to make this change to align the payload format with DSP0287 standards?

[steven-bellock]

@manojkiraneda brought this up just yesterday and seemed open to contributing. The first step is to file a feature issue in https://github.com/DMTF/libspdm/issues to add spdm_transport_tcp_lib to https://github.com/DMTF/libspdm/tree/main/library. The basic design, if there is any, can be discussed there. Then you and/or @manojkiraneda (or someone else entirely) can contribute the code.

[midas7912]

@steven-bellock . Thanks for the feedback . could you please review my opinion as below ?
No Changes Needed for libspdm: From the perspective of DSP0287, the body of SPDM(libspdm) does not require any modifications.
SPDM over TCP: Changes should be limited to SPDM over TCP (spdm-emu::socket things) only.
Historical Context and Recommendation: Since the spdm-emu --trans TCP implementation occurred years ago and is itself an important historical footprint, DSP0287 should consider incorporating ex: --tcp_sub DSP0287 with --trans TCP for all other uses, ensuring backward compatibility.

[steven-bellock]

No Changes Needed for libspdm: From the perspective of DSP0287, the body of SPDM(libspdm) does not require any modifications.

Yes, changes are needed for libspdm. spdm-emu would leverage the newly created TCP transport library in https://github.com/DMTF/libspdm/tree/main/library/spdm_transport_tcp_lib/.