On 7/11/2022 4:43 PM, Rick Macklem wrote:
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.
