Re: [PATCH] af_key: parse and send SADB_X_EXT_NAT_T_OA extension

["Timo Teräs" <timo.teras@iki.fi>]

Herbert Xu wrote:
> On Wed, Jan 21, 2009 at 10:21:12PM -0800, David Miller wrote:
>>> I would not consider this a new feature. It just makes pfkey
>>> act consistently. If you don't want it supported, it'd make
>>> more sense to not #define SADB_X_EXT_NAT_T_OA and drop all of
>>> the verification code already present than to silently
>>> ignore it. Make kernel return an error if some tried using it.
>> Fair enough, sounds like a reasonable argument.
>>
>> Herbert what do you think?  The proposal is that we just reflect the
>> value we get, rather than acting upon it.
> 
> The only references to SADB_X_EXT_NAT_T_OA in our kernel currently
> are for the user => kernel direction.  This patch does kernel =>
> user so I don't see a connection.
>
> In any case I just grabbed the latest ipsec-tools source and it
> doesn't use this stuff at all so IMO this is a new feature.

There hasn't been new release for ipsec-tools for a while.
It's been in ipsec-tools CVS since 2007-12-12. And I know many
who are using the CVS code in production.

Again, my argument is that the code does not modify any headers,
add/modify structures, extensions or messages. So in kernel
point of view it's not a new feature. From userland point of
view it makes kernel act consistently as now the kernel claims
to support something (by having the defines, checking it,
validating it) but just ignores it silently.

Now the split is artificial: the pfkey code knows about nat-oa
but silently ignores it instead of passing it to xfrm. It made
more sense if it was properly or not knowing at all about it.

- Timo