*** Bug 1418377 has been marked as a duplicate of this bug. ***

> Opportunistic Encryption support (mesh encryption)
> Support for NAT OE Client Address Translation (leftcat=yes)

Already covered by BZ#1300752.

> Routed based VPN support using VTI (leftvti=, vti-interface= vti-routing=, vti-shared, mark=)

Unfortunately cannot test, no VPN available for testing.

> Improved support for non-root configuration/nss db location
> Improved proposal packet transform parser
> Further FIPS tightening

Can you please give us more details about these, Paul? Or are there any GH issues associated with these changes?

> SECCOMP support (seccomp=enabled|tolerant|disabled)

Already covered by BZ#1375750 - SECCOMP support for libreswan.

> Support for Traffic Flow Confidentiality tfc=
> Support disabling and increasing replay window via replay-window=

SanityOnly candidates. We can check that options work. These changes are aimed to mitigate rather non-trivial attacks and hence we probably cannot test them properly.

> Update cipher preferences as per RFC 4307bis and RFC 7321bis

Already covered by BZ#1335949.

> ESN support (XFRM linux 2.6.39+) via esn=yes|no
> Improved OCSP and CRLs support (ocsp-method ocsp-cache-size ocsp-cache-min-age, ocsp-cache-max-age)

These should be relatively easy to test.

VTI can be tested between two libreswan endpoints. Just pick any existing host to host test case and on both ends _add_ to the conn:

  mark=2/0xffffffff
  vti-routing=no
  vti-shared=no
  vti-interface=ipsec0
  leftsubnet=0.0.0.0/0
  rightsubnet=0.0.0.0/0

You can do various pings and nothing should get encrypted, you can verify with ipsec whack --trafficstatus. Then let's say you configure the "right" end to have 10.0.2.0/24, so on the "left" end run:

ip route add 10.0.2.0/24 dev ipsec0

Do a ping to that network and packets should get encrypted.

As a bonus, using this setup you can use tcpdump -n -i ipsec0 to see pre-encrypt and post-decrypted traffic, without seeing the ESP encrypted traffic. And when running tcpdump on the physical interface, no cleartext should be visiable at all (unlike before, without VTI where you say "half" the plaintext with tcpdump)

The non-root / not-default locations are to better support neutron generated configurations. This can be tested by using a non-root user nss db and ipsec.conf in a custom dir, and starting pluto with ipsec pluto --nssdir XXX --configdir YYY

The improved proposal parser is tested most easilly by using a strongswan interop test with default proposal set on strongswan, and plutodebug=all on the libreswan end. This basically runs pluto into an infinite loop going over proposals and logigng things (for minutes or more!). With the newer libreswan version, this does not happen as the parser is much smarter in accepting/rejecting from the Giant List of Strongswan Proposals

Further FIPS tightening consists of a few things. From the changelog:

* FIPS: Only pluto needs a .hmac file, reducing crypto boundary [Paul]
* FIPS: do not allow DBG_PRIVATE to be set when running in FIPS mode [Paul]
* FIPS: Ignore failureshunt=passthrough and negotiationshunt=passthrough [Paul]
* FIPS: Filter default proposals of non-FIPS allowed proposals [Andrew]
* FIPS: Added CAVP test for pluto GCM code [Andrew]
* FIPS: More cleanup of crypto related structs and functions [Andrew]
* FIPS: Implement SHA based PRFs directly in NSS [Andrew]
* FIPS: Support for CAVP testing 'HMAC construct' based SHA PRF code [Andrew]
* verify: fix "with FIPS" output to print OK [Paul]
* FIPS: Only the pluto binary needs a fipscheck .hmac file for self-test [Paul]
* FIPS: Change SA_LIFE_DURATION_MAXIMUM from 1 day to 8h [Paul]
* FIPS: Do not allow Linux-style sha2 truncation for ESP in FIPS mode [Paul]
* FIPS: Allow PSK in FIPS mode. This was erroneously not allowed [Paul]
* FIPS: Added new ipsec whack --fipsstatus [Paul]
* FIPS: Code cleanup and misc. fixes [Andrew / Paul]

I'm not sure what you would want to test here. Probably testing PSK in FIPS mode would be a useful test to add. And trying to use 3des-md5 to confirm it fails, and ensuring connections cannot have sha2-truncbug=yes, and test if using plutostderrlog=private is properly unset when in FIPS mode.

Thanks a lot Paul, is it possible to build scratch build of 3.20 for RHEL? I would like to run a full test coverage we have.

(In reply to Ondrej Moriš from comment #5)
> Thanks a lot Paul, is it possible to build scratch build of 3.20 for RHEL? I
> would like to run a full test coverage we have.

(Or is there a way to build x86_64 rpm for RHEL-7 from github?)

We executed all tests we have using libreswan-3.20 to check regressions and identify differences from the last RHEL-7 version (3.15) and here are the results:

 * Notable changes
   
   1. Configuration options
      a) esp - obsoleted, phase2alg should be used instead
      b) auth - not supported, causes parser error, service fails to
         start 
      c) force_busy - replaced by force-busy and obsoleted by ddos-mode
      d) nat_traversal - not supported (ignored)

   2. Commands & Parameters
      a) ipsec auto --rereadall - obsoleted by ipsec whack --fetchcrls
      b) ipsec ikeping - not supported (unknown command)
      c) ipsec {check,init}nss - location of NSS DB is not the first 
         argument but it is expected as argument of --nssdir parameter
      d) ipsec newhostkey - parameter --random changed to --seeddev,
         previous a default value of --output was /etc/ipsec.secrets, 
         now there is no default value
      e) ipsec {new,show}hostkey - output changed

   3. Cryptography
      a) FIPS-related messages changed
      b) Only pluto hmac is checked by POST. But hmacs are provided for 
         all commands
      c) DH22 is not supported
      d) mark phase2alg is not supported
      e) plase2alg not support null value

 * Possible regressions
   
   1. BZ#1146106 - phase2alg=null causes abort:

      > "test" #1: ASSERTION FAILED: "test" #1: encrypt->keydeflen > 0 (in append_encrypt_transform at /root/rpmbuild/BUILD/libreswan-3.20dr3/programs/pluto/ikev2_spdb_struct.c:1775)
      > "test" #1: ABORT at /root/rpmbuild/BUILD/libreswan-3.20dr3/programs/pluto/ikev2_spdb_struct.c:1775
      > "test" #1: ABORT at /root/rpmbuild/BUILD/libreswan-3.20dr3/programs/pluto/ikev2_spdb_struct.c:1775

   2. keyingtries - it looks like keyingtries does not work, we see no
      keyingtries attempts being logged 

   3. BZ#1126066 - using Paul's reproducer with ddos-mode=force instead
      of force_mode=yes leads to the following:

      > # ipsec auto --up test
      > 002 "test" #1: initiating v2 parent SA
      > 133 "test" #1: STATE_PARENT_I1: initiate
      > 002 "test" #1: test IKE proposals for initial initiator (selecting KE): 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 2:IKE:ENCR=AES_GCM_C_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=NONE;DH=MODP2048,MODP3072,MODP4096,MODP8192 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 4:IKE:ENCR=AES_CBC_128;PRF=HMAC_SHA2_512,HMAC_SHA2_256,HMAC_SHA1;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128,HMAC_SHA1_96;DH=MODP2048,MODP3072,MODP1536 (default)
      > 133 "test" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
      > 002 "test" #1: Received anti-DDOS COOKIE, resending I1 with cookie payload
      > 010 "test" #1: STATE_PARENT_I1: retransmission; will wait 500ms for response
      > 002 "test" #1: ERROR: asynchronous network error report on eth0 (sport=500) for message to 10.16.68.122 port 500, complainant 10.16.68.122: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
      > 010 "test" #1: STATE_PARENT_I1: retransmission; will wait 1000ms for response
      > 002 "test" #1: ERROR: asynchronous network error report on eth0 (sport=500) for message to 10.16.68.122 port 500, complainant 10.16.68.122: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
      > 010 "test" #1: STATE_PARENT_I1: retransmission; will wait 2000ms for response
      > 010 "test" #1: STATE_PARENT_I1: retransmission; will wait 4000ms for response
      > 010 "test" #1: STATE_PARENT_I1: retransmission; will wait 8000ms for response
      > 010 "test" #1: STATE_PARENT_I1: retransmission; will wait 16000ms for response
      > 010 "test" #1: STATE_PARENT_I1: retransmission; will wait 32000ms for response
      > 031 "test" #1: max number of retransmissions (8) reached STATE_PARENT_I1.  No response (or no acceptable response) to our first IKEv2 message
      > 000 "test" #1: starting keying attempt 2 of an unlimited number, but releasing whack

Paul, check you please check "regressions" and confirm that the changes mentioned above are expected? Are there anything else I am missing?

Some feedback on your findings:

   1. Configuration options
      a) esp - obsoleted, phase2alg should be used instead

This has always been the case for libreswan (and even openswan). It's not new
We will not remove the esp= or ah= keywords. So this should not be a problem
other then updating documentation to use phase2= and phase2alg= instead of esp= or ah=

      b) auth - not supported, causes parser error, service fails to
         start 

This is a change due to  the nature of the parser. We cannot have a symmetric option that is also an asymmetric option. We introduced support for asymmetric authentication. Since the symmetric keyword is authby=, we could not use leftauthby= and rightauthby=, so we used leftauth= and rightauth=. This means the (already long obsolete) auth= option can no longer be specified as it has been changed.

      c) force_busy - replaced by force-busy and obsoleted by ddos-mode

Docs need updating. but all old names are left for compatibility. Should not cause any issus.

      d) nat_traversal - not supported (ignored)

Also, is no actual change unless someone set this to "no". But even if they set it to "no" it does not lead to different runtime behaviour.

   2. Commands & Parameters
      a) ipsec auto --rereadall - obsoleted by ipsec whack --fetchcrls

rereadall is not obsoleted. It still should cause the fetchcrl action and other reread actions. A quick peek at the code looks like this is a bug we should fix.

      b) ipsec ikeping - not supported (unknown command)

It really did not work well and was pretty broken and not a standard so all
non-swan implementations would not answer anyway.

      c) ipsec {check,init}nss - location of NSS DB is not the first 
         argument but it is expected as argument of --nssdir parameter

This was done for consistency. The old -d also still works. I'm not aware of
the use of specifying the dir without a option name.

      d) ipsec newhostkey - parameter --random changed to --seeddev,

The name was clarified because originally it did mean the random device used for entropy. But libreswan always used the NSS functions to get entropy. The name was re-used for the BSI additional seeddev requirements. This was confusing, so we changed the name to match reality. But basically no one should be affected by this as in production one woult never specify the --random device. If any scripts used this, it should simply remove the option.


         previous a default value of --output was /etc/ipsec.secrets, 
         now there is no default value

That is because it is no longer required. pluto can pull the keys from NSS without needing this obsoleted information from ipsec.secrets. Also, the ipsec showhostkey command that relied on it no longer relies on this, and for administrators trying to find keys without knowing the keyid, they can run: ipsec showhostkey --list

      e) ipsec {new,show}hostkey - output changed

See above.

   1. BZ#1146106 - phase2alg=null causes abort:

Fixed upstream, will be backported.

   2. keyingtries - it looks like keyingtries does not work, we see no
      keyingtries attempts being logged 

I need to investigate this,

   3. BZ#1126066 - using Paul's reproducer with ddos-mode=force instead
      of force_mode=yes leads to the following:

I need to investigate this one too.

We also found a rekeying regression ourselves that we are working on fixing.
It seems we "forget" the DH if the responder rekeys, and then don't match up a valid proposal.

Successfully verified libreswan rebased to 3.20 upstream version. Based on agreement with development and product management the following list of features were planned to be tested:

Priority 0
==========
updated ciphers to keep up with modern cryptography standards

 * VERIFIED (BZ#1335949, BZ#1444115) 

Priority 1
==========
GSSAPI authentication for cloud/mesh encryption

 * postponed to RHEL-7.5.0 (BZ#1300751)
 
Important bugfixes (CRL, CREATE_CHILD_SA, reconnecting)

 * VERIFIED (BZ#1073137)

IKEv2: Opportunistic IPsec

 * VERIFIED (BZ#1324458)

Priority 2
==========
IKEv2: support CERT chain sending

 * VEFIFIED SanityOnly (BZ#1416144, BZ#1375751)
 
VTI support and MARK support for routing based VPNs

 * VERIFIED SanityOnly

Priority 3
==========
X509: New whack --fetchcrls

 * VERIFIED
 
split-dns draft support (BZ#1300763)

 * postponed to RHEL-7.5.0 (BZ#1375750)

Priority 4
==========
pluto: EXPERIMENTAL SECCOMP support (seccomp=enabled|tolerant|disabled)

 * postponed to RHEL-7.5.0 (BZ#1375750)

Priority 5
==========
pluto: Add keyword replay-window= (default 32, 0 means disable)

 * VERIFIED (BZ#1373280)

IKEv2: Add asymmetric AUTH support (leftauth= and rightauth=)

* VERIFIED (BZ#1168795)

X509: Additional OCSP options to tweak the cache and fetch method

 * not tested due to QA capacity

XFRM: Support for Traffic Flow Confidentiality tfc=XXX

 * not tested due to QA capacity

IKEv2: ESN support (XFRM linux 2.6.39+) via esn=yes|no(default)|either

 * not tested due to QA capacity

Complete test coverage has been executed and results reviewed several times (TR#306842, TR#309731 and TR#313761). No significant issues or regressions were found. Various parts of test coverage were updated to work with 3.20 version of libreswan.

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-2017:2101