On Wed, 2005-14-12 at 16:48 -0800, David S. Miller wrote: > Please have a look at: > > http://bugzilla.kernel.org/show_bug.cgi?id=4952 > > It should look familiar.
It is - the soup nazi got involved on that bug ;-> http://marc.theaimsgroup.com/?l=linux-netdev&m=113070963711648&w=2 > We were discussing this in depth a few weeks ago, but the > discussion tailed off and I don't know how close we came > to a consensus or what that consensus might be :-) > it sort of is still hanging but there is progress. > The crux of the matter, to reiterate, is that it is a non-trivial > problem to determine what existing SA entries are subsumed by a > newly inserted one. The kernel would need to execute a rather > complicated search in order to determine this SA set. Right - Herbert has some ideas that would require help from the KM. And we are actually agreeing we should implement a minimalist approach. More below .. > The subsequent argument states that actually, unlike the kernel, > the keying daemon does have some knowledge about what a new > SA entry might be replacing. And therefore, that userland > daemons such as racoon bear some responsibility in assisting > in the smooth and efficient switchover from the dying state > entry to the newly inserted SA. > > Any comments or corrections on this? correct with caveats: 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. 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. 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. So bug in racoon for sure but not good enough given the unreliability of IKEv1. So in the last discussion Herbert and I had we talked about doing something in the kernel since this was getting frustrating ... Herbert has it on his TODO and i was going to get racoon part once he has his patch. cheers, jamal - 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
