On Fri, 2008-18-01 at 08:45 +0200, Timo Teräs wrote:
> I'll run my patched kernel
> and try to get ipsec-tools fixed to use netlink...
> eventually.
If you are going to mod racoon to use netlink then thats without a doubt
the _best_ solution (linux distros dilema i had essentially disappears).
Herbert Xu wrote:
> On Thu, Jan 17, 2008 at 03:31:14PM +0200, Timo Teräs wrote:
>> I guess the idea was that application should know about the SAs it
>> created. Though a SA dump needs to be done if you want to check
>> for existing entries (created by other processes, or if you are
>> recovering f
On Thu, Jan 17, 2008 at 03:31:14PM +0200, Timo Teräs wrote:
>
> I guess the idea was that application should know about the SAs it
> created. Though a SA dump needs to be done if you want to check
> for existing entries (created by other processes, or if you are
> recovering from a crash).
That's
Herbert Xu wrote:
> On Thu, Jan 17, 2008 at 07:42:30AM -0500, jamal wrote:
>> Looking at the pfkey RFC one more time, heres a funny quote:
>> "
>> The dump message is used for debugging
>> purposes only and is not intended for production use.
>> "
>
> In fact it goes much further:
>
>Support
On Thu, 2008-17-01 at 23:50 +1100, Herbert Xu wrote:
> In fact it goes much further:
>
>Support for the dump message MAY be discontinued in future versions
>of PF_KEY. Key management applications MUST NOT depend on this
>message for basic operation.
No doubt PF_KEY being an RFC has
On Thu, Jan 17, 2008 at 07:42:30AM -0500, jamal wrote:
>
> Looking at the pfkey RFC one more time, heres a funny quote:
> "
> The dump message is used for debugging
> purposes only and is not intended for production use.
> "
In fact it goes much further:
Support for the dump message MAY be di
On Thu, 2008-17-01 at 07:54 +0200, Timo Teräs wrote:
> You listen for the events. It is guaranteed that if the dumping code
> does return the entry to be deleted, the deletion notification will
> occur after that dump entry.
Ok, sounds reasonable - as long as there is a known order for
occurances
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 13:00:09 +0200
>
>> IMHO, it's a lot better then losing >50% of entries and the end
>> of sequence message on big dumps. SPD and SADB are not that
>> volatile; in most of the cases the dump would be as good as an
>
On Thu, 2008-17-01 at 22:11 +1100, Herbert Xu wrote:
> Sure racoon uses pfkey but the question is does it use pfkey dumping?
>
it does when trying to purge phase 2 SAs...
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTE
Herbert Xu wrote:
> On Thu, Jan 17, 2008 at 07:54:32AM +0200, Timo Teräs wrote:
>>> Racoon doesn't use pfkey dumping as far as I know.
>> ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to
>> make it use netlink; it relies heavily all around the code to pfkey
>> structs. It also
On Thu, Jan 17, 2008 at 07:54:32AM +0200, Timo Teräs wrote:
>
> > Racoon doesn't use pfkey dumping as far as I know.
>
> ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to
> make it use netlink; it relies heavily all around the code to pfkey
> structs. It also runs on BSD so we
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 13:00:09 +0200
> IMHO, it's a lot better then losing >50% of entries and the end
> of sequence message on big dumps. SPD and SADB are not that
> volatile; in most of the cases the dump would be as good as an
> atomic one.
I humbly disagr
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 12:01:17 +0200
>
>> David Miller wrote:
>>> This is an inherent aspect of AF_KEY (and what it was
>>> derived from, BSD routing sockets).
>> Yes, this is the way BSD does it.
>>
>>> It has to provide dumps atomic
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 12:01:17 +0200
> David Miller wrote:
> > This is an inherent aspect of AF_KEY (and what it was
> > derived from, BSD routing sockets).
>
> Yes, this is the way BSD does it.
>
> > It has to provide dumps atomically, and if there is no
>
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 11:38:13 +0200
>
>> The af_key issue is that in big dumps you get only first X
>> entries. The rest of the entries are dropped because the
>> socket receive buffer goes full. You get data corruption:
>> missing ent
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 11:38:13 +0200
> The af_key issue is that in big dumps you get only first X
> entries. The rest of the entries are dropped because the
> socket receive buffer goes full. You get data corruption:
> missing entries.
This is an inherent asp
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 11:20:42 +0200
>
>> Where as the pfkey bug fix is non-intrusive and helps all
>> legacy applications still using af_key by _fixing a bug in
>> kernel_.
>
> It's not a bug. You're fixing a speed issue, not a crash
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 11:20:42 +0200
> Where as the pfkey bug fix is non-intrusive and helps all
> legacy applications still using af_key by _fixing a bug in
> kernel_.
It's not a bug. You're fixing a speed issue, not a crash
or a case where AF_KEY is provid
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 10:11:17 +0200
>
>> I thought my patch would qualify as "life support" bug fix.
>> Currently racoon fails to work if there are too many SPDs or SAs
>> because the kernel cannot handle the dump request properly. And
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 10:11:17 +0200
> I thought my patch would qualify as "life support" bug fix.
> Currently racoon fails to work if there are too many SPDs or SAs
> because the kernel cannot handle the dump request properly. And this
> is what my patch fixe
David Miller wrote:
> Doing anything other than "life support" bug fixes for AF_KEY is
> inappropriate.
Yes. I thought my patch would qualify as "life support" bug fix.
Currently racoon fails to work if there are too many SPDs or SAs
because the kernel cannot handle the dump request properly. And
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 09:38:15 +0200
> David Miller wrote:
> > From: Timo_Teräs <[EMAIL PROTECTED]>
> > Date: Thu, 17 Jan 2008 08:27:14 +0200
> >
> >> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
> >> So I'd say pfkey might be a bi
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 08:27:14 +0200
>
>> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
>> So I'd say pfkey might be a bit more portable. Though netlink is definitely
>> more robust and extensive.
>
> The RFC
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 08:27:14 +0200
> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
> So I'd say pfkey might be a bit more portable. Though netlink is definitely
> more robust and extensive.
The RFCs say absolutely nothing about po
Herbert Xu wrote:
> jamal <[EMAIL PROTECTED]> wrote:
>> There are two issues that are inter-mingled in there. The most important
>> is pf_key not being robust on dump. The other being the accurracy of
>
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over
jamal wrote:
> On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
>> > No. I'm not creating second copies of the SADB/SPD entries. The entries
>> > are just added to one more list.
>
> Ah, sorry - yes, that sounds reasonable.
> So what happens if i delete an entry; does it get removed from the l
On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
>
> I wouldnt disagree except some apps like racoon which depend on pfkey
> are unfortunately beyond repair. Timo has a pretty good handle on the
Racoon doesn't use pfkey dumping as far as I know.
Cheers,
--
Visit Openswan at http://www.open
On Thu, 2008-17-01 at 09:58 +1100, Herbert Xu wrote:
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over xfrm_user since neither is portable. So we
> should discourage people from using af_key wherever possible.
I wouldnt disagree except some apps like
On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
[..]
> Creating a separate af_key patch would not be a big problem. I was
> just hoping avoiding it as the xfrm_state / xfrm_policy changes
> modify the API and requires changing af_key also.
The way dumping is done by xfrm_user is consistent ac
jamal <[EMAIL PROTECTED]> wrote:
>
> There are two issues that are inter-mingled in there. The most important
> is pf_key not being robust on dump. The other being the accurracy of
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over xfrm_user since neither i
jamal wrote:
> On Sun, 2008-13-01 at 14:26 +0200, Timo Teräs wrote:
>> I tried to address all these problems, and added the xfrm_policy
>> and xfrm_state structure to a new linked list that is used solely
>> for dumping. This way the dumps can be done in O(n) and have an
>> iterator point to them.
Timo,
Thanks for the effort you are putting on this.
I would just speak to the concepts instead of the code - hopefully that
would simulate a discussion (and shorten my email)
On Sun, 2008-13-01 at 14:26 +0200, Timo Teräs wrote:
> Hi all,
>
> The problem with IPsec SP/SA dumping is that they do
Hi all,
The problem with IPsec SP/SA dumping is that they don't work well with large
SPD/SADB:s. In netlink the dumping code is O(n^2) and can miss some
entries/dump duplicates if the DB is changed between the recv() calls to read
the dump entries. This is due to the entry index counting done i
33 matches
Mail list logo
