SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Security Gateways



    David,
    
    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