Re: [Ipsec-tools-devel] SAs not gettin g purged when peer goes down

[Matthew G. <mg...@sh...>]

VANHULLEBUS Yvan wrote:

Thanks. This is very educational so I hope you don't mind me picking
your brain here with a few more questions.

> On Tue, Nov 28, 2006 at 10:20:34PM -0600, Matthew Grooms wrote:
> 
>> My guess is that there is a subtle platform difference when dumping sad 
>> entries where BSD returns the NATT ports as part of the sadb_address 
>> extension and Linux returns 0 values. This would explain why the 
>> CMPSADDR would cause problems on Linux but not on BSD.
> 
> The difference is that NetBSD and FreeBSD (with a patch I maintain)
> have some code on kernel size to handle the ports issue.
> 
> However, some people raised issues with the way the ports are
> exchanged between kernel and userland, which seems to generate
> problems for Linux stack.
> 

Were the issues raised related to the reliance of NATT port values being
returned in the sadb_address or is the problem more involved?

> I know that, have to fix it as soon as possible, but it is not a small
> issue (I'll have to fix all pfkey commands on userland, have a
> complete check of all cmp*addr* uses, will have to do quite the same
> think on all three IPSec stacks, then we'll have the compatibility
> problem with actuel NetBSD kernels (FreeBSD is not so much a problem,
> as the feature is actually a separate patch, not provided with the
> official releases).
> 

If you don't mind me asking, how does this cause a consistency problem
when interfacing with the NetBSD kernel? Can ipsec-tools not rely on a
set of NATT port extensions being returned as part of an SA for some
platforms that also support NATT?

>> For what its worth, I think your patch contains the correct approach. 
> 
> I had a very quick look at it. It will fix the Linux issue, but will
> break again some configurations on Net/FreeBSD.
> 

I should look at that patch again after its applied.

>> I'm just wondering if this couldn't be solved at the libipsec level so 
>> we don't have to include multiple special cases throughout racoon. I'm 
>> sure Manu and Yvan will chime in as they have quite a bit more NATT 
>> knowhow than I do.
> 
> We will always need a CMPSADDR macro, because in racoon, if we support
> multiple peers behind the same IP, the ports info is stored in the
> addess structs.
> 
> But at pfkey level, some cleanup is needed !
> 

In my head, the suggestion was that the next lower pfkey API call could
be possibly modified to return the data in a consistent fashion so that
special casing the use of CMPSADDR could be avoided. I apparently don't
understand the problem completely ( or the scope of libipsec ) :)

Thanks again,

-Matthew