|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Security GatewaysDear David, I would like to address the rather serious question you have raised here about both architectural layering and market requirements. After considerable thought, based on the explanations below, I have concluded that the FCIP RFC should specify that security is optional to implement and optional to use. 1) Concerning architectural layering: It is clear that the problems of security are well understood within IETF. Numerous solutions have been proposed and many of those have become standard implementations. The most successful of those (as an example, IPSec) have used the principles of architectural layering very well. IPSec provides a secure mechanism for transporting any IP-based protocol if the protocol requires such security. However, the overlaying protocols (as an example, TCP) have no requirement to actually make use of IPSec, and in fact have no particular requirement to make use of IP. This is as it should be. Each layer is implemented independently of the other. The services that each layer implements depend on the market requirements for the environment. By that logic, it is unnecessary for FCIP to specify any security mechanism at all, since so many security mechanisms are available. However, FCIP has provided the additional guidance that, if security in a TCP environment is used, it shall be provided at a layer below the TCP interface. In particular, it recommends the use of IPSec for TCP/IP environments (and will recommend the appropriate IPSec options). This additional guidance has nothing to do with the architecture or definition of FCIP and is merely a recommendation that should improve interoperability. 2) Concerning market requirements: A very high percentage of storage environments today manage their configurations very carefully. Such careful management is necessary to guarantee redundant paths for proper availability, to provide sufficient paths to provide the required performance, and to guarantee known paths to improve reparability and consistency of behavior. As a side effect, a very high percentage of the paths of a storage environment are physically secured and have no requirement for additional security mechanisms. At present, the only paths that are using security are those very few paths that leave one physically secure environment to transport data to another physically secure environment. Those few paths almost universally use security mechanisms at a lower level (as an example, a virtual private network) to achieve their goals. As a first guess, such paths are well under 1% of the storage paths being used today. I do not believe that this paradigm will change significantly over the next several years, although of course the percentage of paths requiring transport security may rise over 1%. The requirements for storage performance and the desire to maintain the storage devices and many of their primary processors in a physically secure environment will assure similar configurations. In this environment, the market will demand low cost and high performance for the great majority of interconnects and will demand security for a relatively low percentage of interconnects. What this implies for technologies like FCIP is that security be available as a separate option, outside the primary FCIP definition. While still allowing the integration of security inside an FCIP unit, the IETF draft for FCIP must also allow security to be provided either not at all or by an outside mechanism. The most common outside mechanism would be a gateway box of some sort. In many cases, the gateway box will be a secure router placed on the external link and servicing a large number of locally attached unsecured FCIP boxes. CONCLUSIONS: The FCIP draft should continue to specify a security mechanism, with IPSec being the appropriate candidate, to guarantee interoperability when security is provided. The FCIP draft should be modified to indicate that security is optional to implement and optional to use. In addition, it should explicitly indicate that external gateway boxes are allowed implementation mechanisms for security. As a side question, note that management of storage area networks and FCIP boxes is a separate question and is outside the scope of the FCIP draft. Both Fibre Channel and Ethernet management paths have security appropriate to the particular management mechanism. As an example, web-based management mechanisms use web-based security tools. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, July 24, 2001 7:11 PM To: ips@ece.cmu.edu Subject: Security Gateways The following issue was hidden in my long set of comments on the -03 version of FCIP: > > Delete 12 b). If an FCIP entity is operating with an external > > security gateway, only the interface on the public side of the > > gateway is compliant with this specification. The interface > > between the FCIP entity and the gateway is not compliant because > > it is lacking required security features - the FCIP entity > > *includes* the security gateway in this structure. > > Please post this as a separate issue because several of the > FCIP Authors believe it is appropriate for FCIP and I cannot > represent their opinions. The issue is not whether it's "appropriate". The issue is that if an implementation uses an FCIP Entity plus an external security gateway, the only interface that conforms to the forthcoming RFC is the public/external interface on the security gateway. The interface between the FCIP Entity and the security gateway is private and fails to conform to the security that will be required of all FCIP implementations. The above paragraph also applies to iSCSI (substitute iSCSI for FCIP in all instances). Let me also note that iSCSI's ability to use a security gateway is not final at this juncture. The spectrum of security possibilities includes things like SRP keying of ESP and IPsec transport mode that would make external gateways difficult or impossible to use. Those who care about being able to use security gateways (or think that there's no need to support their use) should speak up on the list, in London, and/or in Orange County (I would expect the decision not to be made prior to Orange County) and *EXPLAIN WHY* [technical rationale]. Thanks, --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:04:06 2001 6315 messages in chronological order |