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

[VANHULLEBUS Y. <va...@fr...>]

On Tue, Nov 28, 2006 at 10:20:34PM -0600, Matthew Grooms wrote:
[....]
> If I understand the problem correctly, the ports are being compared 
> because there may be multiple peers behind a NAT device which share the 
> same address but will have different translated ports specified. If the 
> comparison is performed without the ports, you could potentially remove 
> SAs that are still valid and in use.

Exactly.


> 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.

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).

And my TODO list is as big as usual.....


> 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.

The fist stet to fix the issue would be to be able to determine, at
compile time, for which kind of kernel we'll have to run:

- No NATT support
- NAT-T support "a la Linux" (and I don't know exactly if this stack
  does something specific for ports)
- NAT-T "a la NetBSD" (with the actual way of sending ports
  information between kernel/userland).
- NAT-T with the future "clean" implementation (using PFKey extensions
  SADB_X_EXT_NAT_T_*).

Then we could at least have an appropriate CMPSADDR macro for each
situation, and a few other defines to help fixing all actual
configurations.


> 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 !


Yvan.