8. IPSec

8.1. In This Chapter

This chapter provides information to configure security parameters. Topics in this chapter include:

  1. IPSec Overview
  2. Public Key Infrastructure (PKI)
  3. Best Practices Recommendations
  4. Configuration Notes
  5. Configuring IPSec with CLI
  6. IPSec Command Reference

8.2. IPSec Overview

This section contains the following topics:

  1. IPSec Implementation
  2. X.509v3 Certificate Overview
  3. Using Certificates For IPSec Tunnel Authentication
  4. Trust Anchor Profile
  5. Certificate Profile
  6. Certificate Management Protocol Version 2 (CMPv2)
  7. OCSP
  8. Applications
  9. NAT-Traversal for IKEv1/v2 and IPSec
  10. BFD over IPSec Tunnel
  11. QoS for IPSec
  12. Fragmentation and IP MTU
  13. Support for Private VPRN Service Features
  14. Routing in Private Services
  15. IPSec on the 10-port 1GigE/1-port 10GigE X-Adapter Card
  16. IPSec Sequence Number
  17. PBR and MFC
  18. OSPFv3 Packet Authentication with IPv6 IPSec
  19. Statistics
  20. Security Support

8.2.1. IPSec Implementation

This section contains the following topics:

  1. IPSec Overview
  2. Hardware Support
  3. IPSec Encryption Features
  4. SHA2 Support
  5. IPSec Security Policy, IKE Policy, and IPSec Transform
  6. Tunnel Group
  7. Tunnel Interfaces and SAPs
  8. IPSec Tunnel Configuration

8.2.1.1. IPSec Overview

IPSec is a structure of open standards to ensure private, secure communications over Internet Protocol (IP) networks by using cryptographic security services.

For IPSec, the 7705 SAR supports VPRN for the private side of the tunnel and IES for the public side of the tunnel. A public service instance (IES) connects to the public network and a private service instance (VPRN) connects to the private network, which originates the traffic that is to be encrypted (see Figure 116).

In Figure 116, all ingress customer traffic from the trusted network is aggregated into the private VPRN service, where a VPRN static route directs the traffic into the encryption engine. The encryption engine encrypts the customer traffic using configurable encryption and authentication protocols, and adds the IPSec tunnel outer IP header. The source IP address of the outer IP header is the local security gateway address, and the destination IP address is the peer security gateway address.

The encrypted IPSec packet exits the node via an IES or router interface that is configured on an encryption-capable adapter card; it gets routed to its destination via a standard FIB lookup.

On ingress from an untrusted network, all arriving IPSec traffic is routed to the appropriate security gateway as configured on the VPRN service. The incoming IPSec traffic is processed and checked against the tunnel security configuration.

If the traffic passes all security checks, it is decrypted and the customer traffic is routed through the associated VPRN. Any traffic that does not match the tunnel security configuration is dropped.

Figure 116:  IPSec Implementation Architecture 

IPSec messages can be routed over BGP or MPLS tunneled routes. The 7705 SAR supports resolution of IPSec routes to the secure gateway address by using either BGP 3107 label routes or IGP shortcuts. When BGP learns IPv4 addresses as 3107 label routes, BGP resolves the next hops for these routes with an LDP or RSVP-TE tunnel. These BGP routes create BGP tunnels that can be used to resolve an IPSec secure gateway address. When an IGP shortcut is enabled on the 7705 SAR by using the config>router>ospf>rsvp-shortcut command, OSPF installs an OSPF route in the RIB, with an RSVP-TE LSP as the next hop. If this OSPF route is determined as the overall best route, then the next hop is an RSVP-TE tunnel. For information about setting up BGP 3107 label routes or IGP shortcuts to resolve IPSec routes, see Configuring IPSec over MPLS.

8.2.1.2. Hardware Support

The 7705 SAR supports IPSec on the following nodes and adapter cards:

  1. 7705 SAR-8 with one of the following:
    1. 8-port Gigabit Ethernet Adapter card, version 3
    2. 6-port Ethernet 10Gbps Adapter card
    3. 2-port 10GigE (Ethernet) Adapter card
  2. 7705 SAR-18 with one of the following:
    1. 8-port Gigabit Ethernet Adapter card, version 3
    2. 10-port 1GigE/1-port 10GigE X-Adapter card, version 2
    3. 6-port Ethernet 10Gbps Adapter card
    4. 2-port 10GigE (Ethernet) Adapter card
  3. 7705 SAR-Ax
  4. 7705 SAR-H
  5. 7705 SAR-Hc
  6. 7705 SAR-W
  7. 7705 SAR-Wx
  8. 7705 SAR-X
Note:

On the 7705 SAR-X, each Ethernet port has its own encryption engine.

8.2.1.3. IPSec Encryption Features

IPSec provides a variety of encryption features required to establish bidirectional IPSec tunnels, including:

Control plane:

  1. manual keying
  2. dynamic keying: IKEv1, IKEv2
  3. IKEv1 mode: main or aggressive
  4. authentication: pre-shared-key (PSK)
  5. perfect forward secrecy (PFS)
  6. dead peer detection (DPD)
  7. NAT-traversal (NAT-T)
  8. security policy

Data plane:

  1. ESP (with authentication) tunnel mode
  2. IPSec transform (NULL cannot be used for authentication and encryption at the same time):
    1. authentication algorithm: NULL/MD5/SHA1/SHA256/SHA384/SHA512
    2. encryption algorithm: NULL/DES/3DES/AES128/AES192/AES256
  3. IPSec IKE policy (NULL is not supported):
    1. authentication algorithm: MD5/SHA1/SHA256/SHA384/SHA512
    2. encryption algorithm: DES/3DES/AES128/AES192/AES256
  4. DH-Group: 1/2/5/14/15
Note:

The 7705 SAR uses a configured authentication algorithm in an IKE policy for the pseudorandom function (PRF).

8.2.1.4. SHA2 Support

The 7705 SAR supports RFC 4868. For data origin authentication and integrity verification functions in the IKEv1 or IKEv2 and Encapsulating Security Payload (ESP) protocols, the 7705 SAR supports the following HMAC-SHA-256+ algorithms:

  1. AUTH_HMAC_SHA2_256_128
  2. AUTH_HMAC_SHA2_384_192
  3. AUTH_HMAC_SHA2_512_256

For pseudorandom functions (PRF) with IKEv1 or IKEv2, the 7705 SAR supports the following HMAC-SHA-256+ algorithms:

  1. PRF_HMAC_SHA2_256_128
  2. PRF_HMAC_SHA2_384_192
  3. PRF_HMAC_SHA2_512_256

8.2.1.5. IPSec Security Policy, IKE Policy, and IPSec Transform

An IPSec security policy defines the type of traffic allowed to pass in or out of an IPSec tunnel. The policy does this through the configuration of local and remote IP address pairs. The behavior of an IPSec security policy is similar to IP filtering. IPSec security policies are created for a VPRN service context and applied to an IPSec tunnel in that service.

An IKE policy defines how the 7705 SAR encrypts and authenticates an IPSec tunnel that uses that policy. Its configuration includes specifics on Diffie-Hellman key derivation algorithms, encryption and authentication protocols to be used for establishing phase 1 and phase 2 security associations, and so on.

An IPSec transform defines the algorithms used for IPSec SA. The transform configuration dictates the algorithms that customer traffic uses for encryption and authentication.

8.2.1.6. Tunnel Group

A tunnel group is a collection of IPSec tunnels. The 7705 SAR supports one tunnel group that always uses tunnel ID 1.

An IPSec tunnel belongs to only one tunnel group. The show>isa>tunnel-group command allows the operator to view information about the configured tunnel group.

8.2.1.7. Tunnel Interfaces and SAPs

There are two types of tunnel interfaces and associated SAPs:

  1. public tunnel interface: configured in the public IES service; outgoing tunnel packets have a source IP address (local gateway address) in this subnet
    1. public tunnel SAP: associated with the public tunnel interface
  2. private tunnel interface: configured in the private VPRN service
    1. private tunnel SAP: associated with the private tunnel interface, logically linked to the public tunnel SAP

8.2.1.7.1. Public Tunnel SAPs

An IES service (the delivery service) must have at least one IP interface associated with a public tunnel SAP to receive and process the following types of packets associated with IPSec tunnels:

  1. IPSec ESP (IP protocol 50)
  2. IKEv1/v2 (UDP)

The public tunnel SAP type has the format tunnel-tunnel-group-id.public:tag, where tunnel-group-id is always 1. See Configuring IPSec and IPSec Tunnels in Services for a CLI configuration example.

8.2.1.7.2. Private Tunnel SAPs

The private (VPRN) service must have an IP interface to an IPSec tunnel in order to forward IP packets into the tunnel, causing them to be encapsulated according to the tunnel configuration, and to receive IP packets from the tunnel after the encapsulation has been removed (and decrypted). That IP interface is associated with a private tunnel SAP.

The private tunnel SAP has the format tunnel-tunnel-group-id.private:tag, where tunnel-group-id is always 1. The tunnel keyword must be used when creating the private tunnel interface. See Configuring IPSec and IPSec Tunnels in Services for a CLI configuration example.

8.2.1.7.3. IP Interface Configuration

The IP MTU of a private tunnel SAP interface can be configured. This sets the maximum payload IP packet size (including IP header) that can be sent into the tunnel and applies to the packet size before the tunnel encapsulation is added. When an IPv4 payload packet that needs to be forwarded to the tunnel is larger than M bytes, one of the following behaviors occurs.

  1. If the DF bit is clear (not set), the payload packet is fragmented to the MTU size prior to tunnel encapsulation.
  2. If the DF bit is set, the payload packet is discarded and (if allowed by the ICMP setting of the sending interface) an ICMP type 3/code 4 is returned to the sender (with the MTU of the private tunnel SAP interface in the payload).

8.2.1.8. IPSec Tunnel Configuration

To bind an IPSec tunnel to a private tunnel SAP, the ipsec-tunnel command is configured under the SAP context, where the ipsec-tunnel context provides access to the following parameters:

    security-policy 1
    local-gateway-address 80.22.22.2 peer 80.11.11.2 delivery-service 21
    dynamic-keying
    ike-policy 1
    pre-shared-key "nokia"
    transform 1

The local gateway address must belong to the same subnet as the delivery-service (IES) public tunnel interface address. The local gateway address and peer gateway address are the source and destination addresses for the outgoing IPSec traffic.

A private tunnel SAP can have only one IPSec tunnel.

8.2.2. X.509v3 Certificate Overview

X.509v3 is an ITU-T standard that consists of a hierarchical system of certificate authorities (CAs) that issue certificates that bind a public key to particular entity’s identification. The entity’s identification could be a distinguished name or an alternative name, such as a fully qualified domain name (FQDN) or an IP address.

An end entity (EE) is an entity that is not a CA. For example, an end entity can be a web server, a VPN client, or a VPN gateway.

A CA issues a certificate by signing an entity’s public key with its own private key. A CA can issue certificates for an end entity as well as for another CA. When a CA certificate is issued for itself (signed by its own private key), this CA is called the root CA. Therefore, an end entity’s certificate can be issued by the root CA or by a subordinate CA (that is, issued by another subordinate CA or root CA). When there are multiple CAs involved, this is called a chain of CAs.

In addition to issuing certificates, the public key infrastructure (PKI) also includes a mechanism for revoking certificates due to reasons such as a compromised private key.

A certificate can be used for authentication. Typically, the certificate authentication process functions as follows.

  1. The system trusts a CA as the trust anchor CA (which typically is a root CA). This means that all certificates issued by a trust anchor CA, or the certificates issued by a subordinate CA that have been issued by the trust anchor CA, are consider trusted.
  2. A peer that is to be authenticated presents its certificate along with a signature over some shared data between the peer and system, and the certificate is signed using a private key.
  3. The signature is verified by using the public key in the certificate. In addition, the certificate itself is verified as being issued by the trust anchor CA or a subordinate CA that is part of the chain leading up to the trust anchor CA. The system can also check if the peer’s certificate has been revoked. Only when all these verifications succeed does the certificate authentication succeed.

8.2.2.1. X.509v3 Certificate Support on the 7705 SAR

The 7705 SAR PKI implementation supports the following features:

  1. certificate enrollment:
    1. locally generated RSA/DSA key
    2. offline enrollment via PKCS#10 (public key cryptography standards)
    3. online enrollment via CMPv2
  2. support for CA chain
  3. certificate revocation check:
    1. certificate revocation list (CRL) for both EE and CA certificates
    2. online certificate status protocol (OCSP) for EE certificate only

8.2.2.2. Local Storage

The 7705 SAR requires the following objects to be stored locally as a file:

  1. CA certificate
  2. CRL
  3. the system’s own certificate
  4. the system’s own key

All these objects must be imported with the admin certificate import command before they can be used by the 7705 SAR. The import process converts the format of the input file to distinguished encoding rules (DER), encrypts the key file, and saves it in the cf3:/system-pki directory.

The imported file can also be exported using a specified format by means of the admin certificate export command.

The admin certificate import and admin certificate export commands support the following formats:

  1. certificates can be imported and exported using the following formats:
    1. PKCS #12
    2. PKCS #7 (DER and PEM) (privacy enhanced mail)
    3. PEM
    4. DER
    If there are multiple certificates in the file, only the first one is used.
  2. key pairs can be imported and exported using the following formats:
    1. PKCS #12
    2. PEM
    3. DER
  3. the CRL can be imported and exported using the following formats:
    1. PKCS #7 (DER and PEM)
    2. PEM
    3. DER
  4. The PKCS #12 file can be encrypted with a password.

8.2.2.3. CA Profile

On the 7705 SAR, the CA-related configuration is stored in a CA profile that contains the following configurable items:

  1. name and description
  2. CA’s certificate — an imported certificate
  3. CA’s CRL— an imported CRL
  4. revocation check method — specifies the way the CA checks the revocation status of the certificate it issued
  5. CMPv2 — a CMPv2 server-related configuration
  6. OCSP— an OCSP responder-related configuration

When a user enables a ca-profile (no shutdown), the system loads the specified CA certificate and CRL into memory. The following checks are performed:

  1. for the CA certificate:
    1. all mandatory fields defined in section 4.1 of RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, exist and conform to the RFC 5280 defined format
    2. the version field value is 0x2
    3. the validity field indicates that the certificate is still in its validity period
    4. the X.509 Basic Constraints extension exists and the CA Boolean value is true
    5. if the Key Usage extension exists, at the least), the keyCertSign and cRLSign are asserted
  2. for the CRL:
    1. all mandatory fields defined in section 5.1 of RFC 5280 exist and conform to the RFC 5280 defined format
    2. if the version field exists, the value is 0x1
    3. the delta CRL indicator does not exist (delta CRL is not supported)
    4. the CRL is signed by the configured CA certificate

The CRL is required in order to enable ca-profile.

8.2.2.4. CA Chain Computation

When verifying a certificate with a CA or a chain of CAs, the system must identify the issuer CA of the certificate. The 7705 SAR looks through all configured CA profiles to find the issuer CA. The following is the method that the system uses to find the issuer CA:

  1. the issuer CA’s certificate subject must match the issuer field of the certificate in question
  2. if present, the authority key identifier of the certificate in question must match the subject key identifier of the issuer CA’s certificate
  3. if present, the key usage extension of the issuer CA’s certificate must permit certificate signing

8.2.2.5. Certificate Enrollment

The 7705 SAR supports two certificate enrollment methods:

  1. the offline method using PKCS #10
  2. the online method using CMPv2

To use the offline method, perform the following steps:

  1. Generate a key pair using the admin certificate gen-keypair command.
    For example: admin certificate gen-keypair cf3:/segw.key size 2048 type rsa
  2. Generate a PKCS#10 certificate signing request with the key generated in Step 1 using the admin certificate gen-local-cert-req command.
    For example: admin certificate gen-local-cert-req keypair cf3:/segw.key subject-dn C=US,ST=CA,O=ALU,CN=SeGW domain-name segw-1.alu.com file cf3:/segw.pkcs10
    As well as specifying the subject of the certificate request, you can optionally specify an FQDN and an IP address as SubjectAltName.
  3. Import the key file using the admin certificate import command.
    Example: admin certificate import type key input cf3:/segw.key output segw.key format der
  4. Because the key is imported, remove the key file generated in Step 1 for security reasons.
  5. Send the PKCS #10 file to the CA via an offline method such as email.
    The CA signs the request and returns the certificate.
  6. Import the returned certificate using the admin certificate import command.
    Example: admin certificate import type cert input cf3:/segw.cert output segw.cert format pem

For the online method using CMPv2-based enrollment, see the Certificate Management Protocol Version 2 (CMPv2).

8.2.2.6. Certificate Revocation Check

A revocation check is a process that checks whether a certificate has been revoked by the issuer CA.

The 7705 SAR supports two methods for the certificate revocation check:

  1. CRL
  2. OCSP

The CRL can be used for both EE and CA certificate checks, while OCSP can only be used for an EE certificate check.

For an IPSec application, users can configure multiple check methods with a priority order for an EE certificate. Using the status-verify command in the ipsec-tunnel configuration context, users can configure a primary method, a secondary method, and a default result. The primary and secondary methods can be either OCSP or CRL. The default result is either good or revoked. If the system does not get an answer from the primary method, it falls back to the secondary method. If the secondary method does not return an answer, the system uses the default result.

By default, the system uses the CRL to check the revocation status of a certificate, whether it is an end entity certificate or a CA certificate. This makes the CRL a mandatory configuration in the ca-profile.

For details about OCSP, see OCSP.

8.2.2.7. Certificate, CRL, and Key Cache

Configured certificates, CRLs, and keys are cached in memory before they are used by the system.

Every certificate, CRL, and key has one system-wide cache copy.

For a CA certificate and a CRL, the cache is created when there is a CA profile and when a no shutdown is performed and removed.

For an IPSec tunnel using legacy cert and key configurations, the cache is created only when the first tunnel using the cache is in a no shutdown state, and it is cleared when the last tunnel that used it is shut down.

For an IPSec tunnel using a cert-profile, the cache is created when the first cert-profile using the cache is in a no shutdown state, and it is removed when the last cert-profile that used it is shut down.

If a certificate or key is configured with both a cert-profile and legacy cert or key command, the cache is created when the first object (an ipsec-tunnel or a cert-profile) using it is in a no shutdown state, and it is removed when the last object using it is shut down.

In order to update a certificate or key without a shutdown ca-profile or ipsec-tunnel, the CLI command admin>certificate>reload manually reloads the certificate and key cache.

8.2.3. Using Certificates For IPSec Tunnel Authentication

The 7705 SAR supports X.509v3 certificate authentication for an IKEv2 tunnel (LAN-to-LAN tunnel and remote-access tunnel). The 7705 SAR also supports asymmetric authentication. This means that the 7705 SAR and the IKEv2 peer can use different methods to authenticate. For example, one side of the tunnel could use a pre-shared key and the other side could use a certificate.

The 7705 SAR supports certificate chain verification. For a static LAN-to-LAN tunnel, the command trust-anchor-profile specifies which CAs are expected to be present in the certificate chain before reaching the root CA (self-signed CA) configured in the system.

The key and certificate for the 7705 SAR are also configurable on a per-tunnel basis.

When using certificate authentication, the 7705 SAR uses the subject of the configured certificate as its ID by default.

8.2.4. Trust Anchor Profile

The 7705 SAR supports multiple trust anchors for each IPSec tunnel. A trust anchor profile can be configured with up to eight CAs. The system builds a certificate chain by using the certificate in the first certificate payload in the received IKEv2 message. If any of the configured trust anchor CAs in the trust anchor profile appear in the chain, then authentication is successful; otherwise, authentication fails.

Note:

The 7705 SAR only supports processing of up to 16 hashes for the trust anchor list from other products. If the remote end sends more than 16 hashes and a certificate match is in the 17th or later hash, the tunnel remains down due to authentication failure.

8.2.5. Certificate Profile

The 7705 SAR supports sending different certificates and chains according to the received IKEv2 certificate-request payload. This is done by configuring a cert-profile that allows up to eight entries. Each entry includes a certificate and a key and, optionally, a chain of CA certificates.

The system loads the certificate and/or key in the cert-profile into memory and builds a compare-chain for the certificate configured in each entry of the cert-profile upon a no shutdown of the cert-profile. These chains are used for IKEv2 certificate authentication. If a chain computation cannot be completed for a configured certificate, the corresponding compare-chain will be empty or only partially computed.

Because there can be multiple entries configured in the cert-profile, the system must pick the certificate and key in the entry that the other side expects to receive. This is done by looking up the CAs within the received certificate request payload in the compare-chain and picking the first entry that has a certificate request CA appearing in its chain. If there is no such cert, the system picks the first entry in the cert-profile. The first entry is the first configured entry in the cert-profile. The entry-id of the first entry does not have to be “1”.

For example, assume there are three CAs listed in the certificate-request payload: CA-1, CA-2 and CA-3, and there are two entries configured in the cert-profile, as shown in the following configuration:

cert-profile “cert-profile-1”
  entry 1
    cert “cert-1”
    key “key-1”
  entry 2
    cert “cert-2”
    key “key-2”
    send-chain
      ca-profile “CA-1”
      ca-profile “CA-2”
 

The system builds two compare-chains: chain-1 for cert-1 and chain-2 for cert-2. Assume CA-2 appears in chain-2, but CA-1 and CA-3 do not appear in either chain-1 or chain-2. In that case, the system will pick entry 2.

After a certificate profile entry is selected, the system generates the AUTH payload by using the configured key in the selected entry. The system also sends the certificate in the selected entry as “certificate” payload to the peer.

If a chain is configured in the selected entry, then one certificate payload is needed for each certificate in the configured chain. The first certificate payload in the IKEv2 message will be the signing certificate, which is configured by the cert command in the chosen cert-profile entry. In the preceding example, the system will send three certificate payloads: cert-2, CA-1, and CA-2.

The following CA chain-related enhancements are supported.

  1. The no shutdown of a ca-profile triggers a recomputation of the compute-chain in related certificate profiles. The system also generates a new log-1 to indicate that a new compute-chain has been generated; the log includes the CA profile names on the new chain. Another log, log-2, is generated if the send-chain in a cert-profile entry is not in a compute-chain due to this CA profile change. Another log is generated if the hash calculation for a certificate under a ca-profile has changed.
  2. When performing a no shutdown command on a cert-profile, the system allows the CAs in the send-chain, not in the compute-chain. The system also generates log-2, as above.
  3. The system allows changes to the configuration of the send-chain without shutting down cert-profile.

8.2.6. Certificate Management Protocol Version 2 (CMPv2)

CMPv2 is a protocol between a Certificate Authority (CA) and an end entity (EE) based on RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP). It provides multiple certificate management functions, such as certificate enrollment, certificate update, and so on.

The 7705 SAR supports the following CMPv2 operations:

  1. initial registration — the process by which the 7705 SAR enrolls a certificate with a certain CA for the first time, where:
    1. a public/private key pair must be pre-provisioned before enrollment by means of local generation or other methods
    2. optionally, users can include a certificate or certificate chain in the extraCerts field of the initial registration request
  2. key pair update — a process by which the 7705 SAR updates an existing certificate for any reason (for example, a refresh of a key or certificate before it expires)
  3. certificate update — a process by which an initialized 7705 SAR obtains additional certificates
  4. polling — in some cases, the CA may not immediately return the certificate for reasons such as “request processing needs manual intervention”. In such cases, the 7705 SAR supports polling requests and responds as described in Section 5.3.22, Polling Request and Response, in RFC 4210.

The following list provides implementation details.

  1. HTTP is the only supported transport protocol for CMPv2. HTTP 1.1 and 1.0 are supported and configurable.
  2. All CMPv2 messages sent by the 7705 SAR consist of only one PKI message. In all cases, the size of the sequence for PKI messages is 1.
  3. Both password-based MAC and public key-based signature CMPv2 message protection are supported.
  4. The 7705 SAR only allows one outstanding ir/cr/kur request for each CMPv2 server. The means that no new requests are allowed if a pending request is present.

8.2.7. OCSP

The Online Certificate Status Protocol (OCSP) is used by 7705 SAR applications to determine the revocation state of an identified certificate, based on RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Unlike the CRL, which relies on checking against an offline file, OCSP provides timely, online information regarding the revocation status of a certificate.

IPSec is the only supported application that uses OCSP. The 7705 SAR supports both the CRL and OCSP as the certificate revocation status checking method. For a given IPSec tunnel, the user can configure a primary method, a secondary method, and a default result to achieve a hierarchical fallback mechanism. If the primary method fails to return a result, the system falls back to the secondary method. If the secondary method fails, the system uses the default result.

The following list provides implementation details.

  1. Only an OCSP client function is supported.
  2. HTTP is the only supported transport protocol.
  3. OCSP server access via a management routing instance is not supported.
  4. The 7705 SAR does not sign an OCSP request.
  5. The OCSP response must be signed. The system will verify the response by using the signer’s certificate included in the response. If there is no such certificate, the CA certificate in the ca-profile will be used.
  6. If a nextUpdate exists in the OCSP response, the 7705 SAR checks the current time to determine if it is earlier than the nextUpdate. If yes, then the response is valid; otherwise, the response is considered unreliable and the 7705 SAR moves to the next revocation checking method.
  7. The revocation status result from a valid OCSP response is cached in the system.
  8. OCSP can only be used to verify the revocation status of the EE certificate. The CRL is still needed to verify the status of a CA certificate.

8.2.8. Applications

Two mobile backhaul applications are described in this section:

  1. Metrocell Deployment: a solution for providers who are looking for security in the transmission medium to manage remote private networks in a metrocell deployment. IPSec is used as an encrypted uplink for OAM and mobile traffic to connect the remote network to the MTSO. The 7705 SAR-initiated IPSec tunnels can provide a secure means for managing the 7705 SAR and any private network behind the 7705 SAR, while NAT can provide scalability of IPSec tunnels over a single public IP address.
  2. Small Business Deployment: the use of LTE and IP NodeBs, as an alternative to PWs, to provide a better match for an operator’s choice of transport network (that is, IPSec over public network compared to MPLS/PWs over a private network)

8.2.8.1. Metrocell Deployment

As shown in Figure 117, in a typical metrocell deployment, the cell site network is divided into two separate segments: the private domain and the public domain. An IPSec tunnel generated from the 7705 SAR-H is used to backhaul the management and OAM traffic of the private network, including the management traffic of the switches and the 7705 SAR-H itself. All OAM traffic is aggregated within a VPRN service and uses the IPSec tunnel as the uplink tunnel to the 7750 SR gateway.

Figure 117:  Typical Metrocell Deployment 

8.2.8.2. Small Business Deployment

In a small business deployment, the network is usually designed with a hub and spoke topology. The spoke sites connect to the hub through a leased line or a public non-secure domain. IPSec provides the security and encryption needed to connect the spoke sites to the centralized office (hub). The hub and spoke topology in a small business deployment is favorable because of the security that the hub side can provide to the entire network. IPS/IDS and anti-virus appliances can be deployed to the hub site, which examines arriving traffic from the spoke sites. SPAM and viruses can be filtered out on the hub site by these appliances. If additional spoke-to-spoke connectivity is required, then additional IPSec tunnels can be established. See Figure 118.

Figure 118:  Typical Small Business Deployment 

8.2.9. NAT-Traversal for IKEv1/v2 and IPSec

The 7705 SAR supports NAT-T (Network Address Translation-Traversal) for IKEv1 and IKEv2. NAT-T is functionality belonging to IPSec and IKEv1/v2. It is not functionality belonging to the NAT device.

In a private network where the entire network is hidden behind a single public IP address, NAT-T for IPSec is used to support the fan-out of multiple IPSec tunnels in the private network.

IPSec is an IP protocol and as such does not use ports. Figure 119 illustrates how the UDP header is injected into the packet as well as the many-to-one to one-to-many mappings. NAT relies on port mapping, so in order to allow traversal of a NAT device, NAT-T adds a UDP header with port 4500 to the IPSec traffic when the NAT device is detected. The UDP header is added to the IPSec packet above the ESP header and IKEv1/v2 already uses UDP port 500. This UDP header can be used by the NAT device to uniquely map each IPSec tunnel and assign a different source port to each individual tunnel. That is, many IP addresses using UDP 4500 lead to a NAT mapping where a single public IP address uses many UDP ports.

In Figure 119, the 7750 SR performs the following functions:

  1. tracks the different metrocell IKEv2 port-to-session mappings
  2. tracks the different metrocell IPSec port-to-tunnel mappings
  3. transmits traffic to each metrocell on the appropriate UDP port
Figure 119:  UDP Header Injected by a NAT-T-enabled IPSec Tunnel 

8.2.10. BFD over IPSec Tunnel

To configure BFD for an IPSec tunnel, do the following:

  1. configure BFD on a loopback interface in the private VPRN
  2. configure at least two IPSec tunnels:
    1. one tunnel is a BFD-designate tunnel over which BFD packets are exchanged; this BFD-designate tunnel does not go down when BFD goes down
    2. the other tunnels are tunnels that use the BFD-designate tunnel’s BFD session; these tunnels go down when BFD goes down
  3. configure a static route in the private VPRN, where the static route points to the destination node’s private-side loopback interface, using the BFD-designate tunnel as the next hop
  4. configure BFD under the BFD-designate tunnel using the loopback interface and point to the far-end loopback address
  5. configure BFD under the protected tunnels also using the loopback interface (same configuration as under the BFD-designate tunnel)

8.2.11. QoS for IPSec

This section contains information on the following topics:

  1. Network and Access Ingress QoS (Decryption QoS)
  2. Network and Access Egress QoS (Encryption QoS)

8.2.11.1. Network and Access Ingress QoS (Decryption QoS)

IPSec traffic arriving on network ingress is classified based on network policy and network queue policy when the uplink interface is a network interface (refer to the 7705 SAR OS Quality of Service Guide). This classification is done based on the DSCP marking of the IPSec outer IP header.

The IPSec (encrypted) traffic destined for the secure gateway (SeGW) of the 7705 SAR is mapped to two queues (expedited and best effort) of the decryption engine on the ingress adapter card. This means that encrypted traffic is mapped to the decryption queue.

The encrypted traffic is mapped to one of these two queues based on the queue-type of its mapped network ingress queue, as determined by the result of the network ingress classification. For example, at network ingress, the QoS network policy determines a forwarding class (FC) for the packet. Then, the network-ingress queue policy maps the FC to a queue. The configured queue-type of network-ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the ingress adapter card (where the uplink interface resides).

The uplink interface for the SeGW can be configured as a network interface or as an access IES interface. For an access IES interface, the decryption-queue mapping is based on the queue-type of the access ingress queue of the IES interface SAP. For example, at IES ingress, the SAP ingress policy determines a forwarding class (FC) for the packet. The FC is mapped to a SAP ingress queue. The queue-type of this SAP ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the ingress adapter card where the IES interface SAP resides.

The decrypted customer traffic with removed IPSec tunnel header is queued on network and access ingress queues (the uplink interface can be a network interface or an IES interface) based on the network and access ingress policy, and the DSCP bits of the IPSec outer IP header are used for the classification.

8.2.11.1.1. Network Ingress QoS Tunnel Override

When a network QoS policy is enabled on an ingress network interface, IPSec packets arriving at that interface are assigned to encryption queues based on the IPSec outer IP header. However, if the QoS network policy of the arriving network interface is configured with ler-use-dscp, then after decryption, all the datapath or firewall queuing is based on the DSCP marking of the IPSec inner IP header rather than on the DSCP marking of the IPSec outer IP header. For more information about the ler-use-dscp command, refer to the 7705 SAR OS Quality of Service Guide, “QoS Policy Network Commands”.

8.2.11.2. Network and Access Egress QoS (Encryption QoS)

Customer packets arriving on access ingress in the VPRN are classified based on the SAP ingress policy (refer to the 7705 SAR OS Quality of Service Guide).

Customer packets arriving in the VPRN that are destined for the IPSec tunnel are enqueued before the encryption engine on the egress adapter card. There are three queues servicing the encryption engine on the egress adapter card (expedited, best effort, and CTL).

All CSM traffic over IPSec (BFD, ping, and so on) is queued in the CTL queue, while data (customer) traffic is mapped to the expedited or best-effort queue.

The customer traffic to the two data queues is mapped based on the queue-type of the ingress SAP queue. For example, at access VPRN SAP ingress, the ingress SAP policy determines a forwarding class (FC) for the packet. The FC is mapped to a SAP ingress queue. The queue-type of the SAP ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the egress adapter card (where the uplink interface resides).

Note:

If DSCP egress re-marking is configured on the network interface or access interface (uplink interface), DSCP bits are re-marked on the IPSec outer IP header.

8.2.12. Fragmentation and IP MTU

On the 7705 SAR, unencrypted IP packets arriving on a VPRN access interface and destined for an IPSec uplink will be fragmented if the incoming packet is larger than:

  1. the VPRN private interface MTU
  2. the IPSec tunnel MTU
  3. the difference between the uplink MTU and the IPSec overhead (uplink interface MTU minus IPSec overhead), where the IPSec overhead values are calculated as follows:
    1. IPSec overhead if NAT-T is enabled
      IPSec overhead = outer IPSec (20) + UDP (8) + ESP (24) + trailer (17) +  ICV (32) = 101 bytes
    2. IPSec overhead if NAT-T is disabled (no nat-t)
      IPSec overhead = outer IP (20) + ESP (24) + trailer (17) + ICV (32) = 93 bytes

For example, if a private tunnel interface has its IP MTU set to 1000 bytes, then a packet larger than 1000 bytes will be fragmented. As another example, if an uplink interface has its IP MTU set to 1000 bytes, then a packet that is larger than 1000 – IPSec overhead will be fragmented. Both these examples assume that the DF bit is not set or the clear-df-bit command is enabled.

8.2.12.1. Fragmentation Configuration

By default, the 7705 SAR sets the DF bit on the IPSec tunnel IP header.

There are some configurations where the customer IP header DF bit needs to be copied into the IPSec tunnel IP header. The copy-df-bit command under the config>service>vprn>if>sap>ipsec-tunnel context enables copying the customer clear text IP header DF bit into IPSec tunnel IP header.

The clear-df-bit command, also under the ipsec-tunnel context, clears the customer clear text IP header DF bit (if it is set). This allows the customer packet to be fragmented into the IPSec tunnel even if the customer packet has the DF bit set. However, the fragmented customer clear text packet is not be reassembled at the far end of IPSec tunnel.

8.2.12.2. Reassembly

The 7705 SAR does not support reassembly of fragmented IPSec packets.

8.2.13. Support for Private VPRN Service Features

Private VPRN access features are only supported on non-IPSec interfaces. That is, they are only supported for Layer 3 interfaces that are not configured with a private IPSec tunnel.

Some of these features include r-VPLS, VRRP, ECMP, and LAG. See VPRN Services for information on these features.

8.2.14. Routing in Private Services

For static LAN-to-LAN tunnels, the static route with the IPSec tunnel as the next-hop could be exported to a routing protocol by a route policy. The protocol type remains static.

8.2.15. IPSec on the 10-port 1GigE/1-port 10GigE X-Adapter Card

The 10-port 1GigE/1-port 10GigE X-Adapter card has two encryption engines that share the encryption/decryption load. Therefore, the 10-port 1GigE/1-port 10GigE X-Adapter card has the potential for double the encryption/decryption throughput when compared with other adapter cards and nodes with a single encryption engine (the 8-port Gigabit Ethernet Adapter card, 7705 SAR-Ax, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-W, 7705 SAR-Wx, and 7705 SAR-X).

To utilize the potential of the 10-port 1GigE/1-port 10GigE X-Adapter card, the IPSec security associations (SAs) are load-balanced between the two engines based on a round-robin algorithm. When there is an SA download to the 10-port 1GigE/1-port 10GigE X-Adapter card, the upper-layer software load-balances the SA on the two engines.

8.2.16. IPSec Sequence Number

The IPSec sequence number is used to prevent replay attacks. A replay attack is a network attack in which valid data transmission is repeated or delayed for fraudulent purposes. The 7705 SAR supports a 32-bit sequence number, where the transmission of each packet increments the sequence number. If there is a sequence number rollover, the 7705 SAR performs the rollover by resignaling the phase-2 IKE negotiation.

8.2.17. PBR and MFC

Both PBR (policy-based routing) and MFC (multi-field classification) are part of the ingress ACL (access control list) configuration on the 7705 SAR. Hence, both PBR and MFC are supported by IPSec on the 7705 SAR, as discussed below:

  1. PBR
  2. MFC

8.2.17.1. PBR

PBR configuration can be applied in two places for an IPSec service.

The first place is for VPRN and applies to all incoming access traffic into a private VPRN. In this case, PBR can be used to direct the customer traffic into uplink IPSec tunnels by means of ACL matching criteria. The filtering action of forwarding to an indirect next hop can be used to direct customer traffic into the appropriate IPSec tunnel. The security policy works only on the original (customer packet) IP header; that is, the PBR next hop is not used in making the security policy decision.

The second place is for IPSec traffic entering the 7705 SAR from the public domain. A PBR filter can be placed on the network interface or the IES interface to direct the IPSec packet based on the matching/forwarding criteria. In this case, IPSec packets are processed by the PBR filter in the same way as any other IP packet.

For more information on PBR, refer to the “Policy-Based Routing” section in the 7705 SAR OS Router Configuration Guide.

Note:

  1. All routing decisions are made based on the PBR configuration; therefore, it is possible that even if the packet is destined for the local node security gateway (SeGW), the PBR filter might redirect the packet to another interface.
  2. Alternatively, for IPSec packets that are not destined for the local node SeGW, PBR can force the packets into the local node SeGW. In this case, the encapsulating security payload (ESP) index of the IPSec packet will not match the SeGW ESP configuration and the packet will be dropped. Thus, it is the responsibility of the network administrator to ensure that the PBR configuration is correct and meets the network needs.

8.2.17.2. MFC

Multi-field classification (MFC) is supported on the private IPSec service (VPRN). MFC functions in the same manner as the VPRN configuration of traditional services.

For more information on MFC, refer to the “Multi-field Classification” section in the 7705 SAR OS Router Configuration Guide.

8.2.18. OSPFv3 Packet Authentication with IPv6 IPSec

The 7705 SAR supports the use of IPv6 IPSec to authenticate OSPFv3 packets. The following features are supported:

  1. two types of encryption and authentication protocols: authentication header (AH) and IP encapsulation security payload (ESP)
  2. IPSec transport mode to authenticate the IP payload
  3. manually keyed IPSec security associations (SA)
  4. the MD5 and SHA1 authentication algorithms

In order to be authenticated, OSPFv3 peers must be configured with matching inbound and outbound SAs using the same parameters (for example, SPIs and encryption keys). One SA can be used for both inbound and outbound directions.

Authentication of OSPFv3 packets is supported on VPRN interfaces, network interfaces, and virtual links.

The 7705 SAR supports the rekeying procedure defined in RFC 4552, Authentication/Confidentiality for OSPFv3.

  1. For every router on the link, create an additional inbound SA for the interface being rekeyed using a new SPI and the new key.
  2. The SA replacement operation is atomic, meaning that no OSPFv3 packets are sent on the link until the replacement operation is complete. This ensures that no packets are sent without authentication or encryption.
  3. For every router on the link, remove the original inbound SA.

The key rollover procedure automatically starts when the operator changes the configuration of the inbound static security association or bidirectional static security association under an interface or virtual link. Within the KeyRolloverInterval time period, OSPFv3 accepts packets with both the previous inbound static SA and the new inbound static SA; the previous outbound static SA will continue to be used. When the timer expires, OSPFv3 will only accept packets with the new inbound static SA. For outgoing OSPFv3 packets, the new outbound static SA will be used instead.

8.2.19. Statistics

All statistics for security association and tunnel statistics on the 7705 SAR are retrieved from the datapath on demand. When the user requests the statistics for a tunnel, the statistics are retrieved directly from the datapath; the retrieved statistics are not cached on the 7705 SAR. This means that on redundant platforms (that is, on the 7705 SAR-8 or 7705 SAR-18), statistics will not synchronize over to the inactive CSM, and at the time of a CSM switchover, all statistics will be lost. Also, in the case of statistics rollover in the datapath, the newly retrieved statistics will start from 0 (zero) again.

8.2.20. Security Support

IPSec on the 7705 SAR requires a public service (IES or VPRN) and a private service (VPLS). All IPSec traffic on the public service is encrypted. By the time the traffic is routed to the private service, it has been decrypted and can be examined by the 7705 SAR firewall engine.

The public interface of IPSec service is a secure gateway (SeGW). Because packets arriving on and leaving this interface are encrypted with an IPSec header, they are not firewalled. However, NAT can be applied to traffic traversing the public interface of IPSec security zones.

After being decrypted, the customer traffic may traverse a second security zone configured within the VPRN, to sanitize any of these packets according to the firewall rules. This security zone can be extended to have NAT performed on the customer clear text packets.

For more information about configuring security parameters, refer to the 7705 SAR OS Router Configuration Guide, “Configuring Security Parameters”.

8.3. Public Key Infrastructure (PKI)

Public Key Infrastructure (PKI) is a cryptographic technique that enables users to securely communicate on an insecure public network, and reliably verify and authenticate the identity of a user through the use of digital signatures.

PKI is a system for creating, storing, and distributing digital certificates, which are used to verify that a particular public key belongs to a particular entity. PKI creates digital certificates that map public keys to entities and securely stores these certificates in a central repository, revoking them as needed.

PKI includes the following components:

  1. X.509v3 identity certificates
  2. a certificate authority (CA), which has the following properties:
    1. has a secure server
    2. can sign and publish X.509v3 certificates
    3. is trusted by all users of the system
  3. public/private key pairs
  4. the ability to be deployed as flat architecture or hierarchical architecture (chained certificates)

8.3.1. CA Role in PKI

The role of a CA in PKI includes the following items.

  1. The CA is a trusted third-party organization or company that issues digital certificates.
  2. The CA may or may not be a third party from the end entity’s (EE’s) point of view.
  3. The CA often belongs to the same organization as the EEs it supports.
  4. The CA can be a root CA or a subordinate CA:
    1. root CA – a CA that is directly trusted by an end entity.
    2. subordinate CA – CAs that are not root CAs. The first subordinate CA in a hierarchy obtains its CA certificate from the root CA. This first subordinate CA can, in turn, use this key to issue certificates that verify the integrity of another subordinate CA.
  5. The CA verifies digital certificates using a chain of trust, the root CA being the trust anchor for the digital certificate.
  6. The root CA issues a root certificate, which is the top-most certificate of the certificate tree. The root certificate’s private key is used to sign other certificates. All certificates immediately below the root certificate inherit the trustworthiness of the root certificate.

8.3.2. Digital Signature and Certificates

Digital signatures and digital certificates are not the same objects.

A digital signature is an electronic signature that can be used to demonstrate the authenticity of a message. Digital signatures use hashing and asymmetric encryption. There are two aspects to a digital signature:

  1. signature construction
  2. signature verification

A digital certificate is an electronic document that uses a digital signature to bind a public key with an identity that has been digitally signed by a CA.

8.3.2.1. Certificates

PKI uses two types of certificates:

  1. root certificate
    1. created by a well-known root CA (see CA Role in PKI)
    2. used to validate the authenticity of provider certificates
    3. must be installed on the 7705 SAR manually, where the installation method can be FTP, SFTP, or SC, into the cf3: directory of the 7705 SAR
  2. provider certificate
    1. created by each vendor for its own authentication needs
    2. contains the public RSA or DSA keys that are used in PKI for the encryption of the phase 1 IKE message
    3. must be signed by the root CA to prove the authenticity of the vendor certificate to the far-end node

8.3.2.1.1. Vendor Certificate Signature by the Root CA

For each vendor, the 7705 SAR must have a vendor certificate signed by the CA and stored internally.

The sequence of events is as follows:

  1. The 7705 SAR creates an X.509v3 certificate and the key pair (public/private key).
  2. The 7705 SAR sends the certificate to the CA to be signed by the CA private key.
    1. The CA runs the hash over the X.509v3 certificate.
    2. The result of the hash is encrypted via the CA public key (digital signature).
    3. The digital signature is appended to the certificate and, consequently, the signed vendor certificate.

8.3.2.1.2. Vendor Certificate Authentication by a Peer

While the IKE is being initiated, phase 1 of the IKE can be authenticated via PKI. As such, the certificate from Vendor Certificate Signature by the Root CA is sent to the peer as part of the IKE authorization stage. The peer must ensure that this certificate is generated by the correct 7705 SAR and not an intermediary node.

Upon receiving the certificate, the peer does the following.

  1. The peer runs a hash over the X.509v3 part of the certificate.
  2. The peer decrypts the digital signature of the certificate.
  3. If the hash calculated in step 1 and the hash decrypted in step 2 match, then the certificate is authenticated.
  4. The peer can use the public key in the certificate to encrypt the IKE phase 2 channel.

8.3.2.1.3. Example of PKI Operation

In the following scenario, which provides an example of PKI operation, the 7705 SAR and 7750 SR trust the same CAs and they have already obtained the CA’s certificate (which includes the CA’s public key) using an out-band method. The CA issues a certificate for the 7705 SAR, as follows.

  1. The CA calculates a hash of the contents of the 7705 SAR certificate, which includes the 7705 SAR public key, name, validity date, allowed uses for the certificate, and so on.
  2. The CA encrypts this hash using its private key, and attaches the resulting signature to the 7705 SAR certificate.

The 7705 SAR can now present this signed certificate to the 7750 SR during the IKE phase.

The 7750 SR verifies the received certificate as follows.

  1. The 7750 SR calculates its own hash of the 7705 SAR certificate contents.
  2. The 7750 SR decrypts the signed hash in the certificate using the CA’s public key, and if the hashes match the 7750 SR knows that this certificate was signed by the CA.
  3. Optionally, the 7750 SR consults the CA’s certificate revocation list (CRL) and checks that the certificate from the 7705 SAR has not been revoked.

8.3.2.1.4. Certificate Chain

A peer’s certificate may be issued by an intermediate CA. In this case, a user must have and trust all the intermediate CA certificates up to and including the root CA installed in the peer for authentication of an end entity.

The 7705 SAR supports the following implementation.

  1. When receiving a certificate, all subordinate CAs must be installed locally (that is, only an EE certificate can be received from the peer and processed by the 7705 SAR). Even if a certificate chain is received from the peer, the 7705 SAR processes the EE certificate only.
  2. The send-chain command under cert-profile is for third-party peers that support receiving a chain certificate. In this case, the 7705 SAR can send a chain certificate to be used in the entire chain if the third-party peer supports receiving a chained certificate. The 7705 SAR does not support receiving chained certificates.

8.3.3. Certificate Storage

The 7705 SAR IPSec configuration expects the keys and certificates to be stored in a particular directory on the 7705 SAR compact flash. This directory is called cf3:\system-pki and is created automatically when the first file is imported into this folder.

The following files can be imported and exported to and from the cf3:\system-pki directory. A sample directory is shown after the list.

  1. key pair – this file is encrypted during the import process
  2. certificates
  3. certificate revocation list (CRL)
 
A:ALU-A>file cf3:\system-pki\ # dir
Directory of cf3:\system-pki\
09/09/2015  09:17a     <DIR>        ./
09/09/2015  09:17a     <DIR>        ../
09/22/2015  11:38a              906 CMS1-ROOTCA-CERT 
09/22/2015  11:41a              458 CMS1-ROOTCA-CRL 
09/24/2015  08:18a              864 cert-1 
09/25/2015  08:18a             1192 SAR-key-1 
09/25/2015  09:32a              905 cal_cert_CMS1-SUBCA 
09/25/2015  09:32a              457 cal_crl_CMS1-SUBCA 
          6 Files(s)            4732 bytes.
          2 Dir(s)              65605632 bytes free.
Note:

Always use the import and export commands to move files in and out of this directory. Do not copy any files directly to or from the system PKI directory.

8.3.4. CMPv2 Certificate Management

The Certificate Management Protocol (CMP) is an Internet protocol used for obtaining X.509v3 digital certificates in a PKI. It is described in RFC 4210. CMP messages are encoded in ASN.1 using the DER method and are usually transported over HTTP.

A CA issues the certificates and acts as the secure server in PKI using CMP. One of the clients obtains its digital certificates by means of this protocol and is called the end entity (EE).

The 7705 SAR supports the following CMPv2 operations:

  1. initial registration (ir)
    This is the process that the 7705 SAR uses to enroll a certificate with a certain CA for the first time.
    A public/private key pair must be pre-provisioned before enrollment by means of local generation or another method.
  2. certificate update (cr)
    This is the process whereby an initialized 7705 SAR obtains additional certificates.
  3. key pair update (kur)
    This is the process where the 7705 SAR updates an existing certificate due to any reason, such as a key or certificate refresh before the key or certificate expires.
  4. polling
    In some cases, the CA may not return the certificate immediately, for reasons such as “request processing needs manual intervention”. In such cases, the 7705 SAR supports polling requests and responses, as described in Section 5.3.22, Polling Request and Response, in RFC 4210.

8.3.4.1. CMPv2 Initial Registration

Initial registration is a process that the end entity uses to enroll a certificate with a certain CA for the first time. The result of this process is that a CA issues a certificate for an end entity’s public key, returning that certificate to the end entity or posting that certificate in a public repository (or both).

The 7705 SAR must be pre-provisioned with the operator CA certificate.

The 7705 SAR public/private key pair is always pre-provisioned before enrollment by means of local generation or another method.

The 7705 SAR uses the CMPv2 initial registration process to enroll its pre-provisioned key with an operator’s CA. The result of this process is a certificate issued by the operator’s CA.

There are two authentication methods (PKI message protection) in this process, which are chosen using the CLI:

  1. MSG_MAC_ALG: uses a pre-shared key and a reference number that is pre-issued by the CA
  2. MSG_SIG_ALG: uses a CLI-provided protection key to sign the message; if a protection key is not provided, the key to be certified is used

8.3.4.2. Key Update

When a key pair is due to expire, the relevant end entity (EE) may request a key update. That is, the EE may request that the CA issue a new certificate for a new key pair or, under certain circumstances, a new certificate for the same key pair. The request is made using a key update request (kur) message, also known as a certificate update operation.

This command requests a new certificate from the CA in order to update an existing certificate due to reasons such as the need to refresh a key or to replace a compromised key.

If the EE already has a signing key pair with a corresponding verification certificate, then communication between the EE and the CA will be protected by the EE’s digital signature.

If the request is successful, the CA returns the new certificate in a key update response (kup) message, which is syntactically identical to a CertRepMessage.

8.3.4.3. CRL

In the operation of some cryptosystems, such as PKIs, a certificate revocation list (CRL) is used. A CRL is list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked. Entities presenting those revoked certificates should not be trusted.

The CRL must be obtained and imported via CMPv2.

8.3.5. OCSP

The online certificate status protocol (OCSP) enables applications to determine the revocation status of an X.509v3 digital certificate. OCSP was created as an alternative to using CRLs and can be used to obtain additional status information. OCSP is described in RFC 6960.

Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. OCSP consists of a request message and a response message.

An OCSP responder may return a signed response indicating that the certificate specified in the request is good, revoked, or unknown. The Enterprise Java Bean Certificate Authority (EJBCA) server contains, by default, an internal OCSP responder and, therefore, can be used in conjunction with the 7705 SAR.

Ensure that both the 7705 SAR and the OCSP server are running NTP so that both devices are synchronized with respect to their timing.

8.4. Best Practices Recommendations

This section provides best practices recommendations.

8.4.1. IPSec Best Practices

To avoid high CPU loads and some complex cases, the following are suggestions to configure the IKEv2 lifetime.

  1. Both the IKE_SA and CHILD_SA lifetime on one side should be approximately 2 or 3 times larger than the other side.
  2. With the previous rule, the lifetime of the side with the smaller lifetime should NOT be too small:
    1. IKE_SA: greater than or equal to 86 400 s
    2. CHILD_SA: greater than or equal to 3600 s
  3. With the first rule, on the side with the smaller lifetime, the IKE_SA lifetime should be at least 3 times larger than the CHILD_SA lifetime.

The IKE protocol is the control plane of IPSec; thus, the IKE packet should be treated as high QoS priority in the end-to-end path of public service.

  1. On a public interface, a SAP-ingress QoS policy should be configured to ensure that the IKE packet gets high QoS priority.

8.5. Configuration Notes

This section describes operational conditions and IPSec configuration caveats.

  1. A tunnel group that is in use cannot be deleted. Changes are allowed only when the tunnel group is in a shutdown state.
  2. A change to the IPSec transform policy is allowed at any time. The change will not impact tunnels that have been established until they are renegotiated. If the change is required immediately, the tunnel must be cleared (reset) for force renegotiation.
  3. A change to the IKE policy is allowed at any time. The change will not impact tunnels that have been established until they are renegotiated. If the change is required immediately, the tunnel must be cleared (reset) for force renegotiation.
  4. An IPSec tunnel must be shut down before the transform policy can be modified.
  5. The public interface address can be changed at any time (current behavior). If changed, tunnels that were configured to use it will require a configuration change. If the subnet has been changed, the tunnels will be in an operationally down state until their configuration is corrected. The public service cannot be deleted while tunnels are configured to use it. A public service is the IES service that holds an interface with a public tunnel SAP that connects the node to the public network. A private service connects to the private protected service.
  6. The 7705 SAR supports only one tunnel group (tunnel-group 1).
  7. A change to the security policy is not allowed while a tunnel is active and using the policy.
  8. The tunnel local gateway address, peer address, or delivery router parameters cannot be changed while the tunnel is operationally up (shutdown makes the tunnel both administratively down and operationally down).
  9. A tunnel security policy cannot be changed while the tunnel is operationally up. An IPSec transform policy or IKE policy assignment to a tunnel requires the tunnel to be shut down.

8.5.1. Reference Sources

For information on supported IEEE standards, IETF drafts and standards as well as standard and proprietary MIBs, refer to Standards and Protocol Support.