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

Re: [saag] RE: IP Storage and IPsec encapsulation



To add a bit to the debate, one has to consider not only the
impact of the tunnel vs. transport decision itself, but also the other
implications. For example, while iFCP and FCIP endpoints are
typically statically addressed, iSCSI initiators are often hosts with
dynamically assigned addresses. Therefore if tunnel mode is used with
iSCSI, there is a need to dynamically configure the tunnel parameters,
including IP address, configuration, etc. There is some additional
complexity required as a result, and also some potential pitfalls, since
most tunnel mode gateways don't yet implement the IPSRA WG recommendation
for tunnel mode config, draft-ietf-ipsec-dhcp-13.txt. I'd hate to see us
do a lot of work to specify how IPsec tunnel mode would be used to secure
iSCSI only to find that the implementations won't interoperate
because they were using various proprietary tunnel mode authentication and
configuration extensions.

Been there, done that ;)



On Thu, 29 Nov 2001, William Dixon wrote:

> Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require
> a transport layer interface definition for using IPSec security - in the
> iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port
> connection, deal with the binding of the authentication credential to
> the traffic in the SA, allow/disallow iSCSI awareness of IKE SA
> credentials, and IKE QM/IPSec SA state, and deal with the programmatic
> policy addition to an otherwise admin defined SPD.  
> 
> Practically, shipping products that use IKE and IPSec in either mode for
> TCP connection security means a well defined "policy" so that client
> (iSCSI initiator) and server (iSCSI target) side products interoperate
> with just credentials configured properly, ala web-based usage of
> SSL/TLS.
> 
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com] 
> Sent: Thursday, November 29, 2001 8:40 AM
> To: Black_David@emc.com
> Cc: ipsec@lists.tislabs.com; saag@mit.edu
> Subject: Re: IP Storage and IPsec encapsulation
> 
> 
> David,
> 
> I'm trying to make my way through over 1K messages (that's what I get 
> for going on a week vacation when new IPsec IDs come out ...) and so 
> I didn't read all of your messages in order.
> 
> Looking back at your original (?) message about use of tunnel vs. 
> transport mode I agree with you that this should not be a problem for 
> iSCSI use of IPsec, from a standards perspective. As you note, people 
> need to be smart in configuring an external IPsec device (or set of 
> devices) to ensure that, within their context, the desired security 
> properties are achieved. Thus, merely because tunnel mode could be 
> terminated at a point which would undermine security, in general, 
> that does not mean that its use should be avoided in your spec, for 
> the reasons you cite. My previous message also noted that the 
> outboard IPsec device could be a bump in the wire, vs. an SG, which 
> would allow both transport and tunnel mode, but this is a minor 
> difference relative to your bugger question.
> 
> As you noted, it is a local security policy (and architecture) issue 
> where the IPsec devices are placed and whether that placement 
> provides adequate security.
> 
> Steve
> 
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://jis.mit.edu/mailman/listinfo/saag
> 



References: