Correcting trademark symbols

Author: Kim Hoffman

index.html.md.erb

@@ -5,15 +5,15 @@ owner: Security Engineering
 
 <strong><%= modified_date %></strong>
 
-This guide describes the [Pivotal Cloud Foundry&reg;](https://network.pivotal.io/products/pivotal-cf) (PCF) IPsec add-on. The topics included in this guide cover installation and configuration, troubleshooting, and credential rotation. Your organization may require IPSec if you transmit sensitive data.
+This guide describes the [Pivotal Cloud Foundry](https://network.pivotal.io/products/pivotal-cf) (PCF) IPsec add-on. The topics included in this guide cover installation and configuration, troubleshooting, and credential rotation. Your organization may require IPSec if you transmit sensitive data.
 
-<p class="note"><strong>Note</strong>: If you apply the IPsec add-on to your PCF deployment, you cannot remove IPsec without removing and reinstalling the entire deployment.</p>	
+<p class="note"><strong>Note</strong>: If you apply the IPsec add-on to your PCF deployment, you cannot remove IPsec without removing and reinstalling the entire deployment.</p>
 
 ## Overview ##
 
-The IPsec add-on for PCF provides security to the network layer of the OSI model with a [strongSwan](https://www.strongswan.org/) implementation of IPsec. The IPsec add-on provides a strongSwan job to each BOSH-deployed virtual machine (VM). 
+The IPsec add-on for PCF provides security to the network layer of the OSI model with a [strongSwan](https://www.strongswan.org/) implementation of IPsec. The IPsec add-on provides a strongSwan job to each BOSH-deployed virtual machine (VM).
 
-IPsec encrypts IP data flow between hosts, between security gateways, and between security gateways and hosts. The PCF IPsec add-on secures network traffic within a Cloud Foundry deployment and provides internal system protection if a malicious actor breaches your firewall. 
+IPsec encrypts IP data flow between hosts, between security gateways, and between security gateways and hosts. The PCF IPsec add-on secures network traffic within a Cloud Foundry deployment and provides internal system protection if a malicious actor breaches your firewall.
 
 ## PCF IPsec Implementation Details ##
 The PCF IPsec add-on implements the following cryptographic suite:

installing.html.md.erb

@@ -1,28 +1,28 @@
 ---
-title: Installing the Pivotal Cloud Foundry® IPSec Add-On
+title: Installing the Pivotal Cloud Foundry IPSec Add-On
 owner: Security Engineering
 ---
 
 <strong><%= modified_date %></strong>
 
-This topic describes how to prepare your network for IPsec, create an IPsec manifest, and add IPsec to your deployment. 
+This topic describes how to prepare your network for IPsec, create an IPsec manifest, and add IPsec to your deployment.
 ##<a id="prereqs"></a>Prerequisites
 
-To complete the IPsec installation, check that you have satisfied the following prerequisites before you begin: 
+To complete the IPsec installation, check that you have satisfied the following prerequisites before you begin:
 
-* AWS, vSphere, or OpenStack as your IaaS 
+* AWS, vSphere, or OpenStack as your IaaS
 
-* Pivotal Cloud Foundry&reg; (PCF) operator administration rights
+* Pivotal Cloud Foundry (PCF) operator administration rights
 
 * BOSH deployed through Ops Manager 1.7 or higher
 
 <p class="note"><strong>Note</strong>: You must install the IPsec add-on before installing any other tiles to enable
- the IPsec functionality. Pivotal recommends installing IPsec immediately after Ops Manager, and before installing the 
+ the IPsec functionality. Pivotal recommends installing IPsec immediately after Ops Manager, and before installing the
 Elastic Runtime tile. </p>
 
 <p class="note"><strong>Note</strong>: IPsec may affect the functionality of other service tiles. As a result, Pivotal recommends deploying Elastic Runtime and each service tile to different isolated subnets. Alternatively, you can minimally deploy all service tiles to a single isolated subnet, apart from the Elastic Runtime subnet.</p>
 
-<p class="note"><strong>Note</strong>: For IPsec, Pivotal recommends any Ubuntu stemcells for vSphere and OpenStack, and HVM stemcells for AWS. These stemcells are available on <a href="https://network.pivotal.io/products/stemcells">Pivotal Network</a>. If you are using PV stemcells obtained from <a href="https://bosh.io">bosh.io</a>, see <a href="./troubleshooting.html#ipsec-installation-issues">Preventing Packet Loss</a> in the Troubleshooting topic to adjust MTU values. Pivotal recommends MTU values of 1354 on OpenStack, and the default values on AWS and vSphere.</p> 
+<p class="note"><strong>Note</strong>: For IPsec, Pivotal recommends any Ubuntu stemcells for vSphere and OpenStack, and HVM stemcells for AWS. These stemcells are available on <a href="https://network.pivotal.io/products/stemcells">Pivotal Network</a>. If you are using PV stemcells obtained from <a href="https://bosh.io">bosh.io</a>, see <a href="./troubleshooting.html#ipsec-installation-issues">Preventing Packet Loss</a> in the Troubleshooting topic to adjust MTU values. Pivotal recommends MTU values of 1354 on OpenStack, and the default values on AWS and vSphere.</p>
 
 ##<a id="config-network"></a>Configure Network Security
 Refer to the appropriate section below for your IaaS network configuration details.
@@ -68,7 +68,7 @@ Confirm that your network allows protocols 50 and 51 and UDP on port 500.
 
 ###<a id="openstack"></a>OpenStack
 
-<p class="note"><strong>Note</strong>: The following network configuration is optimized for Mirantis OpenStack, but other OpenStack distributions have a similar workflow.</p> 
+<p class="note"><strong>Note</strong>: The following network configuration is optimized for Mirantis OpenStack, but other OpenStack distributions have a similar workflow.</p>
 
 For Mirantis OpenStack, follow these steps:
 
@@ -105,7 +105,7 @@ For Mirantis OpenStack, follow these steps:
 
 Follow these steps to create the IPsec manifest for your deployment:
 
-1. Create an IPsec manifest file `ipsec-addon.yml` starting with the code below as a template. 
+1. Create an IPsec manifest file `ipsec-addon.yml` starting with the code below as a template.
   <pre>releases:
   \- {name: ipsec, <strong>version</strong>: 1.0.0}<br>
   addons:
@@ -143,20 +143,20 @@ Follow these steps to create the IPsec manifest for your deployment:
           <strong>prestart\_timeout</strong>: 30 </pre>
 
 2. Replace the properties listed in the file as follows:
- * <code>releases: - version:</code> Specify the version number of your IPsec download from Pivotal Network. 
- * <code>jobs: - name:</code> Do not change the name of this job. It must be `ipsec`. 
+ * <code>releases: - version:</code> Specify the version number of your IPsec download from Pivotal Network.
+ * <code>jobs: - name:</code> Do not change the name of this job. It must be `ipsec`.
  * <code>ipsec\_subnets:</code> List the subnets that you want to be encrypted. You can include the entire deployment or a portion of the network. Encrypt any network that handles business-sensitive data.
  * <code>no\_ipsec\_subnets:</code> List the IP address of your BOSH director, and any other IPs in your PCF deployment that you want to communicate without encryption. Pivotal recommends that you list the subnets that are used for PCF managed services.
- * <code>instance\_certificate:</code> Paste in the signed certificate for use by all your instance VMs. You must use one of the CAs in the ca\_certificates property to sign this certificate. For a development or test environment, you can use a self-signed certificate. See the [Generate a Self-Signed Certificate](#self-signed) section. 
- * <code>instance\_private\_key:</code> Paste in the private key that corresponds to the instance\_certificate above. The key must not use a pass phrase. 
- * <code>ca\_certificates:</code> Paste in CA certificates for the instance VM to trust during the validation process. In most cases, you only need the CA certificate used to sign the instance certificate. During CA credential rotation, you need two CA certificates.  
+ * <code>instance\_certificate:</code> Paste in the signed certificate for use by all your instance VMs. You must use one of the CAs in the ca\_certificates property to sign this certificate. For a development or test environment, you can use a self-signed certificate. See the [Generate a Self-Signed Certificate](#self-signed) section.
+ * <code>instance\_private\_key:</code> Paste in the private key that corresponds to the instance\_certificate above. The key must not use a pass phrase.
+ * <code>ca\_certificates:</code> Paste in CA certificates for the instance VM to trust during the validation process. In most cases, you only need the CA certificate used to sign the instance certificate. During CA credential rotation, you need two CA certificates.
  * <code>prestart\_timeout:</code> You can optionally modify the 30 second default prestart timeout value. The value limits the number of seconds allowed for IPsec to start before failing the attempt.
 
 <p class="note"><strong>Note:</strong> To modify <code>ipsec_subnets</code> or <code>no_ipsec_subnets</code> in an existing deployment, you must update the manifest file and redeploy.</p>
 
-##<a id="download-deploy"></a>Download and Deploy the IPsec Add-on  
+##<a id="download-deploy"></a>Download and Deploy the IPsec Add-on
 
-1. Download the IPsec add-on software binary from the [Pivotal Network](https://network.pivotal.io/products/p-ipsec-addon) to your local machine. 
+1. Download the IPsec add-on software binary from the [Pivotal Network](https://network.pivotal.io/products/p-ipsec-addon) to your local machine.
 
 2. Copy the software binary to your Ops Manager instance.
 <pre class="terminal">$ scp -i PATH/TO/PRIVATE/KEY ipsec-release.tar.gz ubuntu@YOUR-OPS-MANAGER-VM-IP:</pre>
@@ -172,16 +172,16 @@ Follow these steps to create the IPsec manifest for your deployment:
 $ cd PATH-TO-BINARY</pre>
 
 6. Target your BOSH director instance with BOSH.<pre class="terminal">
-  $ bosh target YOUR-OPS-MANAGER-DIRECTOR-IP 
+  $ bosh target YOUR-OPS-MANAGER-DIRECTOR-IP
   Target set to 'Ops Manager'
   Your username: director
   Enter password: ******************
   Logged in as 'director'
-</pre> 
+</pre>
 
 7. Upload your release.<pre class="terminal">$ bosh upload release PATH-TO-BINARY/BINARY-NAME.tar</pre>
 
-8. Optionally, from the command line, confirm that the upload of the IPsec software binary completed. You should see the IPsec binary file.  
+8. Optionally, from the command line, confirm that the upload of the IPsec software binary completed. You should see the IPsec binary file.
 <pre class="terminal">$ bosh releases</pre>
 
 9. Update your runtime configuration to include the IPsec add-on.

release-notes.html.md.erb

@@ -5,9 +5,9 @@ owner: Security Engineering
 
 <strong><%= modified_date %></strong>
 
-This topic contains release notes for the Pivotal Cloud Foundry &reg; (PCF) IPsec add-on.
+This topic contains release notes for the Pivotal Cloud Foundry (PCF) IPsec add-on.
 
-##  v1.5.31 
+##  v1.5.31
 
 ### New Features
 
@@ -27,18 +27,18 @@ This topic contains release notes for the Pivotal Cloud Foundry &reg; (PCF) IPse
 
 	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. 
+* **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.
 	<br><br>
-	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. 
+	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.
 	<br><br>
 	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.
 	<br><br>
-	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). 
+	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).
 	<br><br>
 	Operators can use their favorite certificate management tool to confirm that their certificate matches what they expect. Using OpenSSL, one can issue the command:
 	<pre class="terminal">
 	$ openssl x509 -in myCA.crt -text
 	</pre>
-	If this command produces valid output, then the certificate will be OK when configured for IPsec. 
+	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.