SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: Login Proposal



    none first is definitely legal (although it may invite the question "who's
    first" :-))  Julo
    
    "Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 22-08-2001
    03:13:21
    
    Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI: Login Proposal
    
    
    
    We're so close!!  See comments (***) below,
    Stephen
    
    -----Original Message-----
    From: Steve Senum [mailto:ssenum@cisco.com]
    Sent: Tuesday, August 21, 2001 4:56 PM
    To: ietf-ips
    Subject: Re: iSCSI: Login Proposal
    
    
    Hi Stephen,
    
    I think the assumption is that <something> is usually
    preferred over <none>.
    *** But we have the option to specify deterministic behavior,
    *** over accepting assumptions.
    
    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.
    *** yes, yes, yes, yes, so let it be possible to put <none> first.
    *** We get determinism and flexibility.
    
    
    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
    
    
    
    


Home

Last updated: Tue Sep 04 01:03:57 2001
6315 messages in chronological order