Re: [storm] iSER approach - update: Next Steps

[Michael Ko <[e-mail]>]

I am submitting the proposed changes pertaining to item (v) in David's note
that David and I (mostly David) worked out to be reviewed by the group
before they go into the new iSER draft.

These are the changes to sec. 2.4.1:

OLD

The iSER layer at the initiator is required to invalildate the Advertised
STag upon a normal completion of the associated task.  The Send with
Invalidate Message, if supported by the RCaP layer (e.g., iWARP), can be
used for automatic invalidation when it is used to carry the SCSI Response
PDU.  There are two exceptions to this automatic invalidation -
bidirectional commands, and abnormal completion of a command.  The iSER
Layer at the initiator is required to explicitly invalidate the STag in
these cases, in addition to sanity checking the automatic invalidation even
when that does happen.

NEW

The iSER layer at the initiator SHOULD invalidate the Advertised STag upon
a normal completion of the associated task.  The Send with Invalidate
Message, if supported by the RCaP layer (e.g., iWARP), can be used for
automatic invalidation when it is used to carry the SCSI Response PDU.
There are two exceptions to this automatic invalidation - bidirectional
commands, and abnormal completion of a command.  The iSER Layer at the
initiator SHOULD explicitly invalidate the STag in these two cases.  That
iSER layer MUST check that STag invalidation has occurred whenever receipt
of a Send with Invalidate message is the expected means of causing an STag
to be invalidated, and MUST perform the STag invalidation if the STag has
not already been invalidated (e.g., because a Send message was used instead
of Send with Invalidate).

If the Advertised STag is not invalidated as recommended in the foregoing
paragraph (e.g., in order to cache the STag for future reuse), the I/O
Buffer remains exposed to the network for access by the RCaP.  Such an I/O
Buffer is capable of being read or written by the RCaP outside the scope of
the iSCSI operation for which it was originally established, which has both
robustness and security considerations.  The robustness considerations are
that the system containing the iSER initiator may react poorly to an
unexpected modification of its memory.  For the security considerations,
see Section 11.

END

Here is a new Security Considerations paragraph for Section 11:

A valid STag exposes I/O Buffer resources to the network for access via the
RCaP.  The security considerations referred to in the above paragraphs
provide means of controlling that access in order to prevent undesired
disclosure or modification of data in the I/O Buffer.  These considerations
are of heightened importance for implementations that do not invalidate the
STag after completion of the associated task (ISCSI I/O operation) because
the period of exposure is correspondingly longer.  For this reason, STag
invalidation after completion of the associated task is RECOMMENDED in
Section 2.4.1

Mike

On Tue, May 15, 2012 at 10:54 AM, <[e-mail]> wrote:

> Having seen no dissension, I believe (with WG chair hat on) that we have
> WG rough consensus for this updated approach to resolving the iSER issues
> around SendSE, SendInv and SendInvSE.
>
> Mike (Ko) - please update the draft accordingly, *BUT*, I want to see the
> Security Considerations and related caching text for the following item
> proposed to the list and worked out on the list before going into the next
> version of t he draft (I'd be happy to review a first draft of this text
> via private email if that would help):
>
> > v) Some new text will be needed (especially Security Considerations) to
> >       make it clear that STag invalidation is the initiator's
> responsibility
> >       for security reasons, and the initiator cannot rely on the target
> >       using an Invalidate version of Send - the initiator MUST check and
> >       do its own invalidation as required.  The initiator MAY choose to
> cache
> >       mappings (i.e., reuse STags) across I/Os for efficiency, but that
> has
> >       security consequences (exposes initiator memory to remote access
> for
> >       longer) that have to be discussed in the new Security
> Considerations text.
>
> In contrast, I believe the other five items are routine updates that can
> just be made in the next version of the draft.
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> > [e-mail]
> > Sent: Thursday, May 03, 2012 6:29 PM
> > To: [e-mail]
> > Subject: [storm] iSER approach - update
> >
> > Attempting to summarize where we are ... the changes from my earlier
> attempt
> > are:
> > - Dropped the MUST for error reporting by the receiver.
> > - Added a more general "SHOULD NOT use" to iii).
> > - Added caching discussion and need for yet more security considerations
> >       text to v).
> > - Added a warning about relying on SendSE and SendInvSE at receiver -
> new item
> >       vi).
> >
> > Are we getting closer?  Here's the new version:
> >
> > i) Some iSER implementations have not followed RFC 5046's strict
> requirements
> >       for use of SendSE, SendInv and SendInvSE; they use Send instead.
> > ii) For interoperability, iSER implementations SHOULD accept and
> correctly
> >       process SendSE, SendInv and SendInvSE messages.
> > iii) SendSE, SendInv and SendInvSE are to be regarded as optimizations or
> >       enhancements to the basic Send message, and their support may vary
> by
> >       RCaP protocol and specific implementation.  In general, these
> messages
> >       SHOULD NOT be used, unless the RCaP requires support for them in
> all
> >       implementations.  If these messages are used, the implementation
> SHOULD
> >       be capable of reverting to use of Send in order to work with a
> receiver
> >       that does not support these message (and we need to note that
> attempted
> >       use of these messages with a peer that doesn't support them may
> result
> >       in a fatal error that closes the RCaP connection).  A specific
> instance
> >       that needs to be noted is that these messages SHOULD NOT be used
> with
> >       the InfiniBand RCaP because InfiniBand does not require support
> for them
> >       in all cases.
> > iv) New iSER implementations SHOULD use Send (and not these three
> additional
> >       messages) unless there are compelling reasons for doing otherwise
> >       (latter is implicit in use of "SHOULD", but worth saying
> explicitly,
> >       IMHO).
> > v) Some new text will be needed (especially Security Considerations) to
> >       make it clear that STag invalidation is the initiator's
> responsibility
> >       for security reasons, and the initiator cannot rely on the target
> >       using an Invalidate version of Send - the initiator MUST check and
> >       do its own invalidation as required.  The initiator MAY choose to
> cache
> >       mappings (i.e., reuse STags) across I/Os for efficiency, but that
> has
> >       security consequences (exposes initiator memory to remote access
> for
> >       longer) that have to be discussed in the new Security
> Considerations text.
> > vi) Similarly, iSER implementations SHOULD NOT rely on events triggered
> by
> >       SendSE and SendInvSE, as these messages may not be used.  In
> contrast
> >       to invalidation, there are no security consequences in this aspect.
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------
>