netdev - Re: [PATCH] af_key: parse and send SADB_X_EXT_NAT_T

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 Jan 2009 08:39:35 +0200
From:	Timo Teräs <timo.teras@....fi>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] af_key: parse and send SADB_X_EXT_NAT_T_OA extension

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html