On Thu, 15 Dec 2005, jamal wrote:
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.
It does matter. This problem does not exist when cisco acts as responder,
this problem does not exist when linksys acts as initiator.
Do you disagree with this?
Yes ;)
Other people who have tried the patch dont seem to agree with your
thesis.
Not sure:
---------- Forwarded message BEGIN ----------
Date: Mon, 21 Nov 2005 15:31:54 +0100
From: [EMAIL PROTECTED]
To: jamal <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: [Ipsec-tools-devel] Forcing SA soft limit?
I could give you a patch that forces the soft limit. I have not tested
it and have not seen interest from the racoon folks to incorporate it.
Talk to me privately.
Unfortunately setting the soft limit does not solve my problem. I
tried recompiling from the sources setting my wanted soft limit.
The problem turned out to be the peer (a cheapo DrayTek Vigor
2500 router) which discard the old SA before the hard limit
expires and without agreeing the revoke with Racoon.
---------- Forwarded message END ----------
Very simple and accurate explanation.
You are the one who opened the bug - have you tried the patch? ;->
It adds very useful feature but does not solve my problem.
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.
Sometime yes, sometime no. Generally: no.
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.
True. I can accept any fix, as long as it is going to _solve_ the problem.
For me both kernel or racoon fixes are totally fine. But please notice
that dirty workarounds are not going to fix this and I alredy have one
("echo -ne -1 > /proc/sys/net/ipv4/route/flush" after negotiating each new
SA). It works and it is ugly. Very ugly. ;)
Best regards,
Krzysztof Olędzki
