Re: Minor IPSec bug + solution

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