RE: Security Use Requirements

[julian_satran@il.ibm.com]

It would be interesting to findout if the chips support transport IPsec or
tunneling IPsec or both.
For tunneling IPsec you have to be a "believer" - i.e., you'll have to
believe that there is such a think on the wire
as iSCSI  is oblivious to it.  However if provided in an external box it
can provide excellent security.
The "required to implement" statement - if made by iSCSI - would have only
propaganda value
as it can't be assessed in a compliance testing suite.

Julo

"John Hufferd" <hufferd@us.ibm.com> on 07/02/2001 11:37:05

Please respond to "John Hufferd" <hufferd@us.ibm.com>

To:   RJ Atkinson <rja@inet.org>
cc:   ips@ece.cmu.edu
Subject:  RE: Security Use Requirements





RJ,
I can not tell, from the obvious intensity of your note, if you agree with
me are not.  As Julian pointed out the prices were probably for the 100
Mb/s links.  In any event. the need is for security is at least 3DES.
Also the cost of a Gigabit chip for 3DES, I just found out, is $300 for
Samples.  If you go from Cost to street price, you will probably have a 3x
difference.  Now, that is a bit much for only one of the key componets on
an iSCSI/TOE HBA that is suppose to be competitive to Fibre Channels.

Therefore, I am reconsidering my statements, that we Must Implement.  Your
opinion might be useful here.  I had thought that in the real world,
separate box IPSec/ TLS, at the edge of the secure network might be all
that is required.

Since we must also consider the SW implementations on Desktops and Laptops
perhaps IPSec is OK there, since the volume of data will be relatively
slow.

Now, I am beginning to think that it is reasonable for one of the following
approaches to be OK. That is, one of those approaches should meet the
requirement for "Must Implement".
1. Only implementing an interface to the external IPSec/TLS box
2, SW implementation of IPSec/TLS
3. HW IPSec/TLS

In this case, if the customer wants protection, they either pay for the
separate IPSec/TLS box (can be shared by many connections), or the HW
IPSec/TLS or accept the overhead and lack of speed in SW implementations.

OK folks, lets here all your opinions on this.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com


RJ Atkinson <rja@inet.org>@ece.cmu.edu on 02/06/2001 01:29:38 PM

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS
cc:   "Bernard Aboba" <aboba@internaut.com>, <ips@ece.cmu.edu>,
      <Black_David@emc.com>, "RJ Atkinson" <rja@inet.org>, "Smb@Research.
      Att. Com" <smb@research.att.com>
Subject:  RE: Security Use Requirements



At 16:21 06/02/01, John Hufferd wrote:

>I think that Julian addressed this, but, an installation might want only
>the connection to the local environment, and if so administratively tell
>the iSCSI ends to not do the encryption etc.  Especially if some of the
>ends are Laptops and Desktops.  But all side must implement the features.

        Implement != turn on operationally.  The above explains
why clever vendors might have a configuration knob to turn off
security.  The above does NOT make any kind of case for not
always *implementing* security.

>By the way you might have slightly overstated the IPSec chips going at
full
>gig speed, when you talk about triple Des.  And if there are some they are
>not within the normal costs one would expect for a iSCSI NIC HBA.

        So if you believe the costs are so high, implement single DES.
For a lot of threat environments DES-CBC is sufficient and it surely beats
the hell out of nothing.  By the way, the crypto parts vendors
that I'm talking with must be giving me better prices than you,
which I find surprising, since by the parts quotes I'm seeing
Bernard's math works just fine.

        Nothing anyone has said here has given any kind of reasonable
excuse to not make implementing security mandatory.  There has been
lots of rationale for making it optional for the user to turn on
for a given box, but nothing for making it optional to implement.
(Implement in the box != deploy operationally).

Ran
rja@inet.org