Tom Talpey <tom@xxxxxxxxxx> wrote: > 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. 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.
