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

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

David Miller wrote:
> From: Timo Teräs <timo.teras@iki.fi>
>> David Miller wrote:
>>> From: Timo Teräs <timo.teras@iki.fi>
>>>> 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?
>>> Because it isn't deprecated if we keep adding features to it.
>> 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.

Going back to the original patch. Knowing that it's bad idea to
use it for my other purposes, I have no strong feelings to push
for this.

Then again, since as discussed earlier, encap_oa is not used for
anything (and never will be). It's just stored and given back if
requested, so this patch adds nothing new; it just stores and
gives the attribute back if the SA is dumped.

Do note that currently pfkey_msg2xfrm_state() currently allocates
xfrm_encap_tmpl with kmalloc() and leaves encap_oa uninitialized,
thus all SAs with NAT-T created via pfkey currently show random
crap in encap_oa when dumped via "ip xfrm state".

Also the patch I sent first should memset() the encap_oa if
SADB_X_EXT_NAT_T_OA is not present.

If you still consider that the copying of that extension is
inappropriate then maybe memset():ing the encap_oa to zero
would be acceptable?

Cheers,
  Timo