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

["Douglas Otis" <dotis@sanlight.net>]

Daniel,

While you are right about the Internet using DNS to find public IPs and
systems will automatically resolve a name to an IP using DNS unless already
entered into the routing table, it is not right to assume this information
must be include within a SCSI transport.  Developing what could be described
as LDAP or a Web CGI and at the same time contend it to be the only means to
get the job done is redeveloping these servers within the SCSI transport.  A
much smaller effort could extend inter-operability with already prevalent
servers understood by IT.  The means of getting a browser, mail program, and
may other network devices configured within an enterprise environment is
with an LDAP server.  Rather than reinventing the Web CGI or LDAP server and
cramming it into a SCSI transport, split it out of the transport layer.
Identifying a connection is a small price to pay.  In addition, it would
provide a higher level of control rather than depending on DNS to provide a
point of entry.  It is not surprizing to see DNS take a day to update.  If
you had a problem with your router flapping, even longer.  You would want a
scheme that the IT manager can control and not a new database you just
invented and wedged into a target device.

Doug

> -----Original Message-----
> From: Daniel Smith [mailto:dfsmith@almaden.ibm.com]
> Sent: Monday, October 02, 2000 12:25 PM
> To: Douglas Otis
> Cc: julian_satran@il.ibm.com; ips@ece.cmu.edu
> Subject: Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
>
>
> 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
>