Minor IPSec bug + solution

Minor IPSec bug + solution

[Martin Bouzek]

Hi,

I was setting up an VPN via IPSec in kernel 2.6.x on IPv4 and found the
following bug. It is not possible to set up an IPComp/ESP tunnel with
IPComp set as mandatory. The following setup works fine for me:

spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec
           ipcomp/tunnel/192.168.1.100-192.168.2.212/use
           esp/tunnel/192.168.1.100-82.99.145.1/require;

(IPs are little bit confusing, because computers are behing NAT and the
pair SP is not shown, because it is not important)

But the following one is not working:

spdadd 192.168.1.0/24 192.168.2.0/24 any -P out ipsec
           ipcomp/tunnel/192.168.1.100-192.168.2.212/require
           esp/tunnel/192.168.1.100-82.99.145.1/require;



Of course it is possible to use the first setup, but I found that
problem was in "require" for IPComp only after quite a while of
debugging. :-) 

The later setup is not working, because all IP-IP packets are droped by 
__xfrm_policy_check function, because of error in xfrm_state_ok
function. For tunnels it returns 

tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family);

but it should return 

tmpl->optional || !xfrm_state_addr_cmp(tmpl, x, family);

The packet should pass policy check if either the policy is optional OR
the source address match. The code says that check pass if policy is
optional AND the address match, which is obviously wrong. IMHO it is the
reason, why I have to set this "use" for IPComp tunnel.

So the problem is in file "net/xfrm/xfrm_policy.c" in function
"xfrm_state_ok" - on line 868 in 2.6.8.1 kernel. It seems to me to
trivial change to create a patch.


I am not sure where I shall send this mail. As I said, it is a minnor
bug, and it is possible to set up things working even with it.
Nevertheless it would be nice to have it fixed. Can somebody help me,
where I shall send it?

Thanks.
- Martin Bouzek
- martin.bouzek@radas-atc.cz

Re: Minor IPSec bug + solution

[Herbert Xu]

Martin Bouzek <martin.bouzek@radas-atc.cz> wrote:
> 
> I was setting up an VPN via IPSec in kernel 2.6.x on IPv4 and found the
> following bug. It is not possible to set up an IPComp/ESP tunnel with
> IPComp set as mandatory. The following setup works fine for me:

You can never set IPComp as mandatory because ipcomp_output() will not
compress anything that is incompressible.

> function. For tunnels it returns 
> 
> tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family);

The check is correct as it is.  Internal states must never match any
required transform.
-- 
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: Minor IPSec bug + solution

[Martin Bouzek]

On Thu, 2004-09-16 at 23:19, Herbert Xu wrote:
> Martin Bouzek <martin.bouzek@radas-atc.cz> wrote:
> > 
> > I was setting up an VPN via IPSec in kernel 2.6.x on IPv4 and found the
> > following bug. It is not possible to set up an IPComp/ESP tunnel with
> > IPComp set as mandatory. The following setup works fine for me:
> 
> You can never set IPComp as mandatory because ipcomp_output() will not
> compress anything that is incompressible.

Sure. I receive IP-IP packets and they are checked with the same rules
as IPComp.

> 
> > function. For tunnels it returns 
> > 
> > tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family);
> 
> The check is correct as it is.  Internal states must never match any
> required transform.

Well, I am not expierienced with the networking kernel code,
nevertheless I still think the check is not correct. 

As I understand it, xfrm_state_addr_cmp returns 0 when tmpl->saddr is
0.0.0.0 (ipv4) or when tmpl->saddr.a4 == x->props.saddr.a4, that is why
there is the "!" before it. The "xfrm_state_ok" itself returns nonzero
if the tmpl matches the state. In such case the "xfrm_policy_ok" will 
return index to next state in sec_path. If no matching state is found
the "xfrm_policy_ok" returns -1 (if not tmpl->optional) and in such case
"__xfrm_policy_check" returns 0 and packet is rejected.

So the following happens for me when packet is received for mandatory
IPComp tunnel:

With my setup the pol->xfrm_nr is 1 and sp->len is 1 (in
"__xfrm_policy_check" context). "xfrm_policy_ok" is called and it calls
the "xfrm_state_ok". x->tunnel_users is 2 - so the 
"tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family)" is returned.
Because tmpl->optional is set to 0 (required IPComp),
xfrm_state_addr_cmp is not called at all and "xfrm_state_ok" returns 0.
Because sp->x[idx].xvec->props.mode is set, "xfrm_policy_ok" returns -1
(again tmpl->optional is 0). And so "__xfrm_policy_check" returns 0 and
packet is droped.

If you are still not convinced, please look at the xfrm_state_ok and the
part for non-tunnel. It clearly returns 1 when the tmpl and x matches.

Moreover with
"tmpl->optional || !xfrm_state_addr_cmp(tmpl, x, family);" in
"xfrm_state_ok" I can set up the mandatory IPComp without problems.
I am not sure there are not any side effects, but it seems ok to me.

Regards

Martin Bouzek
- martin.bouzek@radas-atc.cz

Re: Minor IPSec bug + solution

[Herbert Xu]

On Fri, Sep 17, 2004 at 11:26:13AM +0200, Martin Bouzek wrote:
>
> > > function. For tunnels it returns 
> > > 
> > > tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family);
> 
> Well, I am not expierienced with the networking kernel code,
> nevertheless I still think the check is not correct. 

If you change the && to ||, then an ESP tunnel SA marked as required
can be matched by a simple IPIP SA with the same addresses.
-- 
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: Minor IPSec bug + solution

[Martin Bouzek]

On Fri, 2004-09-17 at 12:27, Herbert Xu wrote:
> On Fri, Sep 17, 2004 at 11:26:13AM +0200, Martin Bouzek wrote:
> >
> > > > function. For tunnels it returns 
> > > > 
> > > > tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family);
> > 
> > Well, I am not expierienced with the networking kernel code,
> > nevertheless I still think the check is not correct. 
> 
> If you change the && to ||, then an ESP tunnel SA marked as required
> can be matched by a simple IPIP SA with the same addresses.

Ok. And would it be possible to check the protocols too (eg.
tmpl->id.proto == x->id.proto)? If it is realy not possible to make the
IPComp/required tunnel to work, it would be nice to mention it in for
example the setkey man page. It could save quite lot of time to some
people. (like me :-) ).

Re: Minor IPSec bug + solution

[Herbert Xu]

On Mon, Sep 20, 2004 at 09:49:49AM +0200, Martin Bouzek wrote:
> 
> Ok. And would it be possible to check the protocols too (eg.
> tmpl->id.proto == x->id.proto)? If it is realy not possible to make the

Obviously not, since IPCOMP != IPIP.

> IPComp/required tunnel to work, it would be nice to mention it in for
> example the setkey man page. It could save quite lot of time to some
> people. (like me :-) ).

IPComp is the main reason why we have optional SAs at all.  So
IPComp/required definitely does not make sense.

As to the documentation of this issue, feel free to write something up
and send it to either the kernel maintainers or one of the user-space
projects.

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