Expected behavior for identical GET_CAPABILITIES or NEGOTIATE_ALGORITHMS requests

[nitinklohar]

As per the SPDM 1.2.1 specification document:

a requester can send multiple requests for GET_CAPABILITIES and NEGOTIATE_ALGORITHMS. And it is written that in case of non-identical requests, responder shall either discard the requests or return SPDM_ERROR with Unexpected Request error code. For the identical requests, what should be the responder's behavior? Current implementation of the libspdm code does not check whether the request has come before and returns SPDM_ERROR_CODE_UNEXPECTED_REQUEST for both identical and non-identical requests, which does not seem to align with the specification.

[steven-bellock]

Retries have long been a point of ambiguity in the SPDM specification and are ill-defined. In addition, they add unnecessary complexity to the SPDM layer of a Responder. To alleviate this @xiaoyuruan filed https://github.com/DMTF/SPDM-WG/issues/3092 against the specification which led to

If the transport is not reliable, then the Responder should support retry by identifying whether a received request is a retried one or a new one. If the Responder supports retry, then the response to a retried request shall be identical to the original response. If the transport is reliable, then the Responder may support retry.

in the 1.2.2 specification. In particular libspdm assumes that the transport is reliable.

[nitinklohar]

Thanks for the reply. Can you also answer the following related query?
Are the GET_CAPABILITIES and NEGOTIATE_ALGORITHMS requests allowed once the SPDM state has been changed to LIBSPDM_CONNECTION_STATE_AFTER_CAPABILITIES and LIBSPDM_CONNECTION_STATE_NEGOTIATED, respectively? Specifically, what do the tests 2.6 (SPDM_RESPONDER_TEST_CASE_CAPABILITIES_UNEXPECTED_REQUEST_NON_IDENTICAL) and 3.7 (SPDM_RESPONDER_TEST_CASE_ALGORITHMS_UNEXPECTED_REQUEST_NON_IDENTICAL) test in SPDM-Responder-Validator? Because once the state has been changed to AFTER_CAPABILITIES or NEGOTIATED, it seems that these requests are not allowed, be it identical or non-identical. These are not the retries, but the new requests after receiving successful response from the previous request.

[steven-bellock]

For Responders that do not support retries an error occurs because Responder expects VCA in that order and without repetition of messages. For Responders that do support retries an error occurs because the retried message is not identical to the original message.