iSCSI: "when a target acts as an initiator..."

["Jim Hafner" <hafner@almaden.ibm.com>]

Folks,

Draft 07 contains, in clause 1.2.7, the following paragraph concerning copy
manager type functions:

"When a target has to act as an initiator for a third party command, it MAY
use the iSCSI Initiator Name it learned during login as required by the
authentication mechanism to the third party."

I believe this paragraph should be deleted for the following reasons:
1) by saying 'MAY' it doesn't define the behavior well-enough
2) without careful review, this could open gapping security holes (e.g.,
under what conditions can I pretend to be someone else?)
3) generally speaking, a "target acting as an initiator" (aka copy manager)
is just another initiator in the world.  The fact that it's acting on
someone else's behalf is pretty much lost (particularly at the SCSI layer).
4) copy managers usually have more rights than the requesting initiator,
consequently, this may be a bad thing.
5) copy managers may be acting more on behalf of an enterprise level backup
operation and not specifically on behalf of the requesting initiator
through which the SCSI command is sent (e.g., the backup app could use
InitiatorA as the "conduit" for delivering an Extended Copy command that
moves InitiatorB's data around in the SAN - in this case, pretending to be
'A' wouldn't do the copy manager any good).

As seen from this post and the previous one on Copy Manager session type,
there is a lot of ill-defined stuff in the document about third party
issues.   I would suggest that this is a complex issue and that it needs to
be addressed in its entirety.  To facilitate this, I would recommend that
we avoid this topic for the first version of the iSCSI standard (it's not a
critical component at all), remove all specific behavior specifications
(required or otherwise) concerning third party/copy manager/etc. and save
this for a more detailed review in a second generation of the standard (if
a need arises).

Comments?
Jim Hafner