Re: [storm] iSER - new security text: Please review

[<[e-mail]>]

Having seen no comments, Mike should incorporate this text into the revised iSER draft (along with changes for the other items) and submit the result.  If I find anything that needs attention, I'll put it into an RFC Editor Note as part of the RFC publication request.

Mike - please make sure to update the summary of changes from RFC 5046 in Appendix A of the new draft.

Thanks,
--David

From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, May 17, 2012 9:51 AM
To: [e-mail]
Subject: [storm] iSER - new security text: Please review
Importance: High

Any review and comments on this new text need to happen ASAP, as the revised iSER draft will probably be submitted and an RFC publication request for it sent to the IESG over this coming weekend.  Now that we *finally* have an approach to this issue that appears to work, I really do want this draft moving onward ...

Also, I will be on vacation with effectively no email access May 25-June 11.  After I get back, we're going to need to take up the RDMAP extensions draft.

Thanks,
--David (as storm WG co-chair)

From: Michael Ko [mailto:[e-mail]]
Sent: Wednesday, May 16, 2012 11:47 PM
To: Black, David
Cc: [e-mail]
Subject: Re: [storm] iSER approach - update: Next Steps

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]<mailto:[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]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of
> [e-mail]<mailto:[e-mail]>
> Sent: Thursday, May 03, 2012 6:29 PM
> To: [e-mail]<mailto:[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]<tel:%2B1%20%28508%29%20293-7953>             FAX: [phone]<tel:%2B1%20%28508%29%20293-7786>
> [e-mail]<mailto:[e-mail]>        Mobile: [phone]<tel:%2B1%20%28978%29%20394-7754>
> ----------------------------------------------------