ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] Ikev2 HA message Id Issue

Re: [IPsec] Ikev2 HA message Id Issue

From: Tero Kivinen <kivinen_at_nospam>
Date: Fri Sep 04 2009 - 09:40:10 GMT
To: <Pasi.Eronen@nokia.com>


Pasi.Eronen@nokia.com writes:
> > If dpd is enabled then ikev2 counters keep updated frequently.
>
> This depends on how often you do DPD... Obviously, you want dead
> IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would
> be sufficient for that. If your DPD interval was close to the value
> of N, that would not work well... but on the other hand, if you have
> lot of traffic going back and forth, IKEv2 DPD won't get triggered..

You should not really have fixed timer for DPD. You should base your DPD interval depending on the other things, i.e. if there is ESP traffic coming from the other end to your site, there is no point of doing DPD based on timer unless something else says otherwise.

If you start suspecting there might be something wrong with IKEv2 SA (i.e. you receive ICMP or network goes down and comes up again etc), then you might trigger DPD once to see if the other end is still there.

If you only trigger timer based DPD when there is no ESP traffic at all (i.e. the both IKEv2 SA and IPsec SA are completely idle) then there is no point of trying to use too short DPD timers as the SA is idle anyways, and in such cases you do not need very fast recovery from other ends crashes...

Only case where you might need more frequent timer based DPD is when your traffic is unidirectional, i.e. you are sending ESP traffic to other end but other end is not sending anything back. As this is not a common case in normal operation, that is good indication there might be something wrong and in such cases you should trigger DPD to verify it the other end is up.

In general I consider syncing HA boxes after each IKEv2 Message (or once per second etc) not too big problem. HA boxes are usually directly connected with fast network cable (usually at least as fast as their traffic in), and every single IKEv2 message requires some cryptographic operations anyways, and is bigger than what it would be to send short cleartext message to other HA telling "I finished processing my request message id XXX at IKE SA YYY" or "I finished processing my reply to message id XXX at IKE SA YYY and packet sent was ZZZ" (you need to sync the reply packet data you sent to other end just in case the packet was lost and other end didn't get it, so you can retransmit it from HA pair).

In any case you will loose all IKE SA which are in the middle of exchanges when one of the devices goes down, as syncing intermediate state from one device to other would be way too complex. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec