RE: Re: Invalidation

Sorry if my proposed text was construed as wanting to change in
something in the DDP spec. It was pointed out to me offline, and it
certainly wasn't my intention. I'm perfectly fine with saying a remote
invalidate MUST invalidate the local STag (as the current DDP draft
states) and that this needs to be directly addressed in the security
draft for how that effects trust models and mitigations.

So here's proposed new text:


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 where the Remote Peer may attempt to invalidate
the STag prematurely, the application SHOULD NOT allow an STag to be
valid across multiple connections.



Jim






> -----Original Message-----
> From: Caitlin Bestler [mailto:[email protected]]
> Sent: Thursday, October 02, 2003 7:49 AM
> To: Jim Pinkerton
> Cc: [email protected]; David Black
> Subject: Re: [rddp] 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.
> 
>