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]

Message-ID: <49780AA9.9050508@iki.fi>
Date:	Thu, 22 Jan 2009 07:56:57 +0200
From:	Timo Teräs <timo.teras@....fi>
To:	David Miller <davem@...emloft.net>
CC:	herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: [PATCH] af_key: parse and send SADB_X_EXT_NAT_T_OA extension

David Miller wrote:
> From: Herbert Xu <herbert@...dor.apana.org.au>
> Date: Thu, 22 Jan 2009 09:33:29 +1100
> 
>> Timo Teras <timo.teras@....fi> wrote:
>>> Parse and send SADB_X_EXT_NAT_T_OA along with other NAT-T extensions.
>>>
>>> Signed-off-by: Timo Teras <timo.teras@....fi>
>> Whatever application that you have in mind that's going to use
>> this should switch over to netlink.
> 
> Agreed, I won't be applying this patch.

It's for ipsec-tools. Currently the NAT OA in xfrm structs isn't
really used, but I need it later when implementing the NHRP/GRE/NAT
traversal I've sent couple mails about [1,2].

I do understand that netlink/xfrm is better, and I have it on
my long todo list. But rewriting 30-40 thousand lines of code
isn't going to happen that soon.

Is there any particular reason why setting NAT-OA info should/
must be done using netlink? Or is this just a way to try to
put more pressure for the change to happen?

I find it very confusing that NAT_T_[SD]PORT are supported, but
NAT_T_OA is not which is part of the same set of extensions
(required by some other kernels to make nat-t work in first
place; to fix up the checksums in transport mode SAs).

Even though if kernel currently does not use that information it
might confuse applications to get mismatching information back.

Currently if pfkey adds an NAT_T SA, and someone queries it
via xfrm you get back a random NAT OA. It's because
pfkey_msg2xfrm_state() kmallocs() the encap struct but does not
zero out or copy in the encap_oa field. IMHO, it's better to
just copy the information. But checking that again now, it looks
like we would need to memset() the encap_oa also when NAT_T_OA
is not present.

Also I find it a bit confusing which things are to be allowed
in pfkey and which not. We've had bigger fixes/changes to pfkey
in past like MIGRATE rewrite, etc.

- Timo

[1] http://marc.info/?l=linux-netdev&m=122232910618099&w=4
[2] http://marc.info/?l=linux-netdev&m=123252926623554&w=2

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