Re: iSCSI: Login Proposal

[Steve Senum <ssenum@cisco.com>]

Hi Stephen,

I think the assumption is that <something> is usually
preferred over <none>.

Even if an option is required to be implemented
though (like crc-32c), an Initiator or Target
could be configured to not allow it (including <none>).
However, in such cases, it would be easy to get
into a situation where the Initiator and Target
will never agree and no connection is possible.
I think the offering party (usually the Initiator)
need to be allowed to control the preference.

Steve Senum

"Wheat, Stephen R" wrote:
> 
> Yup, I thought I had seen it, but couldn't find it; thanks.  And am now
> embarrassed that I couldn't find it, when it was indeed documented in two
> places.  I'll save related comments for when we go through the spec clean-up
> phase.
> 
> So, the second paragraph you cite from both p22 and p100 imply that a target
> could avoid selecting "none".  Thus, the initiator could prefer "none", but
> the target still select another initiator-offered value, hence avoiding the
> situation you propose, where "none" is always selected.
> 
> Yes?
> 
> Otherwise, how would a target and initiator be able to select "none", in the
> presence of the ability to mutually do at least one method?
> 
> Aren't there times where either could do all protocols, but both would
> *prefer* to do "none"??
> 
> Perhaps my question then is to get Para5 of 1.2.4 on p22 slightly clarified,
> so as to avoid your conclusion.  I.e., the initiator should be allowed to
> prefer "none" over something else, yet have the target be capable of not
> selecting "none".
> 
> Again, I agree with you that the new-and-improved-login proposal would be
> even better with a requirement to have the initiator include its security
> parameters, even if they consist of only "none".
> 
> Stephen
> 
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Tuesday, August 21, 2001 2:31 PM
> To: ietf-ips
> Subject: Re: iSCSI: Login Proposal
> 
> Hi Stephen,
> 
> The current draft (-07) does actually answer your
> question, though it is somewhat buried:
> 
> On page 22:
> 
>         In "list" negotiation, the offering party sends for each key a list
>         of values (which may include "none") in its order of preference.
> 
>         The responding party answers with the first value from the list it
>         supports and is allowed to use for the specific initiator.
> 
> And on page 100:
> 
>           -The initiator sends a text command with an ordered list of the
>            options it supports for each subject (authentication algorithm,
>            iSCSI parameters and so on). The options are listed in the
>            initiator's order of preference.
> 
>            -The target MUST reply with the first option in the list it
>            supports and is allowed for the specific initiator....
> 
> Even so, I don't see the value in:
> 
> AuthMethod=none,CHAP
> 
> Since every implementation must support "none", "CHAP"
> will never get picked.
> 
> In the interest of keeping login processing as simple as
> possible, I would simply require the initiator to offer
> what it can support (if anything).  The target can then
> pick a compatiable method, or reject the connection.
> 
> Steve Senum
> 
> "Wheat, Stephen R" wrote:
> >
> > Good questions, Steve.
> >
> > Question 2 caused me to ponder the concept of key-value preferences.
> I.e.,
> > I suspect that the concept in the proposed login spec was to address that
> > the initiator may prefer to not have any security digests, but might be
> able
> > to negotiate them if the target insisted.
> >
> > I cannot find anywhere in the I-D that states that a recipient MUST
> consider
> > key=v1,v2,v3 as the sender having preference of v1 over v2, and v2 over
> v3.
> > Thus, I second Q2, but only if key values are to be interpreted in
> > preferential order.  Thus, an initiator could send
> > "DataDigest=none,crc32-c,SPKM", and the target's response MUST honor the
> > preference order.
> >
> > So, Q4 is: should the values in a key-value list be consider the sender's
> > preference order that the receiver must honor?
> >
> > Stephen
> >
> > -----Original Message-----
> > From: Steve Senum [mailto:ssenum@cisco.com]
> > Sent: Tuesday, August 21, 2001 1:14 PM
> > To: ietf-ips
> > Subject: Re: iSCSI: Login Proposal
> >
> > Matthew/Marjorie/Bob:
> >
> > Some questions on your login proposal:
> >
> > 1. Why the following restriction?
> >
> >     SecurityContextComplete=yes MUST NOT be present
> >     in the login command.
> >
> > I don't see the benefit in not allowing something like:
> >
> > I: AuthMethod:none
> >    HeaderDigest:crc-32c,none
> >    DataDigest:crc-32c,none
> >    SecurityContextComplete=yes
> > T: AuthMethod:none
> >    HeaderDigest:crc-32c
> >    DataDigest:crc-32c
> >    SecurityContextComlete=yes
> >
> > 2. In the following:
> >
> >     If the login command does not contain security parameters
> >     the target MUST perform one of the two actions below:
> >
> >     a) If the target requires security negotiation
> >        to be performed, then it MUST enter the security
> >        phase and MUST send a text response containing
> >        one or more security parameters and F=0.
> >
> >     b)
> >
> > Is this really needed?  Why not simply require the
> > initiator to offer security parameters if it supports them?
> > I would hope authentication would become the typical case
> > for login.
> >
> > 3. Is there only one Login Reponse then (just asking)?
> >
> > Regards,
> > Steve Senum