From paul at nohats.ca Wed Jun 3 22:56:31 2020 From: paul at nohats.ca (Paul Wouters) Date: Wed, 3 Jun 2020 18:56:31 -0400 (EDT) Subject: [Swan-dev] Namespace based testing for Ubuntu/Debian mostly working now Message-ID: Hi, I pushed some changes to make namespace based libreswan testing work on Ubuntu (and presumably Debian). https://github.com/libreswan/libreswan/commit/47866f3f45c7edae891c45e0037ac4916e3b8158 Mostly related to hardcoded paths of binaries. The new ones work on all systems that I could test (centos8/fedora32/ubuntu) I changed some sanitizers to deal with the /var/lib/ipsec/nss vs /etc/ipsec.d directory. The only issue left in the basic test cases is this: - dir fwd priority 2084814 ptype main + dir fwd priority 2084814 I'm not sure what is causing this? A different kernel version? The Unbuntu 18.04 system I used has 4.15.0-101-generic. Or is it a difference in iproute command version? Obviously, we could sanitize this away, but I feel it might be important to leave there, if we ever are going to use multiple xfrm tables that are not "main". Paul From andrew.cagney at gmail.com Fri Jun 5 20:11:07 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 5 Jun 2020 16:11:07 -0400 Subject: [Swan-dev] [Swan-commit] Changes to ref refs/heads/master In-Reply-To: <49drCx4C0fz7cfFV@vault.libreswan.fi> References: <49drCx4C0fz7cfFV@vault.libreswan.fi> Message-ID: On Fri, 5 Jun 2020 at 14:05, Paul Wouters wrote: > > New commits: > commit bdee688c85b8d8687e72d77618b82363827df3b5 > Author: Paul Wouters > Date: Fri Jun 5 14:04:50 2020 -0400 > > testing: fixup sanitizer again for ephemeral port range > > Seems Fedora 23 decided not to start at 32768 but at 29xxx now ? That's getting pretty messed up, the recommended range is 49152 to 65535 echo 49152 65535 | sudo dd of=/proc/sys/net/ipv4/ip_local_port_range > _______________________________________________ > Swan-commit mailing list > Swan-commit at lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-commit From paul at nohats.ca Fri Jun 5 20:33:40 2020 From: paul at nohats.ca (Paul Wouters) Date: Fri, 5 Jun 2020 16:33:40 -0400 (EDT) Subject: [Swan-dev] [Swan-commit] Changes to ref refs/heads/master In-Reply-To: References: <49drCx4C0fz7cfFV@vault.libreswan.fi> Message-ID: On Fri, 5 Jun 2020, Andrew Cagney wrote: >> Seems Fedora 23 decided not to start at 32768 but at 29xxx now ? > > That's getting pretty messed up, the recommended range is 49152 to 65535 > echo 49152 65535 | sudo dd of=/proc/sys/net/ipv4/ip_local_port_range We could do that but we'd have to set it for every test. We don't really care and as long as some static ports we use as < 20k, we should be fine with the current sanitizer? Paul From lsorense at csclub.uwaterloo.ca Fri Jun 5 21:05:59 2020 From: lsorense at csclub.uwaterloo.ca (Lennart Sorensen) Date: Fri, 5 Jun 2020 17:05:59 -0400 Subject: [Swan-dev] [Swan-commit] Changes to ref refs/heads/master In-Reply-To: References: <49drCx4C0fz7cfFV@vault.libreswan.fi> Message-ID: <20200605210559.khytm5bs2y5mtsub@csclub.uwaterloo.ca> On Fri, Jun 05, 2020 at 04:11:07PM -0400, Andrew Cagney wrote: > That's getting pretty messed up, the recommended range is 49152 to 65535 > echo 49152 65535 | sudo dd of=/proc/sys/net/ipv4/ip_local_port_range Why would someone use dd for that rather than sysctl -w? ie: sudo sysctl -w net.ipv4.ip_local_port_range="49152 65535" -- Len Sorensen From andrew.cagney at gmail.com Fri Jun 5 21:59:37 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 5 Jun 2020 17:59:37 -0400 Subject: [Swan-dev] [Swan-commit] Changes to ref refs/heads/master In-Reply-To: References: <49drCx4C0fz7cfFV@vault.libreswan.fi> Message-ID: On Fri, 5 Jun 2020 at 16:33, Paul Wouters wrote: > > On Fri, 5 Jun 2020, Andrew Cagney wrote: > > >> Seems Fedora 23 decided not to start at 32768 but at 29xxx now ? > > > > That's getting pretty messed up, the recommended range is 49152 to 65535 > > echo 49152 65535 | sudo dd of=/proc/sys/net/ipv4/ip_local_port_range > > We could do that but we'd have to set it for every test. We don't really > care and as long as some static ports we use as < 20k, we should be fine > with the current sanitizer? Yea, we'll see. From hugh at mimosa.com Sat Jun 6 14:09:41 2020 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Sat, 6 Jun 2020 10:09:41 -0400 (EDT) Subject: [Swan-dev] please use a useful message Subject Message-ID: [grumpy old man mode] | From: Andrew Cagney | To: Libreswan Development List | Date: Fri, 5 Jun 2020 16:11:07 -0400 | Subject: Re: [Swan-dev] [Swan-commit] Changes to ref refs/heads/master This thread has useless Subject: headers. It is much more useful to have an apt Subject. If you lack imagination, the commit hash is an obvious candidate. Just to make another point, I've left it so you will probably see three copies of out mailing list postscript. It would be helpful to trim this and other superflous text when quoting. | > _______________________________________________ | > Swan-commit mailing list | > Swan-commit at lists.libreswan.org | > https://lists.libreswan.org/mailman/listinfo/swan-commit | _______________________________________________ | Swan-dev mailing list | Swan-dev at lists.libreswan.org | https://lists.libreswan.org/mailman/listinfo/swan-dev From andrew.cagney at gmail.com Sat Jun 6 14:33:47 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Sat, 6 Jun 2020 10:33:47 -0400 Subject: [Swan-dev] please use a useful message Subject In-Reply-To: References: Message-ID: On Sat, 6 Jun 2020 at 10:19, D. Hugh Redelmeier wrote: > > [grumpy old man mode] Have you looked at the script that generates the e-mail? > | From: Andrew Cagney > | To: Libreswan Development List > | Date: Fri, 5 Jun 2020 16:11:07 -0400 > | Subject: Re: [Swan-dev] [Swan-commit] Changes to ref refs/heads/master > > This thread has useless Subject: headers. > > It is much more useful to have an apt Subject. If you lack imagination, > the commit hash is an obvious candidate. > > Just to make another point, I've left it so you will probably see three > copies of out mailing list postscript. It would be helpful to trim this > and other superflous text when quoting. > > | > _______________________________________________ > | > Swan-commit mailing list > | > Swan-commit at lists.libreswan.org > | > https://lists.libreswan.org/mailman/listinfo/swan-commit > | _______________________________________________ > | Swan-dev mailing list > | Swan-dev at lists.libreswan.org > | https://lists.libreswan.org/mailman/listinfo/swan-dev > > _______________________________________________ > Swan-dev mailing list > Swan-dev at lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev From c.mailer at grad.ufsc.br Wed Jun 10 21:19:18 2020 From: c.mailer at grad.ufsc.br (c.mailer at grad.ufsc.br) Date: Wed, 10 Jun 2020 18:19:18 -0300 Subject: [Swan-dev] Question PSK Asymmetric Patch Message-ID: <81c29d287553463cb7ac9375b84bf215@grad.ufsc.br> Hello, What would I need to change to add support for asymmetric PSK authentication on Libreswan? Thank you, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at nohats.ca Thu Jun 11 02:21:31 2020 From: paul at nohats.ca (Paul Wouters) Date: Wed, 10 Jun 2020 22:21:31 -0400 (EDT) Subject: [Swan-dev] Question PSK Asymmetric Patch In-Reply-To: <81c29d287553463cb7ac9375b84bf215@grad.ufsc.br> References: <81c29d287553463cb7ac9375b84bf215@grad.ufsc.br> Message-ID: On Wed, 10 Jun 2020, c.mailer at grad.ufsc.br wrote: > What would I need to change to add support for asymmetric PSK authentication on Libreswan? There are two aspects to this. 1) How do we specify this in our secrets file ? 2) How we do implement 1) The biggest question is 1) Currently, secrets are tied to IDs, so if you have: conn test leftid=@foo rightid=@bar authby=secret [...] Your secrets file will have: @foo @bar : PSK "secret" you can omit an ID and it will become a wildcard, eg: : PSK "secret" or: @vpnserver %any: PSK "secret" So we could look at extending the syntax. Possibly: @foo @bar : PSK "secret1" "secret2" But what would that mean, @foo identies using "secret1" ? or @foo requiring from @bar "secret1". So perhaps it would be better to use: @foo : PSK "secret1" @bar : PSK "secret2" But currently, the code would look up our own id (eg @foo) and pick that secret, and not look at the remote id. Also, if you have two conns for which you use id @foo, eg one to @bar and one to @zzz, which use different secrets for you, then you need to bind the secrets to use to both IDs, so this latter one would not help. We could add a new secret type, eg APSK that takes two secrets, eg @foo @bar : APSK "secret1" "secret2" @foo @zzz : APSK "secret3" "secret4" And perhaps try to patch APSKs before PSKs to that the wildcards won't match before asymmetric PSKs, eg when using: @foo : PSK "secret1" @foo @bar : APSK "secret1 secret2" But, there is an additional potential problem. What if we do not yet know the remote id? We send our AUTH payload in IKE_AUTH before receiving the remote ID in their IKE_AUTH reply. Usually, if you don't know the remote ID it is because it is packet triggered, but usually those cannot really use PSK anyway. Or because it is CERT based, and then you don't use PSK. So perhaps the new APSK keyword would work? Then we have 2) Who is going to change the code in lib/libswan/secrets.c and programs/pluto/ikev2_parent.c The reason I think this entire endavour is a bit silly is that both ends need to know both PSKs. What security is gained by using two seperate PSKs over using one symmetric PSK ? Paul From hugh at mimosa.com Sat Jun 13 22:31:32 2020 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Sat, 13 Jun 2020 18:31:32 -0400 (EDT) Subject: [Swan-dev] style: naming of parameters should match in function prototype and definition Message-ID: I just noticed an example where our code violates this. The function prototype for initsubnet: extern err_t initsubnet(const ip_address *addr, int maskbits, int clash, ip_subnet *dst); The start of its definition: err_t /* NULL for success, else string literal */ initsubnet(addr, count, clash, dst) const ip_address * addr; int count; int clash; /* '0' zero host-part bits, 'x' die on them */ ip_subnet *dst; { The second argument is called "maskbits" in the prototype and "count" in the definition. The documentation (lib/libswan/initsubnet.3.xml) calls it maskbits. This is legal. I think that it is quite confusing I can think of no advantage. Conclusion: we should avoid this. (Technical detail that doesn't concern our project: Parameter names are local to the function or function prototype. If you are building library code and want to reduce possible name clashes with macros, you might choose not to name the parameters in the function prototype in the .h file. I think that impairs readability.) ================ We should probably convert everything from old style function definitions. I don't see this as urgent. From ng.leesing at stengg.com Mon Jun 15 01:36:13 2020 From: ng.leesing at stengg.com (NG Lee Sing) Date: Mon, 15 Jun 2020 01:36:13 +0000 Subject: [Swan-dev] Dependency query Message-ID: <3b2e6b0927704f69ad0031bd55dcf19d@stengg.com> Hi Team, May I queries for Libreswan: 3.10.0-123.el7.x86-64, whether it supports RHEL OS v7.7? Thanks Best Regards, Lee Sing ST Electronics (Info-Security) Pte Ltd 100 Jurong East Street 21 ST Electronics Jurong East Building Singapore 609602 www.digisafe.com www.stee.stengg.com (Regn. No.: 199902746G) [ST_Banner] This message contains confidential information and is intended only for the individual(s) addressed in the message. If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ng.leesing at stengg.com Mon Jun 15 01:22:53 2020 From: ng.leesing at stengg.com (NG Lee Sing) Date: Mon, 15 Jun 2020 01:22:53 +0000 Subject: [Swan-dev] Dependency query Message-ID: Hi Team, May I queries for Libreswan: 3.10.0-123.el7.x86-64, whether it supports RHEL OS v7.7? Thanks Best Regards, Lee Sing ST Electronics (Info-Security) Pte Ltd 100 Jurong East Street 21 ST Electronics Jurong East Building Singapore 609602 www.digisafe.com www.stee.stengg.com (Regn. No.: 199902746G) [ST_Banner] This message contains confidential information and is intended only for the individual(s) addressed in the message. If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at nohats.ca Mon Jun 15 02:37:33 2020 From: paul at nohats.ca (Paul Wouters) Date: Sun, 14 Jun 2020 22:37:33 -0400 (EDT) Subject: [Swan-dev] Dependency query In-Reply-To: <3b2e6b0927704f69ad0031bd55dcf19d@stengg.com> References: <3b2e6b0927704f69ad0031bd55dcf19d@stengg.com> Message-ID: On Mon, 15 Jun 2020, NG Lee Sing wrote: > May I queries for Libreswan: 3.10.0-123.el7.x86-64, whether it supports RHEL OS v7.7? I think you are asking wether the RHEL7 version of libreswan (3.25-8.1) works when installing RHEL kernel 3.10.0-123.el7.x86-64 ? In general, any 3.x and 4.x kernel will work with libreswan. I see for RHEL7, the latest kernel is kernel-3.10.0-1127.10.1.el7 I'm not sure how old that 3.10.0-123 is. It should work but it might not have some newer features (like MOBIKE) If you have a specific issue, we can try and figure out what your problem might be. Paul From andrew.cagney at gmail.com Wed Jun 17 15:06:17 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Wed, 17 Jun 2020 11:06:17 -0400 Subject: [Swan-dev] DBG_* cleanout Message-ID: I'm planning on flushing out all these redundant macros: -#define DBG_RAW DBG_BASE -#define DBG_PARSING DBG_BASE -#define DBG_EMITTING DBG_BASE -#define DBG_CONTROL DBG_BASE -#define DBG_LIFECYCLE DBG_BASE -#define DBG_KERNEL DBG_BASE -#define DBG_DNS DBG_BASE -#define DBG_OPPO DBG_BASE -#define DBG_CONTROLMORE DBG_BASE -#define DBG_NATT DBG_BASE -#define DBG_X509 DBG_BASE -#define DBG_DPD DBG_BASE -#define DBG_XAUTH DBG_BASE -#define DBG_RETRANSMITS DBG_BASE -#define DBG_OPPOINFO DBG_BASE -#define DBG_PROPOSAL_PARSER DBG_TMI and where possible, reducing: DBG(DBG_, DBG_log(...)) to just dbg(...) From paul at nohats.ca Wed Jun 17 18:08:49 2020 From: paul at nohats.ca (Paul Wouters) Date: Wed, 17 Jun 2020 14:08:49 -0400 (EDT) Subject: [Swan-dev] DBG_* cleanout In-Reply-To: References: Message-ID: On Wed, 17 Jun 2020, Andrew Cagney wrote: > I'm planning on flushing out all these redundant macros: > > -#define DBG_RAW DBG_BASE > -#define DBG_PARSING DBG_BASE > -#define DBG_EMITTING DBG_BASE > -#define DBG_CONTROL DBG_BASE > -#define DBG_LIFECYCLE DBG_BASE > -#define DBG_KERNEL DBG_BASE > -#define DBG_DNS DBG_BASE > -#define DBG_OPPO DBG_BASE > -#define DBG_CONTROLMORE DBG_BASE > -#define DBG_NATT DBG_BASE > -#define DBG_X509 DBG_BASE > -#define DBG_DPD DBG_BASE > -#define DBG_XAUTH DBG_BASE > -#define DBG_RETRANSMITS DBG_BASE > -#define DBG_OPPOINFO DBG_BASE > -#define DBG_PROPOSAL_PARSER DBG_TMI > > and where possible, reducing: > DBG(DBG_, DBG_log(...)) > to just > dbg(...) Sounds good! As long as the old keywords still work and lead to something sane, so configs with plutodebug=control won't fail to load. Paul From andrew.cagney at gmail.com Thu Jun 18 13:42:45 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Thu, 18 Jun 2020 09:42:45 -0400 Subject: [Swan-dev] DBG_* cleanout In-Reply-To: References: Message-ID: On Wed, 17 Jun 2020 at 14:08, Paul Wouters wrote: > > On Wed, 17 Jun 2020, Andrew Cagney wrote: > > > I'm planning on flushing out all these redundant macros: > > > > -#define DBG_RAW DBG_BASE > > -#define DBG_PARSING DBG_BASE > > -#define DBG_EMITTING DBG_BASE > > -#define DBG_CONTROL DBG_BASE > > -#define DBG_LIFECYCLE DBG_BASE > > -#define DBG_KERNEL DBG_BASE > > -#define DBG_DNS DBG_BASE > > -#define DBG_OPPO DBG_BASE > > -#define DBG_CONTROLMORE DBG_BASE > > -#define DBG_NATT DBG_BASE > > -#define DBG_X509 DBG_BASE > > -#define DBG_DPD DBG_BASE > > -#define DBG_XAUTH DBG_BASE > > -#define DBG_RETRANSMITS DBG_BASE > > -#define DBG_OPPOINFO DBG_BASE > > -#define DBG_PROPOSAL_PARSER DBG_TMI > > > > and where possible, reducing: > > DBG(DBG_, DBG_log(...)) > > to just > > dbg(...) > > Sounds good! Pushed. > As long as the old keywords still work and lead to something sane, > so configs with plutodebug=control won't fail to load. All the above keywords map onto basic debugging (it's been that way for some time). > Paul From andrew.cagney at gmail.com Fri Jun 19 02:28:19 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Thu, 18 Jun 2020 22:28:19 -0400 Subject: [Swan-dev] Kernel 5.6.18-300.fc32.x86_64 VS Kernel 5.6.14-300.fc32.x86_64 Message-ID: Rebuilding the testing VMs seems to have introduced a failure vis: pre-rebuild: https://testing.libreswan.org/v3.30-1022-g4bd4d18c0f-master/newoe-04-pass-pass/OUTPUT/ post-rebuild (which has the effect of upgrading everything): https://testing.libreswan.org/v3.30-1023-g5e4995c608-master/newoe-04-pass-pass/OUTPUT/road.console.diff yes consecutive commits and nothing changed. the key difference, I'm assuming, is the kernel (however, it could be something else). Any ideas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at nohats.ca Fri Jun 19 12:22:19 2020 From: paul at nohats.ca (Paul Wouters) Date: Fri, 19 Jun 2020 08:22:19 -0400 (EDT) Subject: [Swan-dev] icmp acquire Message-ID: The following patch is needed for newer kernels to fix the icmp acquire kernel bug. Thanks to Sabrina for hunting this one down. diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c index 535427292194..df6fbefe44d4 100644 --- a/net/ipv4/ping.c +++ b/net/ipv4/ping.c @@ -786,6 +786,9 @@ static int ping_v4_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) inet_sk_flowi_flags(sk), faddr, saddr, 0, 0, sk->sk_uid); + fl4.fl4_icmp_type = user_icmph.type; + fl4.fl4_icmp_code = user_icmph.code; + security_sk_classify_flow(sk, flowi4_to_flowi(&fl4)); rt = ip_route_output_flow(net, &fl4, sk); if (IS_ERR(rt)) { note that I worked around this by: testing/guestbin/swan-prep:subprocess.getoutput('sudo sysctl net.ipv4.ping_group_range="1 65535"') So we will be able to remove that workaround in the future again. Paul From andrew.cagney at gmail.com Fri Jun 19 15:02:31 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 19 Jun 2020 11:02:31 -0400 Subject: [Swan-dev] Kernel 5.6.18-300.fc32.x86_64 VS Kernel 5.6.14-300.fc32.x86_64 In-Reply-To: References: Message-ID: I'm forcing f32 to not upgrade as an immediate workaround. On Thu, 18 Jun 2020 at 22:28, Andrew Cagney wrote: > Rebuilding the testing VMs seems to have introduced a failure vis: > > pre-rebuild: > > https://testing.libreswan.org/v3.30-1022-g4bd4d18c0f-master/newoe-04-pass-pass/OUTPUT/ > > post-rebuild (which has the effect of upgrading everything): > > https://testing.libreswan.org/v3.30-1023-g5e4995c608-master/newoe-04-pass-pass/OUTPUT/road.console.diff > yes consecutive commits and nothing changed. > > the key difference, I'm assuming, is the kernel (however, it could be > something else). > > Any ideas. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at nohats.ca Fri Jun 19 22:00:35 2020 From: paul at nohats.ca (Paul Wouters) Date: Fri, 19 Jun 2020 18:00:35 -0400 (EDT) Subject: [Swan-dev] Kernel 5.6.18-300.fc32.x86_64 VS Kernel 5.6.14-300.fc32.x86_64 In-Reply-To: References: Message-ID: On Thu, 18 Jun 2020, Andrew Cagney wrote: > > Rebuilding the testing VMs seems to have introduced a failure vis: > > pre-rebuild:https://testing.libreswan.org/v3.30-1022-g4bd4d18c0f-master/newoe-04-pass-pass/OUTPUT/ > > post-rebuild (which has the effect of upgrading everything): > https://testing.libreswan.org/v3.30-1023-g5e4995c608-master/newoe-04-pass-pass/OUTPUT/road.console.diff > yes consecutive commits and nothing changed. > > the key difference, I'm assuming, is the kernel (however, it could be something else). It is caused by nic losing the IP info on its eth1. Which is because it is racing with eth0. Since it tries to add the route to a network for which it needs eth0, eth1 fails. Then eth0 establishes. I think the race is caused by having NetworkManager and systemd-networkd. On nic, run: rpm -e NetworkManager That fixed it for me on my laptop. Paul From andrew.cagney at gmail.com Sat Jun 20 00:42:57 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Fri, 19 Jun 2020 20:42:57 -0400 Subject: [Swan-dev] Kernel 5.6.18-300.fc32.x86_64 VS Kernel 5.6.14-300.fc32.x86_64 In-Reply-To: References: Message-ID: On Fri, 19 Jun 2020 at 18:00, Paul Wouters wrote: > On Thu, 18 Jun 2020, Andrew Cagney wrote: > > > > > Rebuilding the testing VMs seems to have introduced a failure vis: > > > > pre-rebuild: > https://testing.libreswan.org/v3.30-1022-g4bd4d18c0f-master/newoe-04-pass-pass/OUTPUT/ > > > > post-rebuild (which has the effect of upgrading everything): > > > https://testing.libreswan.org/v3.30-1023-g5e4995c608-master/newoe-04-pass-pass/OUTPUT/road.console.diff > > yes consecutive commits and nothing changed. > > > > the key difference, I'm assuming, is the kernel (however, it could be > something else). > > It is caused by nic losing the IP info on its eth1. > Which is because it is racing with eth0. Since it tries to add the route > to a network for which it needs eth0, eth1 fails. Then eth0 establishes. > > I think the race is caused by having NetworkManager and systemd-networkd. > On nic, run: rpm -e NetworkManager > I'm not so sure. f32.ks already excludes it during the initial install and only a select list of packages is updated (NetworkManager isn't on the list). So adding NetworkManager to the exclude list is just a safety net. This run, which is working, https://testing.libreswan.org/v3.30-1044-gb7aa1cdd94-master/ has everything on the short update list except the kernel & xl2tpd. And, locally where things failed, NetworkManager isn't installed. That fixed it for me on my laptop. > > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at nohats.ca Sat Jun 20 00:46:44 2020 From: paul at nohats.ca (Paul Wouters) Date: Fri, 19 Jun 2020 20:46:44 -0400 Subject: [Swan-dev] Kernel 5.6.18-300.fc32.x86_64 VS Kernel 5.6.14-300.fc32.x86_64 In-Reply-To: References: Message-ID: <38F60B8D-BE68-45E1-8A2F-80609E21612E@nohats.ca> My nic had it installed and it raced with systemd-networkd because our baseconfig provides configs for both managers Sent from my iPhone > On Jun 19, 2020, at 20:43, Andrew Cagney wrote: > > ? > > >>> On Fri, 19 Jun 2020 at 18:00, Paul Wouters wrote: >>> On Thu, 18 Jun 2020, Andrew Cagney wrote: >>> >>> > >>> > Rebuilding the testing VMs seems to have introduced a failure vis: >>> > >>> > pre-rebuild:https://testing.libreswan.org/v3.30-1022-g4bd4d18c0f-master/newoe-04-pass-pass/OUTPUT/ >>> > >>> > post-rebuild (which has the effect of upgrading everything): >>> > https://testing.libreswan.org/v3.30-1023-g5e4995c608-master/newoe-04-pass-pass/OUTPUT/road.console.diff >>> > yes consecutive commits and nothing changed. >>> > >>> > the key difference, I'm assuming, is the kernel (however, it could be something else). >>> >>> It is caused by nic losing the IP info on its eth1. >>> Which is because it is racing with eth0. Since it tries to add the route >>> to a network for which it needs eth0, eth1 fails. Then eth0 establishes. >>> >>> I think the race is caused by having NetworkManager and systemd-networkd. >>> On nic, run: rpm -e NetworkManager >> >> I'm not so sure. >> >> f32.ks already excludes it during the initial install and only a select list of packages is updated (NetworkManager isn't on the list). So adding NetworkManager to the exclude list is just a safety net. >> >> This run, which is working, >> https://testing.libreswan.org/v3.30-1044-gb7aa1cdd94-master/ >> has everything on the short update list except the kernel & xl2tpd. >> >> And, locally where things failed, NetworkManager isn't installed. >> >> >> That fixed it for me on my laptop. >> >> Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.cagney at gmail.com Mon Jun 29 21:46:36 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Mon, 29 Jun 2020 17:46:36 -0400 Subject: [Swan-dev] libipsecconf: promote ah= / esp= as desired keywords over phase2alg= In-Reply-To: <49wgNc2m1Vz7VTdm@vault.libreswan.fi> References: <49wgNc2m1Vz7VTdm@vault.libreswan.fi> Message-ID: On Mon, 29 Jun 2020 at 17:19, Paul Wouters wrote: > > New commits: > commit b98c10dc015c6c6bbc34c2020f7f5b20cf3483c8 > Author: Paul Wouters > Date: Mon Jun 29 17:16:47 2020 -0400 > > libipsecconf: promote ah= / esp= as desired keywords over phase2alg= > > This is a reversal of what we tried to do in the past. Since IKEv2 > does not really talk about phase2 anymore, this term is no longer > favoured. Ya! > Ideally, phase2=ah|esp would also get renamed, but what word to use? > > (type is already used for tunnel|transport, and mode= would be confused > with transport|tunnel mode. And encapsulation=ah would be weird because > there is no encapsulation. And no one wants ah=yes) Right, mode is either transport or tunnel. Encapsulation, however, refers to UDP / TCP. (It's really confusing that the E in ESP is also encapsulate). The RFC seems to refer to ESP and AH as child SAs (which does make sense). > > _______________________________________________ > Swan-commit mailing list > Swan-commit at lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-commit From andrew.cagney at gmail.com Tue Jun 30 00:04:06 2020 From: andrew.cagney at gmail.com (Andrew Cagney) Date: Mon, 29 Jun 2020 20:04:06 -0400 Subject: [Swan-dev] libipsecconf: promote ah= / esp= as desired keywords over phase2alg= In-Reply-To: References: <49wgNc2m1Vz7VTdm@vault.libreswan.fi> Message-ID: On Mon, 29 Jun 2020 at 17:46, Andrew Cagney wrote: > > On Mon, 29 Jun 2020 at 17:19, Paul Wouters wrote: > > > > New commits: > > commit b98c10dc015c6c6bbc34c2020f7f5b20cf3483c8 > > Author: Paul Wouters > > Date: Mon Jun 29 17:16:47 2020 -0400 > > > > libipsecconf: promote ah= / esp= as desired keywords over phase2alg= > > > > This is a reversal of what we tried to do in the past. Since IKEv2 > > does not really talk about phase2 anymore, this term is no longer > > favoured. > > Ya! To clarify one thing, does this mean that: ah=sha1 implies AH? > > > Ideally, phase2=ah|esp would also get renamed, but what word to use? > > > > (type is already used for tunnel|transport, and mode= would be confused > > with transport|tunnel mode. And encapsulation=ah would be weird because > > there is no encapsulation. And no one wants ah=yes) > > Right, mode is either transport or tunnel. > Encapsulation, however, refers to UDP / TCP. > (It's really confusing that the E in ESP is also encapsulate). > The RFC seems to refer to ESP and AH as child SAs (which does make sense). > > > > _______________________________________________ > > Swan-commit mailing list > > Swan-commit at lists.libreswan.org > > https://lists.libreswan.org/mailman/listinfo/swan-commit From paul at nohats.ca Tue Jun 30 00:49:38 2020 From: paul at nohats.ca (Paul Wouters) Date: Mon, 29 Jun 2020 20:49:38 -0400 (EDT) Subject: [Swan-dev] libipsecconf: promote ah= / esp= as desired keywords over phase2alg= In-Reply-To: References: <49wgNc2m1Vz7VTdm@vault.libreswan.fi> Message-ID: On Mon, 29 Jun 2020, Andrew Cagney wrote: >> libipsecconf: promote ah= / esp= as desired keywords over phase2alg= >> >> This is a reversal of what we tried to do in the past. Since IKEv2 >> does not really talk about phase2 anymore, this term is no longer >> favoured. > > Ya! >> Ideally, phase2=ah|esp would also get renamed, but what word to use? >> >> (type is already used for tunnel|transport, and mode= would be confused >> with transport|tunnel mode. And encapsulation=ah would be weird because >> there is no encapsulation. And no one wants ah=yes) > > Right, mode is either transport or tunnel. > Encapsulation, however, refers to UDP / TCP. > (It's really confusing that the E in ESP is also encapsulate). > The RFC seems to refer to ESP and AH as child SAs (which does make sense). Child SA is an IKEv2 only term though. So I wouldn't use it here. We could perhaps use ipsec=ah|esp|wesp|iptfs > To clarify one thing, does this mean that: > ah=sha1 > implies AH? Currently it does not, because: /* attributes of the phase2 policy */ { "esp", kv_conn, kt_string, KSCF_ESP, NULL, NULL, }, { "ah", kv_conn, kt_string, KSCF_ESP, NULL, NULL, }, { "phase2alg", kv_conn | kv_alias, kt_string, KSCF_ESP, NULL, NULL, }, /* obsolete */ It's all KSCF_ESP. So esp= and ah= are actually the same thing. We could introduce KSCF_AH and make it so, but that complicates thing with implied defaults (eg system wide crypto policies via conn %default). I would actually prefer it the other way, I would want to be able to say: conn %default esp=aes_gcm256,chacha20_poly1305,aes256-sha2_512+sha1+sha2_256,aes_gcm128,aes128-sha1+sha2_256 ah=aes_ccm256+sha2_512+sha1+sha2_256 And have: conn my-esp-tunnel phase2alg=esp [...] conn my-ah-link phase2alg=ah [...] Currently, on RHEL, we have a system wide crypto policy with conn %default specifying esp= which means that any phase2alg=ah MUST specify crypto algorithms via ah= or it will fail to load because it will include ESP algos. Paul