From: Davide B. <da...@gm...> - 2010-04-17 17:36:14
|
I'm using ipsec-tools-0.8alpha-20090903 for a lan-to-lan VPN and I'm seeing an issue in ISAKMP SA rekeying. I've set "rekey force" in racoon.conf to force periodic rekeying. Now it turns out that if the other peer was the initiator of the first ISAKMP SA, Racoon does not reinitiate the negotiation even if its soft timer expires first. In the log I see: Apr 17 18:10:41 arch racoon: INFO: respond new phase 1 negotiation: 10.0.0.1[500]<=>192.168.0.1[500] ... Apr 17 18:10:41 arch racoon: INFO: respond new phase 2 negotiation: 10.0.0.1[500]<=>192.168.0.1[500] ... So here Racoon is the responder. But it happens that its soft timer expires before that of the peer, so it wants to rekey: Apr 17 19:03:53 arch racoon: INFO: renegotiating phase1 to 192.168.0.1 due to active phase2 but nothing happens. After a while, when the peer's soft timer expires, it initiates an IKE renegotiation which finally renews the IKE SA. And indeed looking at the source it seems that Racoon reinitiates only if it's already an initiator (isakmp.c, line 1968): plog(LLV_INFO, LOCATION, NULL, "renegotiating phase1 to %s due to " "active phase2\n", saddrwop2str(iph1->remote)); if (iph1->side == INITIATOR) isakmp_ph1begin_i(iph1->rmconf, iph1->remote, iph1->local); ... So my question is: is this expected behavior? Thanks in advance. -- D. |
From: Timo T. <tim...@ik...> - 2010-04-19 08:21:02
|
Davide Brini wrote: > And indeed looking at the source it seems that Racoon reinitiates only if it's > already an initiator (isakmp.c, line 1968): > > So my question is: is this expected behavior? I don't remember the exact reasoning for this when I implemented ISAKMP rekeying. We certainly want to avoid both nodes doing rekeying at the same time, and makes sense that the initiator should be responsible to rekey if needed. You obviously have something else in the other end than racoon since the soft timers expire at different timers. If I remember correctly, the IPsec RFC's do not really specify the exact rekeying semantics. You could even let the ISAKMP SA expire and still continue to IPsec SA, but some implementations do not allow this to happen. Since racoon can allow ISAKMP SA to expire, but let's the IPsec SA's functions, rekeying is not stricly needed in racoon. Well, it helps if one needs to send notifications, and speeds up IPsec SA rekeying in some configurations as we have always valid ISAKMP SA. I'm thinking the current code is acceptable. Improvements are welcome though. If you want responder to rekey ISAKMP SA, it should be done as last resort and much later than the expected rekeying from initiator. Also do note that this is not possible for some configurations. E.g. if XAUTH is used, or some other additional layers above ISAKMP SA, it's not even possible to swap initiator/responder role because ISAKMP SA is needs additional authentication data from the initiator. - Timo |
From: Davide B. <da...@gm...> - 2010-04-19 10:48:19
|
On Monday 19 Apr 2010 09:20:53 Timo Teräs wrote: > Davide Brini wrote: > > And indeed looking at the source it seems that Racoon reinitiates only if > > it's already an initiator (isakmp.c, line 1968): > > > > So my question is: is this expected behavior? > > I don't remember the exact reasoning for this when I implemented ISAKMP > rekeying. We certainly want to avoid both nodes doing rekeying at the > same time, and makes sense that the initiator should be responsible to > rekey if needed. > You obviously have something else in the other end than racoon since > the soft timers expire at different timers. Yes exactly. > If I remember correctly, the IPsec RFC's do not really specify the > exact rekeying semantics. You could even let the ISAKMP SA expire and > still continue to IPsec SA, but some implementations do not allow this > to happen. ISTR this used to happen with older versions of Racoon that did not have the "rekey" directive in the configuration file, and always looked a bit odd to me, so I was happy to find the "rekey" option in the latest version. > Since racoon can allow ISAKMP SA to expire, but let's the IPsec SA's > functions, rekeying is not stricly needed in racoon. Well, it helps > if one needs to send notifications, and speeds up IPsec SA rekeying > in some configurations as we have always valid ISAKMP SA. > > I'm thinking the current code is acceptable. Improvements are > welcome though. If you want responder to rekey ISAKMP SA, it should > be done as last resort and much later than the expected rekeying from > initiator. Well, I was expecting "rekey force" to do exactly that, ie force the rekeying (if the peer hasn't done so already), regardless of whether we were the responder or the initiator. If that means swapping the initiator/responder roles, then so be it as the standard does not prohibit that anyway (IIRC). At least that would be my expectation (which does not mean I'm correct of course). Of course this also assumes that the implementation at the other end has no trouble in swapping the roles too; to be honest, I don't know how many implementations can happily do that; maybe most of them just assume "the initiator always rekeys" like Racoon. Surely it seems to me that, at the very least, the "renegotiating phase1 due to active phase2" message should not be logged if then Racoon isn't going to do anything. It would seem that can be done by simply moving the call to plog() inside the following if (iph1->side == INITIATOR)... Also it would probably help to have the soft timer be a configurable value (perhaps even with IKE SA and IPsec SA soft timers adjustable separately?) rather than fixed at 80%, so one could always tweak things to match the other peer. Maybe that would be enough to solve most problems. I think having more flexibility wouldn't hurt anyway. If that's OK with you, I can try to have a look and see what I can do (no guarantees as I had never look into the code before the other day!) > Also do note that this is not possible for some configurations. > E.g. if XAUTH is used, or some other additional layers above > ISAKMP SA, it's not even possible to swap initiator/responder role > because ISAKMP SA is needs additional authentication data from the > initiator. Right, thanks for bringing this up, as this is something I didn't think of. Perhaps the role swapping could be made conditional to those conditions not being present, but I understand this would probably be a major change. Thanks! -- D. |
From: Timo T. <tim...@ik...> - 2010-04-19 12:05:55
|
Davide Brini wrote: > On Monday 19 Apr 2010 09:20:53 Timo Teräs wrote: >> Davide Brini wrote: If I remember correctly, the IPsec RFC's do not >> really specify the exact rekeying semantics. You could even let the >> ISAKMP SA expire and still continue to IPsec SA, but some >> implementations do not allow this to happen. > > ISTR this used to happen with older versions of Racoon that did not > have the "rekey" directive in the configuration file, and always > looked a bit odd to me, so I was happy to find the "rekey" option in > the latest version. Yes, I implemented it since I need to do dead peer detection reliably. Since DPD works on ISAKMP SA, you really need working rekeying. >> Since racoon can allow ISAKMP SA to expire, but let's the IPsec >> SA's functions, rekeying is not stricly needed in racoon. Well, it >> helps if one needs to send notifications, and speeds up IPsec SA >> rekeying in some configurations as we have always valid ISAKMP SA. >> >> I'm thinking the current code is acceptable. Improvements are >> welcome though. If you want responder to rekey ISAKMP SA, it should >> be done as last resort and much later than the expected rekeying >> from initiator. > > Well, I was expecting "rekey force" to do exactly that, ie force the > rekeying (if the peer hasn't done so already), regardless of whether > we were the responder or the initiator. If that means swapping the > initiator/responder roles, then so be it as the standard does not > prohibit that anyway (IIRC). At least that would be my expectation > (which does not mean I'm correct of course). > > Of course this also assumes that the implementation at the other end > has no trouble in swapping the roles too; to be honest, I don't know > how many implementations can happily do that; maybe most of them just > assume "the initiator always rekeys" like Racoon. Assuming that "initiator always rekeys" is acceptable IMHO. It makes sense scalability wise, and also because initiator should be in charge of things like this anyway. > Surely it seems to me that, at the very least, the "renegotiating > phase1 due to active phase2" message should not be logged if then > Racoon isn't going to do anything. It would seem that can be done by > simply moving the call to plog() inside the following if (iph1->side > == INITIATOR)... Right. At least the message could say something different. Or just different messages if we are initiator or responder. > Also it would probably help to have the soft timer be a configurable > value (perhaps even with IKE SA and IPsec SA soft timers adjustable > separately?) rather than fixed at 80%, so one could always tweak > things to match the other peer. Maybe that would be enough to solve > most problems. I think having more flexibility wouldn't hurt anyway. I have a memory that this is just a #define somewhere in the headers. > If that's OK with you, I can try to have a look and see what I can do > (no guarantees as I had never look into the code before the other > day!) Sure. >> Also do note that this is not possible for some configurations. >> E.g. if XAUTH is used, or some other additional layers above ISAKMP >> SA, it's not even possible to swap initiator/responder role because >> ISAKMP SA is needs additional authentication data from the >> initiator. > > Right, thanks for bringing this up, as this is something I didn't > think of. Perhaps the role swapping could be made conditional to > those conditions not being present, but I understand this would > probably be a major change. I'd prefer to not to have conditional behaviour depending on the SA configuration. Instead the initiator/responder division is much better. Is there any benifit for making responder renegotiate the SA? I can't think of any situation where that would help. |
From: Davide B. <da...@gm...> - 2010-04-19 12:48:48
|
On Monday 19 Apr 2010 13:05:44 Timo Teräs wrote: > Assuming that "initiator always rekeys" is acceptable IMHO. It makes > sense scalability wise, and also because initiator should be in charge > of things like this anyway. Ok. > > Surely it seems to me that, at the very least, the "renegotiating > > phase1 due to active phase2" message should not be logged if then > > Racoon isn't going to do anything. It would seem that can be done by > > simply moving the call to plog() inside the following if (iph1->side > > == INITIATOR)... > > Right. At least the message could say something different. Or just > different messages if we are initiator or responder. > > > Also it would probably help to have the soft timer be a configurable > > value (perhaps even with IKE SA and IPsec SA soft timers adjustable > > separately?) rather than fixed at 80%, so one could always tweak > > things to match the other peer. Maybe that would be enough to solve > > most problems. I think having more flexibility wouldn't hurt anyway. > > I have a memory that this is just a #define somewhere in the headers. Well yes, but I was thinking of introducing a new configuration directive like "rekeysoft" or perhaps "{ike,ipsec}rekeysoft" so one could tweak it without the need for rebuilding (and per-peer/per-proposal as well). It could even accept absolute times, or percentages of the lifetime (with different syntaxes of course). > > If that's OK with you, I can try to have a look and see what I can do > > (no guarantees as I had never look into the code before the other > > day!) > > Sure. Ok, don't hold your breath but I'll start looking into this. > I'd prefer to not to have conditional behaviour depending on the > SA configuration. Instead the initiator/responder division is much > better. > > Is there any benifit for making responder renegotiate the SA? I can't > think of any situation where that would help. Well, probably not major problems, just minor annoyances; and even those could probably be avoided by having a configurable soft timer. Thanks. -- D. |