RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1457904 - rebase libreswan to 3.23
Summary: rebase libreswan to 3.23
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreswan
Version: 7.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: Ondrej Moriš
Mirek Jahoda
URL:
Whiteboard:
Depends On: 1251440 1434661
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-01 13:37 UTC by Paul Wouters
Modified: 2018-10-26 07:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Libreswan rebased to version 3.23 The _libreswan_ packages have been upgraded to upstream version 3.23, which provides a number of bug fixes, speed improvements, and enhancements over the previous version. Notable changes include: * Support for the extended DNS Security Extensions (DNSSEC) suite through the "dnssec-enable=yes|no", "dnssec-rootkey-file=", and "dnssec-anchors=" options. * Experimental support for Postquantum Preshared Keys (PPK) through the "ppk=yes|no|insist" option. * Support for Signature Authentication (RFC 7427) for RSA-SHA. * The new "logip=" option with the default value `yes` can be used to disable logging of incoming IP addresses. This is useful for large-scale service providers concerned for privacy. * Unbound DNS server "ipsecmod module" support for Opportunistic IPsec using `IPSECKEY` records in DNS. * Support for the Differentiated Services Code Point (DSCP) architecture through the "decap-dscp=yes" option. DSCP was formerly known as Terms Of Service (TOS). * Support for disabling Path MTU Discovery (PMTUD) through the "nopmtudisc=yes" option. * Support for the IDr (Identification - Responder) payload for improved multi-domain deployments. * Resending IKE packets on extremely busy servers that return the `EAGAIN` error message. * Various improvements to the updown scripts for customizations. * Updated preferences of crypto algorithms as per RFC 8221 and RFC 8247. * Added the `%none` and `/dev/null` values to the "leftupdown=" option for disabling the updown script. * Improved support for rekeying using the CREATE_CHILD_SA exchange. * IKEv1 XAUTH thread race conditions resolved. * Significant performance increase due to optimized pthread locking. See the `ipsec.conf` man page for more information.
Clone Of:
Environment:
Last Closed: 2018-04-10 17:22:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0932 0 None None None 2018-04-10 17:23:18 UTC

Description Paul Wouters 2017-06-01 13:37:34 UTC
This will add support for:

From v3.21:
- DNSSEC based Opportunistic IPsec (require unbound >= 1.5.0 for libevent support and the ipsecmod module of unbound that should get into 1.6.3)

- whack --listevents support
- improved CREATE_CHILD_SA and PFS support
- AH alignment fixes for IPv4
- New dnssec-enable=yes|no, dnssec-rootkey-file=, dnssec-anchors= 
  (to better support root key rollover)
- Various REKEY improvements
- Support for Opportunistic IPsec servers behind a NAT with port forward
- Monitoring support and munin plugin

From v3.22:
- IKE over TCP (draft-ietf-ipsecme-tcp-encaps)
- Post Quantum support (draft-fluhrer-qr-ikev2)
- Improved algorithm support (curve25519, chacha20poly1305)
  (requires NSS update)
- Digital Signatures support (RFC-7427)
- Improved DNSSEC support (draft-ietf-ipsecme-split-dns)
- GSSAPI AUTH

Comment 2 Ondrej Moriš 2018-01-11 19:56:42 UTC
Paul, isn't it worth mentioning in documentation that certificates requirements changed (Subject Alternative Name is needed)? Well, I am not sure how many customers are using certs without SAN but such certificates will be rejected with latest libreswan (with clear explanation in the logs though).

Comment 3 Paul Wouters 2018-01-11 20:56:59 UTC
yes that must be part of the release notes

Comment 5 Ondrej Moriš 2018-01-16 14:30:48 UTC
Paul, during Common Criteria testing we noticed the following issue:

conn test
        auto=route
        authby=secret
        type=transport
        left=%defaultroute
        right=<CLIENT>
        ikev2=yes
        ike=aes_gcm_a128-sha1;dh24
        phase2=esp
        phase2alg=aes_cbc128-sha1;dh24
        labeled_ipsec=no
        connaddrfamily=ipv4
        leftprotoport=tcp/4301
        rightprotoport=tcp
        policy_label=""

# service ipsec restart
Redirecting to /bin/systemctl restart ipsec.service

# journalctl -u ipsec
...
pluto[28226]: Failed to add connection "10.37.150.135-to-10.37.150.59": ike string error: IKE encryption algorithm 'aes_gcm_a' is not supported by IKEv1, enc_alg="aes_gcm_a"(128), auth_alg="sha1", modp="dh24"to-10.37.150.59":
...

So pluto thinks we want IKEv1 despite ikev2=yes setting! This is tested with both 3.22 and 3.23 with the same results. It works as expected with 3.20. What's wrong with that configuration?

Comment 6 Ondrej Moriš 2018-01-16 14:33:28 UTC
BTW: Ah, I pasted incorrect journal message, it should be:

Failed to add connection "test": ike string error: IKE encryption algorithm 'aes_gcm_a' is not supported by IKEv1, enc_alg="aes_gcm_a"(128), auth_alg="sha1", modp="dh24"

Comment 7 Ondrej Moriš 2018-01-16 14:45:21 UTC
(In reply to Ondrej Moriš from comment #5)

> So pluto thinks we want IKEv1 despite ikev2=yes setting! This is tested with
> both 3.22 and 3.23 with the same results. It works as expected with 3.20.
> What's wrong with that configuration?

OK, let me add one more detail - it depends how ike and ikev2 options are ordered. If ikev2 is first, it works. If ikev2 is after ike, it fails as mentioned in the previous comments.

Comment 8 Ondrej Moriš 2018-01-16 14:53:39 UTC
(In reply to Ondrej Moriš from comment #7)
> (In reply to Ondrej Moriš from comment #5)
> 
> > So pluto thinks we want IKEv1 despite ikev2=yes setting! This is tested with
> > both 3.22 and 3.23 with the same results. It works as expected with 3.20.
> > What's wrong with that configuration?
> 
> OK, let me add one more detail - it depends how ike and ikev2 options are
> ordered. If ikev2 is first, it works. If ikev2 is after ike, it fails as
> mentioned in the previous comments.

Well, let me correct this :). It not true. Ordering obviously does not matter. But  with ikev2=insist it works. Therefore with ikev2=yes/propose it fails. With ikev2=insist it works.

Comment 9 Paul Wouters 2018-01-16 15:35:02 UTC
AES_GCM is only valid for ESP (phase2alg= or esp) and IKEv2. IKEv1 does not support AES_GCM - there is no IANA Code Point in the IKEv1 Encryption Algorithms for AES_GCM. So using ike=aes_gcm means you MUST have ikev2=insist.

ikev2=yes means allow ikev2 (but also allow ikev1)

Note that aes_gcm_a is not recommended as perf RFC 8247:

   The reason for promotion from MAY to
   SHOULD is to promote the slightly more secure AEAD method over the
   traditional encrypt+auth method.  Its status is expected to be raised
   once widely implemented.  As the advantage of the shorter (and
   weaker) Integrity Check Values (ICVs) is minimal, the 8- and 12-octet
   ICVs remain at the MAY level.

Comment 11 Ondrej Moriš 2018-01-18 13:42:31 UTC
Thanks Paul, it makes sense, I knew that aes_gcm is IKEv2-only. What confused me was that previously it worked. Anyway, as you pointed out - with ikev2=yes/propose it makes sense to assume that communication might use IKEv1 and use only IKEv1-compatible ciphers. 

Unfortunately, I am experiencing another issue with 3.23, this one is even more confusing. Suppose I have both client and server configured with type=transport. Now when I start connection from client I got:

Jan 18 14:38:33.891787: "test-rsasig" #2: local policy requires Transport Mode but peer requires required Tunnel Mode

Despite the fact that IPsec SA on server is established:

Jan 18 14:38:33.887348: "test-rsasig" #2: STATE_V2_IPSEC_R: IPsec SA established transport mode {ESP=>0xbe49035d <0x7a4d546a xfrm=AES_GCM_16_256-NONE NATOA=none NATD=none DPD=passive}

It looks like some message from server to client telling that transport mode is used by server is missing!

Comment 12 Paul Wouters 2018-01-18 14:59:11 UTC
this was bug fixed two days ago, and was due to not all NOTIFY payloads being sent properly. will be fixed in next respin

Comment 23 errata-xmlrpc 2018-04-10 17:22:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0932

Comment 24 Paul Wouters 2018-10-26 07:16:24 UTC
note the comment above incorrectly mentions GSSAPI support in libreswan 3.22. This is not the case.


Note You need to log in before you can comment on or make changes to this bug.