[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> ---------------------------------------------------
References: