SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: IPsec Usage Question



    > I agree with Paul, the association of *any* internal network address
    > to any external mapping is  an IPSec configuration concern!
    
    On the one hand, I like this, because it's the simplest way to close
    this issue, and I have a strong preference for simple approaches that
    allow us to declare victory sooner.  OTOH, I want to make sure that people
    understand what the issue is:
    
    	AFAIK, IPsec has no standard or widely deployed mechanism for
    	handling gateway discovery or address association dynamically.
    
    This has concrete consequences.  Suppose that:
    - An IPsec implementation operating only in tunnel mode and requiring
    	different inner and outer IP addresses is used to provide the
    	IPsec security required by an IP Storage protocol. AND
    - A dynamic discovery mechanism (e.g., Send Targets, SLP, and iSNS) is
    	used to discover IP Storage peers.
    Then the dynamic discovery mechanism only discovers the IP address
    of the IP Storage peer, and does not provide information about the
    IP address of the security gateway that must be contacted in order
    to talk to that peer.
    
    The current state of the art is to statically pre-configure the gateway
    address information (i.e., every peer that wants to communicate with a
    specific implementation will have to know that implementation's security
    gateway IP address in advance, even though the IP Storage IP address
    can be discovered dynamically).  This approach works, but it makes dynamic
    discovery much more difficult to use with security gateways.  To the
    extent that this biases IP storage against the use of security gateways,
    it will make my life easier in dealing with the folks who want to make
    absolutely sure that IP Storage uses end-to-end security, but I wanted
    to make sure that the practical configuration consequences of this
    approach were understood.
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    black_david@emc.com         Cell: +1 (978) 394-7754
    ---------------------------------------------------
    


Home

Last updated: Mon Feb 04 18:18:01 2002
8627 messages in chronological order