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



    Matthew,
    
    At the risk of violating IETF protocol, I have a new question on the Login
    Proposal and a comment on Steve's earlier question.  Please let me know if I
    should really have segregated these into two messages.
    
    My question is: Does the Login Proposal propose Restart Login Command no
    longer be implemented?  If so, ok fine.  If not, then where can I find the
    logic of Restart and having it overlaid with Login versus having a message
    type of its own?  E.g., CoalesceCIDs:
    
    	CID 1 is in effect, but Initiator wants to restart it
    
    	I->T  Login CID2
          T->I .... full login process, yadda, yadda
    	I->T ....
    	T->I  Login CID2 accepted
    
    	I->T CoalesceCIDs CID1 to CID2
    
    	Target verifies CID1 and CID2 are equivalent in all aspects,
    		authentication, security, etc.  If so, Target Logs out CID1,
    		moves all CID1 state to CID2, and closes TCP connection
    associated with CID1.
    		The target then replies with success.  Both parties then
    mutually rename CID2
    		to be CID1.
    		If CID1 and CID2 are not equivalent, target logs out CID2
    with coalesce failure.
    
    Frankly, I don't know why we really would want Restart semantics, versus
    just logging it out.  And as such, I'd prefer removing Restart Login from
    the spec.
    
    ----------------------
    
    Regarding your answer to Steve's second question...
    
    Given the near consensus on the ability to have <none> listed first, second,
    ..., last, or not at all, it would appear that we could require an initiator
    to include all auth and digest methods it supports AND is willing to have
    selected by the target, in preferential order.
    
    In this case, all required flexibility exists, and several protocol
    scenarios are removed, thus simplifying the process.  Yes, this is at the
    cost of an extra message exchange, but only in what both you and Steve
    thought were rare cases.  Is the potential saving of that message exchange
    worth the additional scenarios?  I think not.
    
    Stephen
    
    -----Original Message-----
    From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
    [mailto:matthew_burbridge@hp.com]
    Sent: Wednesday, August 22, 2001 1:24 AM
    To: 'Steve Senum'; ietf-ips
    Subject: RE: iSCSI: Login Proposal
    
    
    Hi Steve,
    
    I forgot to answer your latter two questions in my earlier email!
    
    Comments within:-
    
    Cheers
    
    Matthew
    
    -----Original Message-----
    From: Steve Senum [mailto:ssenum@cisco.com]
    Sent: Tuesday, August 21, 2001 9: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.
    
    MATTHEW: So I was maintaining flexibility here.  If an initiator prefers not
    to negotiate security then why force it? Also, the login is faster if
    neither side want to negotiate security.  I think the majority of people
    would go for flexibility and provided that the procedure caters for all four
    scenarios of either side wanting/not wanting security then the flexibility
    should be present.  In other words, as long as the flexibility does not
    cause interoperability problems and allows everyone to do what they want to
    do then the flexibility should be there. I agree that the typical case would
    be to include authentication but some people will always want to skip it.
    
    3. Is there only one Login Reponse then (just asking)?
    
    MATTHEW: yes.  In deriving the proposal we came to the conclusion that the
    partial login response is unnecessary so we removed it.  Also, some
    implementers have said that this makes the implementation easier as they
    will always return a text response unless login is completed (successfully
    or otherwise).
    
    Regards,
    Steve Senum
    


Home

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