RE: iSCSI: Option Preference (was Login Proposal)

["Julian Satran" <Julian_Satran@il.ibm.com>]

Marjorie,

If you'll take the time and go through all the scenarios (I know that your
time is precious :-))
you'll find that the order of "exposing" preferences in a negotiation does
not matter if the negotiation is symmetric (and it is).
As we are bound to a certain order of things by the main function (command
processing) we start all exchanges at initiator.
Having the initiator send an empty request only because you think that in
most cases the target dictates authentication
seems a vaste of bits (and time) - contrary to your assertion. This is why
we never gave any example involving it.
But it is certainly a legal sequence in the current draft.  To force
everybody to use it - BAD IDEA.
I assume that as storage gets more decoupled from systems the need for
mutual authentication will increase (why would you believe that
the volume given to you over the net is where you wrote your precious data
last time?).

Julo



"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 23-08-2001 02:08:30

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: Option Preference (was Login Proposal)



That really makes the most sense to me.  IMO, having the initiator
"request"
authmethods is kind of a waste of bits.  The model I have in mind is that a
target basicly has one AuthMethod and all initiators that want to access it
either MUST use that AuthMethod (external "storage service provider" model)
or may either use that AuthMethod or none.  I'm having a hard time
imagining
poor little targets implementing multiple authMethods in the same box and
actually allowing initiators with different authMethods to access it
simultaneously.  In any case, seems like there's little value in having the
initiator offer a list of AuthMethods.  Makes more sense for the initiator
to request login, and the target to return the required AuthMethod.  If the
initiator can't handle it, it terminates the exchange.  That's my
understanding of how client-server auth relationships usually work.
Actually, typically the client is simply expected to know the required
AuthMethod (thru configuration) and begins the exchange by requesting
authorization.

Marj

> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Wednesday, August 22, 2001 3:24 PM
> To: ietf-ips
> Subject: Re: iSCSI: Option Preference (was Login Proposal)
>
>
> Not to try to beat this into the ground anymore
> then already has been done, but...
>
> Many months ago, when I first looked over
> the iSCSI spec, I remember thinking it was
> kind of odd for the side being authenticated
> to control the possible options.  Other
> protocols I have worked with would have the
> side driving the authentication (i.e., the Target)
> control this.
>
> If the IPS group wants to stay with the
> current target-really-controls-authentication
> notion, we might want to go a step further,
> and allow only the Target to send the AuthMethod
> key out.
>
> Just a thought,
> Steve Senum
>
>