RE: Security Use Requirements

["Bernard Aboba" <aboba@internaut.com>]

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

SSL/TLS has many nice features, including better API support in
most cases, more flexible certificate policies, and lightweight
ciphers (e.g. RC4) This often makes it an attractive choice
for applications requiring ~ 100 Mbps throughput (e.g. your
average web server).

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

Really? Mind if I order a few thousand to use as ordinary Gigabit
Ethernet NICs? Our server farms need an inexpensive upgrade for
the 100 Mbps adapters ;)

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

Well, if you only have a few sessions per card, you can do
session establishment in software. However, even though RC4
is very light weight, it is very hard to get close to 1 Gbps
throughput on it, even with a 1 Ghz processor. So you will
be likely to bottleneck at relatively low interface
utilization unless you have more than one CPU to throw at it.

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

Not sure why this would be necessary. Doesn't IKE (either
with Certs or shared secrets) give you the necessary
authentication/integrity protection?