Addedd CC: to the [EMAIL PROTECTED] mailing list.
On Wed, 14 Dec 2005, jamal wrote:
On Wed, 2005-14-12 at 16:48 -0800, David S. Miller wrote:
Please have a look at:
http://bugzilla.kernel.org/show_bug.cgi?id=4952
It should look familiar.
It is - the soup nazi got involved on that bug ;->
http://marc.theaimsgroup.com/?l=linux-netdev&m=113070963711648&w=2
We were discussing this in depth a few weeks ago, but the
discussion tailed off and I don't know how close we came
to a consensus or what that consensus might be :-)
it sort of is still hanging but there is progress.
The crux of the matter, to reiterate, is that it is a non-trivial
problem to determine what existing SA entries are subsumed by a
newly inserted one. The kernel would need to execute a rather
complicated search in order to determine this SA set.
Right - Herbert has some ideas that would require help from the KM.
And we are actually agreeing we should implement a minimalist approach.
More below ..
Yes, it is possible but it is still belevied to be not trivial. Racoon
developers explained it several times.
The subsequent argument states that actually, unlike the kernel,
the keying daemon does have some knowledge about what a new
SA entry might be replacing. And therefore, that userland
daemons such as racoon bear some responsibility in assisting
in the smooth and efficient switchover from the dying state
entry to the newly inserted SA.
Any comments or corrections on this?
correct with caveats:
there are two sorts of problematic devices.
1) The Ciscos, I think PIX and their relatives (I heard linksys):
These suckers have a "fixed" time between soft expiry time and
hard expiry time;->
IKE only negotiates hard expiry, and soft expiry is up to the peer.
Racoon says soft expiry = 80% of hard expiry.
So if you have the expiry at 10 hours, racoon will set soft expiry
at 8 hours. CISCO hardcodes 30 seconds to be between the hard and soft
expiry ;-> Yep, when you have RFCs written in a natural language like
English shit like this happens. So at the 8 hour mark, racoon
renegotiates. For 30 seconds more after that, things continue working.
Then for the next 119.5 minutes nothing works because infact CISCO
purges its old SA and Linux (as it should) starts using the new one.
The proper way is for CISCO to send a IKE delete; it doesnt.
AFAIK this is not true. The real problem is that Linux does not start
using new SAs without additional routing cache flush as long as old SA
exist. The problem has nothing with hardcoded expiry time. When acting as
initiator, Cisco negotiates new IPSec-SA and fluses old one while Linux
still uses it. Similar problem exists with Linksys (for example BEFSX41)
when Linux act as initiator. After 80% of a lifetime it negotiates new SA
but still uses old one, and such packets are ignored by BEFSX41.
To fix this i submitted a patch to racoon which is in their CVS - i was
told it will show up around their release 0.7. The patch allows people
to hardcode like in cisco a specific time. So this fixes the CISCO
problem without touching the kernel.
It may be useful but it does not fix _this_ problem, really. IPSec
initiator can negotiate new SA an any time so this will not work when
Linux is the responder. Negotiating new SA, for example 30s before hard
expiratin, means 30s without communication so this is also unacceptable
solution.
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.
So bug in racoon for sure but not good enough given the unreliability of
IKEv1. So in the last discussion Herbert and I had we talked about doing
something in the kernel since this was getting frustrating ...
Herbert has it on his TODO and i was going to get racoon part once he
has his patch.
Best regards,
Krzysztof Olędzki
