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.

But of course the ULP MAY have other reasons to disable remote
invalidation that are beyond the ability of transport layer
designers to comprehend. In other words, part of the definition
of "ULP" is that it is allowed to do things for stupid, I mean
application-specific, reasons.

The language proposed sounds fine, and covers the *justifying*
reason well. After all, a Memory Region is just one type of
shared STag.

But we also need permission to do this in the DDP document.
Currently it specifies that after a remote invalidation that
the STag MUST be invalid until it is re-instated by the ULP.

That should be reduced to a SHOULD, with a comments that
local interfaces MAY offer variants such as not recognizing
an invalidation.

The wire-protocol issue is what the response to a blocked
remote invalidate should be:

a) ignore it. The remote end doesn't have to know that the
    STag is still valid, because it won't be attempting to
    use it anyway.
b) treat it as an access violation and terminate the connection.

I favor A, whether thinking as an application designer or as
an RNIC designer.