On Thu, Dec 15, 2005 at 02:55:13PM -0800, David S. Miller wrote:
[]
> I think the kernel is definitely within it's rights to interpret
> section 4.3 of RFC2408 the way that it does.
We can say that, but then, we have to accept that this interpretation
can lead to interoperability problems !
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 17:04:56 -0800 (PST)
> I'm trying to see if there is a clever way to make existing SA
> entries get invalidated upon insertion of a new SA which "shadows"
> them.
To illustrate why this is a "hard problem", I've drawn an
extensive
From: Krzysztof Oledzki <[EMAIL PROTECTED]>
Date: Fri, 16 Dec 2005 01:04:47 +0100 (CET)
> It looks like XFRM caches that information, so kernel does need to search
> whole SADB for each packet and this is the reason why usage of old SA is
> observed. This is my theory only, someone who wrote XFR
On Thu, 15 Dec 2005, David S. Miller wrote:
1) I don't understand how a routing cache flush "fixes" the problem.
The routing cache flush only marks non-IPSEC cached routes as
invalid, not IPSEC ones.
New IPsec SA is used for communication between new src/dst (previously
unseend) pair ev
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 15:56:52 -0500
> Refer to Herberts solution and see if that "solves the problem".
I think the kernel is definitely within it's rights to interpret
section 4.3 of RFC2408 the way that it does.
And I bet that whoever wrote those paragraphs use
On Thu, 2005-15-12 at 21:28 +0100, Krzysztof Oledzki wrote:
>
> On Thu, 15 Dec 2005, jamal wrote:
> > 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
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
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
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
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
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
delet
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.
>
On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
> On Thu, 2005-15-12 at 05:57 +0100, Krzysztof Oledzki wrote:
> > Addedd CC: to the [EMAIL PROTECTED] mailing list.
> >
>
> And I added Shoichi Sakane to the CC. He is responsible for bringing
> "use new SA" feature to BSD to begin with and i
13 matches
Mail list logo
