Re: Re: Invalidation

On Wednesday, October 1, 2003, at 10:59 PM, Jim Pinkerton wrote:

> Here's proposed text to address this in the security draft. Note that
> the threat actually has nothing to do with whether the STag is
> long-lived or not - the key issue is sharing it across multiple
> connections.
>
>
> 7.5.5	Remote Invalidation of an STag Shared Across Multiple
> Connections
>
> If a Local Peer has enabled an STag for remote access, the Remote Peer
> could attempt to invalidate the STag by using the RDMAP Send with
> Invalidate or Send with SE and Invalidate Message. If the STag is only
> valid on the current connection (NS-NT or NS-RT, S-NT), then the only
> side effect is that the Remote Peer can no longer use the STag, thus
> there are no security issues.
>
> If the STag is valid across multiple connections, then the Remote Peer
> can prevent other connections from using that STag by using the remote
> invalidate functionality.
>
> Thus for trust models that involve shared local STags across multiple
> connections connecting to mutually untrusted Remote Peers, the
> invalidate STag capability SHOULD be disabled for the shared STag.

Thinking about this a bit more in the context of the Security draft,
the most critical advise remains that an STag should have no wider
of a scope than the ULP requires.

Hence, the ULP SHOULD have the ability to make an STag valid only
on those DDP Streams that are associated with a specific session,
or are otherwise presumed to have a trusting relationship with
each other.

In other words, if there is a basis to assume that the peers for
multiple remote peers can be trusted to share an STag, they can
probably be trusted to invalidate it.

The major exception that I can think of would be an STag that
was enabled for RDMA Read usage only. The Data Source could be
publishing status data, for example, that any client could
read at its convenience.

In that case, just as none of them are trusted to write to the
data, none would be trusted to invalidate the STag.


I also note that the inability to support dynamically bound
STags across multiple DDP Streams is, in my opinion, a critical
flaw in the RDMAC proposed iWarp verbs. It would also be easily
corrected by replacing the "QP ID" used in validating a bound
STag with a "QP Set ID". By default each QP would belong to its
own QP Set.


On the original topic, a "data publishing STag" is just one
example of many valid *local* reasons to disallow remote
invalidation.