On Thu, 2005-15-12 at 17:11 +0100, Krzysztof Oledzki wrote: > > On Thu, 15 Dec 2005, jamal wrote:
[..] > > Thats one interpretation. The other is in the same section and says: > > "Deletion of the old SA is dependent on local security policy." > > Please notice - there are two SA: incomming and outgoing. You may (or > may not) still accept old SA but use new for outgoing traffic. > I understand this friend. > > So is the RFC poorly worded? i.e should those have been MUST instead of > > SHOULD? > Not really. It is very, _very_ precise. > it is not precise, sorry. > > 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'm not sure if you have ever read any RFC carefully. I have _written_ or coauthored RFCs and internet drafts - many - and had to be carefully selective of the language for preciseness. This piece of description would have been appropriate to use a MUST instead of SHOULD given that full interop is impossible otherwise. > > > 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. > AFAIR that ideas require to use native XFRM interface. Racoon, which > can work on may platforms, uses PF_KEY. > should work fine with PF_KEY; requires small changes to SADB_UPDATE and the way state is stored in racoon. > > 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? > No, again, it does not help. I explained it in my previous mail. > It will help 100% of the time _if you know_ you have CISCOs on the other end and you configure racoon with that in mind. In other words it doesnt matter who the initiator/responder is in this case. Do you disagree with this? Other people who have tried the patch dont seem to agree with your thesis. You are the one who opened the bug - have you tried the patch? ;-> > > > > 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. > Really? I don't think so. > OK, let me ask you this: When you configure "use new SA" - are you making assumption about what is on the other end? in other words, you have knowledge of the end device to assume it will start accepting the new SA immediately. > > 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. > But what if the same problem exists in other IPSec implementations that > can not be detected by vendor ID? > then you will need to use the admins brain as a last resort i.e. no different than you making the assumption that the other end is respecting "use new SA". In any case - what we need to do is fix this issue and not argue semantics of the RFC. IMO, its a screw up in the RFC definition. 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
