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

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

Julo,

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
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
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.

By creating a separate draft to define an authentication database access
(LDAP structures), options remain possible without impact on the transport
specification.  The only aspect of authentication within the transport
should be a cookie.  Authentication provides access at some IP and port or
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
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.

Doug



> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> julian_satran@il.ibm.com
> Sent: Monday, October 02, 2000 3:05 AM
> To: ips@ece.cmu.edu
> Subject: RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
>
>
>
>
> Doug,
>
> That is a nice and very long response. But what was the question?
>
> Julo
>
> "Douglas Otis" <dotis@sanlight.net> on 29/09/2000 22:21:32
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
>
>
>
>
> Julo,
>
> You would not authenticate exclusively from a single token out of
> the blue.
> There must be an additional layer of authentication that indicates
> IP:Port[]
> x is customer 'y' and today they wish to connect to target z[].
> Only in the
> most simplest configurations would a flat file provide this information.
> You could easily have two servers that manage the customer and target
> databases separately and join them using a 'Key.'  This join would be a
> database construct and not a SCSI.  This additional management layer will
> share with both ends and not pass over SCSI transport.  With this
> management
> layer, binary representations are adaquate and provide far less
> information
> to those wishing to crack data.  DNS, if used, would be run by a
> management
> layer and not a transport layer.
>
> Doug
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > julian_satran@il.ibm.com
> > Sent: Friday, September 29, 2000 6:15 AM
> > To: ips@ece.cmu.edu
> > Subject: Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
> >
> >
> >
> >
> > I would add that we wanted the path to be an additional
> > identifier that the
> > target could use
> > to determine what collection of LUs to present to the initiator.
> >
> > Julo
> >
> > csapuntz@csapuntz-u1.cisco.com on 23/09/2000 05:00:33
> >
> > Please respond to csapuntz@csapuntz-u1.cisco.com
> >
> > To:   "IP Storage" <IPS@ece.cmu.edu>
> > cc:    (bcc: Julian Satran/Haifa/IBM)
> > Subject:  Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
> >
> >
> >
> >
> >
> > Just for clarification... I was not proposing to add the extended
> > URL scheme for the transport spec. It isn't necessary.
> >
> > In this thread, Doug makes an excellent point about LDAP being a
> > superior mechanism for describing how to connect to the
> > storage. Directory services such as LDAP, as Doug has pointed out,
> > will be critical to managing large quantities of storage. A host can
> > ask such a directory service for a list of storage devices it should
> > mount and how to connect to those storage devices. The query against
> > the directory server that returns this information can be based on
> > machine ID, user ID, operating system ID, or even the owner's
> > birthday. One of the things discovery will end up doing, no doubt, is
> > defining LDAP schemas that describe how to connect to storage
> > (i.e. use SCTP or TCP, what port, what target name, what LUN, what
> > WWN, how to authenticate, etc.).
> >
> > However, there is one place where the transport protocol has to define
> > a name: third party commands. There needs to be some kind of global
> > name which the initiator can pass to the target. The name must be
> > distillable into a string. The target must understand the name and
> > be able to use the information to establish a connection to
> > another target.
> >
> > One could say that the string that is passed is not specified by the
> > standard but instead specified by some management software. I think
> > this will lead to poor interoperability.
> >
> > The SCSI URL-type name is the current proposal for target name.
> >
> > Why is SCSI target name made up of a hostname + a path? Why is the
> > hostname + path passed on connection setup? There are two reasons.
> > I think NAT and IPv6 makes passing hostnames rather than addresses in
> > protocols more desirable. Hostnames can be re-resolved as you cross
> > addressing boundaries. The path is there so that the name can
> > support multiple targets behind a single IP address without having
> > to add entries to the DNS server. At Cisco, for example,
> > I have no control over the local DNS servers and cannot
> > add DNS entries for the ATAPI DVD and floppy in my computer.
> >
> > _Costa
> >
> >
> >
>
>
>
>