Re: IPSEC in High Availability scenarios

[Stephen Kent <kent@bbn.com>]

At 3:31 PM -0700 5/2/03, suren wrote:
>Hi,
>
>   Small introduction:
>   We find the IPSEC is being used in critical applications and
>   high availability is one of requirements of customers. Typically
>   two SGs are used - one acting as Master and other acting as
>   backup device. VRRP like kind of utilities are used to detect
>   the aliveness of master SG. Backup SG inherits the same IP
>   address. In these cases, the remote peers don't know that
>   that there are two SGs and control is transferred from master
>   to backup device.

Perhaps this is not a good model. The backup SG, in order to be able 
to take over the SAs from the primary SG must have access to all the 
keys in use, and the movement of keys between the two may create 
security assurance problems.  For example, are any of the 
implementations that support this approach evaluated under FIPS 
140-1/2 at level 3 or 4?

An alternative would be to have backup SAs created at the same time 
as the primary SAs, but homed to the backup SG, at its own address, 
and then move the traffic to the existing, backup SAs, which would 
avoid the sequence number problem you noted.

>
>   Problem:
>   Due to critical timing nature of applications run on IPSEC tunnels,
>   customers are increasingly asking for SA transfer between master and backup
>   so that backup can take over tunnel when master fails (To avoid 
>new tunnel establishment).
>   There is a problem when anti-replay is enabled on SAs, which is MUST in
>   most of the cases. Transferring this change of sequence number
>   information between master and backup device,might have performance
>   implications and some times not practical.
>
>   Solution:
>   Today, we have proprietary mechanism to solve this problem, but
>   it works between same kind of implementations. We are trying to
>   see if there is any inter-operable solution for this problem. We feel that
>   backup device can send notification message (when tunnels in backup
>   device get activated) indicating to the peer that it can accept the
>   packets with some specific sequence number. Basically, synchronizing
>   the sequence numbers in the tunnel.
>   What do others think of this solution: Having SYNCH-SEQUENCE
>   notification message. We can force that this has to be protected message.
>   Also, we can have sequence number information for detecting replaying
>   of this notification message.
>
>   Do you see any problem with this approach? Or Is there any inter-operable
>   solution already defined?

I'm not saying this can't be done securely, but you have no provided 
sufficient detail to know. For example, is this new message sent over 
the IKE SA or over the subscriber SA?  If via IKE, then there may be 
problems matching the SYNCH-SEQUENCE to the data path sequence 
numbers. If via the subscriber SA, then how is this message accepted 
out of order? Also, is this proprietary mechanism patented?

Steve