Re: Recent IPSEC changes

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Sat, Oct 14, 2017 at 2:19 AM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> On Fri, Oct 13, 2017 at 9:28 PM, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>>
>> Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>>>On Fri, Oct 13, 2017 at 4:41 PM, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>>>
>>> Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>>>>On Fri, Oct 13, 2017 at 5:49 AM, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>>>>>
>>>>> I think something in the recent IPSEC changes is setting the ipsec_used
>>>>> flag to be always true.
>>>>
>>>>Not really on my machine. I guess it depends on environments.
>>>
>>> My environment is INET, INET6 & IPSEC in the kernel config, no modules.
>>>
>>> I have taken out any other protocols.
>>
>> My config is similar to GENERIC in in terms of network protocols.
>>
>>>
>>>>>There is a change that affects the ipsec_used flag:
>>>>>  http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199
>>>>
>>>> Ok.
>>>>
>>>>>It turns on the flag when a socket is enabled the IP_IPSEC_POLICY option.
>>>>>There was a bug that having such a socket didn't turn on the flag; the
>>>>>above commit fixed the bug.
>>>>
>>>> The flag is on at boot for me.
>>>
>>>Heh. ipsec_used is initially 0. And only key_update_used() changes the
>>>value. Could you add KASSERT(0) to at the beginning of key_update_used,
>>>rebuild a kernel and try to boot it? Then, we can know who changes it
>>>(or it's initialized with 1 unexpectedly).
>>
>> I added a printf in key_socksplist_add(), it gets called multiple times
>> at startup.
>>
>> Replacing it with KASSERT(0) suggests that the first one is from inetd.
>>
>>>>
>>>>>Do you have any processes having a socket with IP_IPSEC_POLICY on your
>>>>>machine in mind?
>>>>
>>>> No.
>>>
>>>Hmm.
>>
>> I wrote "no", but inetd(8) does seem to be creating some.
>>
>> I have not put a policy specifier into /etc/inetd.conf, just uncommented
>> some services.
>
> It seems that inetd tries to set a dummy policy ("in entrust; out entrust")
> to each socket of daemons even if there is no policy specifier in the config.
> The code looks purposefully setting the dummy policy but at least its
> behavior conflicts with the manual.
>
> Anyway there seems to be another bug that the ipsec_used flag isn't cleared;
> if I stopped inetd, the flag wasn't changed. I'll investigate the issues
> next week.

It seems that the behavior is expected; the ipsec_used flag never back to 0
intentionally to avoid a race condition once it's set to 1. We should
eventually fix the issue in the future though, what we should do now is to
stop inetd setting SPs meaninglessly, I think.

  ozaki-r