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

RE: IP Storage and IPsec encapsulation



> Since this is a host-host application layer
> protocol, that pretty much implies that you'd want
> to use transport mode, since you end up with the
> same IP src/dst addresses if you used tunnel mode,
> which sounds gratuitously redundant.

The configuration of interest is:

|--------------------------|    |---------------|
| IP Storage without IPsec |----| IPsec gateway |-->
|--------------------------|    |---------------|

Where the link between the two boxes is not attached
to anything else.  The only IPsec implementation on this
end of the connection is in the gateway, and the only
link in the above diagram that complies with the protocol
requirements is the link on the right hand side of the
gateway.  The gateway does not implement transport
mode, hence the interest in tunnel mode.

> Thus -- and I'm sorry this is rather circuitous --
> I really don't see what tunnel mode is buying over
> transport mode here, other than adding extra
> overhead and making things more confusing.

It's buying the above implementation approach in which
IPsec does not have to be implemented on the IP Storage
box in the diagram.

If IPsec were implemented on the IP Storage box, then one
wouldn't need the gateway for protocol compliance (although
it might be present for other reasons), and if both ends
of the connection implemented IPsec in that fashion, then
transport mode would be the more efficient choice for the
end-to-end SA (but that's a policy decision, and negotiable
via IKE).  Please note the two "if"s in the previous sentence;
the IPS WG is currently reluctant to impose them as
requirements on all implementations.

Thanks,
--David

---------------------------------------------------
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
---------------------------------------------------

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, November 28, 2001 3:36 PM
> To: Black_David@emc.com
> Cc: ipsec@lists.tislabs.com; saag@mit.edu
> Subject: IP Storage and IPsec encapsulation
> 
> 
> 
> Let me see if I understand this: you don't want to
> preclude the use of security gateways. Fine,
> that's impossible to do anyway. You say that a
> host which doesn't implement some TBD profile of
> IPsec wouldn't be compliant with the draft. Fine,
> nothing that affects either intermediate security
> gateways or the choice of tunnel or transport
> mode. Since this is a host-host application layer
> protocol, that pretty much implies that you'd want
> to use transport mode, since you end up with the
> same IP src/dst addresses if you used tunnel mode,
> which sounds gratuitously redundant.
> 
> Now, if you wanted colocate your IP storage box
> with a security gateway so that you can attach it
> to another security gateway -- possibly in a
> non-compliant arrangement -- you might want to
> have a tunnel. However, there is nothing to
> prevent such a box to still be compliant since you
> can always place IPsec protected packets
> (transport) into an IPsec tunnel. This doesn't
> require anything new as it's just a standard
> feature of RFC 2401. 
> 
> Thus -- and I'm sorry this is rather circuitous --
> I really don't see what tunnel mode is buying over
> transport mode here, other than adding extra
> overhead and making things more confusing.
> 
> 	     Mike
> 
> Black_David@emc.com writes:
>  > 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
>  > ---------------------------------------------------
> 


Follow-Ups: