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



    Bernard,
    
    Thanks for the response.  After reading the dhcp-13.txt document
    and your clarification a couple of times, I am not quite clear on
    a couple of aspects here - most possibly because I am not that familiar
    with IPSec.... Additional responses to comments below would be 
    very helpful.
    
    Your reference to the desirability of not changing the existing 
    security gateways below makes me think you're visualizing a scenario 
    with two security gateways operating in tunnel model in the path 
    from a initiator (with a DHCP-assigned IP address) and a target.
    
    > For iSCSI with dynamically assigned addresses,...
    
    You sound like you're referring to the original routable IP 
    address of the initiator itself being assigned via DHCP, but refer 
    to the dhcp-13 draft which has to do with the "virtual host" 
    receiving a DCHP-assigned address.  
    
    Also, in the two-gateway scenario, would it be the gateway (the
    tunnel end point) that receives a DHCP address, than the initiator?
    Or, are you referring to a scenario with two DHCP relays in both
    security gateways - ultimately with the "virtual host" in the 
    initiator?
    
    My reading of the dhcp-13 draft is that it is predicated on the
    requirement - "making the remote host appear to be present on the
    local corporate network is quite useful".  Could you please 
    comment why - is it because the routers within the corporate 
    network might discard packets destined to non-local addresses?
    
    > ..., and we would not have interoperability.
    
    If I understand this correctly, you're referring to gateways 
    receiving dynamically assigned addresses (than the initiators).
    
    Since iSCSI does not really require/prohibit external security 
    gateways (since it's really product packaging), I am not sure that
    iSCSI needs to say anything about external security gateway 
    compatibility.
    
    Regards.
    
    -- 
    Mallikarjun 
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668	Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    Bernard Aboba wrote:
    > 
    > >- 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."
    >
    


Home

Last updated: Sat Dec 08 02:18:00 2001
8018 messages in chronological order