Discussion:
Recent IPSEC changes
(too old to reply)
Robert Swindells
2017-10-12 20:49:29 UTC
Permalink
I think something in the recent IPSEC changes is setting the ipsec_used
flag to be always true.

This means that non-IPSEC traffic is sent through the IPSEC code.

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ryota Ozaki
2017-10-13 02:01:18 UTC
Permalink
Post by Robert Swindells
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.

There is a change that affects the ipsec_used flag:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199

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.

Do you have any processes having a socket with IP_IPSEC_POLICY on your
machine in mind?

Thanks,
ozaki-r

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Robert Swindells
2017-10-13 07:41:08 UTC
Permalink
Post by Ryota Ozaki
Post by Robert Swindells
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.
Post by Ryota Ozaki
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199
Ok.
Post by Ryota Ozaki
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.
Post by Ryota Ozaki
Do you have any processes having a socket with IP_IPSEC_POLICY on your
machine in mind?
No.

Robert Swindells


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ryota Ozaki
2017-10-13 09:31:39 UTC
Permalink
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199
Ok.
Post by Ryota Ozaki
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).
Post by Robert Swindells
Post by Ryota Ozaki
Do you have any processes having a socket with IP_IPSEC_POLICY on your
machine in mind?
No.
Hmm.

ozaki-r

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Robert Swindells
2017-10-13 12:28:01 UTC
Permalink
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199
Ok.
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ryota Ozaki
2017-10-13 17:19:11 UTC
Permalink
Post by Ryota Ozaki
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199
Ok.
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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.

ozaki-r

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Michael van Elst
2017-10-14 16:33:54 UTC
Permalink
Post by Robert Swindells
I have not put a policy specifier into /etc/inetd.conf, just uncommented
some services.
Looks like inetd always configures a policy. If none is given, the
policy defaults to "in entrust; out entrust". Doesn't look that useful.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ryota Ozaki
2017-10-16 09:43:59 UTC
Permalink
Post by Ryota Ozaki
Post by Ryota Ozaki
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199
Ok.
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ryota Ozaki
2017-10-20 02:12:42 UTC
Permalink
Post by Ryota Ozaki
Post by Ryota Ozaki
Post by Ryota Ozaki
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199
Ok.
Post by Robert Swindells
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.
Post by Robert Swindells
Post by Ryota Ozaki
Post by Robert Swindells
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.
Fixed in -current (some days ago). If the issue remains, please let me know.

Thanks,
ozaki-r

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...