Summary

  • RFC 7145 says an iSER initiator cannot rely on its peer to invalidate a local STag: Send with Invalidate is optional, and the local layer must check and revoke a tag when invalidation is expected.
  • The rule protects resource lifetime, not just message correctness: an STag left valid can keep its I/O buffer accessible through the RDMA-capable protocol beyond the task that exposed it.

The command ended; the permission might not have

A storage command has a visible finish: a response arrives, the task is retired, and software may want to reuse its buffer. RDMA adds a less visible question. Is the remote access capability for that memory actually gone? In iSER, the Steering Tag, or STag, identifies an I/O buffer that one node advertises so the other can perform an RDMA read or write. The identifier is not the data; it is part of the path by which a peer can reach the data.

RFC 7145, published in 2014 as an update to RFC 5046, spells out who owns the final check. A Send with Invalidate can let the target's response automatically invalidate a tag, but support and use of that message are optional. The standard therefore says the initiator-side iSER layer must not depend on the remote peer choosing that mechanism. When the task's expected outcome is an invalid STag, the local layer must check the tag and invalidate it if it is still valid. RFC 7145

That wording is more careful than “the target sends a response, so the buffer is safe.” The response and the local registration state are different facts. A normal completion is guidance to invalidate the advertised STag; bidirectional commands and abnormal completion complicate automatic invalidation. In a bidirectional case, one Send-with-Invalidate message can name only one tag, so the initiator may still need to invalidate another explicitly. Where a command ends without its response PDU, RFC 7145 specifies a separate task-resource deallocation path that locates and invalidates the initiator's associated tags.

The standard explains why this distinction matters. If an STag is retained—for example, to cache it for reuse—the associated I/O buffer remains exposed to network access through the RDMA-capable protocol beyond the original iSCSI operation. The concern is not that every retained tag is evidence of misuse. It is that a completed command does not, by itself, prove the access window closed. RFC 7145's security section makes local verification a control against that ambiguity.

The design leaves useful flexibility. An implementation may use automatic invalidation where the underlying RDMA-capable protocol supports it, and it may optimize resource handling. But a convenient remote action cannot be the only proof of a local state transition. This is a narrowly scoped protocol obligation, not a report of a breach, a claim about any vendor's implementation, or a substitute for authentication and the wider security requirements of iSCSI and the underlying RDMA protocol. The earlier RFC 5046 text had required more reliance on these message variants; RFC 7145's change history says the later document clarified that initiator-side invalidation is the initiator's responsibility for security reasons. RFC 5046 · RFC 7143 Sources: RFC Editor information page.