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

IP Storage and IPsec encapsulation



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: