[storm] iSER approach - update: Next Steps

[<[e-mail]>]

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]
> ----------------------------------------------------
> 
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm