RE: Security Use Requirements

[julian_satran@il.ibm.com]

Bernard,

This is becoming an interesting thread.

The reason we went after TLS is that it can be used for session
authentication with stronger schemes than
and it is very popular for software implementations.

As for the cost of the hardware - the figures you quote are for 100Mbs (and
even there the NIC numbers are higher).
The low-end iSCSI adapters will cost well under $100 (at 1GBbs).

I don't envision all the options becoming necessary for hardware
implementations.  The pieces we wanted from TLS can be implemented in
software.

If we where forced to select one I would too go for IPsec (and that is what
we have in the current draft) but then we have
to specify session authentication on our own and keep updating it as new
schemes enter the world.  It seems far better
to rely on a specialized standard and TLS fits the bill.

Regards,
Julo

"Bernard Aboba" <aboba@internaut.com> on 06/02/2001 23:21:14

Please respond to "Bernard Aboba" <aboba@internaut.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   Black_David@emc.com, ips@ece.cmu.edu, "RJ Atkinson" <rja@inet.org>,
      "Smb@Research. Att. Com" <smb@research.att.com>, Ofer
      Biran/Haifa/IBM@IBMIL
Subject:  RE: Security Use Requirements




>Both IPSec and TLS will be in the standard.

Including *both* IPSEC and TLS as options will probably result
in both much higher cost to customers as well as fewer vendors
implementing either. Choosing one or the other (IPSEC is my
preference) would be a better choice.

In general, it is a bad idea to have too many security options in
a standard. Options are bad because you have to implement them
to be able to interoperate with those people who do, yet you cannot
guarantee that the work will be used. In particular, including both
IPSEC and TLS would cause vendors to try to implement both on
the same NIC, since they could never be sure which security scheme
would be used on a given iSCSI target. This would drive up the cost
enormously since the acceleration architectures are very different
between the protocols.

>As we are talking about speeds that will be in excess of 1GBs
>even on modest disk controllers we were all hesitant if to make
>anything in this category mandatory to implement today.

As Ran noted, making implementation mandatory doesn't mean that
users have to turn it on. But not making it mandatory will probably
ensure that security will not be available in most cases. Given
the modest cost of adding IPSEC acceleration hardware (today
IPSEC accelerated NICs are available for around $100) it is hard
to see how this would be a worthwhile tradeoff.

Right now, SSL/TLS acceleration hardware is a lot more expensive than
IPSEC accelerators (at least $2000), so I could understand if SSL/TLS
were left out of the standard.

>We assume that all those who require security beyond CRC

CRC provides only integrity protection, but since it is not keyed,
there is no per-packet authentication or protection against spoofing
or modification. CRC therefore has little or no security value.

> session authentication

All session authentication does is guarantee the user identity
at the beginning of the session. Unless you have per-packet
authentication and integrity protection, all bets are off after
that. In particular, session authentication provides no protection
against TCP session hijacking.

>However those that build a Storage Area Newtork within a
>small enterprise completely isolated from the
>internet will not have to pay for what they do not need.

Actually, the decision made above will guarantee that all users
will need to pay a huge incremental cost for security, because
of the over abundance of security options. In reality, given the
projected cost of 1+ Gbps iSCSI accelerated adapters, the incremetal
cost of implementing IPSEC security would be minimal.