SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI - Change - Login/Text commands with the binary stage code



    Bill-
    
    In Irvine, we agreed that when IPsec is enabled, IKE will be used
    to do key exchange.  We also agreed on which transforms to use when
    IPsec is enabled.
    
    The key word is "enabled".  Keep in mind that there will probably
    be three classes of iSCSI implementations "out there":
    
    1. iSCSI implementations without security.  These won't be able to
       say they are "compliant", but are likely to be the majority of
       implementations, at least for a little while.  At any rate, we
       all pay our marketing folks to get us around this one.
    
    2. iSCSI implementations with software security.  These will add
       IPsec in software for one of two reasons: either high performance
       is not required (perhaps it's designed to go over a T1 or something),
       or just so the "RFC-xxxx-compliant" bullet can be checked off on
       the list.  If it's for the first reason, IPsec will be used by
       some customers; if it's for the second reason, it will likely
       never be enabled.
    
    3. iSCSI implementations with hardware security.  These will be
       serious implementations that include IPsec, and can perform
       well enough that a customer will want to use IPsec.  These
       implementations will enable IPsec if the customer needs it, but
       again, might not enable it if this is not a concern.
    
    Your assumption seems to be that because we chose IPsec/IKE, that
    it will always be used.  Given the implementations 1 and 2, and
    some of 3, that is not always the case.
    
    As you mentioned, when your assumptions are correct, the login
    phase only has to exchange initiator and target names, and can
    use AuthMethod=none if it likes.  However, those assumptions
    will not always hold.
    
    --
    Mark
    
    Bill Strahm wrote:
    > 
    > Ok,
    > 
    > I am confused here (or maybe it is just a lag effect for me)
    > 
    > I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
    > So basically the process is this
    > 
    > 1) Administrator makes several entries into a Security Policy Database
    > 2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine
    > 3) The IPsec packet filter detects this packet, realized there isn't a
    > security association for it, and asks the Security Policy Database what to
    > do about it
    > 4) The security Policy Database may determine that an IPsec SA needs to be
    > established so tells IKE to negotiate with the remote peer
    > 5) An IKE negotiation proceeds until either it succeeds or fails
    > 6) If it fails, packets are dropped
    > 7) If it succeeds, the negotiated SAs are pushed to the IPsec packet filters
    > 8) The origional TCP-SYN packet is now sent out under the IPsec SA that was
    > negotiated.
    > 
    > Now under this scenario there is no need for iSCSI to negotiate security at
    > all.  I DO now see the need to include an iSCSI Login phase that includes
    > passing user identities across so targets and initiators can identify
    > themselves, but this is over a secure link (see the above discussion) so I
    > can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
    > will secure it for me...
    > 
    > Bill
    > Sanera Systems Inc.
    > -----Original Message-----
    > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > Julian Satran
    > Sent: Wednesday, August 29, 2001 2:40 PM
    > To: ips@ece.cmu.edu
    > Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
    > code
    > 
    > Steve,
    > 
    > Implement and use are different terms. An administrator might set it up not
    > to use security under specific conditions.
    > 
    > Julo
    > 
    > Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28
    > 
    > Please respond to Steve Senum <ssenum@cisco.com>
    > 
    > Sent by:  owner-ips@ece.cmu.edu
    > 
    > To:   ietf-ips <ips@ece.cmu.edu>
    > cc:
    > Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
    >       code
    > 
    > Julian,
    > 
    > In the following section:
    > 
    >    If the initiator decides to forego the SecurityNegotiation stage it
    >    issues the Login with the CNxSG set to LoginOperationalNegotiation in
    >    the current stage and the target may replay with a Login Response
    >    indicating that it is unwilling to accept the connection without
    >    SecurityNegotiation and terminate the connection.
    > 
    > This seems contrary to the requirement to implement
    > authentication (at least AuthMethod=SRP).  I realize
    > this could also be a configuration issue, but I wonder
    > if the spec should at least strongly recommend starting
    > with phase SecurityNegotiation, or better yet, make it
    > a SHOULD?
    > 
    > Regards,
    > Steve Senum
    
    -- 
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    


Home

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