Subject: RE: [Ipsec] is there any idea on ipsec HA?

From: "Yoav Nir" <[email-masked]>
Date: Sun, 1 Jan 2006 10:04:52 +0200

If you're doing HA, you can have a single IKE SA, but a separate IPsec SA
for each security gateway.  If you're using IKEv1, this will work with some
but not all of the peers. If you're using IKEv2, then allowing two parallel
SAs is required.

Even if this is not allowed, when the failover happens, you can quickly
(using Quick Mode or Create-Child-SA) create an IPsec SA and traffic will
continue as before. You don't need to backup every packet or synchronize the
replay counter for every packet. 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wade
Sent: Friday, December 30, 2005 6:33 PM
To: [email-masked]; [email-masked]
Subject: [Ipsec] is there any idea on ipsec HA?

hello,
 
     The Ipsec high availability is one of requirement of people. Usually we
use two security gateways, one acting as a master and another acting as a
standby SG. 
     I got a question on the packet sequence number,  should the master SG
send every packet to standby SG? The sequence number is used by anti-reply,
if we don't bakeup it, when the master SG is halt for some reason the remote
peer won't accept the packet which received from the backup SG because the
packet SN won't pass the anti-reply checking mechanism. But to backup every
packet is impossible, it's take too much throughput.. 
 
     If we don't want to disable the anti-replay,  is there any advice to
solve this problem?

Thanks
 
Huide

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Jan 2006 09:48:03 +0200

> replay counter for every packet. 

For IKEv2 you need to synchronize all IKEv2 exchange data for every
IKEv2 SA packet, as if the peer doing the negotiation crashes in the
middle of the exchange, then the backup host needs to be able to
complete that exchange.

On the other hand IKE SA exchanges are much less frequent than IPsec
packets, thus synchronizing those shouldn't be problem.

There is also all kind of tricks you can do to make the syncronizing
less frequent. If you are really doing HA system (i.e. no load
balancing) then the easiest way is to make sure that backup node
actually will see all same packets that the main system sees (i.e. it
can keep up to date window for received packets), and for outgoing
packets you simply need to skip far enough forward to make sure you do
not reuse any sequence numbers already used by the main node (i.e. if
you transmit last outgoing sequence number every 0.1 seconds from main
node to backup node, and the link speed is 100 MBit/s, there can be at
maximum 20000 packets sent out by the main node during that 0.1 second
time, thus if you skip forward for example 1 000 000 that should make
sure you do not reuse previous sequence numbers (provided you noticed
the crash of main node in less than 50 seconds time).

If you want to do load balancing, i.e. both nodes process packets all
the time, and your normal load is high enough that you cannot process
full stream of packets on one node, then you have to use much more
complicated tricks (and most likely you need to have fast enough
communications between the nodes to keep the reply window information
in sync).
-- 
[email-masked]

---

From: Huide Yin <[email-masked]>
Date: Mon, 2 Jan 2006 23:02:14 +0800

> replay counter for every packet.

    Here, does you mean only backup the phase I SA is enough?  so .. when
the master SG broken down, we still need to re-negotiating the phase II SA ,
that will take some time, at least we need the 3 message each side for quick
mode exchange,  and we should notify the remote peer to delete the old one
of the Phase II and initiating the exchange, all of the must take some
time... If the traffic is busy, this will cause many packets in the ipsec
tunnel be droped...

   And for the "load share" the phase II SA is necessary, right? The 2
phases SA should be backed up, and may be the 32 packets anti-reply window
can be used.

   Here is an idea on the SN processing, but I'm not sure it's
feasibility: We can send the backup info only when the anti-reply checking
reach the edge of window, that means we will send 1 backup info every 32
packets have been processed by Ipsec.  So if the master halt, the backup SG
can increase the SN counter and continue the packet forwarding...

Huide

---

From: Huide Yin <[email-masked]>
Date: Tue, 3 Jan 2006 00:04:20 +0800

> the crash of main node in less than 50 seconds time).

   Is there any problem about this method?  I think it can solve the
packet's sequence number problem between master & standby SGs, but we must
assume the maximum link speed  between remote peer and HA group, right?
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 11:57:48 +0200

Huide Yin writes:
>    Is there any problem about this method?

There are all kind of implementation problems with all of these
methods, and you need to think of those and solve them when making
implementation. I haven't really implemented full HA setup myself, so
I cannot say if there is more problems that I missed with that
approach, but I do know that some people have used that kind of method
to implement HA setups.

> I think it can solve the packet's sequence number problem between
> master & standby SGs, but we must assume the maximum link speed
> between remote peer and HA group, right?

The actual amount of packets you jump forward does not really matter,
so you can increment the outbound sequence number with large enough
number when you notice the failure of the master node. I mean, you
could also simply set it to 0xf0000000 or so, and immediately start
rekey, and hope that the 0x0fffffff packets is enough for you to be able
to finish the rekey (the actual values could depend on your setup). In
that case you of course need to make sure that the sequence number
never normally gets up to that big, i.e. start rekey normally when
sequence number is around 0xe0000000 or so.

There is also other kind of tricks you can do depending on your setup.
-- 
[email-masked]

---

From: VANHULLEBUS Yvan <[email-masked]>
Date: Tue, 3 Jan 2006 16:01:59 +0100

(for moderators: once again, with my *good* address for
ipsec@ietf. Sorry if the mail appears twice on some lists...)

Looks this mail didn't reach ipsec@ietf mailing list (I'm not using
the same mail adress for my subscriptions to both lists...), sending
it again with the "good" email for this list (for "who moderates
ipsec-tools-devel: discard this mail, already sent to the list...).

On Fri, Dec 30, 2005 at 07:50:54PM +0000, Brian Candler wrote:
[IPSec HA]
> ipsec-tools is a package which negotiates keys and installs a SA - it does
> not actually perform any ESP packet processing - so I'm not sure why you're
> asking on the ipsec-tools-devel list.

IPSec HA is a process which involves all layers, including racoon, if
you want *real* and working HA.

Let's guess you use a Linux / BSD kernel with racoon, and implement an
IPSec SA tool to synchronize both kernels.

When the active gate hangs up, negociated tunnels will continue to
work....

But if you have NAT-T tunnels, you won't have anymore keepalives (done
by racoon).

If your peer have DPD enabled, you won't be able anymore to decrypt
it's DPD requests (protected by the IKE SA), so your peer will
quickly consider you're dead.

And if you don't have DPD, and if your peers wand to negociate a new
IPSec SA, it will probably try to negociate it through an existing IKE
SA, which does NOT exists for you !

There are other problems (generated policies, etc...), which are more
or less complex to solve.

> If you want to have instant failover between a master and slave gateway,
> then yes you will need to synchronise state between them. The two solutions
> I'm aware of are OpenBSD (sasyncd/pfsync) and Cisco IOS (State
> Synchronisation Protocol, SSP)

Such solutions to synchronize IPSec SAs (I did not have a closer look
on those solutions, I just *believe* they "just" synchronize IPSec
SAs) are "instant failover", but will generate problems I just
explained, at least for racoon + Linux / BSD solutions.

> >         If we don't want to disable the anti-replay,  is there any advice
> >    to solve this problem?
> 
> Since you didn't describe what sort of gateways you have, then no-one is
> going to be able to advise you whether the feature you want is available for
> them or not.

A *perfect* IPSec HA solution does NOT depends on the gateways type,
usage, peers, etc....

It just depends on the gate on which you wants to have HA, and as this
was posted on ipsec-tools ML, I believe the answer is "ipsec-tools
with Linux/BSD stack".

Yvan.

-- 
NETASQ - Secure Internet Connectivity
http://www.netasq.com

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Jan 2006 10:18:07 -0500

At 12:33 AM +0800 12/31/05, Wade wrote:
>hello,
>
>      The Ipsec high availability is one of requirement of people. 
>Usually we use two security gateways, one acting as a master and 
>another acting as a standby SG.
>      I got a question on the packet sequence number,  should the 
>master SG send every packet to standby SG? The sequence number is 
>used by anti-reply, if we don't bakeup it, when the master SG is 
>halt for some reason the remote peer won't accept the packet which 
>received from the backup SG because the packet SN won't pass the 
>anti-reply checking mechanism. But to backup every packet is 
>impossible, it's take too much throughput..
>
>      If we don't want to disable the anti-replay,  is there any 
>advice to solve this problem?
>
>
>Thanks
>
>Huide

To mirror an SA on two devices requires sharing a lot of state, 
including keys. In general, making provisions to share the SA keys 
may create vulnerabilities. Only if you can avoid such 
vulnerabilities does it make sense to pursue the sort of tricks Tero 
suggests.

Steve