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

[Darrel G. <dgo...@tr...>]

VANHULLEBUS Yvan wrote:
> 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.

Yeah, I made sure that actually worked with the patch I sent.  Not that I
can actually get two initiators behind the same NAT to talk to the same
responder, but I could at least get them to negotiate SAs on different
encapsulation ports (data on the first initiator is disappearing in the
stack somewhere...).  If anyone has successfully run with two initiators
behind the same NAT talking to the same responder on the other side of
the NAT, (all on Linux) feel free to drop me an email - I'd love to talk :)

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

Can you point me to that patch please?  A pointer the the NetBSD code may
be helpful as well.

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

IIUC, the ipsec-tools code assumes that the ports in the sockaddrs for
*all* SAs refer to the isakmp port being used?  Even in the case where
there is no NAT traversal being used (always isakmp on 500)?  If that
is the case, I will see what I can do to doctor ports at dump time in
libipsec and setkey.  If the dump contains the same info on all platforms,
I think my problem should be solved since it apparently is working on
the some BSDs.

I should gain a better understanding of this once I check out the
implementations in the 3 kernels.

Thanks for the help so far.

> 
>>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.
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel


-- 

Darrel