jamal wrote:
> I can see where the %8 >= 3 comes from.
> [per socket creation with calls xfrm_gen_index(XFRM_POLICY_MAX+dir)
> and the kernel does things in increments of 8]
>
> I didnt quiet understand that check in racoon: Why this guess work? if
> per-socket policies need to be identified, why dont they get explicitly
> marked as per-socket somehow? I am actually curious why that check is
> needed. Sorry have never stared at the racoon code. Do other IKE/ISAKMP
> daemons depend on it?
Not sure why they're not marked as per-socket. Probably because
sadb_x_policy_id is a KAME extension and KAME pf_key doesn't dump
these policies with SADB_X_SPDDUMP. Racoon needs to skip them
to avoid adding them to its internal SPD, they could conflict
with global policies.
>>So how could we handle this?
>>
> We can disallow the explicit setting of any index which passes test
> (index % 8 >= 3) - but it does seem to me the whole concept of reserving
> those indices for per-socket policies is a bit of a hack and may need a
> rethinking. Maybe we need to maintain a mark in the kernel for
> per-socket polices and do the same as BSD?
Disallowing this special case seems a bit inconsistent to me. We can
deduce which are per-socket from the list they are contained in. We
don't notify on per-socket policy change, perhaps we should also skip
them when dumping in pf_key.
Regards
Patrick
|