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, GRE, or IP-IP 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

The ISA can interact with the queuing functions on the IOM through the ingress and egress QoS provisioning in the IES or IP VPN service where the IPsec session is bound. Multiple IPsec sessions can be assigned to a single IES or VPRN service. In this case, QoS defined at the IES or VPRN service level is applied to the aggregate traffic coming out of, or going into, the set of sessions assigned to that service.

To keep marking relevant in the overall networking design, the following traffic-class processing is supported:

• In the encapsulating direction (private to public), the system copies the traffic class of the payload IP packet header to the outer tunnel IP packet header.

• In the decapsulating direction (public to private), the system can optionally copy the traffic class from the outer tunnel IP packet header to the payload IP packet header using the copy-traffic-class-upon-decapsulation command for the template, service, or router IPsec tunnel configuration.

For the tunnel-group ESA VM, if a SAP egress QoS policy is needed on a public or private tunnel SAP, the CIR of all queues configured in the policy should be zero (non-zero CIR is not supported).

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.

In single-active mode, every tunnel group can be configured with primary and backup ISAs. An ISA can be used as a backup for multiple IPsec groups. The ISAs are cold standby such that upon failure of the primary the standby resumes operation after the tunnels re-negotiate state. While the backup ISA can be shared by multiple tunnel groups only one tunnel group can fail to a single ISA at one time (no double failure support).

In multi-active mode, the active-mda number determines the number of ISA MDAs that are active for this tunnel group, and tunnels are spread across all active ISA MDAs. Additional ISA MDAs in this tunnel group are in cold standby.

IPsec also supports dead peer detection (DPD).

BFD can be configured on the private tunnel interfaces associated with GRE tunnels and used by the OSPF, BGP or static routing that is configured inside the tunnel.

SR OS also supports multichassis IPsec redundancy, which provides 1:1 stateful protection against ISA failure or chassis failure.

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, MS-ISA2 module, 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.

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

The overall MC-IPsec redundancy architecture is displayed in MC-IPsec architecture.

With MIMP enabled, there is a master chassis and a backup chassis. The state of the master or standby is per tunnel group. For example (Master and backup chassis example), chassis A and B, for tunnel-group 1, A is master, B is standby; for tunnel group 2, A is standby, B is master.

All IKEv2 negotiation and ESP traffic encryption and decryption occurs on the master chassis. If the backup chassis receives this traffic, if possible, it shunts it to the master.

There is a mastership election protocol (MIMP) running between the chassis to elect the master. This is an IP-based protocol to avoid any physical topology restrictions.

A central BFD session could be bound to MIMP to achieve fast chassis failure detection.

In many cases, the public side is a Layer 2 network and VRRP is used to provide link or node protection. However, VRRP and MC-IPsec are two independent processes, each has its own mastership state, which means the VRRP master could be different from MC-IPsec master. This results in shunting traffic unnecessarily.

To address this issue, MC-IPsec aware VRRP provides a priority event in the vrrp policy: mc-ipsec-non-forwarding. If the configured tunnel group enters non-forwarding (non-master) state, the priority of the associated VRRP instance is set to the configured value. Delta priority is not supported for this type of event.

An MC-IPsec pair must only act as an IKEv2 responder (except for the automatic CHILD_SA rekey on switchover). To enable this behavior, configure the following command.

configure isa tunnel-group ipsec-responder-only 

Tunnel states are synchronized between all nodes in the domain.

A node may have multiple tunnel groups, and in turn, participate in multiple redundancy domains. See Election for information about how the election of nodes is determined.

Within a specific redundancy domain, each node has a designated role and an operational role:

• Designated role

  Designated roles are user-configured as the designated active (DA) or designated standby (DS).

• Operational role

  Operational roles are decided by election protocol during runtime as operational active (OA) or operational standby (OS).

The user can configure each node in the domain as either DA or DS. Any combination of DA:DS is allowed within a domain; however, only one node is elected as OA, other nodes are OS. A designated active role may be elected as OS and a DS may be elected as operationally active.

N:M allows the use of a single set of ISAs to backup multiple tunnel groups. This is achieved by using the tunnel-member-pool command. The tunnel-member pool includes a set of ISAs, as well as a tunnel group with a DS role that refers to the tunnel-member pool instead of directly referring to the ISA. Multiple DS tunnel groups can refer to the same tunnel-member pool, and in turn, share same set of ISAs.

When a failover occurs, if a DS tunnel group is elected to become the OA, the system then takes the required ISAs out of the underlying tunnel-member pool and uses them to populate the tunnel group and the CPM downloads corresponding tunnel states to the selected ISAs. The number of ISAs taken out of the underlying tunnel member pools equals the value configured by the following command in the DS tunnel group:

• MD-CLI

  configure isa tunnel-group multi-active active-isa-number
  

• classic CLI

  configure isa tunnel-group active-mda-number

If there is enough ISA left in the tunnel member pool for other DS tunnel groups, additional failovers can be supported.

A DA tunnel group refers to the ISA directly, and synchronized states are downloaded to the ISA directly. In the case of a DS tunnel group, synchronized tunnel states are stored first on the CPM and only downloaded to the ISA upon failover. Because of this difference, the traffic impact during a failover is larger than when failing over to a DS tunnel group than to a DA tunnel group.

A DS tunnel group can only refer to a tunnel-member pool, not directly to the ISA.

By default, the synced tunnel states are only downloaded to ISA on switchover. When the optional HA mode for a tunnel-member pool is configured, the CPM pre-downloads the synced tunnel states of all the tunnel groups associated with a pool to every ISA in the pool. After the switchover, the system picks the required number of ISAs out of the pool and activates the states of the switched-over tunnels. Hence, the switchover to a DS is much faster than the default behavior. However, when compared with failover to DA, this mode is still slower because of the extra time required to activate the states.

With HA, a scale mode is specified, which defines the maximum number of tunnels of all tunnel groups associated with a pool.

For each participating domain, an N:M node has a redundancy state with one of following values:

• Discovery

  The node's initial peer discovery, for example, when the system boots up.

• notEligible

  The node is not eligible to be elected as OA, for example, when the local ISA fails.

• Eligible

  The node is unable to reach election consensus with its peers, but the node can function locally as OA, for example, the local tunnel group is up but unable to reach its peers.

• Standby

  The node is able to reach election consensus with its peers and is elected as OA.

• Active

  The node is able to reach election consensus with its peers and is elected as OA.

The system also has a protection status for each participating domain that can be Nominal or notReady. In case of a switchover, traffic impact of notReady can be higher than Nominal.

The protection status serves as an indication for to decide the optimal time to perform a controlled switchover.

Use the following command to check the redundancy state and protection status for a domain:

show redundancy multi-chassis ipsec-domain

The election protocol MIMPv2, for N:M, is used to elect the OA node in a domain. A full meshed MIMPv2 peering is required between all nodes in the domain for each participating domain. The system has a user-configurable priority. The designated role, priority, and router ID impact how an active node is elected.

A central BFD session can be bound to a MIMPv2 peering to accelerate node failure detection.

A failover is triggered by one of following events:

• node failure

• ISA failure

• manually forcing a switchover. Use the following command to manually force a switchover.

  tools perform redundancy multi-chassis mc-ipsec force-switchover domain

Because a domain can contain up to four nodes, there can be up to three failovers to three different nodes for a tunnel group. This gives more node-level redundancy than the 1:1 MC-IPsec feature.

The following example shows the election.

The revertive function allows a node in an N:M domain to automatically take over as the active router in the domain when it becomes eligible. In this example, the node is called the challenger. To be eligible, the challenger must meet all the following criteria:

1. The domain must be configured as revertive on the challenger.

2. The challenger must continuously have been in a redundancy state, which means on standby for the last 60 seconds.

3. The challenger must continuously have been in a protection status, that is, nominal for the last 60 seconds.

4. The challenger must meet the following criteria:

   • The challenger is DA while the existing OA is DS.

   • The challenger is DS while the existing OA is also DS.

   • With the same designated role, the challenger has a higher priority than the existing OA.

   • With the same designated role and priority, the challenger has a higher router ID than the existing OA.

If the 60-second interval for criteria 2 and 3 have elapsed, and the challenger notices that another revertive peer with better properties than in criterion 4 is present and eligible, the challenger continues for another 60 seconds before trying to take over.

The following table summarizes the differences between DA and DS.

To achieve stateful failover, a fully meshed MCS peering between nodes in a domain is used to synchronize IPsec states across nodes.

The following criteria is considered to synchronize IPsec states across nodes:

• An SA is only successfully created after a completed Initial Exchanges or CREATE_CILD_SA Exchange is synced.

• Upon switchover, the new OS node resets the tunnel group.

• The ESP sequence number is not synchronized.

• The CLI configuration is not synchronized.

• The system time must be synchronized across all participating nodes (for example, using NTP or SNTP to synchronize the system time).

• Because the ESP sequence number is not synchronized, a CHILD_SA rekey for each tunnel is initiated by the new OA to reset the sequence number on switchover.

• MCS encryption, as described in 1:1 MC-IPsec, can also be used for N:M.

configure vrrp policy priority-event mc-ipsec-non-forwarding

This is equivalent to the following command in routing:

• MD-CLI

  configure policy-options policy-statement entry from state ipsec-non-master

• classic CLI

  configure router policy-options policy-statement entry from state ipsec-non-master

A VRRP policy can set the priority of the VRRP instance to a configured value after the associated tunnel group enters the redundancy state. Delta priority is not supported for this type of event.

Optionally, if an SR OS node receives IPsec traffic, it can shunt the traffic to the OA node to minimize traffic loss.

For each routing instance, N:M allows users to define a multichassis shunting profile that specifies, for each N:M peer, the IP interface used to shunt traffic and the corresponding next hop is specified using the multi-chassis-shunt-interface command.

Specify the per-peer shunt interface using the following command.

configure router ipsec multi-chassis-shunting-profile peer multi-chassis-shunt-interface
configure service vprn ipsec multi-chassis-shunting-profile peer multi-chassis-shunt-interface

Specify the next-hop of the shunt interface using the following command.

configure router ipsec multi-chassis-shunt-interface next-hop
configure service vprn ipsec multi-chassis-shunt-interface next-hop

Because shunting is performed by forwarding traffic to the specified next hop over the shunt interface, the shunt interface must be an interface directly connected to its peer a spoke SDP-terminated interface.

N:M states that the required node can only act as an IKEv2 responder (except for the automatic CHILD_SA rekey upon switchover). This behavior is enabled with the following command.

configure isa tunnel-group ipsec-responder-only 

The system supports a 1:1 MC-IPsec tunnel group that coexists with an N:M tunnel group. A specific tunnel group cannot be both 1:1 and N:M at the same time.

There are specific provisioning requirement for N:M to work properly, see IPsec deployment requirements for details.

DS tunnel-group-specific configurations require a set of ISAs to be included in the pool, using the following command.

configure isa tunnel-member-pool

The spi-range-index command must be configured in a 1:1 or N:M MC-IPsec-enabled tunnel group if any of the following are true:

• for a specific tunnel group, the active-isa-number (active-mda-number in classic CLI) is different on different MC peering systems
• the tunnel group contains ESA-VMs with weight configured

The spi-range-index value ranges from 1 to 4. For a specific tunnel group, a unique value must be configured across all MC peering systems. For example:

• N:M
  • tunnel group 1 has three peering systems: A configured with index 1, B with 2, C with 3
  • tunnel group 2 has two peering systems: A configured with index 1, B with 2
• 1:1 with two systems, A and B
  • tunnel group 1: A configured with index 1, B with 2
  • tunnel group 2: A configured with index 2, B with 3

Perform the following procedures to gracefully configure the spi-range-index on a configuration that does not already have it, while minimizing the traffic impact:

• Configuring the spi-range-index in a 1:1 setup
• Configuring the spi-range-index in an N:M setup

Perform the following procedures to gracefully modify the active-isa-number (active-mda-number in classic CLI) or ESA-VM weight configuration while minimizing the IPsec traffic impact in a 1:1 or N:M MC-IPsec setup.

• Modifying the active-esa-number or ESA-VM weight in a 1:1 setup
• Modifying the active-esa-number or ESA-VM weight in an N:M setup

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)

For a complete list of supported attributes, see the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide.

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

See the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide for more details about disconnect message support.

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 negotiated traffic selector of CHILD_SA that transports IPv6 multicast traffic must include the following address ranges:

• an address range for MLDv2 traffic

• an address range for multicast source (IPv6 global unicast address)

• an address range for expected multicast group

The following is an example of a traffic selector of a CHILD_SA that only carries multicast traffic:

• TSi

  • FF02::1/128 # destination address of the MLDv2 generic query packet

  • FE80::/64 # IPv6 link local address range, source address of the MLDv2 report packet

  • FF3E::/32 # IPv6 multicast address range, global scope. This is for multicast data traffic and MLDv2 (S,G) specific query

• TSr

  • multicast source address range (global unicast)

  • FF02::16/128 # destination address of the MLDv2 report packet

  • FE80::/64 #source address of the MLDv2 query packet

MLDv2 over IPsec is enabled by adding private IPsec interface in MLD configuration. The following example configures MLDv2 over IPsec.

The MLD configuration under the private interface level is ignored by the system.

 [ex:/configure service vprn "1"]
A:admin@node-2# info
    customer "27"
    mld {
        interface "priv" {
            admin-state enable
        }
    }
    interface "priv" {
        tunnel true
        sap tunnel-1.private:200 {
        }
        ipv6 {
            address 2001:dead::1 {
                prefix-length 96
            }
        }
    }

A:node-2>config>service>vprn# info
----------------------------------------------
     mld
         interface "priv"
             no shutdown
         exit
     no shutdown
     exit  
     interface "priv" tunnel create
         ipv6
             address 2001:dead::1/96
         exit
         sap tunnel-1.private:200 create
         exit
     exit
----------------------------------------------

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)}