RE: IPsec Usage Question

["CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>]

David,

A few comments below as I thought about what you pointed out and, for the
first time, about the implications of peer discovery mechanisms to IPsec.

Vince

|-----Original Message-----
|From: Black_David@emc.com [mailto:Black_David@emc.com]
|Sent: Monday, February 04, 2002 11:08 AM
|To: marjorie_krueger@hp.com
|Cc: ips@ece.cmu.edu
|Subject: 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).  

It is my understanding that this knowlege of security peers is an essential
aspect of IPSec. IPSec is a point-to-point protocol and each entity has to
know every other entity with which it needs to communicate securely. The
security policy database MUST have the information required to reach any
peer. If it is not known beforehand (until they are discovered) who the
peers are, then it is possible that the required policy has not been setup
and it may not be possible to reach that peer.
What appears to mitigate this is that the policy may be described with
coarse granularity and say something like "to reach any IP in subnet x use
gateway y". This way targets in subnet x can be explored or discovered.

I suppose if the discovery traffic can be identified (I have not studied the
discovery mechanisms) the security policy could be set such as to allow such
traffic to pass without security. I don't know if this a safe thing for a
VPN gateway to allow.


|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.

Even if the granularity of the security policy permits discovery (allows a
target to be reached for discovery purposes) the process will be slow.
Discovery cannot occur until an SA has been established between any security
endpoints that may exist in the path between the iSCSI initiator and target.
I don't know how directed the dynamic discovery mechanisms are but it seems
as if this is going to be a very slow process even in simple cases where
there are no nested tunnels.

Consider a simple case of a target in some remote protected subnet and the
initiator in a local protected subnet. Each subnet has a security gateway to
the internet and both gateways secure all traffic between themselves by
means of an IPsec tunnel.

The first packet sent by the initiator to some target's IP will trigger an
IKE exchange to the remote security gateway (whose IP is in the Security
Policy database of the local security gateway) to establish the IPSec SAs.
Depending on how the policy is setup, packets from the initiator to a
different target IP may require a different IPSec SA to be setup. 

Imagine when there are nested tunnels because there is, in the path between
initiator and target,  a company security gateway followed by  a department
security gateway! In this case a security association must first be
established with the corporate security gateway before a security
association can be established with the department security gateway.

Yes, it appears that the combination of IPSec and peer discovery is ugly
indeed!


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