Subject: [storm] iSER approach - update

From: <[email-masked]>
Date: Thu, 3 May 2012 18:29:00 -0400

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Michael Ko <[email-masked]>
Date: Fri, 4 May 2012 10:05:23 -0700

David,

I agree with your summary.

Mike

On Thu, May 3, 2012 at 3:29 PM, <[email-masked]> wrote:

> _______________________________________________
> storm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/storm
>

---

From: <[email-masked]>
Date: Tue, 15 May 2012 13:54:45 -0400

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

> 	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: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, May 03, 2012 6:29 PM
> To: [email-masked]
> Subject: [storm] iSER approach - update
>

---

From: Michael Ko <[email-masked]>
Date: Wed, 16 May 2012 20:47:21 -0700

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

---

From: <[email-masked]>
Date: Thu, 17 May 2012 09:51:12 -0400

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:[email-masked]]
Sent: Wednesday, May 16, 2012 11:47 PM
To: Black, David
Cc: [email-masked]
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.

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

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, <[email-masked]<mailto:[email-masked]>> 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.

Thanks,
--David

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> +1 (508) 293-7953<tel:%2B1%20%28508%29%20293-7953>             FAX: +1 (508) 293-7786<tel:%2B1%20%28508%29%20293-7786>
> [email-masked]<mailto:[email-masked]>        Mobile: +1 (978) 394-7754<tel:%2B1%20%28978%29%20394-7754>

---

From: <[email-masked]>
Date: Fri, 18 May 2012 19:06:50 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, May 17, 2012 9:51 AM
To: [email-masked]
Subject: [storm] iSER - new security text: Please review
Importance: High

Thanks,

OLD

NEW

END

Mike

Thanks,
--David