Unique IPsec security policies

[Jan Mikael Melen]

Hi,

On Tuesday 18 October 2005 11:22, VANHULLEBUS Yvan wrote:
> On Tue, Oct 18, 2005 at 10:50:24AM +0300, Jan Mikael Melen wrote:
> > What I'm trying to do is that:
> > 1. I create SP entry and let the kernel assign a request id for policy
> > (reqid in the add is 0). This policy is a tunnel mode policy and I don't
> > have the outer addresses set at this point. Only the inner addresses are
> > set so I'll get the SADB_AQUIRE message with the inner addresses.
>
> Not sure I understood what you are exactly doing, and *why* you want
> to do that...

For the why part my answer would be that it's because I don't necessarily know 
the end-points address before hand. The keying protocol will take care of 
resolving the address. This is just some experimental stuff I'm working with 
(ref. http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt).

> > 2. When my keying daemon get's the acquire from the kernel I run the key
> > exchange and then I send update to the SP with previously gotten reqid
> > and with outer addresses but it fails and kernel prints out:
> > "key_msg2sp: reqid=16384 range violation, updated by kernel."
> > This message comes from the sys/netkey/key.c:1488. It's obvious when I'm
> > adding a new SP entry that this check is done but when updating the SP
> > shouldn't it just check that the value given in update matches the one
> > assigned earlier?
>
> Perhaps you should just force manual reqids < IPSEC_MANUAL_REQID_MAX
> when creating your SP entries.

Always a possiblity but then I would have to know that wheter this value is 
already being used. So I would prefer that the kernel would assign the values 
for me, as it is obviously the one whom knows which reqids are already in 
use.

> In one hand, you're right: when updating SP entries, it can make sense
> to just ensure that the reqid is the same.
>
> In the other hand, as you used some automatic values while creating
> the SP entry (so, in fact, as you said "I let the kernel do that
> stuff"), it can be logic to not allow you to do "some non common
> things" after, even if you want to update it....

If this is the case it will make atleast my life a bit harder :-) I think that 
not allowing the SP to updated might cause also problems with mobike.

   Cheers,
	Jan