IP tunnels

A tunnel group is a collection of MS-ISA2s (MDA type isa2-tunnel) or ESA-VM (VM type tunnel) configured to handle the termination of one or more IPsec tunnels.

The following example displays tunnel group configurations.

[ex:/configure isa]
A:admin@node-2# info
    tunnel-group 1 {
        admin-state enable
        isa-scale-mode tunnel-limit-2k
        primary 1/1
        backup 2/1
        }

    tunnel-group 2 {
        admin-state enable
        multi-active {
            isa 3/1 { }
            isa 3/2 { }
        }

    tunnel-group 3 {
        admin-state enable
        multi-active {
            esa 3 vm 1 { }
            esa 4 vm 1 { }
        }

A:node-2>config>isa# info
---------------------------------------------- 
	tunnel-group 1 isa-scale-mode tunnel-limit-2k create
            primary 1/1
            backup 1/2
            no shutdown
        exit

        tunnel-group 2 isa-scale-mode tunnel-limit-2k create
 	     multi-active
 	     mda 3/1
 	     mda 3/2
  	    no shutdown
        exit

     tunnel-group 3 create
          multi-active
          esa-vm 3/1
          esa-vm 4/1 
          no shutdown
	exit

The following features and restrictions apply to SL2L tunnels:

• Per-tunnel configuration is supported, which allows each tunnel to be explicitly configured.
• Each tunnel can be used as the next hop in static routes (directly) or BGP (indirectly).
• SL2L tunnels can act as either the tunnel initiator or responder.
• SL2L tunnels support PSK or certificate-based authentication (or PSK only, in the case of IKEv1).

DL2L tunnels are also used for LAN interconnection. Typically, they are used in a hub-spoke topology where a DL2L tunnel is used on the hub site and the SL2L tunnels are used on the spoke sites. The following figure shows a DL2L tunnel in a hub-spoke topology.

The following features and restrictions apply to DL2L tunnels:

• Per-tunnel configuration is not supported; configuration is per-IPsec gateway only.
• A DL2L tunnel is created dynamically when the IPsec gateway receives an incoming tunnel creation request.
• Reverse routes are created dynamically in a private VRF based on the negotiated TSi to route clear traffic into the tunnel.
• DL2L tunnels can only act as the tunnel responder.
• DL2L tunnels support PSK or certificate-based authentication (or PSK only, in the case of IKEv1)

RA tunnels are typically used by end-user devices to securely access the private network, for example, in the road-warrior VPN use case. The following figure shows an RA tunnel used to access a private network.

The following features and restrictions apply to RA tunnels:

• Similar to DL2L, configuration for RA tunnels is per-IPsec gateway only.
• An RA tunnel is created dynamically upon receiving a tunnel creation request from the IPsec client.
• The RA tunnel client requests an internal IP address assignment from the SeGW during tunnel creation. These addresses are used as the source address of the private traffic sent by client. Other optional information, such as the DNS server address, can also be returned by the SeGW.
• RA tunnels support the following authentication options:
  • PSK (optionally with RADIUS)
  • certificate-based authentication (optionally with RADIUS)
  • EAP with RADIUS

• RA tunnels support optional RADIUS accounting

A tunnel group that is in use cannot be deleted. In single-active mode, changes to the primary ISA are allowed only when the tunnel group is in a shutdown state.

Changes can be made to the following:

• enabling or disabling the following configuration

  configure isa tunnel-group ipsec-responder-only

The public interface address can be changed at any time; however, if changed, any static tunnels that were configured to use the public interface address require a configuration changes accordingly. Otherwise, the tunnels are in an operationally down state until their configuration is corrected. The public service cannot be deleted while tunnels are associated.

A tunnel group ID or tag cannot be changed. To remove a tunnel-group instance, it must be in a shutdown state and all IPsec tunnels and IPsec gateways that terminated on the tunnel group must be removed first.

The security policy cannot be changed while an IPsec tunnel is administratively up and using the security policy.

The tunnel local gateway address, peer address, local ID, and public or private service ID parameters cannot be changed while the IPsec gateway or IPsec tunnel is administratively up.

Each IPsec gateway or IPsec tunnel has an administrative state. When the administrative state is down, tunnels cannot be set up.

Each IPsec gateway and IPsec tunnel has an operation state. The operational state can have three possible values:

• oper-up

  All configuration and related information are valid and fully ready for tunnel setup.

• oper-down

  Some critical configuration information is missing or not ready. Tunnels cannot be set up.

• limited

  Not all configuration information is ready to become fully operationally up. When IPsec gateway is in a limited state, it is possible that a new tunnel cannot be established. When the IPsec tunnel is in a limited state, reconnection may fail.

When an IPsec gateway or IPsec tunnel transitions from operationally up to an operationally limited state directly as a result of a hot (non-service affecting) configuration change, established tunnels are not impacted. However, if the IPsec gateway or IPsec tunnel transitions to an operationally down state before it is operationally limited as a result of a service-affecting configuration change, then established tunnels are removed. All operational state transitions are logged.

IPsec gateways or IPsec tunnels can enter the limited state because of the following reasons, among others:

• A Certificate Authority (CA) profile in the configured trust-anchor-profile goes down after the IPsec gateway or IPsec tunnel becomes operationally up.

• An entry in a configured certificate profile goes down after the IPsec gateway or IPsec tunnel becomes operationally up.

The ISA is IP-addressed by an operator-controlled IP on the public side. That IP address can be used in ping and traceroute commands and the ISA can either respond or forward the packets to the CPM.

For static LAN-to-LAN tunnels, in multi-active mode, ping requests to public tunnel addresses are not answered if the source address is different from the remote address of the static tunnel.

The private side IP address is visible. The status of the interfaces and the tunnels can be viewed using show commands.

Traffic that ingresses or egresses an IES or VPRN service associated with specific IPsec tunnels can be mirrored like other traffic.

Mirroring is allowed per interface (public) or IPsec interface (private) side. A filter mirror is allowed for more specific mirroring.

IPsec supports dead peer detection (DPD).

Input and output octets and packets per service queue are used for billing end customers who are on a metered service plan. Because multiple tunnels can be configured per interface, the statistics can include multiple tunnels. These can be viewed in the CLI and SNMP.

Reporting (syslog, traps) for authentication failures and other IPsec errors are supported, including errors during IKE processing for session setup and errors during encryption or decryption.

A session log indicates the sort of SA setup when there is a possible negotiation. This includes the setup time, teardown time, and negotiated parameters (such as encryption algorithm) as well as identifying the service a particular session is mapped to, and the user associated with the session.

The ISA module provides security utilities for IPsec-related service entities that are assigned to interfaces and SAPs. These entities (such as card, virtual MS-ISA, and IES or VPRN services) must be enabled in order for the security services to process. The module only listens to requests for security services from configured remote endpoints. In the case of a VPN concentrator application, these remote endpoints could come from anywhere on the Internet. In the cases where a point-to-point tunnel is configured, the module listens only to messages from that endpoint.

IKEv2, defined in RFC 4306, Internet Key Exchange (IKEv2) Protocol, is the second version of the Internet Key Exchange Protocol. The main driver of IKEv2 is to simplify and optimize IKEv1. An IKE_SA and a CHILD_SA can be created with only four IKEv2 message exchanges. IKEv2 is supported with the following features:

• static LAN-to-LAN tunnel

• dynamic LAN-to-LAN tunnel

• remote-access tunnel

• pre-shared-key authentication, certificate authentication, EAP (remote-access tunnel only)

• liveness check

• IKE_SA rekey

• CHILD_SA rekey (full Traffic-Selector support including protocol and port range)

• extended ESP sequence number

According to RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec, the following SHA2 variants are supported for authentication or pseudo-random functions:

Use HMAC-SHA-256+ algorithms for data origin authentication and integrity verification in IKEv1/2, ESP:

• AUTH_HMAC_SHA2_256_128

• AUTH_HMAC_SHA2_384_192

• AUTH_HMAC_SHA2_512_256

For use of HMAC-SHA-256+ as a PRF in IKEv1/2:

• PRF_HMAC_SHA2_256

• PRF_HMAC_SHA2_384

• PRF_HMAC_SHA2_512

An optional lockout mechanism can be enabled to block malicious clients and prevent them from using invalid credentials to consume system resources, as well as to prevent malicious users from guessing credentials such as a pre-shared key. This mechanism can be enabled by using the lockout command.

If the number of failed authentication attempts from a particular IPsec client exceeds a configured threshold during a specified time interval, the client is blocked for a configurable period of time. If a client is blocked, the system drops all IKE packets from the source IP address and port.

The following authentication failures are counted as failed authentication attempts:

• IKEv1

  • psk: failed to verify the HASH_I payload in main mode

  • plain-psk-xauth:

    • failed to verify the HASH_I payload in main mode

    • RADIUS access-reject received

• IKEv2

  • psk: failed to verify the AUTH payload in the auth-request packet

  • psk-radius:

    • failed to verify the AUTH payload in the auth-request packet

    • RADIUS access-reject received

  • cert:

    • failed to verify the AUTH payload in the auth-request packet

    • failed to verify the peer’s certification to configured trust-anchors

  • cert-radius:

    • failed to verify the AUTH payload in the auth-request packet

    • failed to verify the peer’s certification to configured trust-anchors

    • RADIUS access-reject received

  • eap: RADIUS access-reject received

Other failures, such as being unable to assign an address, are not counted.

The AUTH failure counter is reset by either a successful authentication before the client is blocked, the expiration of a block timer, or the expiration of the duration timer.

If multiple IPsec clients behind a NAT device share the same public IP address, a limit for the maximum number of clients or ports behind the same IP address can be configured. If the number of ports exceeds the configured limitation, all ports from that IP address are blocked.

The clear ipsec lockout command can also be used to manually clear a lockout state for the specified clients.

SR OS supports CHILD_SA rekeying for both IKEv1 and IKEv2. The following are the behaviors for the rekey:

• IKEv1 or IKEv2 CHILD_SA rekey initiator

  • outbound

    The system immediately switches to the new security association (SA) after a new SA is created.

  • inbound

    The old SA is kept for three minutes after the new SA is created. Then, it is removed, and upon removal:

    • IKEv1

      The system does not send a delete message upon removal.

    • IKEv2

      The systems send a delete message upon removal.

• IKEv1or IKEv2 CHILD_SA rekey responder

  • outbound

    The system keeps using the old SA for 25 seconds after the new SA is created before switching to the new SA. If a delete message of the old SA is received before 25 seconds, the system removes the old SA and starts using new SA.

  • inbound

    The old SA is kept for rest of its lifetime. However, if a delete message is received to close the corresponding outbound SA, then the system removes the corresponding inbound SA before its lifetime expires. The system sends a delete message when the old SA lifetime expires.

If the old SA lifetime expires before the 25 seconds or three minutes mentioned above, the old SA is removed upon expiration and the system sends a delete message.

For IPsec tunnels or IPsec gateways, the SR OS allows users to configure up to four IKE transform and four IPsec transform configurations for IKE and ESP traffic.

IKE transform includes the following configurations:

• IKE encryption algorithm

• IKE authentication algorithm

• Diffie-Hellman group

• IKE SA lifetime

IPsec transform includes the following configurations:

• ESP encryption algorithm

• ESP authentication algorithm

• Diffie-Hellman group for CHILD SA rekey with PFS

• CHILD SA lifetime

If multiple IKE and IPsec transform parameters are configured for IPsec gateways and IPsec tunnels, the system uses the configured transforms to negotiate with the peer. This negotiation allows IPsec gateways and IPsec tunnels to support peers with different crypto algorithms.

With dynamic LAN-to-LAN IPsec tunnels, one or multiple reverse routes can be automatically created per CHILD_SA in a private service, based on traffic selectors in the negotiated TSi. Use the following command to enable the creation of reverse routes.

configure ipsec tunnel-template sp-reverse-route

For a specific CHILD_SA, its TSi contains one or multiple address ranges. The system creates one or multiple reverse routes with the largest prefix length to cover all the ranges in the TSi. If a resulting route overlaps with an existing route of the same tunnel, only the route with the smaller prefix length is kept. If a resulting reverse route is a default route, it is ignored if the ignore-default-route command option is enabled in the tunnel template.

Use the following command to configure the acceptance of overlapping DL2L reverse routes.

configure service vprn ipsec overlapping-reverse-route

If a reverse route of an in-setup CHILD_SA overlaps with an existing reverse route from a different tunnel, the system handles it according to following command configurations:

1. If the overlapping-reverse-route command is configured as false (disabled):
   1. If the allow-reverse-route-override-type command (allow-reverse-route-override in classic CLI) is not configured, the in-setup SA fails, resulting in the removal of its tunnel.
   2. If allow-reverse-route-override-type is configured to same-idi and the in-setup SA belongs to a tunnel that has the same IKEv2 IDi as the corresponding tunnel of the existing reverse route, the system removes the existing tunnel (which includes the existing SA and all others belonging to that tunnel) and creates the in-setup SA; otherwise, the in-setup SA fails.
   3. If allow-reverse-route-override-type is configured to any-idi, the system removes the existing tunnel (with the existing SA and all other SAs belonging to it) and creates the in-setup SA.
2. If the overlapping-reverse-route command is configured as true (enabled), the system creates the in-setup SA and also keeps the existing SA. The system installs all overlapping-but-not-same routes in the route table with their associated metric and preference values configured for the reverse-route command in the tunnel template. If there are same routes from different tunnels, the system selects the route to install based on the following rules:
   1. The lower preference route is preferred.
   2. The lower metric route is preferred.
   3. The non-shunting next hop is preferred.
   4. The routes to install are selected from the set of routes where conditions a, b, and c are equal. The quantity of routes to install is the quantity of ECMP next hops specified by the ECMP configuration of the private service (implicitly 1 when ECMP is disabled in the private service). The routes are selected from the set in order of the lowest values returned by the strcmp() function comparing their next-hop strings.

RFC 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) defines a new IKEv2 AUTH payload method which not only indicates the type of public key, but also the hash algorithm that used to generate the signature; it also includes a new IKEv2 notification: SIGNATURE_HASH_ALGORITHMS, which is used to signal support of RFC 7427 and a list of support hash algorithms to a peer.

RFC 7427 is the default way to perform certificate authentication for IKEv2. The system negotiates its support with the peer as follows:

• sending

  • as tunnel initiator, includes SIGNATURE_HASH_ALGORITHMS in the IKE_SA_INIT request.

  • as tunnel responder, includes SIGNATURE_HASH_ALGORITHMS in IKE_SA_INIT response only if the received IKE_SA_INIT request includes it.

  • includes the SHA1/SHA2-256/SHA2-384/SHA2-512 hash algorithms in SIGNATURE_HASH_ALGORITHMS

• receiving

  • If the peer does not include SIGNATURE_HASH_ALGORITHMS in the IKE_SA_INIT packet, then it does not support RFC 7427 and the system uses an RSA Digital Signature for the RSA key(value 1), and DSS Digital Signature (value 3) for the DSA key to generate the AUTH payload.

    Note: If the ECDSA key is selected in the cert-profile entry, then the tunnel setup fails in the system.

  • If the peer sends SIGNATURE_HASH_ALGORITHMS, then the system uses RFC 7427 and the strongest hash algorithms that is supported by both sides to generate the AUTH payload. If there is no common hash algorithms supported by both sides, the system falls back to RSA Digital Signature (Auth Method value 1) or DSS Digital Signature (Auth Method value 3).

    Note: If the selected key is an RSA key, there are specific cases that have a short RSA key with long hash algorithm. The system falls back to RSA Digital Signature for RSA key (value 1) even when both sides send SIGNATURE_HASH_ALGORITHMS and there are common hash algorithms.

    To verify the received digital signature of the AUTH payload, the peer must uses one of the algorithms in the SIGNATURE_HASH_ALGORITHMS that the system sends. Otherwise, the tunnel setup fails.

The system continues to use CAs in received cert-request payloads to select the cert-profile entry; if the selected entry is an RSA key, the system needs to decide to whether use PKCS#1-1.5 or RSASS-PSS to generate the signature by using the value set by the following command.

configure ipsec cert-profile entry rsa-signature

If the authentication method of the IKE policy is psk-radius or cert-radius, then the system authenticates the client using PSK or the certificate as if it is a LAN-to-LAN tunnel. The system also performs a RADIUS authentication or authorization and optionally sends RADIUS accounting messages.

Call flow for RADIUS-based PSK or certificate authentication displays a typical call flow for RADIUS-based PSK or certificate authentication.

The Access-Request includes the following attributes:

• Username is IDi.

• User-Password is one of following value’s hash according to section 5.2 of RFC 2865, Remote Authentication Dial In User Service (RADIUS):

  • client’s PSK if psk-radius command option is configured

  • otherwise, a key configured using the password command in the RADIUS authentication policy; if a password is not configured and the system does not include the User-Password attribute in access-request.

• Acct-Session-Id represents the IPsec tunnel session.

  The format is: local_gw_ip-remote_ip:remote_port-time_stamp.

  For example: 172.16.100.1-192.168.5.100:500-1365016423.

• Use the following command to configure other RADIUS attributes.

  • MD-CLI

    configure ipsec radius authentication-policy include-radius-attribute

  • classic CLI

    configure ipsec radius-authentication-policy include-radius-attribute
    

  This command configures the following command options.

  • Called-Station-Id (local tunnel address)

  • Calling-station-Id (remote tunnel address:port number)

  • Nas-Identifier (the system name)

  • Nas-Ip-Address (the system IP)

  • Nas-port-id (the public tunnel SAP ID)

If RADIUS authentication is successful, then the RADIUS server sends an access-accept message back; otherwise, an access-reject message is sent back.

The following are supported attributes in access-accept:

• Alc-IPsec-Serv-Id

• Alc-IPsec-Interface

• Framed-IP-Address

• Framed-IP-Netmask

• Alc-Primary-Dns

• Alc-Secondary-Dns

• Alc-IPsec-Tunnel-Template-Id

• Alc-IPsec-SA-Lifetime

• Alc-IPsec-SA-PFS-Group

• Alc-IPsec-SA-Encr-Algorithm

• Alc-IPsec-SA-Auth-Algorithm

• Alc-IPsec-SA-Replay-Window

After the tunnel is successfully created, the system could optionally (depending on the configuration of the RADIUS accounting policy configured in the IPsec gateway), send an accounting-start packet to the RADIUS server, and also send an accounting-stop when the tunnel is removed. The user can use the following command to enable this behavior.

• MD-CLI

  configure ipsec radius accounting-policy update-interval

• classic CLI

  configure ipsec radius-accounting-policy update-interval

The following are some attributes included in the acct-start/stop and interim-update:

• Acct-status-type

• Acct-session-id (the same as in the access-request)

• Username

Use the following command to configure which RADIUS attributes are included.

• MD-CLI

  configure ipsec radius accounting-policy include-radius-attribute

• classic CLI

  configure ipsec radius-accounting-policy include-radius-attribute

This command allows the following command options.

• Frame-ip-address: the assigned internal address

• Calling-station-id

• Called-station-id

• Nas-Port-Id

• Nas-Ip-Addr

• Nas-Identifier

• Acct-Session-Time (tunnel session time, only in acct-stop packet)

The system also supports RADIUS disconnect messages to remove an established tunnel, If the following command is enabled in the RADIUS server configuration, then the system accepts the disconnect-request message (RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)), and tear down the specified remote-access tunnel.

• MD-CLI

  configure router radius server accept-coa

• classic CLI

  configure router radius-server server accept-coa
  

For security reasons, the system only accepts a disconnect-request when accept-coa is configured and the disconnect-request comes from the corresponding server.

The target tunnel is identified by one of following methods:

• Acct-Session-Id

• Nas-Port-Id + Framed-Ip-Addr(Framed-Ipv6-Prefix) + Alc-IPsec-Serv-Id

• User-Name

By default, the system only returns what the client has requested in the CFG_REQUEST payload. However, this behavior can be overridden using the following command.

configure ipsec ike-policy relay-unsolicited-cfg-attribute

With this configuration, the configured attributes returned from the source (such as the RADIUS server) are returned to the client regardless if the client has requested it in the CFG_REQUEST payload.

To achieve authentication without RADIUS, the authentication method needs to be configured as psk or cert-auth and a local address assignment must be configured under the IPsec gateway.

Typical call flow of certificate or PSK authentication without RADIUS shows a typical call flow of certificate or PSK authentication without RADIUS.

Typical call flow for EAP authentication shows a typical call flow for EAP authentication.

In this configuration, the RADIUS authentication and accounting policies in the IPsec gateway context are ignored.

RADIUS disconnect messages are supported in this case. Only the following tunnel identification methods are supported:

• Nas-Port-Id + Framed-Ip-Addr(Framed-Ipv6-Prefix) + Alc-IPsec-Serv-Id

• User-Name

The SR OS supports the following methods of address assignment for IKEv2 remote-access tunnels:

• RADIUS

• local address assignment (LAA)

• DHCPv4/v6

For RADIUS-based address assignment, the address information is returned in an access-accept packet. This implies that RADIUS-based address assignment requires using an authentication option with RADIUS, such as psk-radius, cert-radius, or eap.

For LAA, the system gets an address from a pool defined in a local DHCPv4/v6 server. When a tunnel is removed, the assigned address is released back to the pool. If the local DHCPv4/v6 server is shut down, all existing tunnels that have an address from the server are removed. If LAA is shut down, the current established tunnel that used LAA stays up.

For DHCP-based address assignment, the system acts as a DHCP client on behalf of the IPsec client and requests an address from an external DHCP server via the standard DHCP exchange. In this case, the system also acts as a DHCP relay agent, which relays all DHCP packets between the DHCP server and the local DHCP client. DHCP renew and rebind are also supported.

The SR OS provides the following IPv6 support to IPsec functions:

• IPv6 packets as the ESP tunnel payload

• IPv6 as the ESP tunnel encapsulation

The following example displays a card and ISA configuration.

[ex:/configure]
A:admin@node-2# info
card 1 {
        card-type iom4-e
        mda 1 {
            mda-type me40-1gb-csfp
        }
        mda 2 {
            mda-type isa2-tunnel
        }

A:node-2>config# info
----------------------------------------------
...
    card 1
        card-type iom4-e
        mda 1
            mda-type me40-1gb-csfp
            no shutdown
        exit
        mda 2
            mda-type isa2-tunnel
            no shutdown
        exit
        no shutdown
...
----------------------------------------------

The following example displays a tunnel group configuration in the ISA context. The multi-active command specifies that there could be multiple active ISAs in the tunnel group.

[ex:/configure]
A:admin@node-2# info
isa {
        tunnel-group 1 {
            admin-state enable
            isa-scale-mode tunnel-limit-2k
            multi-active {
                isa 1/2 { }
            }
        }
    }

A:node-2>config# info
----------------------------------------------
...
    isa
        tunnel-group 1 isa-scale-mode tunnel-limit-2k create
            multi-active
            mda 1/2
            no shutdown
        exit
    exit
...
----------------------------------------------

The following example displays an interface named ‟internet” that is configured using the network port (1/1/1), which provides network connection on the public side.

[ex:/configure router "Base"]
A:admin@node-2# info
    autonomous-system 123
    interface "internet" {
        port 1/1/1
        ipv4 {
            primary {
                address 10.10.7.118
                prefix-length 24
            }
        }
    }
    interface "system" {
        ipv4 {
            primary {
                address 10.20.1.118
                prefix-length 32
            }
        }
    }

A:node-2>config# info
----------------------------------------------
... 
    router Base
        interface "internet"
            address 10.10.7.118/24
            port 1/1/1
            no shutdown
        exit
        interface "system"
            address 10.20.1.118/32
            no shutdown
        exit
        autonomous-system 123

...
----------------------------------------------

The following example displays an IPsec configuration.

[ex:/configure ipsec]
A:admin@node-2# info
    ike-policy 100 {
        ike-transform [100]
        ike-version-2 {
            auth-method eap
        }
    }
    ike-transform 100 {
        dh-group group-14
        ike-auth-algorithm sha-256
        isakmp-lifetime 90000
    }

A:node-2>config>ipsec# info
----------------------------------------------
        ike-transform 100 create
            dh-group 14
            ike-auth-algorithm sha256
            isakmp-lifetime 90000
        exit
        ike-policy 100 create
            ike-version 2
            auth-method eap
            ike-transform 100
        exit
----------------------------------------------

The following example displays an IES and VPRN service with IPsec command options configured.

[ex:/configure service]
A:admin@node-2# info
    ies "100" {
        admin-state enable
        customer "1"
        interface "ipsec-public" {
            sap tunnel-1.public:1 {
            }
            ipv4 {
                primary {
                    address 10.10.10.1
                    prefix-length 24
                }
            }
        }
    }

    vprn "200" {
    admin-state enable
    customer "1"
    ipsec {
        security-policy 1 {
            entry 1 {
                local-ip {
                    address 172.16.118.0/24
                }
                remote-ip {
                    address 172.16.91.0/24
                }
            }
        }
    }
    bgp-ipvpn {
        mpls {
            admin-state enable
            route-distinguisher "1:1"
        }
    }
    interface "corporate-network" {
        ipv4 {
            primary {
                address 172.16.118.118
                prefix-length 24
            }
        }
        sap 1/1/2 {
        }
    }
    interface "ipsec-private" {
        tunnel true
        sap tunnel-1.private:1 {
            ipsec-tunnel "remote-office" {
                key-exchange {
                    dynamic {
                        ike-policy 1
                        ipsec-transform [1]
                        pre-shared-key "0PuXIi3wAoMOkSffbuDDViSy4jnc4N2vRrT1Qw== hash2"
                    }
                }
                tunnel-endpoint {
                    local-gateway-address 10.10.10.118
                    remote-ip-address 10.10.7.91
                    delivery-service "delivery"
                }
                security-policy {
                    id 1
                }
            }
        }
    static-routes {
        route 172.16.91.0/24 route-type unicast {
            ipsec-tunnel "t1" {
                admin-state enable
            }

    }

A:node-2>config# info
----------------------------------------------
...
    service
        ies 100 name "100" customer 1 create
            interface "ipsec-public" create
                address 10.10.10.1/24
                tos-marking-state untrusted
                sap tunnel-1.public:1 create
                exit
            exit
            no shutdown
        exit
  vprn 200 customer 1 create
            ipsec
                security-policy 1 create
                    entry 1 create
                        local-ip 172.16.118.0/24
                        remote-ip 172.16.91.0/24
                    exit
                exit
            exit
            route-distinguisher 1:1
            interface "ipsec-private" tunnel create
                sap tunnel-1.private:1 create
                    ipsec-tunnel "remote-office" create
                        security-policy 1
                        local-gateway-address 10.10.10.118 peer 10.10.7.91 delivery-service-name delivery
                        dynamic-keying
                            ike-policy 1
                            pre-shared-key "humptydumpty"
                            transform 1
                        exit
                        no shutdown
                    exit
                exit
            exit
            interface "corporate-network" create
                address 172.16.118.118/24
                sap 1/1/2 create
                exit
            exit
            static-route-entry 172.16.91.0/24
                ipsec-tunnel "t1"
                    no shutdown
                exit
            exit
            no shutdown
        exit
    exit
...
----------------------------------------------

The following are steps to configure certificate enrollment:

1. Generate a key.

   • MD-CLI

     admin system security pki generate-keypair cf3:/key_plain_rsa2048
     admin system security pki generate-keypair rsa-key-size 2048
     

   • classic CLI

     admin certificate gen-keypair cf3:/key_plain_rsa2048 size 2048 type rsa
     

2. Generate a certificate request.

   • MD-CLI

     admin system security pki generate-csr key-url cf3:/key_plain_rsa2048 output-url cf3:/7750-req.cs subject-dn "C=US,ST=CA,CN=7750"

   • classic CLI

     admin certificate gen-local-cert-req keypair cf3:/key_plain_rsa2048 subject-
     dn "C=US,ST=CA,CN=7750" file 7750_req.cs
     

3. Send the certificate request to CA-1 to sign and get the signed certificate.

4. Import the key.

   • MD-CLI

     admin system security pki import type key input-url cf3:/key_plain_rs2048 output-file key1_rsa2048 format der

   • classic CLI

     admin certificate import type key input cf3:/key_plain_rsa2048 output key1_rsa2048 format der
     

5. Import the signed certificate.

   • MD-CLI

     admin system security pki import type cert input-url cf3:/7750_cert.pem output-file 7750cert format pem

   • classic CLI

     admin certificate import type cert input cf3:/7750_cert.pem output 7750cert format pem
     

The following are steps to configure CA certificate/CRL import.

1. Import the CA certificate.

   • MD-CLI

     admin system security pki import type certificate input-url cf3:/CA_1_cert.pem output-file ca_cert format pem

   • classic CLI

     admin certificate import type cert input cf3:/CA_1_cert.pem output ca_cert format pem
     

2. Import the CA’s CRL.

   • MD-CLI

     admin system security pki import type certificate input-url cf3:/CA_1_crl.pem output-file ca_crl format pem

   • classic CLI

     admin certificate import type crl input cf3:/CA_1_crl.pem output ca_crl format pem
     

The following example displays a certificate authentication for IKEv2 static LAN-to-LAN tunnel configuration.

[ex:/configure system security pki]
A:admin@node-2# info
    ca-profile "NOKIA-root" {
        admin-state enable
        cert-file "NOKIA_root.cert"
        crl-file "NOKIA_root.crl"
    }

[ex:/configure ipsec]
A:admin@node-2# info
    cert-profile "segw" {
        admin-state enable
        entry 1 {
            cert "segw.cert"
            key "segw.key"
        }
    }
    ike-policy 1 {
        ike-transform [1]
        ike-version-2 {
            auth-method cert
        }
    }
    ike-transform 1 {
    }
    ipsec-transform 1 {
    }
    trust-anchor-profile "nokia" {
        trust-anchor "NOKIA-root" { }
    }

[ex:/configure service vprn "200" interface "ipsec-private" sap tunnel-1.private:1]
A:admin@node-2# info
    ipsec-tunnel "t50" {
        admin-state enable
        key-exchange {
            dynamic {
                ike-policy 1
                ipsec-transform [1]
                cert {
                    cert-profile "segw"
                    trust-anchor-profile "nokia"
                }
            }
        }
        tunnel-endpoint {
            local-gateway-address 192.168.55.30
            remote-ip-address 192.168.33.100
            delivery-service "delivery"
        }
        security-policy {
            id 1
        }
    }

A:node-2>config>system>security>pki# info 
----------------------------------------------
                ca-profile "NOKIA-root" create
                    cert-file "NOKIA_root.cert"
                    crl-file "NOKIA_root.crl"
                    no shutdown
                exit
----------------------------------------------

A:node-2>config>ipsec# info 
----------------------------------------------
        ike-policy 1 create
            ike-version 2
            auth-method cert-auth
            ike-transform 1
        exit
        ipsec-transform 1 create
        exit
        ike-transform 1 create
        exit
       cert-profile "segw" create
            entry 1 create
                cert segw.cert
                key segw.key
            exit                      
            no shutdown
        exit
        trust-anchor-profile "nokia" create
            trust-anchor "nokia-root"
        exit
----------------------------------------------

A:node-2>config>service>vprn>if>sap
----------------------------------------------
                    ipsec-tunnel "t50" create
                        security-policy 1
                        local-gateway-address 192.168.55.30 peer 192.168.33.100 delivery-service delivery
                        dynamic-keying
                            ike-policy 1
                            transform 1
                            cert
                                trust-anchor-profile "nokia"
                                cert-profile "segw"
                            exit
                        exit
                        no shutdown
                    exit

CMPv2 server information is configured using the commands in the following context.

configure system security pki ca-profile cmpv2

The following command options are configured in this context:

• url

  This command option specifies the HTTP URL of the CMPv2 server. The service specifies the routing instance that the system used to access the CMPv2 server (if omitted, then system uses the base routing instance).

• service name or service ID

  This command option is only needed for in-band connections to the server via VPRN services. IES services are not referenced by the service ID as they use the base routing instance.

• response-signing-cert

  This command option specifies an imported certificate used to verify the CMP response message if it is protected by signature. If this command is not configured, the CA certificate is used.

• key-list

  This command option specifies a list of pre-shared keys used for CMPv2 initial registration message protection.

  If there is no key list defined in the CMPv2 configuration, the system defaults to the CMPv2 transaction input for the command line for authenticating a message without a sender ID. Also, if there is no sender ID in the response message, and there is a key list defined, the system chooses the lexicographical first entry only, and if that fails, it outputs a fail result for the transaction.

The system also supports optional commands (such as, always-set-sender-ir) to support inter-op with CMPv2 servers.

The following example displays CMPv2 configuration.

[ex:/configure system security pki ca-profile "profile" cmpv2]
A:admin@node-2# info
    response-signing-cert "filename"
    url {
        url-string "http://cmp.example.com/request"
        service-name "foo"
    }
    key-list {
        key "1" {
            password "RGwT0+xs+Zb9708mSFdzMCxTCu8ykxuSpA2mpHzFwzU= hash2"
        }
    }

A:node-2>config>system>security>pki>ca-profile>cmpv2$ info
----------------------------------------------
                        url "http://cmp.example.com/request" service-name "foo"
                        key-list
                                key "RGwT0+xs+Zb9708mSFdzMCxTCu8ykxuSpA2mpHzFwzU=" hash2 reference "1"
                        exit
                        response-signing-cert "filename"
----------------------------------------------

OCSP server information is configured using the following command.

configure system security pki ca-profile ocsp

The responder-url command option specifies the HTTP URL of the OCSP responder. The service ID or service name command option specifies the routing instance that system used to access the OCSP responder.

For an IPsec tunnel or IPsec gateway, the user can configure a primary method, a secondary method and a default result using the following commands:

• MD-CLI

  configure ipsec ipsec-transport-mode-profile key-exchange dynamic cert status-verify
  configure router interface ipsec ipsec-tunnel key-exchange dynamic cert status-verify
  configure service ies interface ipsec ipsec-tunnel key-exchange dynamic cert status-verify
  configure service vprn interface ipsec ipsec-tunnel key-exchange dynamic cert status-verify
  configure service vprn interface sap ipsec-tunnel key-exchange dynamic cert status-verify
  

• classic CLI

  configure service vprn interface sap ipsec-gw cert status-verify
  configure service ies interface sap ipsec-gw cert status-verify
  configure service vprn interface ipsec ipsec-tunnel dynamic-keying cert status-verify
  configure service vprn interface sap ipsec-tunnel dynamic-keying cert status-verify
  configure service ies interface ipsec ipsec-tunnel dynamic-keying cert status-verify

The following example, shows OCSP configured as the primary method and CRL as the secondary method.

[ex:/configure service ies "2" interface "ipsec-pub" sap tunnel-1.public:100 ipsec-gateway "foo"]
A:admin@node-2# info
    cert {
        status-verify {
            primary ocsp
            secondary crl
        }
    }

A:node-2>config>service>ies>if>sap>ipsec-gw# info
----------------------------------------------
                        shutdown
                        cert
                            status-verify
                                primary ocsp secondary crl
                            exit
                        exit
----------------------------------------------

The following are configuration tasks for an IKEv2 remote-access tunnel:

• Create an IKE policy with one of the authentication methods that enabled the remote-access tunnel.

• Configure a tunnel template or IPsec transform. This is the same as configuring a dynamic LAN-to-LAN tunnel.

• Create a RADIUS authentication policy and optionally, a RADIUS accounting policy (a RADIUS server policy and a RADIUS server must be preconfigured).

• Configure a private VPRN service and private tunnel interface with an address on the interface. The internal address assigned to the client must come from the subnet on the private interface.

• Configure a public IES or VPRN service and an IPsec gateway under the public tunnel SAP.

• Configure the RADIUS authentication policy and RADIUS accounting policy (optional) under the IPsec gateway.

• Configure a certificate if any certificate-related authentication method is used.

The following example shows an IKEv2 configuration using cert-radius.

[ex:/configure system security pki]
A:admin@node-2# info
    ca-profile "NOKIA-ROOT" {
        admin-state enable
        cert-file "NOKIA-ROOT.cert"
        crl-file "NOKIA-ROOT.crl"
    }

[ex:/configure aaa]
A:admin@node-2# info
    radius {
        server-policy "femto-aaa" {
            servers {
                router-instance "management"
                server 1 {
                    server-name "svr-1"
                }
            }
        }
    }

[ex:/configure router "Base"]
A:admin@node-2# info
    radius {
        server "svr-1" {
            address 10.10.1.2
            secret "LCa0a2j/xo/5m0U8HTBBNJYdag== hash2"
        }
    }

[ex:/configure ipsec]
A:admin@node-2# info
    cert-profile "c1" {
        admin-state enable
        entry 1 {
            cert "SeGW2.cert"
            key "SeGW2.key"
        }
    }
    ike-policy 1 {
        ike-transform [1]
        ike-version-2 {
            auth-method cert-radius
        }
    }
    ike-transform 1 {
    }
    ipsec-transform 1 {
    }
    tunnel-template 1 {
        ipsec-transform [1]
    }
    trust-anchor-profile "tap-1" {
        trust-anchor "NOKIA-ROOT" { }
    }
    radius {
        accounting-policy "femto-acct" {
            radius-server-policy "femto-aaa"
            include-radius-attribute {
                calling-station-id true
                framed-ip-addr true
            }
        }
        authentication-policy "femto-auth" {
            radius-server-policy "femto-aaa"
            password "CQsjXp648Zfy3ZJ5NyIsV7gcSkI= hash2"
            include-radius-attribute {
                called-station-id true
                calling-station-id true
            }
        }
    }


[ex:/configure service ies "2"]
A:admin@node-2# info
    admin-state enable
    customer "1"
    interface "pub" {
        sap tunnel-1.public:100 {
            ipsec-gateway "rw" {
                admin-state enable
                default-tunnel-template 1
                ike-policy 1
                cert {
                    cert-profile "c1"
                    trust-anchor-profile "tap-1"
                }
                default-secure-service {
                    service-name "priv"
                    interface "priv"
                }
                radius {
                    accounting-policy "femto-acct"
                    authentication-policy "femto-auth"
                }
            }
        }
        ipv4 {
            primary {
                address 172.16.100.0
                prefix-length 31
            }
        }
    }

[ex:/configure service vprn "1"]
A:admin@node-2# info
    admin-state enable
    bgp-ipvpn {
        mpls {
            admin-state enable
            route-distinguisher "400:11"
        }
    }
    interface "l1" {
        loopback true
        ipv4 {
            primary {
                address 10.9.9.9
                prefix-length 32
            }
        }
    }
    interface "priv" {
        tunnel true
        ipv4 {
            addresses {
                address 10.20.20.1 {
                    prefix-length 24
                }
            }
        }
        sap tunnel-1.private:200 {
        }
    }

A:node-2>config>system>security>pki# info 
----------------------------------------------
                ca-profile "NOKIA-ROOT" create
                    cert-file "NOKIA-ROOT.cert"
                    crl-file "NOKIA-ROOT.crl"
                    no shutdown
                exit
----------------------------------------------

A:node-2>config>aaa# info 
----------------------------------------------
        radius-server-policy "femto-aaa" create
            servers
                router "management"
                server 1 name ‟svr-1"
            exit
        exit
----------------------------------------------

A:node-2>config>router# info 
----------------------------------------------
        radius-server
            server ‟svr-
1" address 10.10.10.1 secret "KR35xB3W4aUXtL8o3WzPD." hash2 create
            exit
        exit
----------------------------------------------

A:node-2>config>ipsec# info 
----------------------------------------------
        ike-policy 1 create
            ike-version 2
            auth-method cert-radius
            ike-transform 1
        exit
        ipsec-transform 1 create
        exit
        ike-transform 1 create
        exit
        tunnel-template 1 create
            transform 1
        exit
        cert-profile "c1" create
            entry 1 create
                cert SeGW2.cert
                key SeGW2.key
            exit
            no shutdown
        exit
        trust-anchor-profile "tap-1" create
            trust-anchor "NOKIA-ROOT"
        exit
radius-authentication-policy "femto-auth" create
            include-radius-attribute
                calling-station-id
                called-station-id
            exit
            password "DJzlyYKCefyhomnFcFSBuLZovSemMKde" hash2
            radius-server-policy "femto-aaa"
        exit
        radius-accounting-policy "femto-acct" create
            include-radius-attribute
                calling-station-id
                framed-ip-addr 
            exit
            radius-server-policy "femto-aaa"
        exit 
----------------------------------------------

A:node-2>config>service>ies# info 
----------------------------------------------
            interface "pub" create
                address 172.16.100.0/31
                tos-marking-state untrusted
                sap tunnel-1.public:100 create
                    ipsec-gw "rw"
                        cert
                            trust-anchor-profile "tap-1"
                            cert-profile "c1"
                        exit
                        default-secure-service 400 interface "priv"
                        default-tunnel-template 1
                        ike-policy 1
                        local-gateway-address 172.16.100.1
                        radius-accounting-policy "femto-acct"
                        radius-authentication-policy "femto-auth"
                        no shutdown
                    exit
                exit
            exit
            no shutdown
----------------------------------------------

A:node-2>config>service>vprn# info
----------------------------------------------
            interface "priv" tunnel create
                address 10.20.20.1/24
                sap tunnel-1.private:200 create
                exit
            exit
            interface "l1" create
                address 10.9.9.9/32
                loopback
            exit
            bgp-ipvpn
                mpls
                    route-distinguisher 400:11
                    no shutdown
                exit
            exit
            no shutdown
----------------------------------------------

The following are configuration tasks of IKEv2 remote-access tunnel:

• Create an IKE policy with any authentication method.

• Configure the tunnel template or IPsec transform. This is the same as configuring a dynamic LAN-to-LAN tunnel.

• Configure a private VPRN service and a private tunnel interface with an address on the interface. The internal address assigned to the client must come from the subnet on the private interface.

• Configure a local DHCPv4 or DHCPv6 server with address pool that from which the internal address to be assigned from.

• Configure public IES or VPRN service and IPsec gateway under public tunnel SAP.

• Configure the local address assignment under the IPsec gateway.

The following example shows an IKEv2 remote-access tunnel using cert-auth.

[ex:/configure system security pki]
A:admin@node-2# info
      ca-profile "smallcell-root" {
        admin-state enable
        cert-file "smallcell-root-ca.cert"
        revocation-check crl-optional
    }


[ex:/configure ipsec]
A:admin@node-2# info
     cert-profile "segw-mlab" {
        admin-state enable
        entry 1 {
            cert "SeGW-MLAB.cert"
            key "SeGW-MLAB.key"
        }
    }
    ike-policy 3 {
        ike-transform [1]
        ike-version-2 {
            auth-method cert
        }
        nat-traversal {
        }
    }
    ike-transform 1 {
    }
    ipsec-transform 1 {
    }
    tunnel-template 1 {
        ipsec-transform [1]
    }
    trust-anchor-profile "sc-root" {
        trust-anchor "smallcell-root" { 
        }
    }
 

[ex:/configure service ies "2"]
A:admin@node-2# info
    admin-state enable
    customer "1"
    interface "pub" {
        sap tunnel-1.public:100 {
            ipsec-gateway "rw" {
                admin-state enable
                default-tunnel-template 1
                ike-policy 3
                cert {
                    cert-profile "segw-mlab"
                    trust-anchor-profile "sc-root"
                    status-verify {
                        default-result good
                    }
                }
                default-secure-service {
                    service-name "priv"
                    interface "priv"
                }
                local {
                    gateway-address 172.16.100.1
                    id {
                        fqdn "segwmobilelab.nokia.com"
                    }
                    address-assignment {
                        admin-state enable
                        ipv6 {
                            router-instance "priv"
                            dhcp-server "d6"
                            pool "1"
                        }
                    }
                }
            }
        }
        ipv4 {
            primary {
                address 172.16.100.253
                prefix-length 24
            }
        }
    }


[ex:/configure service vprn "3"]
A:admin@node-2# info
    admin-state enable
    bgp-ipvpn {
        mpls {
            admin-state enable
            route-distinguisher "400:1"
        }
    }
    interface "priv" {
        admin-state enable
        tunnel true
        sap tunnel-1.private:200 {
        }
        ipv6 {
            address 2001:db8:beef::101 {
                prefix-length 96
            }
        }
    }
    dhcp-server {
        dhcpv6 "d6" {
            admin-state enable
            pool-selection {
                use-pool-from-client {
                }
            }
            pool "1" {
                options {
                    option dns-server {
                        hex-string 0x20010db8beef00000000000000000808
                    }
                }
                prefix 2001:db8:beef::/96 {
                    failover-control-type access-driven
                }
                exclude-prefix 2001:db8:beef::101/128 { }
            }
        }
    }

A:node-2>config>system>security>pki# info 
----------------------------------------------
                ca-profile "smallcell-root" create
                    cert-file "smallcell-root-ca.cert"
                    revocation-check crl-optional
                    no shutdown
                exit
----------------------------------------------

A:node-2>config>ipsec# info 
----------------------------------------------
        ike-policy 3 create
            ike-version 2
            auth-method cert-auth
            nat-traversal
            ike-transform 1
        exit
        ipsec-transform 1 create
        exit
        ike-transform 1 create
        exit
        cert-profile "segw-mlab" create
            entry 1 create
                cert SeGW-MLAB.cert
                key SeGW-MLAB.key     
            exit
            no shutdown
        exit
        trust-anchor-profile "sc-root" create
            trust-anchor "smallcell-root"
        exit
        tunnel-template 1 create
            transform 1
        exit
----------------------------------------------

A:node-2>config>service>ies# info 
----------------------------------------------
            interface "pub" create
                address 172.16.100.253/24
                tos-marking-state untrusted
                sap tunnel-1.public:100 create
                    ipsec-gw "rw"
                        default-secure-service 400 interface "priv"
                        default-tunnel-template 1
                        ike-policy 3
                        local-address-assignment
                            ipv6
                                address-source router 400 dhcp-server "d6" pool "1"
                            exit
                            no shutdown
                        exit
                        local-gateway-address 172.16.100.1
                        cert
                            trust-anchor-profile "sc-root"
                            cert-profile "segw-mlab"
                            status-verify
                                default-result good
                            exit
                        exit
                        local-id type fqdn value segwmobilelab.nokia.com
                        no shutdown   
                    exit
                exit
            exit
            no shutdown
----------------------------------------------

A:node-2>config>service>vprn# info 
----------------------------------------------
            dhcp6
                local-dhcp-server "d6" create
                    use-pool-from-client
                    pool "1" create
                        options
                            dns-server 2001:db8:::808:808
                        exit
                        exclude-prefix 2001:db8:beef::101/128
                        prefix 2001:db8::beef::/96 failover access-driven pd wan-host create
                        exit
                    exit
                    no shutdown
                exit
            exit
            bgp-ipvpn
                mpls
                    route-distinguisher 400:1
                    no shutdown
                exit
            exit
            interface "priv" tunnel create
                ipv6
                    address 2001:db8:beef::101/96 
                exit
                sap tunnel-1.private:200 create
                exit
            exit
            no shutdown

The following example displays a configuration for a secured interface. In this example, a SI tunnel ‟t1” is configured under interface ‟toPeer-1” in Base routing instance, along with an exception filter 100 that allows OSPF packets bypass IPsec processing.

[ex:/configure filter]
A:admin@node-2# info
    ip-exception "100" {
        entry 10 {
            match {
                protocol ospf-igp
            }
        }
    }


*[ex:/configure router "Base"]
A:admin@node-2# info
    interface "toPeer-1" {
        ipsec {
            tunnel-group 1
            public-sap 300
            ip-exception "100"
            ipsec-tunnel "t1" {
                private-sap 300
                local-gateway-address-override 192.168.110.20
                remote-gateway-address 172.16.21.1
                key-exchange {
                    dynamic {
                        ike-policy 3
                        ipsec-transform [2]
                        pre-shared-key "mEg8brQLbDGkSMIqZt7TtTpKaT7xPCY= hash2"
                    }
                }
                security-policy {
                    id 1
                }
            }
        }
        ipv4 {
            primary {
                address 192.168.110.20
                prefix-length 24
            }
        }
    }
    ipsec {
        security-policy 1 {
            entry 1 {
                local-ip {
                    address 100.0.0.20/32
                }
                remote-ip {
                    address 200.1.1.254/32
                }
            }
        }
    }

config>filter# info
----------------------------------------------
        ip-exception 100 create
            entry 10 create
                match protocol ospf-igp
                exit
            exit
        exit
----------------------------------------------
config>router# info
----------------------------------------------
#--------------------------------------------------
echo "IPsec Configuration"
#--------------------------------------------------
        ipsec
            security-policy 1 create
                entry 1 create
                    local-ip 100.0.0.20/32
                    remote-ip 200.1.1.254/32
                exit
            exit
        exit
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
        interface "toPeer-1"
            address 192.168.110.20/24
            port 1/1/3
            ipsec tunnel-group 1 public-sap 300
                ip-exception 100
                ipsec-tunnel "t1" private-sap 300 create
                    local-gateway-address 192.168.110.20
                    remote-gateway-address 172.16.21.1
                    security-policy 1
                    dynamic-keying
                        ike-policy 3
                        pre-shared-key "KrbVPnF6Dg13PM/biw6ErD9+g6HZ" hash2
                        transform 2
                    exit

Traditionally, IKEv2 uses DH or Elliptic-curve DH (ECDH) for all its key derivations during IKE_SA_INIT or IKE_SA/CHILD_SA rekey exchanges.

SR OS supports the ability to mix a Post-quantum Preshared Key (PPK) into the IKEv2 key derivation process, along with traditional DH or ECDH exchanges, as defined in RFC 8784. This feature adds quantum resistance to the IKEv2 protocol until quantum-safe algorithms become available for use. The PPK is a user-provisioned, preshared key that is used to derive the following keys, on top of the key derivation process defined in RFC 7296:

• SK_d - used to derive the CHILD_SA keys and rekey

• SK_pi - used for authentication

• SK_pr - used for authentication

If the PPK has enough entropy, the ESP traffic and IKE traffic after the first IKE_SA rekey are secured against quantum computers.

PPK is supported with all IKEv2 authentication methods.

Initiator                       Responder
------------------------------------------------------------------
HDR, SAi1, KEi, Ni, N(USE_PPK)  --->
                <--- HDR, SAr1, KEr, Nr, [CERTREQ,] N(USE_PPK)

HDR, SK {IDi, [CERT,] [CERTREQ,]
    [IDr,] AUTH, SAi2,
    TSi, TSr, N(PPK_IDENTITY, PPK_ID), [N(NO_PPK_AUTH)]}  --->
                           <--  HDR, SK {IDr, [CERT,]
                                AUTH, SAr2,
                                TSi, TSr, N(PPK_IDENTITY)}