On Thu, 15 Dec 2005, 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. 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.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?
Not really. It is very, _very_ precise.
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'm not sure if you have ever read any RFC carefully. Let's clarify this:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described below.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances
when the particular behavior is acceptable or even useful, but the
full implications should be understood and the case carefully
weighed before implementing any behavior described with this
label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because the vendor feels
that it enhances the product while another vendor may omit the
same item. An implementation which does not include a particular
option MUST be prepared to interoperate with another
implementation which does include the option, though perhaps with
reduced functionality. In the same vein an implementation which
does include a particular option MUST be prepared to interoperate
with another implementation which does not include the option
(except, of course, for the feature the option provides.)
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.
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?
No, again, it does not help. I explained it in my previous mail.
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.
Really? I don't think so.
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?
Best regards,
Krzysztof Olędzki
