Subject: RE: Security Use Requirements

From: "John Hufferd" <[email-masked]>
Date: Wed, 7 Feb 2001 01:37:05 -0800

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: [email-masked]

RJ Atkinson <[email-masked]>@ece.cmu.edu on 02/06/2001 01:29:38 PM

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   "Bernard Aboba" <[email-masked]>, <[email-masked]>,
      <[email-masked]>, "RJ Atkinson" <[email-masked]>, "Smb@Research.
      Att. Com" <[email-masked]>
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
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 07 Feb 2001 08:05:52 -0500

At 04:37 07/02/01, John Hufferd wrote:

>  In any event. the need is for security is at least 3DES.

        It is illogical to argue that having NO SECURITY is
better than having DES-CBC.  Since you appear to be doing
precisely this, I must be confused by your words and not
following you clearly.  Can you kindly clarify ?

>Also the cost of a Gigabit chip for 3DES, I just found out, 
>is $300 for Samples.  

        That's not what I'm seeing, but in any event, 
I think the discussion of hardware is not terribly on point.

>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) is a non-starter because it means no security will
        be widely available to users/operators, IMHO.

        IETF would never say whether a particular implementation 
had to be done in hardware or software; that is obviously an 
implementation detail and product differentiator.  So from an 
IETF perspective (2) and (3) are identical and boil down to 
putting "must implement security" into the specifications 
(for whichever security the WG converges on).

Ran
[email-masked]

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 8 Feb 2001 21:41:05 -0800

>  In any event. the need is for security is at least 3DES.

First you said that you didn't need anything. Now you seem
to imply that you need confidentiality, integrity, and
authentication and that even 3DES may not be enough. 

There are gradations between these two extremes. As Ran
said, even DES will get you something. And there are
circumstances where you might be willing to live with
integrity and authentication alone. 

>Also the cost of a Gigabit chip for 3DES, I just found out, 
  
Well, the cost of a Gigabit NIC is pretty high today in
quantity one, but I don't expect that to be the case in 
18-24 months. You need to factor in time and volume into 
your calculation. 

>2, SW implementation of IPSec/TLS

Problem with approach 1 is that the total cost will be *much*
higher than it would be if you build capability on the NIC. 

Problem with SW implementation of TLS is that you won't be 
able to go much above 200 Mbps if that, even with a 1 Ghz
processor. IPSEC 3DES in SW is much worse. Trust me, a task
oriented crypto co-processor is the way to go in this
application. 

In my opinion, HW IPSEC is the best choice. I expect costs
for 1 Gbps chips to approximate current costs for 100 Mbps
in the next 18-24 months. 

HW TLS is a lot harder because you typically have to terminate
TCP sessions on the card. That means lots of memory, which is
what we've been trying to avoid with RDMA. So cost will be
a good deal higher and the approach won't readily be extensible
to 10 Gbps. Don't go there.