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

IKE "clustering" - IP address sensitive or not?

Good day.  I am evaluating some IPSEC clustering products, and have
come across an impasse in interoperability between two vendors.

All clusters appear to have n+1 IP addresses, one for each node and
a virtual IP address (often called a VIP) for the cluster as a whole.

In at least one vendor's implementation of IKE, the IP address of
the IKE peer changes during the middle of the IKE dialog.  Thus,
a dialog might look like this:


1) Initiator 9.9.9.9 sends to Responder IKE cluster 1.1.1.1 with 
	cookie
2) Responder IKE cluster member 1.1.1.2 responds to Initiator 9.9.9.9

or

1) Initiator IKE cluster 1.1.1.1 sends to Responder 9.9.9.9 with cookie
2) Responder 9.9.9.9 answers Initiator 1.1.1.1 with cookie pair
3) Initiator IKE cluster member 1.1.1.2 starts D-H negotiation part of
	MM

Essentially, the cluster code only uses the cluster address when it absolutely
has to and shifts over to an assigned member address asap, with the proviso
that it may CONTINUE to shift IP addresses over time as the cluster does its
thing.

I cannot find any place in the ISAKMP or IKE RFCs where this is specifically
prohibited; in fact, when the cookie contents are discussed in IKE, there
is a long list of things which does NOT include the destination IP address
(which implies that it might change).  

Similarly, ESP/AH are careful to not tie addresses up in a way which would
prohibit one end from shifting around like this.

However, this strikes me as A Bad Idea on the general principles of "if I
wanted to talk to that IP address, I would have sent to that IP address."

Am I totally off base?  Is this a problem or a non-problem?  [Yes, I know that
it breaks transport mode, but let's talk about tunnel mode here.]  Is this an
example of "total compliance with RFCs, yet completely incompatible?"

jms

Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)  
jms@Opus1.COM    http://www.opus1.com/jms    Opus One