On Thu, 2005-15-12 at 17:23 +0100, VANHULLEBUS Yvan wrote: > 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.... >
yes, but since we are both playing armchair lawyers, as they ask for in court to "speak the truth and nothing but the whole truth", a more full truth cutnpaste is: --- 4.3 Security Association Modification Security Association modification within ISAKMP is accomplished by creating a new SA and initiating communications using that new SA. Deletion of the old SA can be done anytime after the new SA is established. Deletion of the old SA is dependent on local security policy. Modification of SAs by using a "Create New SA followed by Delete Old SA" method is done to avoid potential vulnerabilities in synchronizing modification of existing SA attributes. .. .. .. A protocol implementation SHOULD begin using the newly created SA for outbound traffic and SHOULD continue to support incoming traffic on the old SA until it is deleted or until traffic is received under the protection of the newly created SA. As stated previously in this section, deletion of an old SA is then dependent on local security policy. --- > 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.... > and this is the problem. > > 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.... > so lets settle its poorly worded and move on towards a resolution. > > > 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. > Ok, I will buy your arguement on this possibility however slim it is in happening in the real world ;-> > > 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. > Perhaps that person is having some other issues then. The logs he sent were indicative of the DELETE being seen but the SAs not getting purged. > 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. [EMAIL PROTECTED] could you please provide the details again? Change the subject on the email please when you do. And BTW, this person did send this to the ipsectools list (at least in email cced to me) but no-one responded. > 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". > The mechanism to _use a key_ surely belongs in the kernel. The policy to select between two supposedly valid keys need to sit in the policy setter - the km. > 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. > no problem. You did mention something along version 0.7. > [....] > > > 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 !!!!!! > yes, of course ;-> But why do you have those hooks for phase1 and phase2? Is it not to do unusual things - like workarounds? > > 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 !!!). > ok, here goes, Herbert correct me if iam wrong: i ) a new field that looks like reqid will be needed in racoon on a per SA basis. ii) This field is incremented on every SADB_UPDATE to mean "use new SA" The kernel will refer to this field in the SA vs what it has cached every time it wants to use a cached SA. If the two ids differ, then the old one is purged and the new one is used immediately. This allows us to not have to have a global "use new sa" sysctl and have the km incharge of the policy. Seems like we are in sync on the other two features; so no issues there. 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
