RE: Re: Invalidation

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.




> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
Jim
> Pinkerton
> Sent: Wednesday, October 01, 2003 8:42 PM
> To: Caitlin Bestler; [email protected]
> Cc: David Black
> Subject: RE: [rddp] Re: Invalidation
> 
> 
> David,
> 
> From reading your email, it sounds like you are thinking there is a
> layering violation? Is that your point?
> 
> If so, I'd claim otherwise. Clearly there is an interface above DDP to
> enable a buffer to be mapped to an STag, and just as clearly there is
an
> interface to invalidate that mapping. Thus to me all that is happening
> is RDMAP, as the ULP to DDP, is calling the invalidate mechanism for a
> DDP STag.
> 
> On Caitlin's points below, I agree with the Quirk summary, and also
> agree that we should make it clear that the local peer can choose to
> configure an STag to never be invalidated (regardless of whether an
> invalidate STag is received). This is effectively a DOS attack
otherwise
> (and I'll add it to the security draft).
> 
> 
> 
> Jim
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> > Caitlin Bestler
> > Sent: Tuesday, September 30, 2003 8:14 AM
> > To: [email protected]
> > Cc: David Black
> > Subject: [rddp] Re: Invalidation
> >
> >
> > On Monday, September 29, 2003, at 02:12 PM, [email protected]
wrote:
> >
> > > (2) Invalidation.  We have a lingering issue from way back
> > > 	when that RDMAP is handling invalidation of STags,
> > > 	which are DDP level resources.  This needs some
> > > 	serious examination in this forum.
> >
> > I'm not sure I remember anything that qualifies as an
> > "issue". There are certainly some quirks that relate to
> > the fact that the invalidation is inherently asynchronous
> > because it is processed on the "completion track" and at
> > least theoretically by a different layer (and hence potentially
> > as well).
> >
> > Quirk #1: Invalidation is not a fence. "Later" DDP Segments
> > may be placed prior to the invalidation -- even if received
> > in order. Invalidation offers no guarantees to the sender,
> > only to the receiver. And the receiver is only guaranteed
> > that there will be no further placements *when the notice
> > of the invalidation is delivered*. The only guarantee about
> > what was placed at that point is that *earlier* DDP segments
> > will have been placed. There is no guarantee that *later*
> > DDP segments were *not* placed.
> >
> > Quirk #2: Invalidation may or may not disrupt an in-process
> > RDMA Read. That is, there is no specification on *when* an
> > RDMA Read engine translates STags.
> >
> >
> >
> > The last issue is that the current wording does not allow
> > a local implementation to suppress remote invalidation on
> > specific tags. This essentially prevents exporting STags
> > that are associated with permanent data structures such
> > as Memory Regions (as opposed to windows). That should be
> > fixed.
> >
> > In general, remote invalidation should not be viewed as
> > providing any guarantees to the remote side. It is a
> > service to the local ULP. While it ought to remain
> > mandatory to implement, the local ULP should have
> > the option of not using it for a specific STag.
> >
> >
> >
> > _______________________________________________
> > rddp mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/rddp
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp