On Thu, Dec 15, 2005 at 10:27:02AM -0500, jamal wrote: > On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote: > > On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote: > > > > 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. > > > > Thats one interpretation.
No, that is quite a copy/paste of the RFC.... > The other is in the same section and says: > "Deletion of the old SA is dependent on local security policy." > > i.e this is not something that a remote system would know of and policy > is handled by a km really or someone configuring a km. Perhaps this part just means that an implementation can decide to NOT delete the old SA for some reasons when the new one is used.... Or perhaps it means something else..... Or perhaps there is a contradiction in the RFC.... > > - 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). > > > > So is the RFC poorly worded? i.e should those have been MUST instead of > SHOULD? I think so. Well, at least, as soon as both implementations reacts as described, things works well without problems.... > This is a classical 101 deadlock problem. If there are two resources > involved (in this case old and new SA) - then the order in which they > are used is important. IMO, Linux does the right thing: > 1) Use the old SA until it expires or is deleted. followed by > 2) use new SA but not before step #1. Not always. If remote hosts have significative clock derivations (for example "a few seconds every day") and SA lifetime are "big enough" (for example "one day"), you may have some (quite small) blackouts with this method. Using the new SA as soon as it's available solves this (well, I agree, quite minor) issue. Using the new SA asap also allows implementations to flush "most of the dying SAs" (some may need to be kept back, for example if remote still uses the old SA....), so save some memory for the Key Manager. Using the old SA until it expires would be a "quite not bad solution" (if that was what RFC says and if all implementations did that way), but using the newest SA asap is also a "good sotion", which have advantages against still using old SA. > > The real problem is that 2 implementations which both does "wrong > > things" try to talk to each other.... > > I think "wrong" is strong language given the RFC says "SHOULD". Yep, that's why I quoted it. > And > unfortunately we have to play english language acrobatics;-> because of > the way this thing is worded. > I am actually *not* against putting such a sysctl in the kernel - it is > non-trivial. Herbert has some ideas that will require changes in racoon. I don't really see what racoon could do for that, but we can discuss it. > > 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. > > > > right - and this is the reason we discussed to put something in the > kernel to compensate for that possibly lost message. But the policy to > delete still has to come from racoon. > > At the moment, racoon doesnt even respect this delete from what ive > read. Racoon DOES respect DELETE_SAs afaik, and DOES respect them for every test situation I tried. If some are not respected, that is a bug, perhaps in the implementation which generates the DELETE_SA, perhaps in racoon. And if this is a bug in racoon, give me enough debug/informations and I'll fix it. > > 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). > > > > That does sound sensible. And that helps good interaction with quite any implementation. > > Using the old/new outgoing SA is decided according to a sysctl value. > > which is really pushing policy down into the kernel ;-> Yep. But the "Key storage" is already done mostly in the kernel (racoon "just" does keys negociation and forwards informations to the peer when it receive an appropriate message from kernel), and I think the policy should be "at the key storage level". > > 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. > > ok - sorry i misstated that in my earlier email that you had it in CVS > because i thought you already applied it based on our discussion. Perhaps I told you that I would commit it "in the next few days", but I had other things (some related to ipsec-tools) to do those last days. > > 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.... > > Agree. It is a _workaround_;-> A good one in my opinion. Given that it > works for CISCOs, a very large piece of the problem is resolved, no? If this workaround is good enough for you, great, but I strongly believe that this will NOT close the discussion about old/new SA usage in Linux kernel..... [....] > > Will the next step be to detect cisco's vendor ID and automagically > > adjust soft lifetime when a cisco peers is detected ?????? > > Well, as strange as this may sound, actually it may not be that > unreasonable to dynamically make the policy decision;-> we know which > devices have problems. > Is there no way in racoon that someone will get the vendor id in an > external C program or shell script and then they reconfigure IKE > parameters for that peer only? If yes, then one could create a little > script or C program that sets the softime for ciscos. Again, this is a *workaround*. A big and bad one if we start to detect "broken"/"problematic" implementations with Vids !!!!!! [....] > > 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. > > Theres a few people that have complained about it and are at better > position to give you output. I have CCed one such person > <[EMAIL PROTECTED]> unfortunately i dont know his name. For people who have such problems: please send a mail on ipsec-tools-devel with as many informations as you can, we'll track this problem. > Ok, Yvan, let me sumarize this in the following way so we can solve this > issue: > > 1) Herbert has a kernel approach that will resolve things for you; it > will need help from racoon. If you havent seen the proposal i will let > Herbert explain it or i could if he is not around. Well, I may have already read some parts of this proposal on old mails, but a summary for everybody may be interesting (including for me !!!). > 2) you will honor deletes in racoon We already honour DELETE_SA I am able to generate and test, and if we have a bug for some kind of DELETE_SA, we'll fix it as soon as we'll have enough informations to undestand the problem ! > 3) you will add the softime patch i have sent to racoon. Yep, I consider this is an interesting feature. > I think this would fix all known problematic devices. Hope so ! 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
