Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]

[Daniel Smith <dfsmith@almaden.ibm.com>]

I'll reply to this piece-by-piece as there seem to be a lot of
misconceptions.

(On a side note, I haven't seen any alternative proposals put forward to the
URL scheme as noted.  If things stay this way, then I'll put it forward as
an Internet-Draft.)

Okay, off we go.

Douglas Otis wrote:
> 
> If you wished to crack data being sent via IP, could you ask for a better
> tag of such information- scsi://<domain-name>[/modifier] being sent in clear
> text down the same connection?  Of course, the same is true for login as

<domain-name> will always be sent "in the clear" at some point on the
network.  There's not a lot we can do about that.  The IP address will
always be visible in all packets.  (Insert comments here about why VPNs are
a good thing here....)

In an SSL link, or IPsec the [/modifier] part will be encrypted.  Indeed,
whenever security is tight, the [/modifier] will only be sent after
clearance is granted.

Why?

Let's imagine a large array of fast, reliable and featuresome storage---an
IBM Shark box say.  B-) This box has many user accounts, and is being used
in the context of a storage service provider.  The login sequence might go
something like this....

I: Hello Shark---I'm an initiator.  My authentication ID is "Robert Smith,
   Seattle, next to the donut store, hjhhaskjanbt112kg9d988".

S: Hello initiator.  I'll be your server---we need a secure connection:
   switch to "hjcnneamchjsdkfsdsd394njsdf89423".  (Trivial example.)

I: <encrypted> Alright!  I want to connect to
   "scsi://niceshark.acme.com/bobsstorage/san3?wwn=0x7b4d72658a7410db"

Then we have a choice...

S: <encrypted> Great---off you go and have a nice day.

or

S: <encrypted> Sorry---you haven't got permission to use that any more/it
   doesn't exist.

or (just after they buy more storage)

S: <encrypted> Ok, that URL has been changed to
   "scsi://bobstorage.san3.acme.com:9003/".  Please come again.

> well.  Here again "who, what, and where" are nicely presented in easy to
> read form.  Neither SCSI clients nor servers are likely able to authenticate
> independently or retain textual information.  Both the client and server
> should depend on some outside database.  This compromise in security was

If security is needed, then security is needed and there are no short cuts! 
Whether stored locally or remotely, that information needs to be somewhere,
and securely accessible too.

> done to eliminate an IP selection option but then a textual means of
> including IP was included to ensure all modes of operation remain.  Rather
> than using a secure and opaque means to establish a connection using an
> independent means of authenticating on a different connection, the entire
> function was included in this all encompassing draft.  This was not a good
> choice in my view.

There is no requirement that only the Initiator and Target MUST authenticate
between /themselves/ only.  This may be desirable (in case the
authentication database machine goes down.) There are many papers written on
this subject; for a simple introduction, see "Secure Distributed Computing",
Sci. Am., Nov 1994 pp72--76.  This will give you an idea of what the minimum
requirements are in an open network authentication realm.

> By creating a separate draft to define an authentication database access
> (LDAP structures), options remain possible without impact on the transport
> specification.

URLs have very little impact on the transport.  The iSCSI draft just handles
arbitrary length text strings to identify resources---and that's all it
cares about.  The only time interpretation of this is requred is for
3rd-party commands, when we don't have a choice about it---and technically
the transport still doesn't care about it.  We DO want it standardized.  We
DON'T want it tied to the transport.  In 2003 when iSCSIv5 over SCTP with
Microsoft Active Super Directory v3 running over IPv8 on terrabit-RS232, the
naming scheme should still be handled by the transport.

>                 The only aspect of authentication within the transport
> should be a cookie.  Authentication provides access at some IP and port or

Please forgive my ignorance, but isn't a cookie an arbitrary length text
string (or can be mapped to and from an arbitrary length text string). 
Cookies as /constant/ entities is an extremely bad idea.  That's why we
don't recommend it.  Okay, cookies are really small delicious disks,
sometimes with chocolate chips---what do you mean by cookie?

> perhaps a set of such locations, it could also provide third-party mapping
> in binary as well.  (This mapping could be encoded by various schemes.)  As
> other transports are employed, flexibility becomes important.  Why insist
> targets do DNS lookup?  Keep the workload light as such lookups should never

We don't.  Where did you get this idea?  If it found its way into the drafts
then please point it out so that we can remove it!  Target DNS resolution is
always optional; though sometimes (perhaps often in the Shark example) it is
useful, and perhaps required by the system designer.  Initiator DNS
resolution is mandatory.  (Except in the case where an initiator is allowed
interpret, say, "scsi://123.45.67.89".)

> be needed beyond the process of authentication rightfully done by other
> equipment not involved in the time critical data handling.  I hope this is
> comprehendible this time.

It would be more comprehensible if you gave an example of where the scheme
as currently proposed fails.  Then we can work to fix it and produce a more
baked Internet-Draft for interpreting iSCSI service delivery port names.

Daniel Smith.

[Mmm.  Cookies.]
-- 
IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010