|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Security Use RequirementsJohn and Bernard, I can't agree more with Bernard's comments regarding a single security solution. By implementing a standard like IPsec and leveraging off the volumes of the mainstream market you will achieve the end goal of lowering the cost of adding security to the adapter, plus you will add the likelihood of many silcon vendors implementing a solution which will in turn foster competition and ultimately make the technology more affordable. We have silicon that does 2.4 Gbps IPsec 3DES and MD5 authentication on virtually all packet sizes today, and it is sampling. Our plan is to move this into mainstream PC servers, routers, and switches which will have full duplex Gig Enet ports standard. The way to get affordable silicon is to make big markets for the devices. So to help us engineer silicon solutions to fit this, what is the price target of an iSCSI NIC HBA? What is the market size that a silicon vendor could expect here over a 18-36 month cycle? Over the next 12-18 months the market will see the prices for these solutions drop as the volumes build. As a vendor sitting on the supply side of the equation it would make our job of serving the market easier by leveraging the R&D efforts already expended and aligning yourself with industry roadmaps. In addition the target of hitting 10G IPsec is not so far off as there is a race to develop this techology first as a chip or chipset solution already. From what I see using IPsec here is a safe bet in hitting these objectives - security, performance, scalability, and affordable solutions that can be widely deployed. Daniel Eakins Senior Product Line Manager Broadcom Corp. Security Line of Business -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of John Hufferd Sent: Tuesday, February 06, 2001 1:22 PM To: Bernard Aboba Cc: ips@ece.cmu.edu; Black_David@emc.com; RJ Atkinson; Smb@Research. Att. Com Subject: RE: Security Use Requirements Bernard, 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. 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. . . . 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 "Bernard Aboba" <aboba@internaut.com>@ece.cmu.edu on 02/05/2001 03:26:13 PM Sent by: owner-ips@ece.cmu.edu To: <Black_David@emc.com>, <ips@ece.cmu.edu> cc: "RJ Atkinson" <rja@inet.org>, "Smb@Research. Att. Com" <smb@research.att.com> Subject: RE: Security Use Requirements It is hard for me to see how you could get away with no security services at all (e.g. no per-packet authentication and integrity protection for iSCSI PDUs). After all, we're talking about facilities that are used by the world's major financial institutions. If this data isn't worth protecting, I don't know what is. Do you really want attackers to be able to manipulate the contents of bank accounts at will over the Internet? Furthermore, there really isn't a sound technical argument for dispensing with security. There are chipsets available that can provide IPSEC integrity and authentication services at speeds of 1 Gbps or higher. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Monday, February 05, 2001 12:54 PM To: ips@ece.cmu.edu Subject: Security Use Requirements In Orlando, I picked up an action item to determine what the requirements are for *use* of security features, as opposed to requirements for *implementation*. I believe the answer to be that it is acceptable to specify security measures weaker than those one would want to use in full generality on a public network, where "weaker" includes no security. There are two important caveats that apply: - Security of the negotiation mechanism becomes very important when this is done, as there's an obvious man-in-the-middle attack on the negotiation mechanism to get the endpoints to negotiate weaker security than they intended. - The weaker security mechanisms need to be documented in terms of their security properties (and lack thereof), as well as environments in which they are appropriate. The "Security Considerations" section of RFC 2338 (VRRP) has been recommended as a good example of this. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------
Home Last updated: Tue Sep 04 01:05:34 2001 6315 messages in chronological order |