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

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.

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!

Tom.