RE: iSCSI Security Protocol

[Joshua Tseng <jtseng@NishanSystems.com>]

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