Tom Talpey [off-list ref] wrote:

On 7/11/2022 4:43 PM, Rick Macklem wrote:

quoted

quoted

quoted

quoted

CREATE_SESSION has a built-in reply cache to thwart replay attacks.
It can legitimately return the same sessionid as a previous request.
Granted, DESTROY_SESSION is supposed to wipe that reply cache...

Well, I just re-read the RFC and I don't see anything that says DestroySession
affects the CreateSession reply cache.

It actually does, but I think it's problematic:


18.37.3.  DESCRIPTION

    The DESTROY_SESSION operation closes the session and discards the
    session's reply cache, if any.  Any remaining connections associated
    with the session are immediately disassociated.  If the connection
    has no remaining associated sessions, the connection MAY be closed by
    the server.  Locks, delegations, layouts, wants, and the lease, which
    are all tied to the client ID, are not affected by DESTROY_SESSION.

When I read "discards the session's reply cache" I think I somehow read it
as "discards the create_session reply cache", but it pretty obviously is referring
to what is cached for the session's slots.

What about the reply to DESTROY_SESSION itself? I guess the idea is
that if the client misses the reply and reconnects/retransmits, it
gets NFSERR_BAD_SESSION and figures it out. Maybe not worth taking
to IETF, since you found the root cause!

Yep, the reply to DestroySession doesn't get cached but, as you note, the
client usually can just ignore a NFS4ERR_BAD_SESSION reply and assume it
is a retry, since it wanted to get rid of the session anyhow.

rick

Tom.