Hi!

ipsec.h defines IPSEC_MANUAL_REQID_MAX as 0x3fff (16383) and only
af_key.c, the PF_KEY implementation uses that. When configuring a
policy with a higher reqid, the kernel drops the manually given reqid
and generates a new one.
Contrarily, XFRM allows one to create policies with higher reqid-s and
this is some inconsistency i guess.
I could not find any note on generating reqids in the pf_key rfc. From
where is that come from? Is it really necessary?

As XFRM allows, is it safe to increase this value or even bypass the
checking of the reqid beeing higher than that?

Thanks,
Zsolt Szalai
--

[ message continues ]

Please stop using the af_key interface.  The part dealing with
policies (which is the only place where reqids are generated) is
just as unportable as xfrm.

In any case changing an interface should be avoided unless there
is a really good reason.  In this case I don't see any good reasons
since you can instead switch to xfrm.

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

[ message continues ]

Thanks,

I would like to switch, but it would require much time to port our
code, that we don't have now.
I hope af_key wont be deleted from the kernel tree in the near future,
and then we will have time to migrate.

BR,
Szalai Zsolt



--

[ message continues ]

No it won't be deleted, certainly not for a long time.

But we do encourage people to move away from it.

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

[ message continues ]