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. 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. > - 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? 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. > 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". 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. > 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. > > 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). > That does sound sensible. > Using the old/new outgoing SA is decided according to a sysctl value. > which is really pushing policy down into the kernel ;-> > 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. > 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? > > 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 ?????? > 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. > > > > > 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. > 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. 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. 2) you will honor deletes in racoon 3) you will add the softime patch i have sent to racoon. I think this would fix all known problematic devices. 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
