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



    On market requirements:
    
    1) Curious, what is your basis for the guess of 1% of storage
    environments/paths not being physically secure? While I tend to agree that
    currently this is a low percentage, 1% seems too low. Do you have any hard
    numbers to justify this your guess?
    
    Large companies and companies experiencing rapid growth often have multiple
    locations across a metropolitan area. Do these companies not have some
    commonly accessible storage facility for at least some of their data? Don't
    other companies have or would like to have workers at multiple locations
    across miles if not hundreds of miles to collaborate, requiring access to
    the same data, not just mirrored (and thus often dated) data?
    
    2) Even if the % of paths are in single digits, do you think there won't be
    a paradigm shift?
    
    With increased capacities for bandwidth (OC-12, 0C-48, faster networks
    switches, et al) coming available, it would seem logical that it will become
    practical for more and more companies to shift data storage facilities to
    lower rent facilities than their office and/or research space, and to
    increase collaboration among workers at multiple locations (or even true
    telecommuters connected through broadband technologies).
    
    
    Mark Winstead
    
    NetOctave, Inc.
    P.O. Box 14824
    RTP, NC 27709
    www.netoctave.com
    919.463.9903 x328
    mark.winstead@netoctave.com <mailto:mark.winstead@netoctave.com> 
    
    -----Original Message-----
    From: Jim McKinney [mailto:jmck+@ece.cmu.edu]
    Sent: Wednesday, August 01, 2001 10:06 PM
    To: ips@ece.cmu.edu
    Subject: RE: Security Gateways
    
    
    Dear 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:07 2001
6315 messages in chronological order