SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Comments on ips security draft



    
    >- Section 2.3, page 10.  "Conformant  iSCSI security implementations
    >MUST support ESP in transport mode. "
    >   I assume it should be tunnel mode....
    
    There is now a discussion going on on the SAAG mailing list about whether it 
    should be tunnel mode or transport mode. We'll talk more about this at IETF 
    52.
    
    One significant issue with tunnel mode for iSCSI doesn't arise in iFCP or 
    FCIP, since with iSCSI initiators, addresses may be dynamically assigned, 
    whereas with iFCP and FCIP, the expectation seems to be that the IP 
    addresses will be static. Static addressing for tunnel mode is a lot 
    simpler. For one thing, since the addresses and configuration are static, 
    you don't need to configure tunnel addresses and parameters on the fly. 
    Another implication is that you can use main mode with shared secrets, and 
    have a unique shared secret for each endpoint.
    
    For iSCSI with dynamically assigned addresses, life becomes more 
    complicated.  The implication is that if an iSCSI initiator with a 
    dynamically assigned address were to use tunnel mode, the tunnel mode 
    gateway at the other end would need to assign an IP address and otherwise 
    configure the tunnel. The IPSRA WG has recently put out a Proposed Standard 
    that addresses this issue, draft-ietf-ipsec-dhcp-13.txt. So if you want to 
    do tunnel mode within iSCSI and have it interoperate with the IETF Proposed 
    Standard for Tunnel mode configuration, you'll need to sign up for this too.
    
    The problem is that the goal was to be able to reuse existing IPsec gateways 
    -- if you have to significantly update the gateway, then this cancels one of 
    the advantages of doing tunnel mode. In the absence of referencing the IPSRA 
    WG standard for tunnel mode configuration, there would not be enough detail 
    to ensure interoperability between iSCSI security implementations. It would 
    be highly likely that some vendors would ship; their existing gateways which 
    typically do mode config (a proprietary protocol that is not on standards 
    track and may never even be published as an RFC) while others would do DHCP 
    config, and we would not have interoperability.
    
    Given that configuration is an essential part of IPsec tunnel mode setup for 
    dynamically addressed hosts, it is probably required that we reference the 
    proposed configuration method normatively. This would imply that if we go 
    with anything other than the IETF Proposed Standard, any documents, such as 
    iSCSI, which referenced these proprietary methods could not become IETF 
    standards.
    
    So if I believe this means that if we go with tunnel mode, we probably need 
    a normative reference to draft-ietf-ipsec-dhcp-13.txt as well. As the saying 
    goes "think carefully about what you ask for -- you might get it."
    
    
    >
    >- Section 3.3, page 17.  The well-known target port for iSCSI may
    >   be updated to 3260.
    
    This will be reflected in draft -07. A version of this in progress is 
    available at 
    http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-07.txt.
    
    >
    >- Section 3.4, page 18.
    >    "[d]  a specific connection be closed at the Target's request.  LP
    >      Command [d] is distinct from [b] in that it indicates that the
    >      connection is being closed in response to a request from the Target
    >      for it to be closed. Due to asymmetries in the iSCSI protocol,
    >      Targets cannot close a connection on their own initiative."
    >
    >   It needs to be reworded, since this is incorrect.  [d] is the same as
    >   [b].
    
    Do you have specific language you'd like to suggest?
    
    >
    >- I may be missing something, but the table listing IKE implementation
    >   sizes on page 28 seems completely out-of-context in the middle of
    >   a rekeying frequency discussion.
    
    Moved the table to be closer to the relevant text.
    
    >
    >Thanks.
    >--
    >Mallikarjun
    >
    >
    >Mallikarjun Chadalapaka
    >Networked Storage Architecture
    >Network Storage Solutions Organization
    >MS 5668	Hewlett-Packard, Roseville.
    >cbm@rose.hp.com
    
    
    _________________________________________________________________
    Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
    
    


Home

Last updated: Fri Dec 07 22:17:49 2001
8015 messages in chronological order