[PATCH] af_key: parse and send SADB_X_EXT_NAT_T_OA extension

[PATCH] af_key: parse and send SADB_X_EXT_NAT_T_OA extension

[Timo Teras]

Parse and send SADB_X_EXT_NAT_T_OA along with other NAT-T extensions.

Signed-off-by: Timo Teras <timo.teras@iki.fi>
---
 net/key/af_key.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index f8bd8df..f3e9998 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -824,6 +824,7 @@ static struct sk_buff *__pfkey_xfrm_state2msg(struct xfrm_state *x,
 		size += sizeof(struct sadb_x_nat_t_type);
 		size += sizeof(struct sadb_x_nat_t_port);
 		size += sizeof(struct sadb_x_nat_t_port);
+		size += sizeof(struct sadb_address) + sockaddr_size;
 	}
 
 	skb =  alloc_skb(size + 16, GFP_ATOMIC);
@@ -1031,6 +1032,20 @@ static struct sk_buff *__pfkey_xfrm_state2msg(struct xfrm_state *x,
 		n_port->sadb_x_nat_t_port_exttype = SADB_X_EXT_NAT_T_DPORT;
 		n_port->sadb_x_nat_t_port_port = natt->encap_dport;
 		n_port->sadb_x_nat_t_port_reserved = 0;
+
+		/* original address */
+		addr = (struct sadb_address*) skb_put(skb,
+					      sizeof(struct sadb_address)+sockaddr_size);
+		addr->sadb_address_len =
+			(sizeof(struct sadb_address)+sockaddr_size)/
+			sizeof(uint64_t);
+		addr->sadb_address_exttype = SADB_X_EXT_NAT_T_OA;
+		addr->sadb_address_proto = 0;
+		addr->sadb_address_reserved = 0;
+		addr->sadb_address_prefixlen =
+			pfkey_sockaddr_fill(&natt->encap_oa, 0,
+					    (struct sockaddr *) (addr + 1),
+					    x->props.family);
 	}
 
 	/* security context */
@@ -1285,6 +1300,11 @@ static struct xfrm_state * pfkey_msg2xfrm_state(struct net *net,
 				ext_hdrs[SADB_X_EXT_NAT_T_DPORT-1];
 			natt->encap_dport = n_port->sadb_x_nat_t_port_port;
 		}
+		if (ext_hdrs[SADB_X_EXT_NAT_T_OA-1]) {
+			struct sadb_address* n_oa =
+				ext_hdrs[SADB_X_EXT_NAT_T_OA-1];
+			pfkey_sadb_addr2xfrm_addr(n_oa, &natt->encap_oa);
+		}
 	}
 
 	err = xfrm_init_state(x);
-- 
1.5.6.3

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

[Herbert Xu]

Timo Teras <timo.teras@iki.fi> wrote:
> Parse and send SADB_X_EXT_NAT_T_OA along with other NAT-T extensions.
> 
> Signed-off-by: Timo Teras <timo.teras@iki.fi>

Whatever application that you have in mind that's going to use
this should switch over to netlink.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[David Miller]

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Jan 2009 09:33:29 +1100

> Timo Teras <timo.teras@iki.fi> wrote:
> > Parse and send SADB_X_EXT_NAT_T_OA along with other NAT-T extensions.
> > 
> > Signed-off-by: Timo Teras <timo.teras@iki.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.

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

[Timo Teräs]

David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu, 22 Jan 2009 09:33:29 +1100
> 
>> Timo Teras <timo.teras@iki.fi> wrote:
>>> Parse and send SADB_X_EXT_NAT_T_OA along with other NAT-T extensions.
>>>
>>> Signed-off-by: Timo Teras <timo.teras@iki.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

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

[David Miller]

From: Timo Teräs <timo.teras@iki.fi>
Date: Thu, 22 Jan 2009 07:56:57 +0200

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

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

That was a mistake on my part, I shouldn't have allowed the
pfkey side of the changes there.

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

[Timo Teräs]

David Miller wrote:
> From: Timo Teräs <timo.teras@iki.fi>
> Date: Thu, 22 Jan 2009 07:56:57 +0200
> 
>> 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.

Now you give impression that it's supported but you just drop
it silently.

>> 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.
> 
> That was a mistake on my part, I shouldn't have allowed the
> pfkey side of the changes there.

I see.

- Timo

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

[David Miller]

From: Timo Teräs <timo.teras@iki.fi>
Date: Thu, 22 Jan 2009 08:14:13 +0200

> David Miller wrote:
> > From: Timo Teräs <timo.teras@iki.fi>
> > Date: Thu, 22 Jan 2009 07:56:57 +0200
> > 
> >> 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.

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

[Herbert Xu]

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.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Timo Teräs]

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

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

[Herbert Xu]

On Thu, Jan 22, 2009 at 08:39:35AM +0200, Timo Teräs wrote:
> 
> 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.

If they've had it since 2007 and only just realised that it
doesn't work then it sounds like it doesn't really matter anyway.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Timo Teräs]

Herbert Xu wrote:
> On Thu, Jan 22, 2009 at 08:39:35AM +0200, Timo Teräs wrote:
>> 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.
> 
> If they've had it since 2007 and only just realised that it
> doesn't work then it sounds like it doesn't really matter anyway.

That ipsec-tools feature works on *BSD. Works on Linux too
as kernel does not (yet) use that for anything except reporting
it back. Other OSes might use it already to e.g. fix-up the
packet checksums in transport mode SAs; I believe Linux just
recalculates the checksum.

The future patch I have in my mind I've been talking about,
does make use of NAT-OA. So that's why I noticed it only
just now. Btw, could someone comment on the idea of passing
NAT-OA to neighbour cache and make xfrm use it when choosing
which xfrm state to use?

- Timo

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

[Herbert Xu]

On Thu, Jan 22, 2009 at 08:54:02AM +0200, Timo Teräs wrote:
>
> That ipsec-tools feature works on *BSD. Works on Linux too
> as kernel does not (yet) use that for anything except reporting
> it back. Other OSes might use it already to e.g. fix-up the
> packet checksums in transport mode SAs; I believe Linux just
> recalculates the checksum.

Right, the reason nobody has noticed is because transport mode
NAT-T is inherently insecure (and difficult to deploy if you have
multiple peers behind one gateway) so nobody uses it in the field.

So I think there is even less reason to do this for af_key.

If you don't have the time to convert racoon, couldn't you look
at one of the *swans and use that as the basis of your work?

> The future patch I have in my mind I've been talking about,
> does make use of NAT-OA. So that's why I noticed it only
> just now. Btw, could someone comment on the idea of passing
> NAT-OA to neighbour cache and make xfrm use it when choosing
> which xfrm state to use?

I'm concerned about using NAT-OA for anything policy related
because it is impossible to authenticate or verify.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Timo Teräs]

Herbert Xu wrote:
> On Thu, Jan 22, 2009 at 08:54:02AM +0200, Timo Teräs wrote:
>> That ipsec-tools feature works on *BSD. Works on Linux too
>> as kernel does not (yet) use that for anything except reporting
>> it back. Other OSes might use it already to e.g. fix-up the
>> packet checksums in transport mode SAs; I believe Linux just
>> recalculates the checksum.
> 
> Right, the reason nobody has noticed is because transport mode
> NAT-T is inherently insecure (and difficult to deploy if you have
> multiple peers behind one gateway) so nobody uses it in the field.

Yes, if you have TCP or UDP as upper protocol. DMVPN has GRE as
upper protocol, so most of the problems are handled at GRE
layer with NHRP, dynamic routing protocols, etc.

> So I think there is even less reason to do this for af_key.
>
> If you don't have the time to convert racoon, couldn't you look
> at one of the *swans and use that as the basis of your work?

I did look into them in the beginning. They have a bit different
way of looking into ipsec connections than dmvpn. So I thought
ipsec-tools would be easiest to modify. I did not tie opennhrp
to ipsec-tools specifically (ipsec glue is a script) so it's
changeable.

Basically NHRP works as private IP to public IP mapping
protocol. And wants to be in charge of establishing the IPsec
SAs dynamically. Basically the option of having "unnamed"
connections distinguished by IP:s was the criteria why I went
with ipsec-tools.

The (quickish) look on *swans would imply that for each
dynamic connection I would need to hand create a new connection
entity. Could be scriptable, but then I would somehow
need to make up connection names based on the IPs and always
inject full config by the admin tool.

>> The future patch I have in my mind I've been talking about,
>> does make use of NAT-OA. So that's why I noticed it only
>> just now. Btw, could someone comment on the idea of passing
>> NAT-OA to neighbour cache and make xfrm use it when choosing
>> which xfrm state to use?
> 
> I'm concerned about using NAT-OA for anything policy related
> because it is impossible to authenticate or verify.

I'm not sure if you are familiar how DMVPN works (= IPsec
transport mode + NBMA GRE + NHRP), but I can explain it more
detailed if you want to hear more about it.

In any case the NAT-OA would be used as hint to choose which
cached xfrm state the global xfrm policy "encrypt all GRE
traffic" would return when kernel sends packets out from
the GRE tunnel interface.

Basically, OpenNHRP would:
1. Make ipsec-tools (or some other keying manager) create
   new SAs for the dynamic IPsec connection. The KM would
   inject the NAT-OA for the negotiated xfrm state.

2. OpenNHRP after ensuring the IPsec SA is there, would
   inject GRE interface neighbor entry saying:
      "packets to this IP in GRE subnet, go to this public
       IP. do use this NAT-OA as hint when choosing xfrm state."
   This would be sent via Netlink.

This all works already, if all DMVPN nodes have different
public IP (xfrm chooses correct SA to use based on public IP).

But if there's multiple nodes behind same public IP the xfrm
has two (or more) choices for which xfrm state to use. The
NAT-OA can be used as distinguishing factor. So when ip_gre
sends out packet, the xfrm can choose the correct xfrm state.

Would that sound acceptable?

- Timo

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

[Herbert Xu]

On Thu, Jan 22, 2009 at 10:31:32AM +0200, Timo Teräs wrote:
> 
> The (quickish) look on *swans would imply that for each
> dynamic connection I would need to hand create a new connection
> entity. Could be scriptable, but then I would somehow
> need to make up connection names based on the IPs and always
> inject full config by the admin tool.

They have templates for inbound connections on servers and also
outbound connections which were used for Opportunistic Encryption.
So you can adapt these to generate connections on demand.

Also creating/destroying connections at run-time is really easy
without generating a full config at all by using ipsec whack.
 
> But if there's multiple nodes behind same public IP the xfrm
> has two (or more) choices for which xfrm state to use. The
> NAT-OA can be used as distinguishing factor. So when ip_gre
> sends out packet, the xfrm can choose the correct xfrm state.

That's precisely what you don't want to do unless you trust all
your peers equally.  The reason is that NAT-OA is not authenticated,
i.e., I can choose any address to send over as NAT-OA and there
is nothing you can do to stop me.

It was only ever intended to be used for fixing up the checksum
so you can't safely use it for making policy/routing decisions.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Timo Teräs]

Herbert Xu wrote:
> On Thu, Jan 22, 2009 at 10:31:32AM +0200, Timo Teräs wrote:
>> The (quickish) look on *swans would imply that for each
>> dynamic connection I would need to hand create a new connection
>> entity. Could be scriptable, but then I would somehow
>> need to make up connection names based on the IPs and always
>> inject full config by the admin tool.
> 
> They have templates for inbound connections on servers and also
> outbound connections which were used for Opportunistic Encryption.
> So you can adapt these to generate connections on demand.
> 
> Also creating/destroying connections at run-time is really easy
> without generating a full config at all by using ipsec whack.

I think I looked into openswan int he beginning in detail
and it had various problems. I think there wasn't netlink
stuff there either when I looked into it.

Looking at strongswan now, it does look a lot more usable.

But I don't like how IKEv2 is complitely separate from
IKEv1. Different daemons, different whack interface, etc.

There was some other things too why I decided to go for
ipsec-tools in the beginning. But it doesn't really matter
as long as I get IPsec.

So for the time being, I can have my patched kernel, fix
some of the swans and switch to it, or even write my own
IPsec keying manager if it comes to that. IPsec KM is not
that relevant for me, as long as it works.

>> But if there's multiple nodes behind same public IP the xfrm
>> has two (or more) choices for which xfrm state to use. The
>> NAT-OA can be used as distinguishing factor. So when ip_gre
>> sends out packet, the xfrm can choose the correct xfrm state.
> 
> That's precisely what you don't want to do unless you trust all
> your peers equally.  The reason is that NAT-OA is not authenticated,
> i.e., I can choose any address to send over as NAT-OA and there
> is nothing you can do to stop me.
> 
> It was only ever intended to be used for fixing up the checksum
> so you can't safely use it for making policy/routing decisions.

In DMVPN/GRE case, the NAT-OA from IPsec would not be used
unless the NAT-OA is set on neighbour cache. This would not
happen unless NHRP can authenticate it. In DMVPN case you need
a valid certificate to give the ranom NAT-OA in any case. So
if you lie about your NAT-OA I can just revoke you.

Or do you have, other recommendations how to distinguish peers
behind same public IP than NAT-OA? Maybe we add the certificate
subject to xfrm state and neighbour cache. And use that?
That would certainly be authenticated. Would that be a better
approach? Or in general, allow a random token to be associated
with an xfrm state, so that we can connect neighbor cache in
gre interface to that specific state.

- Timo

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

[Herbert Xu]

On Thu, Jan 22, 2009 at 11:24:41AM +0200, Timo Teräs wrote:
>
> In DMVPN/GRE case, the NAT-OA from IPsec would not be used
> unless the NAT-OA is set on neighbour cache. This would not
> happen unless NHRP can authenticate it. In DMVPN case you need
> a valid certificate to give the ranom NAT-OA in any case. So
> if you lie about your NAT-OA I can just revoke you.

I don't see how NHRP authentication would help if the attacker
takes over someone else's address and causes packets for the
third party to go to it.

As to revoking the attacker's access, that's like saying "I'll
run an open telnet port but if you try to sniff my psasword I'll
revoke your access" :)

> Or do you have, other recommendations how to distinguish peers
> behind same public IP than NAT-OA? Maybe we add the certificate
> subject to xfrm state and neighbour cache. And use that?

Yes I think that is a much better solution for this.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Timo Teräs]

[Offtopic: looking latest openswan code it does look a lot
better too. It looked quite different when checked it out
some years ago.]

Herbert Xu wrote:
> On Thu, Jan 22, 2009 at 11:24:41AM +0200, Timo Teräs wrote:
>> In DMVPN/GRE case, the NAT-OA from IPsec would not be used
>> unless the NAT-OA is set on neighbour cache. This would not
>> happen unless NHRP can authenticate it. In DMVPN case you need
>> a valid certificate to give the ranom NAT-OA in any case. So
>> if you lie about your NAT-OA I can just revoke you.
> 
> I don't see how NHRP authentication would help if the attacker
> takes over someone else's address and causes packets for the
> third party to go to it.
> 
> As to revoking the attacker's access, that's like saying "I'll
> run an open telnet port but if you try to sniff my psasword I'll
> revoke your access" :)

Sorry, I misunderstood the point in the beginning. Yes, if
someone else has valid cert, and has possession of the same
public IP and knows the private-ip I am using, and makes
SA with that info, he might be able to steal my traffic.

Good point.

And thinking more about it, NAT-OA might be even same for
multiple separate clients (if they are double natted).

>> Or do you have, other recommendations how to distinguish peers
>> behind same public IP than NAT-OA? Maybe we add the certificate
>> subject to xfrm state and neighbour cache. And use that?
> 
> Yes I think that is a much better solution for this.

Still, connecting it with variable amount length of data
(like cert subject) might be cumbersome (extending the
APIs, structs, especially neighbor cache).

Then again it might not be easy to come up with identifying
information if we limit it to 32-bits or 64-bits or so.

Ok, I'll think about this more. Ideas would be appreciated
here.

- Timo

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

[Herbert Xu]

On Thu, Jan 22, 2009 at 12:00:22PM +0200, Timo Teräs wrote:
>
> Still, connecting it with variable amount length of data
> (like cert subject) might be cumbersome (extending the
> APIs, structs, especially neighbor cache).

Well you can have a translation table in user-space that turns
the cert into something more digestable, like a u32 or even an
IP address.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Timo Teräs]

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

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

[Herbert Xu]

On Fri, Jan 23, 2009 at 08:18:33AM +0200, Timo Teräs wrote:
.
> If you still consider that the copying of that extension is
> inappropriate then maybe memset():ing the encap_oa to zero
> would be acceptable?

Yes I think doing the memset/zero assignment is not only reasonable
but a requirement since it has security implications.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Herbert Xu]

On Thu, Jan 22, 2009 at 08:14:13AM +0200, Timo Teräs 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.
> 
> Now you give impression that it's supported but you just drop
> it silently.

Timo I think we need to draw a line somewhere, otherwise we're
just providing life support to an interface that should die.

IMO if there is a bug in pfkey that breaks a major existing
app (i.e., ipsec-tools/racoon), then we should fix that.

But if it's something that the existing apps don't care about
then no we need to just stop extending the interface.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt