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

Re: IP Storage and IPsec encapsulation


Hi David,
   It seems to me that this is policy and deployment issue.
   It seems that you have following scenario:


StorageClient---Router1-----(Internet)------Router2-----StorageSrvr

   StorageClient and StorageSrvr terminate iSCSI connection.
   If end-to-end security is needed, then both client and
   server should be IPSEC enabled. In this particular case, these
   are IPSEC hosts and as per IPSEC standard, a host MUST support both
   transport and tunnel modes.

   If end-to-end security is not needed, then Router1 and router2
   can be IPSEC enabled. In this case, tunnel mode is required in
   Router1 and Router2.

   Alternatively, IPSEC session can be between StorageClient and
   router2 OR Router1 to StorageServer. In these two cases, tunnel
   mode is required.

   If IPS group likes to allow only end-to-end security and avoid
   any admin mistakes, then transport mode can be made MUST. But
   I am not sure whether somebody would like to do that.

Srini



On Tue, 27 Nov 2001 Black_David@emc.com wrote:

> Picking up a baseball bat and carefully drawing a bead on
> the hornet's nest ...
> 
> Over in the IP Storage (ips) WG, we're picking up a subset
> of IPsec (primarily ESP and IKE) to provide security for
> our protocols (TCP/IP encapsulations of SCSI and Fibre
> Channel - iSCSI, FCIP, and iFCP).  This approach is being
> used in order to avoid putting out new protocol standards
> that require things like DES and AH (comments in favor
> of DES and/or AH should be sent to /dev/null ;-) ).
> 
> >From a protocol specification standpoint, the IPS WG is
> not prepared to require Integrated or Bump In The
> Stack implementations of IPsec.  In other words, the
> WG does not want to foreclose the ability to take an IP
> Storage protocol implementation without IPsec, hook it up
> directly to a security gateway IPsec implementation and
> obtain a result from the combination that complies with
> the security requirements of the IPS protocol specification.
> The protocol on the link between the IP Storage implementation
> and its security gateway would NOT be compliant because
> it would lack required security functionality (this latter
> point was explained at length by the IESG in the London
> plenary).
> 
> Since IP Storage implementations could be based on host or
> security gateway implementations of IPsec, the appropriate
> thing to do in the IP Storage drafts appears to be to
> REQUIRE tunnel mode as the encapsulation mode that
> must be present for interoperability because it is the
> common mode required by both classes of IPsec implementations.
> OTOH, I've heard concerns that tunnel mode may not provide
> a suitable bias towards end-to-end security - it's not that
> difficult to terminate an IPsec tunnel someplace other than
> the far end of the communication session running through it.
> OTOOH, this concern strikes me as a policy issue - if some
> node other than the far end can terminate the IPsec tunnel,
> that node must have the keying material required to set up
> the tunnel mode SA in the first place.  In turn that
> reflects a conscious security policy decision by the
> administrator who configured that material into that
> intermediate node and got exactly what s/he asked for.
> This policy aspect is unavoidable, as the only way to
> remove this option (tunnel mode to a gateway not at
> the far end) from the admin's hands is to forbid
> tunnel mode, which seems like a really bad idea.
> 
> I'm looking for comments, advice, and insight on this
> issue (which mode to REQUIRE) in the hope of resolving it
> in Salt Lake City in a fashion that won't come back to
> cause problems in IETF Last Call.  For more information
> on IPS Security, see draft-ietf-ips-security-06.txt (-05
> if -06 hasn't hit the servers yet).
> 
> Thanks,
> --David (IPS WG co-chair)
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 

-- 
Srinivasa Rao Addepalli
Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
USA
Ph: 408-844-0480 x317
References: