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. Two example tunnel-group configurations are shown below:

config isa
   tunnel-group 1 create
      primary 1/1
      backup 2/1
      no shutdown
      exit


config isa
   tunnel-group 2 create
      multi-active
      mda 3/1
      mda 3/2
      no shutdown


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

A GRE, IP-IP, or IPsec tunnel belongs to only one tunnel group. There are two types of tunnel groups:

• single-active tunnel-group

  A single-active tunnel-group can have one tunnel-ISA designated as primary and optionally one other tunnel-ISA designated as backup. If the primary ISA fails the affected failed tunnels are re-established on the backup (which is effectively a cold standby) if it is not already in use as a backup for another tunnel-group.

• multi-active tunnel-group

  A multi-active tunnel-group can have multiple tunnel-ISAs designated as primary. Only one ISA is supported on VSR.

  A multi-active tunnel is the recommended tunnel-group type. Certain features like MC-IPsec are only supported with a multi-active tunnel-group.

  The ESA-VM is only supported in a multi-active tunnel-group.

Note that the ESA-VM and ISA/ISA2 cannot coexist in the same tunnel-group.

The show isa tunnel-group command allows the operator to view information about all configured tunnel groups. This command displays the following information for each tunnel-group: group ID, primary tunnel-ISAs, backup tunnel-ISAs, active tunnel-ISAs, admin state and oper state.

There are three thresholds that are used to monitor memory usage in a tunnel ISA:

• max-threshold

  When the memory usage of an ISA exceeds this threshold, any new IKE states are rejected.

• high-watermark

  When the memory usage of an ISA exceed this threshold, a trap is generated.

• low-watermark

  When the memory usage of an ISA fall below this threshold, a clear trap is generated.

These three thresholds are fixed, not configurable.

A tunnel-group has an isa-scale-mode, which defines the maximum number of all tunnels (all types combined) which can be established on each ISA of the tunnel group. This is currently fixed at 32,000 tunnels per ISA. This value is different on VSR and vSIM, see the corresponding User Guides for details.

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 would not be 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 value 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 multi-chassis 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 parameters are configured in the config>ipsec>ike-transform and referenced in the ike-policy, while IPsec transform parameters are configured in the config>ipsec>ipsec-transform context and referenced in the tunnel template for dynamic tunnels and under config>service>vprn>interface>sap>ipsec-tunnel>dynamic-keying for static tunnels.

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-transform 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.

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, then 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 config>ipsec>cert-profile>entry>rsa-signature command.

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/decryption only occurs on the master chassis. If the backup chassis receives such traffic, if possible, it shunts them 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 is introduced in SR OS Release 10.0R8, which add a new priority event in vrrp-policy: mc-ipsec-non-forwarding. If the configured tunnel-group enters non-forwarding (non-master) state, then the priority of associated VRRP instance is set to the configured value. Delta priority is not supported for this type of event.

With MC-IPsec, it is required that MC-IPsec pair can only act as an IKEv2 responder (except for the automatic CHILD_SA rekey upon switchover). To enable this behavior, configure the configure isa tunnel-group ipsec-responder-only command.

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 achieve by 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 active-mda-number command in the DS tunnel group. 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.

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 

  command

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.

priority-event mc-ipsec-non-forwarding

This is equivalent to the following command in routing:

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

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

Optionally, if an 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 multi-chassis shunting profile that specifies, for each N:M peer, the IP interface used to shunt traffic and the corresponding next hop is specified in the following command:

multi-chassis-shunt-interface

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 the following:

• The following command specifies a set of ISAs to be included in the pool.

  configure isa tunnel-member-pool

• The tunnel group refers to the tunnel member pool configured with the following command:

  configure isa tunnel-member-pool

[ex:/configure redundancy multi-chassis]
A:admin@node-2#
    ipsec-domain 1 {
        designated-role active
        priority 250
        tunnel-group 1
    }
    peer 84.84.84.84 {
        sync {
            ipsec true
        }
        mc-ipsec {
            bfd-liveness true
            domain 1 {
            }
        }
    }
    peer 85.85.85.85 {
        sync {
            ipsec true
        }
        mc-ipsec {
            bfd-liveness true
            domain 1 {
            }
        }
    }

*A:admin@node-2>config>redundancy#
----------------------------------------------
        multi-chassis
            ipsec-domain 1 create
                designated-role active
                priority 250
                tunnel-group 1
                no shutdown
            exit
            peer 84.84.84.84 create
                sync
                    ipsec
                    no shutdown
                exit
                mc-ipsec
                    bfd-enable
                    domain 1 create
                        no shutdown
                    exit
                exit
                no shutdown
            exit
            peer 85.85.85.85 create
                sync
                    ipsec
                    no shutdown
                exit
                mc-ipsec
                    bfd-enable
                    domain 1 create
                        no shutdown
                    exit
                exit
                no shutdown
            exit
        exit

[ex:/configure policy-options]
A:admin@node-2#
    policy-statement "export400" {
        entry 10 {
            from {
                state ipsec-master-with-peer
                protocol {
                    name [ipsec]
                }
            }
            action {
                action-type accept
                local-preference 255
                community {
                    add ["vprn400"]
                }
            }
        }
        entry 20 {
            from {
                state ipsec-non-master
                protocol {
                    name [ipsec]
                }
            }
            action {
                action-type accept
                local-preference 70
                community {
                    add ["vprn400"]
                }
            }
        }
        entry 30 {
            from {
                state ipsec-master-without-peer
                protocol {
                    name [ipsec]
                }
            }
            action {
                action-type accept
                local-preference 100
                community {
                    add ["vprn400"]
                }
            }
        }
    }

*A:admin@node-2>config>router>policy-options#
----------------------------------------------
            policy-statement "export400"
                entry 10
                    from
                        protocol ipsec
                        state ipsec-master-with-peer
                    exit
                    action accept
                        community add "vprn400"
                        local-preference 255
                    exit
                exit
                entry 20
                    from
                        protocol ipsec
                        state ipsec-non-master
                    exit
                    action accept
                        community add "vprn400"
                        local-preference 70
                    exit
                exit
                entry 30
                    from
                        protocol ipsec
                        state ipsec-master-without-peer
                    exit
                    action accept
                        community add "vprn400"
                        local-preference 100
                    exit
                exit
            exit

[ex:/configure service vprn "400" ipsec]
A:admin@node-2# 
    multi-chassis-shunt-interface "to84" {
        next-hop {
            address 130.100.14.4
        }
   }
    multi-chassis-shunt-interface "to85" {
        next-hop {
            address 130.110.15.5
        }
    }
    multi-chassis-shunting-profile "shunt1" {
        peer 84.84.84.84 {
            multi-chassis-shunt-interface "to84"
        }
        peer 85.85.85.85 {
            multi-chassis-shunt-interface "to85"
        }
}
[ex:/configure service vprn "400" interface "priv"]
A:admin@v21# info
    tunnel true
    multi-chassis-shunting-profile "shunt1"

*A:admin@node-2>config>service>vprn>ipsec# 
----------------------------------------------
                multi-chassis-shunt-interface "to84" create
                    next-hop 130.100.14.4
                exit
                multi-chassis-shunt-interface "to85" create
                    next-hop 130.110.15.5
                exit
                multi-chassis-shunting-profile "shunt1" create
                    peer 84.84.84.84 create
                        multi-chassis-shunt-interface "to84"
                    exit
                    peer 85.85.85.85 create
                        multi-chassis-shunt-interface "to85"
                    exit
                exit

*A:admin@node-2>config>service>vprn#
  interface “priv” tunnel create
      …
      multi-chassis-shunting-profile "shunt1"

[ex:/configure isa]
A:admin@node-2# 
    tunnel-group 1 {
        admin-state enable
        ipsec-responder-only true
        multi-active {
            member-pool "p1"
        }
        reassembly {
            max-wait-time 2000
        }
    }
    tunnel-group 2 {
        admin-state enable
        ipsec-responder-only true
        multi-active {
            member-pool "p1"
        }
        reassembly {
            max-wait-time 2000
        }
    }
    tunnel-member-pool "p1" {
        isa 1/2 { }
    }

*A:admin@node-2>config>isa#
        tunnel-member-pool p1 create
            mda 1/2
        exit
        tunnel-group 1 create
            reassembly 2000
            ipsec-responder-only
            multi-active
            member-pool p1
            no shutdown
        exit
        tunnel-group 2 create
            reassembly 2000
            ipsec-responder-only
            multi-active
            member-pool p1
            no shutdown
        exit

If the auth-method parameter in the ike-policy is configured as psk-radius or cert-radius, then the system authenticates the client via PSK or certificate accordingly as like a LAN-to-LAN tunnel. The difference being that in the case of psk-radius or cert-radius, the system also performs a RADIUS authentication or authorization and optionally send RADIUS accounting messages.

Call flow for psk-radius/cert-radius displays a typical call flow for psk-radius and cert-radius.

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 the psk-radius is configured (see the CLI)

  • otherwise, a CLI configured key via the password command in the radius-authentication-policy; if password is not configured in this case, then 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.

• Other RADIUS attributes (dependent on the config>ipsec>radius-auth-policy> include-radius-attribute configuration) are as follows:

  • 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 the 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 under the ipsec-gw context), send an accounting-start packet to the RADIUS server, and also send an accounting-stop when the tunnel is removed. The user can also enable the interim-update option in the radius-accounting-policy.

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

The following attributes are dependent on the radius-acct-policy>include-radius-attribute configuration:

• 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 accept-coa (existing 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.

config>router>radius-server>server#
[no] 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 by configuring relay-unsolicited-cfg-attribute in the ike-policy. 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 auth-method needs to be configured as psk or cert-auth and local address assignment must be configured under ipsec-gw.

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-policy and radius-accounting-policy in the ipsec-gw 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 method 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

This feature is enabled by adding private IPsec interface in MLD configuration, for example

config>service>vprn
     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 MLD configuration under the private interface level is ignored by the system.

A tunnel ISA can only be provisioned on an FP2- or FP3-based IOM. The following output displays a card and ISA configuration.

*A:ALA-49>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
...
----------------------------------------------
*A:ALA-49>config#

The following output 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, the mda command specifies the MDA ID of the ISA in the tunnel group. There could be multiple MDA commands in the tunnel group.

*A:ALA-49>config# info
----------------------------------------------
...
    isa
        tunnel-group 1 create
            multi-active
            mda 1/2
            no shutdown
        exit
    exit
...
----------------------------------------------
*A:ALA-49>config#

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

*A:ALA-49>config# info
----------------------------------------------
...
    router 
        interface "internet"
            address 10.10.7.118/24
            port 1/1/1
        exit
        interface "system"
            address 10.20.1.118/32
        exit
        autonomous-system 123
    exit
...
----------------------------------------------
*A:ALA-49>config#

The following output displays an IPsec configuration example.

config>ipsec
        ike-transform 100 create 
            dh-group 14 
            ike-auth-algorithm sha256 
            ike-encryption-algorithm aes128 
            isakmp-lifetime 90000 
        exit 
        ike-policy 100 create 
            ike-version 2 
auth-method psk 
            ike-transform 100 
        exit 

The following output displays an IES and VPRN service with IPsec parameters configured.

*A:ALA-49>config# info
----------------------------------------------
...
    service
        ies 100 customer 1 create
            interface "ipsec-public" create
                address 10.10.10.1/24
                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 100
                        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
...
----------------------------------------------
*A:ALA-49>config#

The following are steps to configure certificate enrollment:

1. Generate a key.

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

2. Generate a certificate request.

   admin certificate gen-local-cert-req keypair cf3:/key_plain_rsa2048 subject-
   rdn "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.

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

5. Import the signed certificate.

   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.

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

2. Import the CA’s CRL.

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

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

config>system>security>pki# info 
----------------------------------------------
                ca-profile "alu-root" create
                    cert-file "alu_root.cert"
                    crl-file "alu_root.crl"
                    no shutdown
                exit
----------------------------------------------
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

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 300
                        dynamic-keying
                            ike-policy 1
                            transform 1
                            cert
                                trust-anchor-profile "nokia"
                                cert-profile "segw"
                            exit
                        exit
                        no shutdown
                    exit

The following displays an example of the syntax to import a certificate from the pem format.

*A:SR-7/Dut-A# admin certificate import type cert input cf3:/pre-import/R1-
0cert.pem output R1-0cert.der format pem

The following displays and example of the syntax to export a certificate to the pem format.

*A:SR-7/Dut-A#  admin certificate export type cert input R1-0cert.der output cf3:/
R1-0cert.pem format pem

CMPv2 server information is configured under the corresponding ca-profile using the following key commands:

config>system>security>pki>ca-profile
   cmpv2
      url <url-string> [service-id <service-id>]
      response-signing-cert <filename>
      key-list
         key <password> reference <reference-number>

The url command 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 base routing instance).

The service ID is only needed for inband connections to the server via VPRN services. IES services are not to be referenced by the service ID as any of those are considered base routing instance.

The response-signing-cert command specifies a imported certificate that is used to verify the CMP response message if they are protected by signature. If this command is not configured, then CA’s certificate is used.

The keylist specifies a list of pre-shared-key used for CMPv2 initial registration message protection.

For example:

config>system>security>pki>ca-profile>
   cmpv2
      url "http://cmp.example.com/request" service-id 100
      key-list
                   key passwordToBeUsed reference "1"

All CMPv2 operations are invoked by using the admin certificate cmpv2 command.

If there is no key-list defined under 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, it chooses the lexicographical first entry only, if that fails, it has a fail result for the transaction.

See the command reference section for details about syntax and usage. The system supports optional commands (such as, always-set-sender-ir) to support inter-op with CMPv2 servers.

OCSP server information is configured under the corresponding ca-profile:

config>system>security>pki>ca-profile>
   ocsp
      responder-url <url-string>
      service <service-id>

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

Example:

config>system>security>pki>ca-profile>
   ocsp
      responder-url ‟http://ocsp.example.com/request”
      service 100

For an ipsec-tunnel or ipsec-gw, the user can configure a primary method, a secondary method and a default result.

config>service>ies>if>sap>ipsec-gw>
config>service>vprn>if>sap>ipsec-gw>
config>service>vprn>if>sap>ipsec-tun>dynamic-keying
   cert
      status-verify
         primary {ocsp | crl} secondary {ocsp | crl}
         default-result {revoked | good}

Example:

config>service>ies>if>sap>ipsec-gw>dynamic-keying
   cert
      status-verify
         primary ocsp secondary crl

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

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

• Configure a tunnel-template/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/VPRN service and an ipsec-gw under the public tunnel SAP.

• Configure the radius-authentication-policy and radius-accounting-policy (optional) under the ipsec-gw.

• Certificate the related configuration if any certificate related authentication method is used.

The following shows an example using cert-radius:

config>system>security>pki# info 
----------------------------------------------
                ca-profile "NOKIA-ROOT" create
                    cert-file "NOKIA-ROOT.cert"
                    crl-file "NOKIA-ROOT.crl"
                    no shutdown
                exit
----------------------------------------------
A:SeGW>config>aaa# info 
----------------------------------------------
        radius-server-policy "femto-aaa" create
            servers
                router "management"
                server 1 name ‟svr-1"
            exit
        exit
----------------------------------------------
A:SeGW>config>router# info 
----------------------------------------------
        radius-server
            server ‟svr-
1" address 10.10.10.1 secret "KR35xB3W4aUXtL8o3WzPD." hash2 create
            exit
        exit
----------------------------------------------

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 

----------------------------------------------
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:SeGW>config>service>vprn# info 
----------------------------------------------
            route-distinguisher 400:11
            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
            no shutdown
----------------------------------------------

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

• Create an ike-policy with any auth-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/VPRN service and ipsec-gw under public tunnel SAP.

• Configure the local address assignment under ipsec-gw.

The following output shows an example using cert-auth:

config>system>security>pki# info 
----------------------------------------------
                ca-profile "smallcell-root" create
                    cert-file "smallcell-root-ca.cert"
                    revocation-check crl-optional
                    no shutdown
                exit
----------------------------------------------
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
----------------------------------------------
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
----------------------------------------------
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
            route-distinguisher 400:1
            interface "priv" tunnel create
                ipv6
                    address 2001:db8::beef::101/96 
                exit
                sap tunnel-1.private:200 create
                exit
            exit
            no shutdown

The following is an example config for 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:

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