RequestResync Error Code Handling

[Ankur-80]

When checking the SPDM functionality using storage controller, synchronization is not reestablished if the responder experiences a reset and loses the last negotiated state.
The sequence of events is as follows:

1. The requester and responder successfully negotiate the SPDM version to 1.1.
2. A controller reset takes place, and the responder's last negotiated state is lost.
3. Despite the reset, the requester continues to believe that the SPDM version is 1.1.
4. The requester sends a GET_DIGEST command with a version of 1.1.
5. Since the responder has not been in a negotiated state following the reset, it responds with an error message indicating a request for resynchronization (0x43), but with an SPDM version of 1.0.
   spdm_response->header.spdm_version = libspdm_get_connection_version (spdm_context); if (spdm_response->header.spdm_version == 0) { /* if version is not negotiated, then use default version 1.0 */ spdm_response->header.spdm_version = SPDM_MESSAGE_VERSION_10; }
6. On the requester's side, the version is validated before the error message is checked, and a version mismatch is identified, resulting in the return of an "InvalidMessage" value.
   /* -=[Validate Response Phase]=- */ if (spdm_response_size < sizeof(spdm_message_header_t)) { status = LIBSPDM_STATUS_INVALID_MSG_SIZE; goto receive_done; } if (spdm_response->header.spdm_version != spdm_request->header.spdm_version) { status = LIBSPDM_STATUS_INVALID_MSG_FIELD; goto receive_done; } if (spdm_response->header.request_response_code == SPDM_ERROR) { status = libspdm_handle_error_response_main( spdm_context, session_id, &spdm_response_size, (void **)&spdm_response, SPDM_GET_DIGESTS, SPDM_DIGESTS); if (LIBSPDM_STATUS_IS_ERROR(status)) { goto receive_done; } }

[steven-bellock]

If the Responder has been completely reset, and does not remember that there even was a connection, then it should reply with UnexpectedRequest. But that UnexpectedRequest would be a 1.0 error message as well and should be conveyed accurately to the Integrator.

I am somewhat sure that RequestResynch must maintain the negotiated version, but I can clarify that with the SPDM Working Group.

[Ankur-80]

As per Spec, Responder can send either UnexpectedRequest or RequestResynch. If RequestResynch is received then Requester will initiate the authentication again.

It is mentioned that RequestResynch can come after firmware update. If device doesn't support Cache Capability then after firmware update it will lost the last negotiated version.

[steven-bellock]

As per Spec, Responder can send either UnexpectedRequest or RequestResynch.

Interestingly the passage

When requests are received out of order, the Responder can silently discard all requests or return an ERROR message with ErrorCode=RequestResynch (with the exception of GET_VERSION ) until the Requester issues a GET_VERSION.

was added in the SPDM 1.2 specification. So I guess that does not apply to your example, where the version is 1.0/1.1? Also the "General ordering rules" section says

These general ordering rules apply to SPDM messages that form a transcript that eventually gets signed.

but what about messages that do not eventually get signed, such as GET_KEY_PAIR_INFO?

On the Responder side I think the fundamental question is

Is it legal for a newly powered-on or reset Responder to return RequestResync to non-GET_VERSION messages?

which hopefully the SPDM Working Group will answer on Thursday.

[Ankur-80]

It is mentioned in the 1.1 specification that if the Responder completes the firmware update, it should either respond with a RequestResynch or discard the message.

This issue is also observed in version 1.2. It is a version-independent issue that can occur if the Responder resets after a firmware update and the Requester sends a command request.
We will wait for the SPDM Group to provide clarity on this issue.