|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Security GatewaysDavid, As introduction to this phase of our discussion, let me draw a picture in (gag) ASCII. +- - - - - - - - - - - - - - - + - - - - - - + Securely Administered Secure Environment Public Environment | | | FC +--------------+ TCP/IP w/o | <-->| FC/FCIP dvc A|<----+ IPSec | | +--------------+ | | | +--------+ | | FC +--------------+ +----->| Secure | TCP/IP w/ IPSec | <-->| FC/FCIP dvc B|<---------->| Router |<------------> | +--------------+ +----->| | | | +--------+ | | FC +--------------+ | | <-->| FC/FCIP dvc C|<----+ | | +--------------+ | | | +- - - - - - - - - - - - - - - + - - - - - - + I believe that the interface provided by FC/FCIP dvc A, B, and C should be called RFC "FCIP" compliant just as completely as the public interface from the secure router is called RFC "FCIP" compliant. In this environment, the FCIP devices will be routinely carrying on traffic among themselves without using IPSec, and will be carrying on traffic with the public environment using securely protected connections. The secure protection may be IPSec as recommended by the RFC "FCIP", but it may also be some other sort of secure connection. If there is a performance and a monetary cost associated with IPSec (which my associates assure me will be significant for some time in the future), that cost is paid one time in this picture. If IPSec was mandatory to implement for RFC "FCIP" compliance, the financial cost would be paid three (or maybe four) times in the picture and the performance cost would be avoided by invoking the optional disabling of the security feature within the securely administered secure environment. This example will be a common structure in FCIP environments. The example provides lots of options for various kinds of tradeoffs. As time goes on, the full integration of security functions in FCIP chips may increase the percentage of RFC "FCIP" complaint devices that actually contain the optional to implement IPSec functions in the FC/FCIP device itself. At any time, individual secure interface boxes (IPSec or other) can be attached loosely or tightly to those FC/FCIP devices that invoke the option to not install security internally. Even the definition of tightly and loosely connected is an artificial distinction related to how long the bolts are and whether adjacent racks constitute tightly coupled functions. To meet these requirements, the only solution I can see is to define the RFC "FCIP" such that security is optional to implement and optional to use. While defining the recommended security to be IPSec, devices that use no security and devices that use alternative security would also be RFC "FCIP" compliant. They of course would list in their manufacturing specifications other RFCs that would be supported, typically including TCP, IP, and the appropriate IPSec RFCs. To address the second part of your comments below: >> This isn't just "push back" >> from the IESG - it is a condition that the IESG required >> for its original approval of the IPS WG charter. The closest wording I can find to that in the charter is: " The WG will address at least the following: - Security measures, including authentication and privacy, sufficient to defend against threats up to and including those that can be expected on a public network. The WG will address security and congestion control as an integral part of bits protocol encapsulation(s); " I can find no hint that those security measures are mandatory to implement for compliance with the RFC "FCIP". They are certainly mandatory to specify in the RFC, and we will have done so with big flashy warnings (or at least as flashy as ASCII allows) that qualify the security limitations for those operating in RFC "FCIP" compliant devices that elect not to install the optional security mechanisms internally. I believe that our proposal would meet both the letter and spirit of the charter. The wording in draft-ietf-ips-framework-00.txt, clause 9, similarly recognizes the requirement we see with wording like: " A partial solution may be obtained by providing enhanced security services at the interfaces from the existing storage network to the IP storage network. There, services such as encryption and authentication may be applied to the non-physically secure portion of the path, without requiring end-station changes. Overall security for such a solution may be no better than that of a SAN presumed to be physically secure, but at least it will not be perceived as worse. Link-level security need not be the only solution. In many applications, privacy of data transmission across the network may be less significant an issue than controlling who accesses the storage resources. In such situations, access-control solutions such as the resource login provided by iSCSI can add value." Note that the FC entities making use of the FCIP entities have a secure authentication mechanism being proposed as part of the FC activities. I hope that we have interpreted the wording and intent correctly, because if not we should probably modify the charter to allow the FCIP proposal. 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: Wednesday, August 01, 2001 4:42 PM To: rsnively@brocade.com; ips@ece.cmu.edu Subject: RE: Security Gateways Bob, An RFC does not tell anyone what can or cannot be built; it specifies what is required for compliance with the RFC. If someone builds a protocol implementations that doesn't comply with the requirements of the RFC, they should not expect to be able to claim RFC compliance for devices based on that implementation. > The marketplace does demand that > security be possible and available for a device. The compliance requirement here is that "possible and available" be realizable without having to add anything to the device. For the structure of interest here, an FCIP device plus a security gateway, the complete system [FCIP device, cable, security gateway] would comply with the FCIP RFC at its external interface (i.e., the external interface of the security gateway). The interface between the FCIP device and the security gateway would be missing some required security functionality and hence would not comply with the RFC. As a result, the FCIP device by itself would not comply with the RFC. > I can understand why the IESG would push back on this > question, but I would expect that they also believe that > an FCIP device without optional security implemented > is still an FCIP device and is compliant with the FCIP RFC. If "optional" means "MUST implement, but MAY use", that expectation would be incorrect. "MUST implement" (cf. RFC 2119) is the level of requirement for authentication and cryptographic integrity that is necessary for FCIP to be approved as an RFC. This isn't just "push back" from the IESG - it is a condition that the IESG required for its original approval of the IPS WG charter. > With an edge security device installed > in front of it, it is also a > secure FCIP device, just like the end-point of a > virtual private network is a secure device. That combination will comply with the RFC. OTOH, the IESG will not permit the FCIP RFC to allow an FCIP device that lacks the basic security mechanisms to be compliant, and hence the FCIP device *without* the edge security device will not comply. > By definition, "man in the middle" attacks are impossible > for a security edge device, since the only place that the > "man in the middle" can be placed is in the encrypted path. "By definition" is not the best wording. Assuming that the "security edge device" is an IPsec security gateway, the IKE and ISAKMP protocols are to negotiate security functionality and parameters; those protocols are resistant to man-in-the- middle attacks, but that resistance is based on careful design. --David > -----Original Message----- > From: Robert Snively [mailto:rsnively@brocade.com] > Sent: Wednesday, August 01, 2001 6:25 PM > To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu > Subject: RE: Security Gateways > > > David, > > I believe this is really a very difficult question, not > susceptible to a simple SHALL/SHALL NOT response. > The technology absolutely allows and encourages > security edge devices and absolutely allows devices using > TCP and other protocols to exploit those edge devices or > not as the system administrator requires. The marketplace > absolutely demands those capabilities. A significant percentage > of the internet economy is based on separately supplied security. > I understand that the IETF > has no interest in devices that are solely for closed > environments, but the marketplace does not demand that > a device have security built in to qualify for compliance with a > protocol. The marketplace does demand that > security be possible and available for a device. > > That is what we have been proposing. > > By definition, "man in the middle" attacks are impossible > for a security edge device, since the only place that the > "man in the middle" can be placed is in the encrypted path. > The physically secured path has no possibility of an > entry point for such an attack. > > I can understand why the IESG would push back on this > question, but I would expect that they also believe that > an FCIP device without optional security implemented > is still an FCIP device and is compliant with the FCIP RFC. > This should be true whether the TCP path is based on IP, > HIPPI, IB, a proprietary backplane or any other transport > that supports TCP. With an edge security device installed > in front of it, it is also a > secure FCIP device, just like the end-point of a > virtual private network is a secure device. > > That is what we would like the RFC to say. > > Bob > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, August 01, 2001 10:13 AM > To: rsnively@brocade.com; ips@ece.cmu.edu > Subject: RE: Security Gateways > > > Bob, > > You've made a good case for "optional to use", but not > "optional to implement". The basic reason is that there > is no way to ensure that vendors and/or users will > restrict the use of an implementation that does not > include security to situations where "paths of a > storage environment are physically secured and have > no requirement for additional security mechanisms". > Hence security needs to be present so that it > can be used when FCIP is deployed in an environment > that requires security. Further, the IETF has no > interest in specification of protocols that are > *solely* for use in the sort of closed environment > that you describe, and the IPS WG charter contains > explicit words to that effect. > > Therefore, the basic FCIP security mechanisms MUST be > implemented, but usage MAY be negotiated. At the moment, > "basic security mechanisms" means authentication and > cryptographic integrity. Confidentiality can currently > be optional to implement, but I think it's a very good > idea to specify the basic confidentiality mechanism > (*if* confidentiality of any form is implemented, *then* > <XXX> MUST be implemented). The design and specification > of any negotiation mechanism must resist man-in-the-middle > attacks on negotiation that would result in turning off > security where that was not the intended outcome - such > an approach can include restrictions on implementation > behavior (e.g., if "no authentication" is not acceptable, > do not offer or accept it during negotiation). > > If the FCIP draft is sent to the IESG without requiring > implementation of the basic security mechanisms, it will > be returned to the WG with instructions to correct > that shortcoming, along with some choice words from the > ADs wondering how the WG chairs could have overlooked > something like this. As a result, an FCIP draft that > does not require implementation of the basic security > mechanisms will not be Last Called in the WG until that > requirement is added. > > Sorry to be blunt, but there is no flexibility on whether > the basic security mechanisms are mandatory to implement; > they will be mandatory to implement, period. > > 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 |