On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote: > On Thu, 2005-15-12 at 05:57 +0100, Krzysztof Oledzki wrote: > > Addedd CC: to the [EMAIL PROTECTED] mailing list. > > > > And I added Shoichi Sakane to the CC. He is responsible for bringing > "use new SA" feature to BSD to begin with and is one of the original > authors of racoon. > So lets take one more go at this discussion ;-> I am annotating the > paragraphs for his benefit - I hope you dont mind Krzysztof. > > > On Wed, 14 Dec 2005, jamal wrote: > > > [..] > > > there are two sorts of problematic devices. > > > > > > 1) The Ciscos, I think PIX and their relatives (I heard linksys): > > > These suckers have a "fixed" time between soft expiry time and > > > hard expiry time;-> > > > IKE only negotiates hard expiry, and soft expiry is up to the peer. > > > Racoon says soft expiry = 80% of hard expiry. > > > So if you have the expiry at 10 hours, racoon will set soft expiry > > > at 8 hours. CISCO hardcodes 30 seconds to be between the hard and soft > > > expiry ;-> Yep, when you have RFCs written in a natural language like > > > English shit like this happens. So at the 8 hour mark, racoon > > > renegotiates. For 30 seconds more after that, things continue working. > > > Then for the next 119.5 minutes nothing works because infact CISCO > > > purges its old SA and Linux (as it should) starts using the new one. > > > The proper way is for CISCO to send a IKE delete; it doesnt. > > > > AFAIK this is not true. > > What is not true?;-> CISCO doesnt hardcode 30 secs as the time between > soft and hard expiry? Or what is said with CISCO not sending IKE > delete? AFAIK, both are true.
According to RFC 2408 (4.3), both implementations are "quite wrong": - Linux SHOULD start using the new SA as soon as possible. - Cisco SHOULD continue to accept packets using the old SA until the new one have been used (or, of course, until the old SA reaches it's *hard* expire lifetime). > > The real problem is that Linux does not start > > using new SAs without additional routing cache flush as long as old SA > > exist. > > To Shoichi: This is _the_ contentious issue per the RFC and the > discussion is to come up with a solution. The logic i, and I am sure > Herbert and Dave are using, is that if it is not Linuxs fault why should > Linux get into this complicated fixes when there are other ways to do > it. The real problem is that 2 implementations which both does "wrong things" try to talk to eachother.... [....] > > The problem has nothing with hardcoded expiry time. When acting as > > initiator, Cisco negotiates new IPSec-SA and fluses old one while Linux > > still uses it. > > No, that is the effect ;-> The problem has to do with _hardcoded expiry > timer_ for the SA. > CISCO could send an IKE delete to indicate it no longer uses the SA or > the assumption is the SA is valid for a period of time that has been > negotiated. CISCO instead keeps the old SA around for 30 secs and the > effect because Linux continues to interpret it as useful for the > remainder 20%. Yep. Some other implementations really delete the old SA before it's hard lifetime expires, but sends a DELETE_SA. Not that this is still not the perfect way of doing things, because the DELETE_SA may be lost. > > Similar problem exists with Linksys (for example BEFSX41) > > when Linux act as initiator. After 80% of a lifetime it negotiates new SA > > but still uses old one, and such packets are ignored by BEFSX41. > > Probably same code base. And blame Shoichi for propagation of this > bug ;-> If this "fix" did not exist on BSD, cisco would have hardly > interoped with anybody - given that majority of deployed ipsec devices > probabaly just copied the KAME code. No, KAME's code will NOT delete the old *incoming* SA until the new one is used (and, if I remember well, until it expires). Using the old/new outgoing SA is decided according to a sysctl value. > > > To fix this i submitted a patch to racoon which is in their CVS - i was > > > told it will show up around their release 0.7. The patch allows people > > > to hardcode like in cisco a specific time. So this fixes the CISCO > > > problem without touching the kernel. > > > > It may be useful but it does not fix _this_ problem, really. > > AFAIK, you of all people has not even bothered trying it because you > insist on a kernel fix so we can just be good people like BSD;-> About the configurable lifetime patch on ipsec-tools: I have NOT reported it on the CVS for now, mainly because I didn't have time to do a quick review and perhaps some minor changes. I think having a configurable soft lifetime is an interesting feature for some configurations, but I'm really *not* sure it will be the good solution for the problem we're talking about.... > > IPSec > > initiator can negotiate new SA an any time so this will not work when > > Linux is the responder. Negotiating new SA, for example 30s before hard > > expiratin, means 30s without communication so this is also unacceptable > > solution. > > > > That will only happen if you are unaware that the initiator is CISCO and > have not preconfigured racoon to expect a device like CISCO. Hopefully > someone you are configuring for will bitch and you can fix your configs. > IOW, the setting of the diff for soft to hard time will fix it if you > have the knowledge which could be taken for granted. Will the next step be to detect cisco's vendor ID and automagically adjust soft lifetime when a cisco peers is detected ?????? > > > 2) There are other sorts of devices - i am told some made by a vendor > > > called DrayTek infact deletes right away after renegotiation. > > > But they do send a IKE delete except racoon ignores it ;-> > > > As was pointed out to me that even since IKEv1 is unreliable such a > > > message could be lost anyways. > > hopefully the ipsec tools folks can pay good attention to this. I could > probably take a crack at fixing it when i get the time. If you have a configuration where DELETE_SA are discarded by racoon, then we'll have to understant why and fix it if it is a racoon's bug. Yvan. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
