SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:34 2001
6315 messages in chronological order