LATEST VERSION: 1.7 - CHANGELOG
PCF IPsec Add-On v1.7

Release Notes for the PCF IPsec Add-On

Page last updated:

This topic contains release notes for the Pivotal Cloud Foundry (PCF) IPsec add-on.

v1.7.1

  • IPsec support for Windows cells
  • For ESP proposals, Windows default is AES128-GCM
  • For Key exchange, Windows default is AES128, SHA256 and DH14

Known Issues

  • IKEv1 on Windows: Windows uses IKEv1 for Key exchange. IKEv2 does not support multiple root certificates, which is used during certificate rotation. An issue has been filed with Microsoft.

  • Spurious Configuration Warning: As part of the upgrade to StrongSwan version 5.4.0, this version of the IPsec add-on may emit a sequence of spurious configuration warning messages. The messages will appear similar to the following:

    !! Your strongswan.conf contains manual plugin load options for charon.
    !! This is recommended for experts only, see
    !! http://wiki.strongswan.org/projects/strongswan/wiki/PluginLoad
    

    These messages are both expected, and harmless. As a caution to end users, the StrongSwan software now emits a warning message when it detects that the installation includes a manually configured set of plug-ins. As a matter of security hygiene best practices, the IPsec add-on has always used a manual (explicit) configuration, and loads a restricted set of StrongSwan plug-ins. Any unused plug-ins are not loaded. The newest version of StrongSwan now issues this warning message when it detects that situation. The actual list of plug-ins in use has been determined to be appropriate for use of StrongSwan in the PCF environment. This warning is expected, and should be ignored.

  • Certificate Verification: There is a known issue with the CA certificate validation. The IPsec add-on supports credential rotation with minimal downtime. The host instance certificate can be rotated at any time by doing a deployment. In addition, the CA certificate that is used to verify trust in the host certificates can be rotated with minimal downtime by doing multiple deployments.

    However, because all VMs typically share the same instance certificate, they will trust each other without relying upon the CA certificate. The CA certificate is not actually needed until the operator does a deployment to rotate the instance certificate(s). While that deployment is running, some of the VMs will have received a new instance certificate, while other VMs are still operating using the prior instance certificate. During this time, while the instance certificates are different, the validation of the peer instance certificate will rely upon the common CA certificate in order to establish trust in the counterparty.

    If the CA certificate is malformed, or otherwise invalid, this problem will remain latent until the time when the instance certificate is being rotated. It is only during that deployment when the operator will discover that the CA certificate is not valid. Of course, as long as the CA certificate is valid, there is no problem.

    It is recommended that operators use a tool such as OpenSSL to verify that the CA certificate they are choosing to configure is in fact valid, and contains the appropriate details for proper end-entity authentication of the VM in the deployment (such as subjectName, issuerName, and validity dates, etc).

    Operators can use their favorite certificate management tool to confirm that their certificate matches what they expect. Using OpenSSL, one can issue the command:

    $ openssl x509 -in myCA.crt -text
    
    If this command produces valid output, then the certificate will be OK when configured for IPsec.

  • MTU Sizing: Use 1354 on OpenStack. Keep the default on AWS and vSphere.

Create a pull request or raise an issue on the source for this page in GitHub