Subject: IPSEC in High Availability scenarios

From: suren <[email-masked]>
Date: Fri, 02 May 2003 15:31:49 -0700

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.

   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?

Thank you for you time.
Suren
Intoto Inc.
3160, De La Cruz Blvd #100
Santa Clara, CA
www.intotoinc.com

---

From: Ravi <[email-masked]>
Date: Mon, 05 May 2003 09:47:41 +0530

Suren,
     This is one of the problem I am trying to solve for one of my customers.
     But fortunately, we don't have requirement of using same tunnel when
     the backup takes over.
     Even without having to have new tunnel to be established, I did not see
     any proper and interoperable solution. This is one of the reason I propose
     to have 'Dead Peer Tunnel (SA) detection'. With this, the other party 
     know eventually that tunnel got terminated on other side and creates 
     new tunnel. 

     SA transfer may not be a good idea for several reasons.
     A. Keying material also has to be sent. There may be security issues 
         with this. 
     B. SA is not stateful. If it is not there, IPSEC nodes creates new SA.
         No connection will be terminated.
         It is not like Firewall/NAT sessions, where some state information
         needs to be syn'ed up for smooth takeover.

     I don't see any requirement for this with my limited knowledge.
     But if there is need for it, then the proposal you suggested seems
     one possible solution.

     Regards
     Ravi 

-- 

The views presented in this mail are completely mine. The company is not 
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 May 2003 18:24:55 -0400

>   that there are two SGs and control is transferred from master

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.

>   so that backup can take over tunnel when master fails (To avoid 
>new tunnel establishment).

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

---

From: suren <[email-masked]>
Date: Mon, 05 May 2003 18:27:24 -0700

Hi Stephen,
     Thank you for the response. You stated that the backup SA
     can be created to avoid the transferring SA key material and
     thereby avoiding transfer sequence number information.
     This works fine, if backup device has IP address different
     from the master device. Also, it requires peer to have
     knowledge of backup IP address for a given tunnel.

     In the case, which I was referring in my last email, backup device
     inherits the IP address of master device, when master fails. We 
understand
     that transferring the keying material is not a good thing. But...

     Notification message:
     SYNCH_SEQUENCE notification message can be sent
     on IKE SA with Protocol ID as ESP or AH and notification data
     containing sequence number of this notification message and
     inbound SA's SPI on the peer.

We have following options:
    1. Mandate that backup device has new IP address.
        I am not sure it flies as customers use backup device for state 
transfer
        of other applications such as NAT/Firewall/QoS etc.. This requires
        that backup device inherits the IP address.
        ==> It means that backup SA may not be possible in this case.
   2. Have some sort of detection mechanism, beyond Peer detection ie
       Dead Tunnel detection ( as mentioned by Ravi ) so that Peer eventually
       knows that tunnel is no longer exist and create new Tunnel and this
       time it goes to backup device. But in this case, there may not be
       any communication for the period Dead Peer Tunnel detection and
       time it takes to establish the tunnel.
   3. SA Transfer:  It does not seem to be good thing... By the way,
       our proprietary method is not patented.
   4. Any new proposal from the members in this list?

Thanks
Suren

At 06:24 PM 5/5/2003 -0400, Stephen Kent wrote:
>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:
>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

---

From: "Rajesh Mohan" <[email-masked]>
Date: Tue, 6 May 2003 12:43:38 +0530

Suren,

I understand, your solution is only for outbound 
sequence number. I see one problem with this 
solution. IPSec Packet may be processed 
before IKE INFO packet though it may arrive before
IPSec packet. You may have few dropped packets. 
BTW what will be the sequnce number on these IPSec 
packets. Are you planning to reset it or have 
regular updates and use last known value?

Another possible solution is to update the backup
at regular intervals with the current state of
the window. After failover, just advance the outgoing
sequnce number (the value depends on rate of 
traffic and update interval). In this case, some 
sequence numbers may not be used. I think lot of
people do this. 

Regarding, FIPS certification for transferring
keying material between HA pairs, I think it is
OK for Level 2, if the key is encrypted. We are 
planning to use IKE SA between HA pair to 
secure HA traffic and we think it is good 
enough for FIPS 140-2 Level 2.

-Rajesh Mohan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of suren
> Sent: Tuesday, May 06, 2003 6:57 AM
> To: Stephen Kent; [email-masked]
> Subject: Re: IPSEC in High Availability scenarios
> 
> 
> Hi Stephen,
> >>   customers are increasingly asking for SA transfer 
> between master and 
> >> backup
***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: "Jesse Alpert" <[email-masked]>
Date: Tue, 6 May 2003 12:29:16 +0300

Hi Suren,

The problem you described can be solved using the existing standards, if you
consider the fact that an IPsec peer should be willing to accept (large)
forward leaps in the replay counter value. The backup GW can start it's
replay counter sequence from some larger value.

Note however that for Load Sharing scenarios (as apposed to the High
Availability scenario you described) the solution may not be as simple.

Jesse

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of suren
Sent: Saturday, May 03, 2003 1:32 AM
To: [email-masked]
Subject: IPSEC in High Availability scenarios

Hi,

   Small introduction:

   Problem:
   customers are increasingly asking for SA transfer between master and

   Solution:
   see if there is any inter-operable solution for this problem. We feel
that

Thank you for you time.
Suren
Intoto Inc.

---

From: "Wei-Jen Yeh" <[email-masked]>
Date: Tue, 06 May 2003 08:06:17 -0400

Hi,
  You need to handle replay info from both sender & receiver perspectives, and
there's also the lifetime info that needs to be considered.
  How about redundancy support for the KMP?
  What if you need to have secured traffic to the spare unit, too?
  You also need to engineer your `private network' based on the amount of
SAs that need to be mirrored (assuming you go this route) and do your queuing
right!

--
Wei-Jen Yeh
[email-masked]      Nortel, RTP, NC
Office Phone: (919) 991-2707,   ESN: 35-12707
Fax: (919) 991-8073