RE: Security Use Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

Bernard,

> 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.

IPSec and TLS provide different capabilities.  While IPSec is
easier to implement and hence, as you point out, much cheaper,
TLS affords the capability of securely communicating through
proxys.  On the other hand, IPSec is a real pain to get through
firewalls.  If we decide that iSCSI doesn't need to go through
firewalls, then we could let go of TLS.  But the last I remember
from reading the IPS charter, it is still a requirement.

> 
> 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. 

Why should IPSEC or TLS be mandatory for iSCSI when it isn't for http,
dns, and other network protocols?  I'm aware of nothing inherent in
iSCSI that makes it need special security measures any more than those
other protocols.  If the security folks intended for all protocols to
be secure, wouldn't it be more efficient for the security WG to say it
just once, and mandate it for all IP protocols?

Josh

> 
> >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. 
>