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

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

Nate,

I agree with you.
If the document defines what a well-behaved target is and defines what a
well-behaved initiator is, then your copy manager should be able to
function correctly, as you suggest.  Now, whether the document does those
two things well is ..... :-{)

Jim Hafner


"Nate Lawson" <nate@decru.com> on 07-24-2001 12:04:38 PM

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:
Subject:  RE: iSCSI: "when a target acts as an initiator..."



I agree that the standard should not specifically try to address copy
manager behavior, however, the standard should do nothing to prevent it.  A
well-behaved copy manager is simply a well-behaved target + well-behaved
initiator.  I certainly hope nothing in the the standard disallows this!

-Nate

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Jim Hafner
> Sent: Tuesday, July 24, 2001 10:41 AM
> To: ips@ece.cmu.edu
> Subject: iSCSI: "when a target acts as an initiator..."
>
>
> 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
>
>