Re: iSCSI Security Protocol

[Yaron Klein <klein@sanrad.com>]

Joshua,

What I meant in “forcing to use IPsec” is that you must have an authentication
mechanism in the iSCSI spec if your client does not support IPsec.

Several other drawbacks for IPsec:

· The iSCSI will use different AH for the header and the data, thus enable fast
performance in iSCSI gateways applications (where the header is modified and the
message is forwarded – only the header AH need to be calculated).

· The point you mentioned, using tunnel mode IPsec may cause some problems while
traveling through gateways and proxies.

So, the system administrator can set and configure the system as he wishes. If
the system supports IPsec, iSCSI authentication will not be needed.

If you have any results from tests with IPsec performance, let us know!

Regards,

Yaron


Joshua Tseng wrote:

> Hi Yaron,
>
> >For full security (authentication and encryption) use external protocol,
> e.g.,
> >IPsec. You can define an IPsec policy for encrypting everything (not
> feasible
> >for most cases) or just the first 48 bytes (headers) and so on.
>
> I agree we should look at IPSec.  Today, all SSH implementations are
> software-based as far as I know.  IPSec hardware is much more readily
> available.
>
> >However, IPsec may cause some problems since it is IP oriented (connection
> >oriented and not session oriented). Moreover, you are forcing the client to
> have
> >IPsec, which is not always true.
>
> I'm not sure what you mean here.  IPSec is a layer-3 protocol, and it has
> no knowledge of TCP.  Conversely, TCP is unaware of IPSec operating at the
> layer below it, and IPSec should not interfere at all with TCP.  The only
> drawback I see is that if you selectively apply a security policy to iSCSI
> conversations which may go over the same TCP connection, some TCP segments
> may be encrypted and others will not.  For example, a policy may dictate
> no security for one iSCSI conversation, but ESP tunneling w/3DES for a
> different iSCSI conversation.  Both conversations use the same TCP
> connection.
> If this happens, you will not see a difference at the TCP end points, but in
> the network you'll see some segments in a TCP connection "disappear", as
> they
> have been encrypted, while others may be left alone and visible to the
> network,
> IP and TCP headers and all.  This effect may confuse firewalls and other
> monitoring points in the network.  But I would rather have the flexibility
> to do this than to be forced to apply a single uniform security policy to
> all
> iSCSI traffic using a TCP connection.
>
> I also don't know what you mean by "forcing the client to have IPSec".  If
> the
> client doesn't have IPSec, this can be negotiated out at iSCSI login.  Or,
> if
> you want to do authentication before iSCSI login, IKE (Internet Key
> Exchange)
> can easily be implemented in software.
>
> >The security scheme in the iSCSI draft includes authorization and
> >authentication. The authorization is done in the login phase with the
> >negotiation (detailed in the draft), and authentication is achieved by a
> trailer
> >that checks the integrity of the data and the header (either simple CRC or
> some
> >mac algorithm).
>
> So it seems you do not intend to leverage the Authentication Headers (AH)
> protocol
> and will imbed the authentication & data integrity mechanism within the
> iSCSI protocol?
>
> Regards,
>
> Josh