|
From: Matthew G. <mg...@sh...> - 2006-11-29 16:56:37
|
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 |