IP tunnels

IP tunnels overview

This section discusses IP Security (IPsec), GRE tunneling, and IP-IP tunneling features supported by the MS-ISA2/ESA-VM (ISA is used to refer to any of these hardware). In these applications, the ISA functions as a resource module for the system, providing encapsulation and (for IPsec) encryption functions. The IPsec encryption functions provided by the ISA are applicable for many applications including mobile backhaul, encrypted SDPs, video wholesale, site-to-site encrypted tunnel, and remote access VPN concentration.

7750 SR IPsec implementation architecture shows an example of an IPsec deployment, and the way this would be supported inside a 7750 SR. GRE and IP-IP tunnel deployments are very similar. IP tunnels have two flavors GRE/IP-IP, in all but a few area the information for IP Tunnels applies to both types.

Figure 1. 7750 SR IPsec implementation architecture

7750 SR IPsec implementation architecture, the public network is typically an ‟insecure network” (for example, the public Internet) over which packets belonging to the private network in the diagram cannot be transmitted natively. Inside the 7750 SR, a public service instance (IES or VPRN) connects to the public network and a private service instance (typically a VPRN) connects to the private network.

The public and private services are typically two different services, and the ISA is the only ‟bridge” between the two. Traffic from the public network may need to be authenticated and encrypted inside an IPsec tunnel to reach the private network. In this way, the authenticity/confidentiality/integrity of accessing the private network can be enforced. If authentication and confidentiality are not important then access to the private network may alternatively be provided through GRE or IP-IP tunnels.

The ISA provides a variety of encryption features required to establish bidirectional IPsec tunnels including:

control plane

  • manual keying

  • dynamic keying: IKEv1/v2

  • IKEv1 mode: main and aggressive

  • authentication: Pre-Shared-Key /xauth with RADIUS support/X.509v3 Certificate/EAP

  • Perfect Forward Secrecy (PFS)

  • DPD

  • NAT-Traversal

  • security policy

  • DH-Group: 1/2/5/14/15/19/20/21

data plane

  • ESP (with authentication) tunnel mode

  • authentication algorithm: MD5/SHA1/SHA256/SHA384/SHA512/AES-XCBC

  • encryption algorithm: DES/3DES/AES128/AES192/AES256/AES-GCM128/AES-GCM192/AES-GCM256/AES-GMAC128/AES-GMAC192/AES-GMAC256

  • anti-replay protection

  • N:M IPsec ISA card redundancy

SR OS uses a configured authentication algorithm for the Pseudorandom Function (PRF). IPsec features are supported on the 7750 SR, the 7450 ESS, and VSR.

There are two types of tunnel interfaces and SAPs. See Tunnel interfaces and SAPs for more information.

Table 1. Tunnel interfaces and SAPs
Tunnel interface/SAP Association/configuration

Public tunnel interface

configured in the public service; outgoing tunnel packets have a source IP address in this subnet

Public tunnel SAP

associated with the public tunnel interface; a logical access point to the ISA card in the public service

Private tunnel interface

configured in the private service; can be used to define the subnet for remote access IPsec clients

Private tunnel SAP

associated with the private tunnel interface, a logical access point to the ISA card in the private service

Traffic flows to and through the ISA card as follows:

  • upstream direction

    The encapsulated (and possibly encrypted) traffic is forwarded to a public tunnel interface if its destination address matches the local or gateway address of an IPsec tunnel or the source address of a GRE or IP-IP tunnel. Inside the ISA card, encrypted traffic is decrypted, the tunnel header is removed, the payload IP packet is delivered to the private service, and from there, the traffic is forwarded again based on the destination address of the payload IP packet.

  • downstream direction

    Unencapsulated/clear traffic belonging to the private service is forwarded into the tunnel by matching a route with the IPsec/GRE/IP-IP tunnel as next-hop. The route can be configured statically, learned by running OSPF on the private tunnel interface (GRE tunnels only), learned by running BGP over the tunnel (IPsec and GRE tunnels only), or learned dynamically during IKE negotiation (IPsec only). After clear traffic is forwarded to the ISA card, it is encrypted if required, encapsulated per the tunnel type, delivered to the public service, and from there, the traffic is forwarded again based on the destination address of the tunnel header.

Tunnel ISAs

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.

Public tunnel SAPs

A VPRN or IES service (the delivery service) must have at least one IP interface associated with a public tunnel SAP to receive and process the following types of packets associated with GRE, IP-IP and IPsec tunnels:

  • GRE (IP protocol 47)

  • IP-IP (IP protocol 4)

  • IPsec ESP (IP protocol 50)

  • IKE (UDP)

The public tunnel SAP type has the format tunnel-tunnel-group.public:index, as shown in the following CLI example.

*A:Dut-C>config>service# info
----------------------------------------------
        customer 1 create
            description "Default customer"
        exit
        ies 1 customer 1 create
            interface "public" create
                address 192.168.12.1/24
                tos-marking-state untrusted
                sap tunnel-1.public:200 create
                exit
            exit
            no shutdown
        exit
        vprn 2 customer 1 create
            route-distinguisher 10.1.1.1:65007
            interface "greTunnel" tunnel create
                address 10.0.0.1/24
                dhcp
                    no shutdown
                exit
                sap tunnel-1.private:210 create
                    ip-tunnel "toCel" create
                        dest-ip 10.0.0.2
                        gre-header
                        source 192.168.12.100
                        remote-ip 10.251.12.2
                        backup-remote-ip 10.251.12.22
                        delivery-service 1
                        no shutdown
                    exit
                exit
            exit
            no shutdown
        exit
----------------------------------------------
*A:Dut-C>config>service#

Private tunnel SAPs

The private service must have an IP interface to a GRE, IP-IP, or IPsec tunnel to forward IP packets into the tunnel, causing them to be encapsulated (and possibly encrypted) per the tunnel configuration and to receive IP packets from the tunnel after the encapsulation has been removed (and decryption). That IP interface is associated with a private tunnel SAP.

The private tunnel SAP has the format tunnel-tunnel-group.private:index, as shown in the following CLI example where a GRE tunnel is configured under the SAP.

*A:Dut-A# show ip tunnel 
===============================================================================
IP Tunnels
===============================================================================
TunnelName                       SapId                          SvcId      Admn
 Local Address                                                  DlvrySvcId Oper
  OperRemoteAddress                                                        
-------------------------------------------------------------------------------
tun-1-gre-tunnel                 tunnel-1.private:1             201        Up
 192.168.1.2                                                    1201       Up  
  192.168.3.2                                                        
-------------------------------------------------------------------------------
IP Tunnels: 1
===============================================================================

IP interface configuration

In the configuration example of the previous section the IP address 10.0.0.1 is the address of the GRE tunnel endpoint from the perspective of payload IP packets. This address belongs to the address space of the VPRN 1 service and is not exposed to the public IP network carrying the GRE encapsulated packets. An IP interface associated with a private tunnel SAP does not support unnumbered operation.

It is possible to configure the IP MTU (M) of a private tunnel SAP interface. This sets the maximum payload IP packet size (including IP header) that can be sent into the tunnel – for example, it applies to the packet size before the tunnel encapsulation is added. When a payload IPv4 packet that needs to be forwarded into the tunnel is larger than M bytes the payload packet is IP fragmented (before tunnel encapsulation) if the DF bit is clear, otherwise the packet is discarded. When a payload IPv6 packet that needs to be forwarded into the tunnel is larger than M bytes the packet is discarded if its size is less than 1280 bytes otherwise it is forwarded and encapsulated intact.

GRE and IP-IP tunnel configuration

To bind an IP/GRE or IP-IP tunnel to a private tunnel SAP, the ip-tunnel command should be added under the SAP. To configure the tunnel as an IP/GRE tunnel, the gre-header command must be present in the configuration of the ip-tunnel. To configure the tunnel as an IP-IP tunnel, the ip-tunnel configuration should have the no gre-header command. When configuring a GRE or IP-IP tunnel, the dest-ip command specifies an IPv4 or IPv6 address (private) of the remote tunnel endpoint. A tunnel can have up to 16 dest-ip addresses. If any of the dest-ip addresses are not contained by a subnet of the local private endpoint, then the tunnel does not come up. In the CLI sub-tree under ip-tunnel, there are commands to configure the following:

  • source address of the GRE or IP-IP tunnel

    This is the source IPv4 address of GRE or IP-IP encapsulated packets sent by the delivery service. It must be an address in the subnet of the associated public tunnel SAP interface.

  • remote IP address

    If this address is reachable in the delivery service (there is a route), then this is the destination IPv4 address of GRE or IP-IP encapsulated packets sent by the delivery service.

  • backup remote IP address

    If the remote IP address of the tunnel is not reachable then this is the destination IPv4 address of GRE or IP-IP encapsulated packets sent by the delivery service.

  • delivery service

    This is the ID or name of the IES or VPRN service where GRE or IP-IP encapsulated packets are injected and terminated. The delivery service can be the same service where the private tunnel SAP interface resides.

  • DSCP marking in the outer IP header of GRE encapsulated packets

    If this is not configured, then the default is to copy the DSCP from the inner IP header to the outer IP header.

A private tunnel SAP can have only one ip-tunnel sub-object (one GRE or IP-IP tunnel per SAP).

The show ip tunnel command displays information about a specific IP tunnel or all configured IP tunnels. The following information is provided for each tunnel:

  • service ID that owns the tunnel

  • private tunnel SAP that owns the tunnel

  • tunnel name, source address

  • remote IP address

  • backup remote IP address

  • local (private) address

  • destination (private) address

  • delivery service

  • dscp

  • admin state

  • oper state

  • type (GRE or IP-IP)

The following is an example of the output of the show ip tunnel tunnel-name command.

A:config>service>vprn>if>sap>ip-tunnel# show ip tunnel "ipv6-gre"
===============================================================================
IP Tunnel Configuration Detail
===============================================================================
Service Id       : 1                    Sap Id           : tunnel-1.private:1
Tunnel Name      : ipv6-gre
Description      : None
GRE Header       : Yes                  Delivery Service : 2
GRE Keys Set     : False                
GRE Send Key     : N/A                  GRE Receive Key  : N/A
Admin State      : Up                   Oper State       : Up
Source Address   : 2001:db8::1:2:3:4
Remote Address   : 3ffe:1::2
Backup Address   : (Not Specified)
Oper Remote Addr : 3ffe:1::2
DSCP             : ef                   
Reassembly       : inherit              
Clear DF Bit     : false                IP MTU           : max
Encap IP MTU     : 1400                 
Pkt Too Big      : true                 
Pkt Too Big Numb*: 100                  Pkt Too Big Intvl: 10 secs
Oper Flags       : None
Last Oper Changed: 02/09/2015 15:22:38  
Host MDA         : 1/2                  

-------------------------------------------------------------------------------
Target Address Table
-------------------------------------------------------------------------------
Destination IP                          IP Resolved Status
-------------------------------------------------------------------------------
172.16.1.2                              Yes
2001:db8::2                             Yes
-------------------------------------------------------------------------------

===============================================================================
IP Tunnel Statistics: ipv6-gre
===============================================================================
Errors Rx        : 0                    Errors Tx        : 0
Pkts Rx          : 0                    Pkts Tx          : 0
Bytes Rx         : 0                    Bytes Tx         : 0
Key Ignored Rx   : 0                    Too Big Tx       : 0
Seq Ignored Rx   : 0                    
Vers Unsup. Rx   : 0                    
Invalid Chksum Rx: 0                    
Key Mismatch Rx  : 0                    
===============================================================================

===============================================================================
Fragmentation Statistics
===============================================================================
Encapsulation Overhead                 : 44
Pre-Encapsulation
    Fragmentation Count                : 0
    Last Fragmented Packet Size        : 0
Post-Encapsulation
    Fragmentation Count                : 0
    Last Fragmented Packet Size        : 0
===============================================================================
===============================================================================

IP fragmentation and reassembly for IP tunnels

An IPsec, GRE or IP-IP tunnel packet that is larger than the IP MTU of some interface in the public network must either be discarded (if the Do Not Fragment (DF) bit is set in the outer IP header) or fragmented. If the tunnel packet is fragmented, then it is up to the destination tunnel endpoint to reassemble the tunnel packet from its fragments. Starting in Release 10, IP reassembly can be enabled for all the IPsec, GRE, and IP-IP tunnels belonging to a tunnel-group. For IP-IP and GRE tunnels, the reassembly option is also configurable on a per-tunnel basis so that some tunnels in the tunnel-group can have reassembly enabled, and others can have the extra processing disabled. When reassembly is disabled for a tunnel, all received fragments belonging to the tunnel are dropped.

To avoid public network fragmentation of IPsec, GRE, or IP-IP packets belonging to a particular tunnel, one possible strategy is to fragment IPv4 payload packets larger than a specified size M at entry into the tunnel (before encapsulation and encryption if applicable). The size M is configurable using the ip-mtu command under the ip-tunnel or ipsec-tunnel/tunnel-template configuration.

If the payload IPv4 packets are all M bytes or less in length then it is guaranteed that all resulting tunnel packets are less than M+N bytes in length, if N is the maximum overhead added by the tunneling protocol. If M+N is less than the smallest interface IP MTU in the public network, fragmentation is avoided. In some cases, some of the IPv4 payload packets entering a tunnel may have their DF bit set. And if needed, the SR OS supports the option (also configurable on a per-tunnel basis) to clear the DF bit in these packets so that they can be fragmented.

The system allows users to configure an encapsulated-ip-mtu for a tunnel under an ip-tunnel or ipsec-tunnel/tunnel-template configuration. This represents the maximum size of the encapsulated tunnel packet. After encapsulation, If the IPv4 or IPv6 tunnel packet size exceeds the configured encapsulated-ip-mtu, then the system fragments the packet against the encapsulated-ip-mtu.

The following is a description of system behavior about fragmentation:

  • private side

    If the size, before encapsulation, of the IPv4 or IPv6 packet entering the tunnel is larger than the ip-mtu configured under ip-tunnel or ipsec-tunnel/tunnel template:

    • IPv4 payload packet

      If the DF bit is not set in the packet or if the clear-df-bit command is configured, then the system fragments the packet against the ip-mtu configured under ip-tunnel or ipsec-tunnel/tunnel-template.

      Otherwise, the system drops the packet and sends back an ICMP error Fragmentation required and DF flag set, with the suggested MTU set as the ip-mtu.

    • IPv6 payload packet

      If the packet size >1280 bytes, the system drops the packet and sends back an ICMPv6 Packet Too Big (PTB) message with the suggested MTU set as the ip-mtu.

      If the packet size<=1280 bytes, the system forwards the packet into the tunnel.

  • public side

    This applies to both ESP and IKE packets, IPv4 and IPv6.

    If the ESP/IKE packet is larger than the encapsulated-ip-mtu, then the system fragments the packet against the encapsulated-ip-mtu, however when the IPv6 ESP/IKE packet is smaller than 1280 bytes, the system does not fragment it, even if it is larger than the encapsulated-ip-mtu.

TCP MSS adjustment

The system supports the Transmission Control Protocol (TCP) Maximum Segment Size (MSS) adjustment feature for the following types of tunnels on the ISA:

  • IPsec

  • IPinIP/GRE

  • L2TPv3 (data packet only)

The intent of TCP MSS adjustment is to avoid IP-level fragmentation for TCP traffic encapsulated in a tunnel by updating the MSS option value in the TCP SYN packet with an appropriate value. This feature is useful when there is tunnel encapsulation that is not known by a TCP host, and the extra tunnel encapsulation overhead may cause IP-level fragmentation.

The system supports TCP MSS adjustment on both the public and private sides.

On the public side, when the ISA receives a tunnel packet (such as ESP), after decryption or decapsulation, if the payload packet is a TCP SYN packet, then the ISA replaces the MSS option with a configured value if the configured MSS value is smaller than the received MSS value or when there is no MSS option:

  • If public-tcp-mss-adjust auto is configured, then:

    new MSS value =public_side_MTU – tunnel_overhead – TCP fixed header – IP fixed header

    where:

    • public_side_MTU = encapsulated-ip-mtu

      If encapsulated-ip-mtu is not configured, which means there is no post-encap fragmentation on ISA, then TCP MSS adjust is disabled.

    • TCP fixed header = 20

    • IP fixed header = 20 (Ipv4) or 40 (IPv6)

  • If a specific MSS value such as public-tcp-mss-adjust new_mss_value is configured, then the new MSS value sets to the new_mss_value.

Note:
  • The public-tcp-mss-adjust auto command only applies to IPsec and IPinIP/GRE tunnels.

  • For an IPsec tunnel, the tunnel_overhead is the maximum overhead of the corresponding CHILD_SA.

  • For an IPinIP tunnel, the tunnel_overhead is 0.

  • For a GRE tunnel, the tunnel_overhead is length of GRE header.

The private side is similar to the public side. The system processes the received TCP SYN packet on the private side if the TCP MSS adjust is enabled. However, there is no auto parameter for private-tcp-mss-adjust command.

MTU propagation

MTU propagation is an optional feature that allows the system to listen for fragmentation-related ICMP error message received from the public side of the tunnel. These error messages include:

  • ICMP Destination Unreachable message "fragmentation needed and DF set" (type 3, code 4)

  • ICMPv6 Packet Too Big message (type 2)

The suggested MTU value in the ICMP message is used to derive two MTU values:

  • Temporary public MTU (TMTU) are determined as follows:

    • The TMTU starts with a configured encapsulated-ip-mtu octets value.

    • If the received MTU is less than 1280 and it is from an ICMPv6 packet, the received value is ignored.

    • If the received MTU is less than 512 and it is from an ICMP packet, the received value is ignored.

    • If the received MTU is greater than or equal to the configured encapsulated-ip-mtu octets value, the received value is ignored.

    • If the received MTU is greater than or equal to the current TMTU, the received value is ignored.

    • If the received MTU is less than the current TMTU, it replaces the current TMTU.

    • To prevent attack and rapid change, there is a damp time of 60 seconds after a new TMTU value is set. Within that time frame, all received MTU values are ignored.

    • TMTU has a lifetime timer (configurable with an aging interval). When the lifetime timer expires, the TMTU’s value is reset to the encapsulated-ip-mtu octets value. The lifetime timer resets whenever a new TMTU value is set.

    • TMTU is a per tunnel value.

  • Temporary private MTU (TPMTU) equals TMTU – Tunnel_Encap_Overhead.

    • TPMTU is a per CHILD_SA value.

    • Tunnel_Encap_Overhead is a fixed value for a non-IPsec tunnel-per-tunnel type. For an IPsec tunnel, its value is the maximum overhead based on the ipsec-transform transform-id value used by the CHILD_SA.

TMTU and TPMTU are used in the following cases:

  • TPMTU is used for fragmenting IP packets received on the private side instead of the configured IP MTU.

  • IKEv2 message fragmentation uses TMTU instead of the configured encapsulated-ip-mtu.

  • IKE IP packet fragmentation uses TMTU instead of the configured encapsulated-ip-mtu.

  • To derive the TCP MSS value for the TCP MSS adjustment, instead of configured encapsulated-ip-mtu.

  • ESP packet fragmentation (post-encapsulation fragmentation) does not use TMTU; it only uses the configured encapsulated-ip-mtu octets value.

To enable this feature, configure the propagate-pmtu-v4 and propagate-pmtu-v6 commands under the ip-tunnel, ipsec-tunnel or tunnel-template contexts.

Operational conditions

A tunnel group that is in use cannot be deleted. In single-active mode, changes to the primary ISA are allowed only when the tunnel group is in a shutdown state. Changing the configured backup ISA (or adding a backup ISA) is allowed at any time unless the ISA is currently active for this tunnel group. When the backup ISA is active, changing the primary ISA is allowed without shutting down the tunnel group.

Changes can be made to the following:

  • the mode from multi-active to single-active

  • the primary ISA that is in single-active mode

  • the active MDA number value that is in multi-active mode

  • enabling or disabling the ipsec-responder-only configuration

In multi-active mode, if the active member ISA goes down, the system replaces it with a backup ISA. However, if a backup ISA is not available, the tunnel group is placed in an operationally down state. A multi-active tunnel group with MC-IPsec enabled cannot be changed into single active-mode unless it is first removed from the MC-IPsec configuration.

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

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

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

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

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

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

  • oper-up

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

  • oper-down

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

  • limited

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

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

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

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

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

Dynamic configuration change support for IPsec gateway

All dynamic IPsec tunnels (dynamic LAN-to-LAN tunnels and remote-access tunnels) that terminate on the same IPsec gateway share the same configuration. Use the respective commands in the following contexts to configure an IPsec gateway for an IES or VPRN service:

  • MD-CLI

    configure service ies interface sap ipsec-gateway
    configure service vprn interface sap ipsec-gateway
  • classic CLI

    configure service ies interface sap ipsec-gw
    configure service vprn interface sap ipsec-gw

SR OS provides dynamic configuration change capability to modify specific IPsec gateway configurations without impacting existing tunnels.

The following IPsec gateway configurations are dynamically configurable without shutting down the IPsec gateway:

  • Changing the pre-shared key, using the following commands:

    • MD-CLI

      configure service ies interface sap ipsec-gateway pre-shared-key
      configure service vprn interface sap ipsec-gateway pre-shared-key
    • classic CLI

      configure service ies interface sap ipsec-gw pre-shared-key
      configure service vprn interface sap ipsec-gw pre-shared-key
  • Changing the reference of the IKE policy, using the following commands:

    • MD-CLI

      configure service ies interface sap ipsec-gateway ike-policy
      configure service vprn interface sap ipsec-gateway ike-policy
    • classic CLI

      configure service ies interface sap ipsec-gw ike-policy
      configure service vprn interface sap ipsec-gw ike-policy
  • Changing the reference of the tunnel template, using the following commands:

    • MD-CLI

      configure service ies interface sap ipsec-gateway default-tunnel-template
      configure service vprn interface sap ipsec-gateway default-tunnel-template
    • classic CLI

      configure service ies interface sap ipsec-gw default-tunnel-template
      configure service vprn interface sap ipsec-gw default-tunnel-template
  • Enabling or changing reference of the RADIUS authentication policy, using the following commands:

    • MD-CLI

      configure service ies interface sap ipsec-gateway radius authentication-policy
      configure service vprn interface sap ipsec-gateway radius authentication-policy
    • classic CLI

      configure service ies interface sap ipsec-gw radius-authentication-policy
      configure service vprn interface sap ipsec-gw radius-authentication-policy
  • Enable or changing reference of the RADIUS accounting policy, using the following commands:

    • MD-CLI

      configure service ies interface sap ipsec-gateway radius accounting-policy
      configure service vprn interface sap ipsec-gateway radius accounting-policy
    • classic CLI

      configure service ies interface sap ipsec-gw radius-accounting-policy
      configure service vprn interface sap ipsec-gw radius-accounting-policy
  • Enabling, disabling, or changing reference of the TS negotiation, using the following commands:

    • MD-CLI

      configure service ies interface sap ipsec-gateway ts-list
      configure service vprn interface sap ipsec-gateway ts-list
    • classic CLI

      configure service ies interface sap ipsec-gw ts-negotiation
      configure service vprn interface sap ipsec-gw ts-negotiation
  • Enabling, disable, or changing reference of the client database, using the command options in the following contexts:

    • MD-CLI

      configure service ies interface sap ipsec-gateway client-db
      configure service vprn interface sap ipsec-gateway client-db
    • classic CLI

      configure service ies interface sap ipsec-gw client-db
      configure service vprn interface sap ipsec-gw client-db
  • Changing certificate configuration, using the commands in the followings contexts:

    • MD-CLI

      configure service ies interface sap ipsec-gateway cert
      configure service vprn interface sap ipsec-gateway cert
    • classic CLI

      configure service ies interface sap ipsec-gw cert
      configure service vprn interface sap ipsec-gw cert
  • Changing DHCPv4-based address assignments, using the commands in the following contexts:

    • MD-CLI

      configure service ies interface sap ipsec-gateway dhcp-address-assignment dhcpv4
      configure service vprn interface sap ipsec-gateway dhcp-address-assignment dhcpv4
    • classic CLI

      configure service ies interface sap ipsec-gw dhcp
      configure service vprn interface sap ipsec-gw dhcp
  • Changing DHCPv6-based address assignments, using the commands in the following contexts:

    • MD-CLI

      configure service ies interface sap ipsec-gateway dhcp-address-assignment dhcpv6
      configure service vprn interface sap ipsec-gateway dhcp-address-assignment dhcpv6
    • classic CLI

      configure service ies interface sap ipsec-gw dhcp6
      configure service vprn interface sap ipsec-gw dhcp6
  • Change local address assignment configuration, using the commands in the following contexts:

    • MD-CLI

      configure service ies interface sap ipsec-gateway local address-assignment
      configure service vprn interface sap ipsec-gateway local address-assignment
    • classic CLI

      configure service ies interface sap ipsec-gw local-address-assignment
      configure service vprn interface sap ipsec-gw local-address-assignment

Existing tunnels are not impacted by dynamic configuration changes. The system uses new configurations for new tunnel negotiations. The system continues to use previous configurations that created the tunnels for ongoing operations (such as rekeying) of the existing tunnel.

QoS interactions

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

OAM interactions

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.

Redundancy

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.

Statistics collection

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.

Security

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.

GRE tunnel multicast support

GRE tunnels support unicast and multicast IP packets as payload. From a multicast prospective, a GRE tunnel IP interface (associated with a private tunnel SAP) can be configured as an IGMP interface or as a PIM interface; MLD is not supported. The following multicast features are supported:

  • IGMP versions 1, 2 and 3

  • IGMP import policies

  • IGMP host tracking

  • static IGMP membership

  • configurable IGMP timers

  • IGMP SSM translation

  • multicast CAC

  • per-interface, per-protocol (IGMP/PIM) multicast group limits

  • MVPN support (draft-rosen)

  • MVPN support (BGP-MPLS)

  • PIM-SM and SSM operation

  • PIM BFD support

  • configurable PIM timers

  • configurable PIM priority

  • PIM tracking support

  • PIM ECMP (bandwidth or hash-based)

  • static multicast route

IPv6 over IPv4 GRE tunnel

IPv6 payload packets can be delivered over an IPv4 GRE tunnel. In this scenario the two endpoints of the GRE tunnel have IPv4 addresses and the VPRN or IES SAP interface to the tunnel is an IPv6 only or dual-stack IPv4/IPv6 interface. IPv6 over IPv4 GRE tunneling allows IPv6 islands to be connected over an IPv4 only transport infrastructure.

To configure a tunnel to carry IPv6 payload, the tunnel must be configured with at least one dest-ip that contains an IPv6 address (global unicast and/or link local). A tunnel can have up to 16 dest-ip addresses (IPv4 and IPv6 together). For a tunnel to come operationally up all the dest-ip addresses must be part of locally configured subnets (associated with the private tunnel interface).

To forward IPv6 traffic through a tunnel supporting IPv6 payload, a dynamic routing protocol (such as BGP or OSPFv3) can be configured to run inside the tunnel (by associating the protocol with the private tunnel interface) or else an IPv6 static route next-hop equal to a dest-ip of the tunnel can be used.

IPv6 payload packets larger than 1280 bytes (the minimum IPv6 MTU) and also larger than the configured ip-mtu value of the tunnel are always discarded. If the icmp6-generation and packet-too-big commands are configured under the tunnel, then ICMPv6 Packet-Too-Big messages are generated and sent back to the originating host when discards occur because of the private side IP MTU being exceeded.

IKEv2

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

  • static LAN-to-LAN tunnel

  • dynamic LAN-to-LAN tunnel

  • remote-access tunnel

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

  • liveness check

  • IKE_SA rekey

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

  • extended ESP sequence number

IKEv2 traffic selector and TS-list

The SR OS IKEv2 implementation supports the following traffic selectors:

  • IPv4/IPv6 address range

  • IP protocol ID

  • protocol port range

Port range (including OPAQUE ports) is supported for the following protocols:

  • TCP

  • UDP

  • SCTP

  • ICMP

  • ICMPv6

  • MIPv6

With ICMP and ICMPv6, the system treats the most significant 8 bits of the IKEv2 TS port value as the ICMP message type and the least significant 8 bits as ICMP code.

With MIPv6, the system treats the most significant 8 bits of the IKEv2 TS port value as the mobility header type.

With ICMP, ICMPv6, and MIPv6, the port value in TSi is the value that the tunnel initiator can send, and the port value in TSr is the value that the tunnel responder can send.

The SR OS supports OPAQUE as a TS port selector. An OPAQUE port means that the corresponding CHILD_SA only accepts packets that are supposed to have port information but do not, such as when a packet is a non-initial fragment.

The system allows users to configure a TS-list for each IPsec gateway, applied to both IKEv2 remote access tunnels and dynamic LAN-to-LAN tunnels. Each TS-list contains a local part and a remote part, with each part containing up to 32 entries. Each entry can contain address ranges or subnets, protocols, and port range configurations.

The local part of the TS-list represents the traffic selector for the local system, while the remote part is for the remote peer. If a TS-list is applied on an IPsec gateway, and the system is the tunnel responder, then the local part is TSr and the remote part is TSi.

Combinations of address range, protocol, and port range are not allowed to overlap between entries in the same TS-list.

The system performs traffic selector narrowing as follows.

  1. For each TS in the received TSi/TSr, independent address, protocol, and port narrowing is performed. The resulting TS-set is the combination of the address, protocol, and range intersections.

  2. The collected TS-set is used as the TSi/TSr.

For a remote access tunnel, TSi narrowing results in an intersection between the following three TSis:

  • the TSi received from the client

  • the remote part configuration of the TS-list

  • a generated TS based on the assigned internal address

    • address (the assigned internal address)

    • protocol (any)

    • port range (any)

The following is an example of a dynamic LAN-to-LAN tunnel.

The configured TS-list local part is as follows:

  • Entry 1: 10.10.1.0 → 10.10.1.20, udp, port 100 → 200

  • Entry 2: 10.20.1.0 → 10.20.1.20, udp, port 300 → 400

The peer proposes the following TSr:

  • Entry 1: 10.10.1.1 → 10.10.1.5, udp, port 110 → 150

  • Entry 2: 10.10.1.6 → 10.10.1.10, udp, port 180 → 210

  • Entry 3: 10.10.1.15 → 10.10.1.28, udp, port 120 → 160

  • Entry 4: 10.20.1.15 → 10.20.1.28, tcp, port 250 → 450

The intersections for the proposed entries are as follows:

  • Entry 1: 10.10.1.1 → 10.10.1.5, udp, port 110 → 150

  • Entry 2: 10.10.1.6 → 10.10.1.10, udp, port 180 → 200

  • Entry 3: 10.10.1.15 → 10.10.1.20, udp, port 120 → 160

  • Entry 4: 10.20.1.15 → 10.20.1.20, tcp, port 300 → 400

The resulting TSr system return would be:

  • 10.10.1.1 → 10.10.1.5, udp, port 110 → 150

  • 10.10.1.6 → 10.10.1.10, udp, port 180 → 200

  • 10.10.1.15 → 10.10.1.20, udp, port 120 → 160

  • 20.20.1.15 → 20.20.1.20, tcp, port 300 → 400

If more than 32 entries are returned, the system rejects the ts-negotiation and returns TS_UNACCEPTABLE to the peer.

For dynamic LAN-to-LAN tunnels, the system can automatically create a reverse route in a private VRF to route clear traffic into the tunnel. The reverse route is created based on the address range part of the narrowed TSi of the CHILD_SA. If there are multiple TSs in the TSi that have overlapping address ranges, the system creates one or more minimal subnet routes that can cover all address ranges in the TSi. If the auto-created reverse route overlaps with an existing reverse route that points to the same tunnel, the system chooses the route with the larger subnet. If the existing route points to a different tunnel, then CHILD_SA creation fails.

For RADIUS authentication, such as psk-radius, cert-radius, or EAP, the RADIUS server can optionally return a TS-list name via the VSA Alc-IPsec-Ts-Override in the access-accept message, which overrides the TS-list name configured via the CLI.

In the event of a CHILD_SA rekey, if the system is a rekey initiator, it sends the current in-use TS to the peer and expect the peer to return the same TS. If the system is a rekey responder, the system does the same narrowing as was done during CHILD_SA creation.

Configuration of a TS-list can be changed without shutting down the IPsec gateway, although the new TS-list only applies to the subsequent rekey or to the new CHILD_SA creation, and does not affect established CHILD_SAs.

IKEv2 fragmentation

In some cases, an IKEv2 message can large, like an IKE_AUTH message with certificate payload. This is likely to cause the IKEv2 packet to be fragmented into a few smaller IP packets. However, in some deployments, there could be devices or network policing, rate limiting or even dropping UDP fragments. In these cases, the SR OS supports fragmenting IKEv2 messages on the protocol level, as specified in RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation.

This feature is enabled by configuring the ikev2-fragment command in the ike-policy context with an MTU. The specified MTU is the maximum size of IKEv2 packet.

The system only enables IKEv2 fragmentation for a specific tunnel when the ikev2-fragment is configured and the peer also announces its support via sending a IKEV2_FRAGMENTATION_SUPPORTED notification.

SHA2 support

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

IPsec client lockout

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.

IPsec tunnel CHILD_SA rekey

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.

Multiple IKE/ESP transform support

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.

Using certificates for IPsec tunnel authentication

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

The SR OS supports certificate chain verification. For a static LAN-to-LAN tunnel or ipsec-gw, there is a configurable trust-anchor-profile which specifies the expecting CAs that should be present in the certificate chain before reaching the root CA (self-signed CA) configured in the system.

The SR OS’s own key and certificate are also configurable per tunnel or ipsec-gw.

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

Note: IPsec application is subject to FIPS restrictions; for more information please see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Basic System Configuration Guide.

IKEv2 digital signature authentication

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.

Trust-anchor profile

Since Release 12.0R1, the SR OS supports multiple trust-anchors per ipsec-tunnel/ipsec-gw. Users can configure a trust-anchor-profile that includes up to eight CAs. The system builds a certificate chain by using the certificate in the first certificate payload in the received IKEv2 message. If any of configured trust-anchor CAs in the trust-anchor-profile appears in the chain, then authentication is successful. Otherwise authentication is failed.

The SR OS only supports processing of up to 16 hashes for the trust-anchor list from other products. If the remote end is sending more than 16, and a certificate match is in the > 16 range, the tunnel remains down with authentication failure.

The legacy trust-anchor command under ipsec-gw/ipsec-tunnel was deprecated in Release 15.0.R1.

Cert-profile

Since Release 12.0R1, the SR OS supports sending different certificate/chain according to the received IKEv2 certificate-request payload. This is achieved by configuring a cert-profile which allows up to eight entries. Each entry includes a certificate and a key and optionally also a chain of CA certificates.

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

Because there could be multiple entries configured in the cert-profile, the system needs to pick the cert/key in the correct entry that the other side expects to receive. This is achieved by a lookup of the CAs within one cert-request payload or multiple cert-request payloads in the compare-chain and then picking the first entry that there is a cert-request CA appearing in its chain. If there is no such cert, the system picks the first entry in the cert-profile. The first entry shown in the output below, is the first configured entry in the cert-profile. The entry-id of first entry does not have to be 1.

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

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

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

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

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

The following CA chain-related enhancements are supported:

  • The no-shut of a ca-profile triggers a re-computation of compute-chain in related cert-profiles. The system also generates a new log-1 to indicate a new compute-chain has been generated; the log includes the ca-profile names on the new chain. Another log-2 is generated if the send-chain in a cert-profile entry is not in compute-chain because of this ca-profile change. Another log is generated if the hash calculation for a certificate under a ca-profile has changed.

  • When no-shutting a cert-profile, the system now allows the CAs in the send-chain, not in the compute-chain. The system also generates log-2 as above.

  • The system now allows changes of the configuration of send-chain without shutdown of cert-profile.

  • When a configure root CA is cross-signed by another CA, multiple overlapping compare-chains for a specific certificate profile entry may occur. Choose one compare-chain by executing the following command to specify the tiebreak CA.
    configure ipsec cert-profile entry compare-chain-include 

Video wholesale example

As satellite headend locations can be costly, many municipal and second tier operators cannot justify the investment in their own ground station to offer triple play features. However, it is possible for a larger provider or a cooperative of smaller providers to unite and provide a video headend. Each retail subscriber can purchase content from this single station, and receive it over IP. However, encryption is required so the signal cannot be understood if intercepted. A high speed encrypted tunnel is preferred over running two layers of double video protection which is cumbersome and computationally intensive.

Video wholesale configuration shows an example of video wholesale configuration.

Figure 2. Video wholesale configuration

1:1 Multi-chassis IPsec redundancy

This section applies to the 7750 SR, the 7450 ESS, and VSR.

Multi-Chassis IPsec redundancy (MC-IPsec) provides a 1:1 (active/standby) IPsec stateful failover mechanism between two chassis.

The following describes features about MC-IPsec:

  • This feature provides protection against ISA failure and chassis failure.

  • MC-IPsec is supported for all types of IKEv2 tunnels, including static LAN-to-LAN, dynamic LAN-to-LAN and remote-access tunnels.

  • This feature is supported only on multi-active tunnel groups.

  • The granularity of failover is per tunnel group, which means a specific tunnel group could failover to the standby chassis independent of other tunnel groups on the master chassis.

  • The components included in this feature as shown in the following table.

    Table 2. MC-IPsec redundancy feature components
    MC-IPsec redundancy feature component Description

    Master election

    MC-IPsec Mastership Protocol (MIMP) runs between chassis to elect master, MIMP runs for each tunnel group independently.

    Synchronization

    Multi-Chassis Synchronization (MCS) synchronizes IPsec states between chassis.

    Routing

    Routing features include the following:

    • MC-IPsec aware routing attracting traffic to the master chassis

    • shunting support

    • MC-IPsec aware VRRP

Architecture

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

Figure 3. MC-IPsec architecture

MIMP

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.

Table 3. Master and backup chassis example

Master Standby

Tunnel Group 1

A

B

Tunnel Group 2

B

A

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.

MIMP protocol states

There are five MIMP states:

  • discovery

  • notEligible

  • eligible

  • standby

  • master

The five MIMP states are described as follows:

  • discovery

    Upon enabling MC-IPsec for the tunnel-group, for example:

    1. system starts up

    2. no shutdown MC-IPsec peer

    3. no shutdown MC-IPsec tunnel-group

    Functionally, this means blackhole traffic to the ISA and no shunting.

    If the peer is reached before the discovery-interval (configurable) has expired, then the state is changed to whatever the MIMP decides

    If the peer is not reached before the discovery-interval has expired, then the state is changed to eligible or notEligible depending on the oper-status of the tunnel-group.

  • notEligible

    The tunnel-group is operationally down. Functionally, this means blackhole traffic to the ISA and no shunting.

  • eligible

    The peer is not reachable or the associated BFD session is down but the tunnel-group is operationally up. Functionally, this means the ISA processes traffic.

  • standby

    Peer is reachable, elected standby. Functionally, this means blackhole traffic to ISA and shunting if possible.

  • master

    Peer is reachable, elected master. Functionally, this means the ISA processes traffic.

Election logic

The following election logic is executed when MIMP packets are exchanged.

  1. Calculate master eligibility.

    • Set masterEligible to TRUE if the local tunnel group is operationally up, otherwise FALSE.

    • Set peerMasterEligible to TRUE if the peer’s tunnel group is operationally up, otherwise FALSE.

  2. Elect based on eligibility.

    • If masterEligible and not peerMasterEligible, elect self master → DONE.

    • If not masterEligible and peerMasterEligible, elect peer master → DONE.

    • If not masterEligible and not peerMasterEligible, no master → DONE.

  3. Apply stickiness rules (mastership tends not to change).

    • If l was ‟acting master” and peer was not ‟acting master”, then elect self master -> DONE.

    • If 1 was not ‟acting master” and peer was ‟acting master”, then elect peer master -> DONE.

    An ‟acting master” is either in MIMP state ‟master” or ‟eligible”.

  4. Elect based on priority and number of active ISAs.

    • If my priority is higher than peer, elect self master → DONE.

    • If peer priority is higher than mine, elect peer master → DONE.

    • If I have more active ISA than peer, elect self master → DONE.

    • If peer has more active ISA than me, elect peer master → DONE.

The tie breaker:

  • If the local chassis’ MIMP source address is higher than the peer’s, elect self master → DONE.

  • Elect peer master → DONE.

Protection status

Each MC-IPsec-enabled tunnel-group has a ‟protection status”, which could be one of following:

  • notReady

    The tunnel-group is not ready for a switchover because there is either no elected standby to takeover, or there are pending IPsec states which need to be synced. If switchover occurs with this status, then there could be a significant traffic impact.

  • nominal

    The tunnel-group is in a better situation to switchover than notReady. However, traffic still may be impacted.

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

The show redundancy multi-chassis mc-ipsec peer <ip-address> tunnel-group <tunnel-group-id>” command can be used to check current protection status.

Other details

  • Mastership election is per tunnel-group.

  • MIMP is running in the base routing instance.

  • MIMP uses the configured value of the config>redundancy>multi-chassis>peer>source-address command as the source address. If not configured, then system address is used.

  • The priority range is from 0 to 255.

  • When an mc-ipsec tunnel-group enters standby from acting master, the tunnel-group is restarted.

  • When a tunnel-group enters an admin shutdown state under the mc-ipsec configuration (add a tunnel-group to mc-ipsec configuration, or upon admin shutdown of an mc-ipsec enabled tunnel group):

    • All tunnels in the tunnel-group are deleted/reinstalled to the ISA.

    • All IKE states associated with those tunnels are locally purged from the MS-ISAs.

    • No IKE messages are sent to the IKE peer.

    These behaviors occur regardless of the presence of a redundant chassis or the state of a redundant chassis.

  • With MC-IPsec enabled:

    • auto-establish is blocked.

    • For DPD configuration, only no dpd and dpd configurations with reply-only are allowed.

Routing

Routing in public service

A /32 route of the local tunnel address is created automatically for all tunnels on the MC-IPsec enabled tunnel-group.

This /32 route can be exported to a routing protocol by a route policy. The protocol type in route-policy is IPsec.

To attract traffic to the master chassis, a route metric of these /32 routes could be set according to the MIMP state, a metric from the master chassis is better than a metric from the standby chassis. There are three available states that can be used in the from state command in the route policy entry configuration:

  • IPsec-master-with-peer

    • Corresponding MIMP states: master

  • IPsec-master-without-peer

    • Corresponding MIMP states: eligible

  • IPsec-non-master

    • Corresponding MIMP states: discovery/standby

However, if the standby chassis receives IPsec traffic, the traffic is shunted to the master chassis by forwarding to a redundant next-hop. The redundant next-hop is an IP next-hop in the public routing instance.

Routing in private services

For static LAN-to-LAN tunnels, the static route with the IPsec tunnel as the next-hop could be exported to a routing protocol by a route policy. The protocol type remains static. For dynamic LAN-to-LAN tunnels, the reverse-route could be exported to a routing protocol by a route policy. The protocol type is ipsec. For remote-access tunnel, the private interface route could be exported to a routing protocol by a route policy.

Similar to routing in public services, the route metric of the above the routes could be set according to the MIMP state. Only a static route with an IPsec tunnel as the nexthop and reverse route has an MIMP state.

If the standby chassis receives IPsec traffic, the traffic is shunted to the master chassis by forwarding to a redundant next-hop. The redundant next-hop is an IP next-hop in a private routing instance.

Other details about shunting

Shunting only works when tunnel-group is operationally up.

Shunting is not supported over auto-bind tunnels.

MC-IPsec aware VRRP

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.

Synchronization

To achieve stateful failover, IPsec states are synced between chassis by using the MCS protocol.

  • Only successfully created SA after a completed INITIAL EXCHANGES or CREATE_CILD_SA EXCHANGES is synced.

  • Upon switchover, the new standby chassis reboots the tunnel-group.

  • The ESP sequence number is not synced except for the high 32 bits of extended sequence numbers.

  • The CLI configuration is not synced.

The time must be the same on both chassis (using NTP/SNTP to sync to the same server is an option).

Automatic CHILD_SA rekey

Because the ESP sequence number is not synced, a CHILD_SA rekey for each tunnel is initiated by the new active chassis to reset the sequence number upon switchover.

Encryption of Synced States

Transport encryption of synced IPsec states can be configured using the config> redundancy>multi-chassis>peer>sync>transport-encryption>application ipsec command, with the ipsec parameter as the keychain name. This causes the system to encrypt the IPsec states during transportation between the active and standby.

The key used to encrypt states is specified by the referenced keychain, which is defined in the config>system>security>keychain context. The keychain provides the user the ability to gracefully enable or disable encryption or change the key.

Gracefully enable encryption steps

To use a keychain for MCS IPsec, the keychain aes-128-gcm-16 entry algorithm must be configured.

Use the following steps to gracefully enable encryption. Chassis A and chassis B must both run releases that support the transport-encryption feature. Chassis A is active and chassis B is standby.

  1. On chassis B, change the configuration to add MCS encryption, using a keychain with two bidirectional entries in the configure system security keychain direction bi entry.
    • For entry-1, use the following values:

      • For entry-id, use null-key.

      • For begin-time, use now.

      • For tolerance, use forever.

    • For entry-2, use the following values:

      • For algorithm, use aes-128-gcm-16.

      • For begin-time: t1, add enough time to complete the next step (for example, if the current time is 2019/4/18 10:00 UTC, then add one hour to complete step 2, begin-time 2019/4/18 11:00 UTC).

    Because both chassis A and chassis B are still using clear transport, A can successfully synchronize states to B.

  2. On chassis A, change the configuration to add MCS encryption, using a keychain with two bidirectional entries in the configure system security keychain direction bi context:
    • For entry-1, use the following values:

      • For entry-id, use null-key.

      • For begin-time, use now.

      • For tolerance, use forever.

    • For entry-2, use the following values:

      • For algorithm, use aes-128-gcm-16.

      • For begin-time: t1, use the same value as in step 1 , begin-time 2019/4/18 11:00:00 UTC.

    Because both A and B can receive either clear or encrypted states, synchronization is successful.

  3. After t1, remove entry-1 from both chassis using the configure system security keychain direction bi no entry 1 command

For an example configuration, see Configuring MCS encryption

Gracefully change the key steps

Use the following steps to gracefully change the key. Chassis A and chassis B both have configured transport-encryption where chassis A is active and chassis B is standby.

  1. On Chassis B, change the configuration to add a new keychain, entry-y, with a new key:
    • entry-x (the old entry)

      For tolerance, use forever (this step can be performed without administratively disabling the entry).

    • entry-y:

      • For algorithm, use aes-128-gcm-16.

      • For begin-time: t1, add enough time to ensure the there is enough time to complete the next step (for example, if the current time is 2019/4/18 10:00 UTC, then add one hour to complete step 2, begin-time 2019/4/18 11:00 UTC).

    At this point, both A and B are still configured to use the old key (entry-x) for transport, so A successfully synchronizes states to B.

  2. On chassis A, change the configuration to add a new keychain, entry-y, with new key:
    • entry-x (the old entry)

      For tolerance, use forever (this can be performed without shutting down the entry).

    • entry-y:

      • For algorithm, use aes-128-gcm-16.

      • For begin-time: t1, use the same value as in step 1. begin-time 2019/4/18 11:00 UTC.

  3. After t1, both A and B begin to use entry-y. Remove entry-x from both chassis using the configure system security keychain direction bi no entry x command.

MC-IPsec Responder only

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.

N:M MC-IPsec redundancy

In addition to 1:1 MC-IPsec, the system also supports N:M multi-chassis IPsec stateful redundancy. The term N:M is used to refer to this feature. N:M provides additional redundancy and potential cost saving compared to 1:1 MC-IPsec.

N:M allows overall N active nodes and tunnel groups to be backed up by the M standby node and tunnel group. The number represented by N can be larger than, equal to, or smaller than the number represented by M.

The following graphic shows a typical N:M configuration.

Figure 4. N active nodes backup by M standby nodes

Redundancy domain

The granularity of protection for N:M is per tunnel group. For each to-be-protected tunnel group (a redundancy domain). It is a 1:1 mapping between the tunnel group and domain. Each domain contains up to four nodes. Among the possible nodes are the following:
  • One node is elected to be the active node for the tunnel group

  • Other nodes are the standby node for the tunnel group

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.

Redundancy role

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.

ISA tunnel-member pool

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.

By default, the synced tunnel states are only downloaded to ISA on switchover. When the optional High Availability (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.

Redundancy state and protection status

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

Election

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.

The election is done through evaluation using the following ordered rules. The evaluation stops when a single winner is left.
  1. DA is preferred over DS.

  2. With the same designated role, the node with a higher priority is preferred.

  3. With the same designated role and priority, the node with the higher router ID is preferred. MIMPv2 uses the router ID as the node identification. This can be different from the MIMPv2 packet’s IP address.

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.

Domain 1 contains node A, B, C, and D:

Table 4. Election of nodes

Node

Designated role

Operational role

Priority

A

DA

OA

200

B

DA

OS

100

C

DS

OS

200

D

DS

OS

150

If node A fails, then the following occurs.

  1. First, node A fails over to node B, because B is DA and C and D are DS. DA is preferred over DS.

  2. If node B is not able to recover (if node B also failed), then it fails over to node C because both C and D are DS. Node C has the higher priority and as a result is selected as OA.

  3. Lastly, if both node B and C are unable to cover, the only available node D is elected as OA.

Revertive

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.

DA versus DS

The following table summarizes the differences between DA and DS.

Table 5. DA and DA differences

DA

DS

ISA member

N/A. Requires a dedicated ISA for each tunnel group.

ISA member pool allows sharing the ISA across multiple tunnel groups.

Sync

Synchronized states are pre-downloaded to the ISA. There is less traffic impact during failover.

Synchronized states are kept on the CPM and downloads to the ISA only upon failover.

An optional HA mode allows pre-downloading states to ISA and activating upon switchover.

Election

DA is preferred over DS

Revertive failover

A DS challenger cannot assume the OA role from a DA node.

admin ipsec display-key

Supported in case of both OA and OS.

Only supported as OA.

State synchronization

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.

Routing

Like 1:1 MC-IPsec, only an OA in the domain can process IPsec traffic, therefore it is required to always attract traffic to the OA node. This is achieved by MC-aware routing, where the same IPsec routes are advertised from all nodes in a domain. The route advertised by OA has best metric, so traffic is attracted to it. This is achieved by using a route policy that sets different metrics according to the redundancy state of the tunnel group that the routes belong to. The system supports the following states in the route policy:
  • IPsec-master-with-peer

    The corresponding redundancy states are active.

  • IPsec-master-without-peer

    The corresponding redundancy states are eligible.

  • IPsec-non-master

    The corresponding redundancy states are discovery, standby, or notEligible.

VRRP

As with 1:1 MC-IPsec, N:M also supports MC-aware VRRP by using following command:
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.

Shunting

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.

Responder only

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 

Coexisting tunnel groups

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.

Configuring N:M

The following configurations are required across all nodes:
  • IPsec-specific configurations, such as IKE policy, transform, IPsec tunnel, IPsec gateway, and so on

  • N:M redundancy configurations require the following:
    • configure redundancy multi-chassis peer mc-ipsec domain

    • Refer to the domain parameter with the configure redundancy multi-chassis peer mc-ipsec domain command.

    • Enable MCS with the configure redundancy multi-chassis peer sync ipsec command.

  • For the VRRP routing configuration, use the MC state in the route policy and VRRP policy.

  • Shunting configurations require the following:

    • Use either of the following commands to specify the shunt interface name and next-hop address.
      configure router ipsec multi-chassis-shunt-interface
      configure service vprn ipsec multi-chassis-shunt-interface
    • Use either of the following commands to specify the shunt interface to use for a specific peer.

      configure router ipsec multi-chassis-shunting-profile
      configure service vprn ipsec multi-chassis-shunting-profile
    • Refer to the following command configured under the public or private tunnel interface.

      multi-chassis-shunting-profile

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

The following example shows a DA in an N:M redundancy configuration.

MD-CLI

[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 {
            }
        }
    }

classic CLI

*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

The following example shows a DA of a route policy configuration on the private side.

MD-CLI

[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"]
                }
            }
        }
    }

classic CLI

*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

The following example shows a shunting configuration on the private side.

MD-CLI

[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"

classic CLI

*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"

The following example shows an ISA member pool configuration example for DS tunnel-groups. A single ISA 1/2 is shared by two DS tunnel-groups.

MD-CLI

[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 { }
    }

classic CLI

*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

IPsec deployment requirements

The following information describes requirements to deploy SR OS IPsec features.

IPsec general

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

  • The IKE_SA lifetime on one side should be approximately twice as large as the other side. The CHILD_SA lifetime on one side should be approximately two or three times larger than the other side.

  • With the previous rule, the lifetime of the side with smaller lifetime should not be too small:

    • IKE_SA: >= 86400 seconds

    • CHILD_SA: >= 3600 seconds

  • With first rule, on the side with the smaller lifetime, the IKE_SA lifetime should be at least three times larger than CHILD_SA lifetime.

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

    On a public interface, a SAP ingress QoS policy should be configured to ensure the IKE packet is treated as high QoS priority.

  • The correct system time is required for certificate authentication to work properly.

  • The peer’s DPD interval must be larger than 30 seconds and should not send a DPD request if it receives IKE or ESP traffic.

MC-IPsec specific

The following are requirements for MC-IPsec specific deployments:

  • The IKEv2 lifetime requirements from IPsec general should be applied with special care to MC-IPsec deployments.

    In an MC-IPsec deployment where the MC-IPsec pair peers with single, non-redundant IKE clients, the IKEv2 lifetime requirements must be applied with the larger lifetimes configured on the MC-IPsec pair.

    An MC-IPsec deployment where one MC-IPsec pair peers with another MC-IPsec pair is not recommended. MC-IPsec performs optimally when the multi-chassis pair peers with a single IKE entity. If such a peering (MC-to-MC) is created, the above IKEv2 lifetime requirements should still be followed. However, with one side nominated to be the primary rekey initiator and having the smaller configured lifetimes.

  • Responder-only configuration is a mandatory requirement for all types of tunnels on the MC-IPsec pair in the usual deployment scenario of a MC-IPsec pair peering with single, non-redundant IKE clients.

  • DPD on the peer side (following the DPD requirement in the above IPsec General section), dpd interval 300 max-retries 3 reply-only on the MC-IPsec side.

  • Dedicated, redundant, direct physical link between chassis with enough bandwidth for MCS and shunting traffic.

    MIMP/MCS and BFD for MC-IPsec traffic must be forwarded over resilient links so that a single IOM/IMM, MDA or port failure does not cause the MIMP to go down. Because this control traffic is forwarded in the base routing instance, the base routing instance links need to spread over multiple ports on multiple IOM/IMMs. Proper QoS configuration is needed to make sure the control traffic gets the highest priority.

  • A MC-IPsec switchover when the protection status is not nominal may result in unexpected behavior and traffic loss. A nominal state must be reached on both MC-IPsec chassis before a MC-IPsec switchover is triggered.

  • When using VRRP in the public service and a chassis failure occurs, the VRRP/Layer 2 network should re-converge before the MC-IPsec switchover occurs. One way to speed up VRRP switchover is to bind a BFD session to VRRP.

  • The system time of the master and standby chassis must be the same. One way to achieve this is for both chassis to sync to an NTP or SNTP server.

  • The CLI configuration is not synchronized via MCS so the user must provision the same IPsec-related configurations on the master and standby chassis. This includes using the same IKE policy ID, tunnel template ID, public or private interface name, and so on.

  • For an MC-IPsec shunting interface, only one next-hop address is supported; in case of multiple redundant next hops configured using the same shunting interface, the last next hop configured is used.

N:M specific

The following are requirements for N:M-specific deployments.

  • All MC-IPsec specific requirements also apply to N:M.

  • A fully meshed MIMPv2/MCS peering is required between all participating nodes for a specific domain.

  • When adding a node to a domain, ensure that the previous nodes in the domain have fully meshed MIMPv2/MCS peering before adding the new node.

IKEv2 remote-access tunnel

Since 11.0R6, SR OS supports IKEv2 remote-access tunnel, the difference between a remote-access tunnel and LAN-to-LAN tunnel is remote-access tunnel allows client to request an internal address (and other attributes like DNS address) via IKEv2 configuration payload. The SR OS supports IKEv2 remote-access tunnel with following features:

  • authentication methods:

    • pre-shared-key with RADIUS (psk-radius) or without RADIUS (psk)

    • certificate with RADIUS (cert-radius) or without RADIUS (cert)

    • EAP/EAP-Only with RADIUS

  • internal address assignment via IKEv2 configuration payload

  • address assignment support:

    • RADIUS server based

    • local address assignment

  • RADIUS accounting to report address usage

  • RADIUS disconnect message to remove tunnel

  • NAT-Traversal support

  • support MC-IPsec

The SR OS only supports address assignments in first CHILD_SA negotiation.

IKEv2 remote access tunnel – RADIUS-based PSK/certificate authentication

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.

Figure 5. Call flow for psk-radius/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.

IKEv2 remote-access tunnel – EAP authentication

The SR OS supports EAP authentication for a IKEv2 remote-access tunnel, in which case, the system acts as an authenticator between an IPsec client and a RADIUS server. It transparently forwards EAP messages between the IKEv2 session and RADIUS session. Thus, the actual EAP authentication occurs between the client and the RADIUS server.

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

Figure 6. Typical call flow of EAP authentication

EAP authentication is enabled by configuring authentication eap. When enabled, after the received IKE_AUTH request from the client, the system sends an EAP-Response/ID with IDi as the value in the access-request to AAA. AAA returns a method request and the system starts passing through between the client and AAA. (as shown in Typical call flow of EAP authentication).

The generation of the AUTH payload in the IKE_AUTH response sent by the SR OS (message 4 in flow shown above) is dependent on the own-auth-method configuration:

psk
The AUTH payload is present and generated by using PSK.
cert
The AUTH payload is present and generated by the configured public and private key pairs as it does in certificate authentication. Any needed certificates are also sent.
eap-only
Neither AUTH nor CERT payload is present.

The RADIUS attributes in authentication and accounting packets are similar as psk-radius and cert-radius with following differences:

  • RADIUS attributes support EAP-Message/Message-Authenticator/State attributes.

  • RADIUS attributes support Access-Challenge packet.

  • RADIUS attributes support MS-MPPE-Send-Key/ MS-MPPE-Recv-Key in access-accept. These two attributes are required for all EAP methods that generate MSK.

The system provides a method to support EAP and other authentication methods on the same ipsec-gw policy. This is enabled by configuring auto-eap-radius or auto-eap as the auth-method in the ike-policy.

With auto-eap-radius:

  • If there is no AUTH payload in an IKE_AUTH request, then the system uses EAP to authenticate the client and also uses own-auth-method to generate the AUTH payload.

  • If there is an AUTH payload in the IKE_AUTH request, the system uses auto-eap-own-method to generate the AUTH payload.

    • If the auto-eap-method is psk, then the system proceeds as auth-method: psk-radius.

    • If the auto-eap-method is cert, then the system proceeds as auth-method: cert-radius.

    • If auto-eap-method is psk-or-cert, then:

      • If the Auth Method field of the AUTH payload is PSK, then the system proceeds as auth-method:psk-radius.

      • If the Auth Method field of the AUTH payload is RSA or DSS, then the system proceeds as auth-method:cert-radius.

With auto-eap:

  • If there is no AUTH payload in IKE_AUTH request, then the system uses EAP to authenticate the client and also uses own-auth-method to generate AUTH payload.

  • If there is an AUTH payload in the IKE_AUTH request:

    • If the auto-eap-method is psk, then the system proceeds as auth-method: psk.

    • If the auto-eap-method is cert, then the system proceeds as auth-method: cert.

    • If the auto-eap-method is psk-or-cert, then:

      • If the Auth Method field of the AUTH payload is PSK, then the system proceeds as auth-method psk.

      • If the Auth Method field of the AUTH payload is RSA or DSS, then the system proceeds as auth-method cert-auth.

The system uses auto-eap-own-method to generate the AUTH payload.

IKEv2 remote-access tunnel – authentication without RADIUS

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.

Figure 7. Typical call flow of certificate or PSK authentication without RADIUS

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

Figure 8. 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

IKEv2 remote-access tunnel – address assignment

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.

DHCPv4 address assignment

The client’s hardware address field (chaddr) in the DHCPv4 header is generated by the SR OS:

  • The first 2 bytes of the MAC address are 02:03.

  • The remaining 4 bytes are the hash result of IKEv2 IDi.

The following options are included in the DHCPv4 packets sent by the SR OS:

  • Option 82 circuit-id (private-SAP-id | private-interface-name; for example, tunnel-1.private:100 | priv-int)

  • Option 82 remote-id (IKEv2 IDi in text format)

  • Option 61 client-id is 1 byte that represents the IKEv2 IDi type plus the IKEv2 IDi in text format. The value of the first byte is as follows:

    • ID_IPV4_ADDR = 1

    • ID_DER_ASN1_DN = 2

    • ID_FQDN = 3

    • ID_RFC822_ADDR = 4

    • ID_IPV6_ADDR = 5

DHCPv6 address assignment

Because the system performs a DHCP relay function, all DHCPv6 packets sent or received are encapsulated in DHCPv6 relay-forward and relay-reply messages.

The following items are values of key fields and options in DHCPv6 packets sent by the system:

  • Hop-count (0)

  • Link address (configurable via the CLI)

  • Peer-address (auto-generated based on the IKEv2 IDi)

  • Option 1 Client Identifier

    • DUID type (2)

    • Enterprise ID (6527)

    • Value is 1 byte that represents the IKEv2 IDi type plus the IKEv2 IDi in text format. The value of the first byte is the same as that of the first byte in Option 61 for DHCPv4.

  • Option 16 Vendor Class

    • Enterprise ID (6527)

    • Value (string ‟SROS IPsec”)

  • Option 18 Interface ID (private-SAP-id | private-interface-name; for example, tunnel-1.private:100 | priv-int)

  • Option 37 Remote Identifier

    • Enterprise ID (6527)

    • Value (IKEv2 IDi in text format)

DHCPv4/v6 usage notes

  • Using a local DHCP server on the same chassis for DHCP-based address assignment is not supported. The DHCP server must be external.

  • IPsec DHCP Relay uses only the gi-address configuration found under the IPsec gateway and does not take into account gi-address with src-ip-addr configuration below other interfaces.

  • The relay-proxy command (config>service>vprn>if>dhcp>relay-proxy) must be enabled on an interface that has a gateway IP address as the interface address for the interface to use a DHCPv4 address assignment. The system ignores other DHCP or DHCPv6 configurations on the interface, with the exception of the relay-proxy configuration.

    • If the DHCP server resides in a private service, and the gi-address is an address configured on the corresponding tunnel interface, then relay-proxy must be enabled on the corresponding private interface.

    • If the DHCP server resides in a routing instance that is different from the private service, then there must be an interface (such as a loopback interface) in the routing instance that has the gi-address as the interface address, and gi-address must be routable for the DHCP server. Also, relay-proxy must be enabled on the interface in the routing instance.

The biggest difference between the LAA and DHCP-based methods is that LAA uses a local API to get an address from a local pool. There is no DHCP packet exchange for LAA, while a DHCP-based method uses standard DHCP packet exchange to request a packet from an external DHCP server.

Because there are three methods for address assignment, the following is the priority order (descending) of sources to choose if more than one source is configured:

  • LAA

  • DHCP

  • RADIUS

There is no fallback between the different sources.

LAA/DHCP can work with an authentication method that does not involve RADIUS, as well as with an authentication method that involves RADIUS. When using LAA/DHCP with an authentication method that involves RADIUS, the following applies:

  • LAA/DHCP only happens after RADIUS is successfully authenticated.

  • The address information returned by the RADIUS server is ignored (even if LAA/DHCP is configured but is shut down).

  • Non-address-related attributes in access-accept messages such as Alc-IPsec-Serv-Id and Alc-IPsec-Tunnel-Template-Id are still accepted.

  • RADIUS accounting is supported in this case, but the Framed-IP-Addr/Framed-IPv6-Prefix reported in the acct-request packet is the LAA/DHCP assigned address, not the address returned by the RADIUS server.

  • RADIUS disconnect messages are supported.

For MC-IPsec:

  • With LAA, the configuration of config>redundancy>multi-chassis>peer >sync local-dhcp-server is not needed. This is because the assigned address is synchronized as part of the IPsec tunnel states.

  • Consider the following about DHCP:

    • The DHCP packet exchange process only occurs on the master chassis.

    • The assigned address is synchronized to the standby chassis as part of the IPsec states. The standby chassis does not initiate any DHCP exchanges.

    • The configured DHCP server address (ipsec-gw>dhcp>server) should be the same on both chassis.

    • After an MC switchover:

      • The new master does not initiate any DHCP process unless it is time to renew an address or a tunnel goes down.

      • If a new master needs to renew an address or release an address, it sends the DHCP packet to the same DHCP server address that assigned the address on the old master, assuming the external DHCP server is still on, and the renew or release is processed normally.

      • If the new master needs to assign an address for a new tunnel setup, it sends a DHCP discovery or solicit message to all configured DHCP server addresses and then pick the first offer or advertise to finish the DHCP process.

    • For DHCPv4, a gateway IP address is used by the server to forward a response back, so the gateway IP address must be an interface address of the router. For multi-chassis operation, if a DHCPv4 server resides in a private VPRN, there are two options:

      • Configure the same private interface address on both chassis and then use it as the gateway IP address. Configure MC-IPsec-aware routing to make sure that the DHCP response is directed to the master.

      • Configure different private interface addresses with the same subnet on both chassis. The gateway IP address is the private interface address of the local chassis. As well as the private subnet, two /32 private interface address routes from two chassis also need to be advertised so that the DHCP response is routed to the correct chassis.

      If the DHCPv4 server does not reside in a private VPRN, then one method is to configure a loopback interface with a /32 address in the private subnet, and the loopback interface address is used as the gateway IP address. Different addresses must be configured on the master and standby chassis.

    • For DHCPv6, unlike DHCPv4, the link-address is not used for the server to forward responses back. The DHCPv6 server sends responses to the source address of the request. This typically is the egress interface address when the system sends out the relay-forward message. For MC-IPsec, no special configuration is required as long as the DHCPv6 server can route relay-reply messages back to the correct chassis.

IPv6 IPsec support

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

  • IPv6 packets as the ESP tunnel payload

  • IPv6 as the ESP tunnel encapsulation

IPv6 as payload

IPv6 as payload allows IPv6 packets to be forwarded within an IPsec tunnel. Current support includes the following:

  • Tunnel type support includes:

    • static LAN-to-LAN tunnel

    • dynamic LAN-to-LAN tunnel

    • remote-access tunnel (only IKEv2 is supported)

  • The prefix length of the IPv6 address on a private interface must be /96 or longer.

IPv6 as payload: static LAN-to-LAN tunnel

There are three methods to forward IPv6 traffic into static tunnels on the private side:

  • The destination address is a configured destination IP (dest-ip) under the tunnel context.

    • The dest-ip can be either an IPv6 address or an IPv4 address.

    • In the case of IPv6, it must be either an IPv6 global unicast address or an IPv6 link-local address.

    • In the case of IPv4, it can be used to forward IPv4 traffic into the tunnel.

    • In case of unicast address, dest-ip must be within the prefix configured on the private interface.

    • Up to 16 destination IPs can be configured per ipsec-tunnel.

  • A v6 route with a configured destination IP as the next-hop, this route can be learned from either a static or dynamic from a routing protocol such as BGP.

  • An IPv6 static route with an ipsec-tunnel used as the next-hop.

A security policy supports either an IPv4 entry or an IPv6 entry or both for dual-stack.

IPv6 as payload: dynamic LAN-to-LAN tunnel

With dynamic LAN-to-LAN tunnels, the system automatically creates a v6 reverse route in the private VPRN based on the received TSi payload with the tunnel as the next hop.

IPv6 as payload: remote-access tunnel

The system supports the following IKEv2 IPv6 configuration attributes:

  • INTERNAL_IP6_ADDRESS

  • INTERNAL_IP6_DNS

The system supports only one internal IPv6 address per tunnel. The following IPv6-related RADIUS attributes are also supported in access-accept:

  • Framed-IPv6-Prefix is translated into INTERNAL_IP6_ADDRESS in the configuration payload, which includes two parts. A 16-byte v6 prefix and a one-byte prefix length.

  • Alc-Ipv6-Primary-Dns

  • Alc-Ipv6-Secondary-Dns

If an internal v6 address has been assigned to the remote-access client, then the Framed-IPv6-Prefix is also included in RADIUS accounting-request packet. The assigned internal v6 address must be within the prefix configured on the corresponding private interface.

If the client request both v4 and v6 address and address source (such as RADIUS or LAA) assign both v4 and v6 address, then both v4 and v6 addresses are assigned to the client via the configuration payload.

IPv6 as encapsulation

IPv6 as encapsulation allows IPv4 or IPv6 packets to be forwarded within an IPv6 ESP tunnel, also the IKE protocol can run over IPv6. Current support only includes tunnel type support:

  • static LAN-to-LAN tunnel

  • dynamic LAN-to-LAN tunnel

  • remote-access tunnel (For IKEv1, only v4 over v6 is supported)

For an ipsec-gw or ipsec-tunnel, only one local gateway address is supported, which could be either an IPv4 or IPv6 address. The SR OS also provides fragmentation and reassembly support for IPv6 ESP/IKE packets.

MLDv2 over IPsec

The system supports replicating IPv6 multicast traffic into IKEv2 IPsec tunnels based on the MLDv2 report received from the IPsec client.

If a client needs to receive IPv6 multicast traffic over an IPsec tunnel, it includes corresponding multicast address ranges in the traffic selector during CHILD_SA negotiation. After the CHILD_SA is created, the client sends an MLDv2 report to join specific multicast groups over the CHILD_SA. The SeGW terminates the MLDv2 report message and begins replicating requested multicast traffic into the CHILD_SA.

Internally, the system treats each multicast-enabled CHILD_SA as an MLD interface called ipsec-interface in various multicast show commands.

This feature supports only IPv6 multicast with MLDv2 and Source Specific Multicast (SSM).

This feature supports only IKEv2 tunnels. For IKEv2 static tunnel, this feature only supports a single child SA per tunnel for multicast traffic.

MLDv2 over IPsec – traffic selector

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 – configuration

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.

Secured interface

A secured interface secures traffic forwarded through a specified IP interface, through one or multiple Secure Interface Tunnels (SI Tunnels) configured under the interface. SI tunnel is conceptually the same as traditional static IPsec tunnels. Some differences are:

  • SI tunnels are configured under an IP interface, while static IPsec tunnels are configured under the private tunnel SAP of a tunnel interface.

  • With an SI tunnel, the following objects are created automatically with an SI tunnel configuration. There is no need for a separate configuration tunnel configuration:

    • public tunnel SAP

    • public interface

    • private tunnel SAP

    • private tunnel interface

  • The public service of SI tunnel is the same service of secured interface, which could be either Base router, an IES or an VPRN service.

  • The local tunnel address of the SI tunnel must be one of interface addresses of the secure interface. If the secure interface is unnumbered, then it must be one of the interface address of the interface specified by the unnumbered configuration.

  • Private service is the same as the public service. The user could also specify a different service.

  • On the public side:

    • With a secured interface, by default, all traffic ingress the interface are subject to IPsec processing. If the received traffic is not IPsec traffic (such as ESP and IKE), it is dropped. This behavior can be changed by configuring an ip-exception or ipv6-exception filter under the interface. All ingress traffic matching the ip-exception or ipv6-exception filter bypasses IPsec processing and is forwarded through normal routing methods.

    • The system forwards all SI tunnel traffic (after encryption and encapsulation) out through the corresponding secured interface.

    • SSH traffic toward the local system and MPLS/SDP always bypasses IPsec processing.

  • On the private side:

    • Like a static IPsec tunnel, traffic is routed into the SI tunnel through a static route or BGP route.

    • When an SI tunnel is operationally down, routes using the next-hop address as the tunnel are unresolved and withdrawn from the route table.

  • show, debug, tool, clear, and admin commands that apply to static IPsec tunnels also apply to SI tunnels.

  • The following features are not supported with SI tunnels on 7705 SAR-Hm (with cellular exit port):

    • Dest-ip

    • MC-IPsec

    • IPv4 over IPv6

    • IPv6 over IPv6

    • MLDv2 over SI tunnel

  • The following features are not supported with SI tunnels on VSR:

    • Dest-ip

    • MC-IPsec

    • MLDv2 over SI tunnel

  • SI tunnel are only supported in VSR and 7705 SAR-Hm families.

IPsec client database

The IPsec client database is a database configured in the (config>ipsec>client-db) CLI context, which can be used to authenticate and authorize IKEv2 dynamic LAN-to-LAN tunnels.

Each client database contains one or more client entries. When the system receives a new tunnel request, it performs a look up in the associated database of the IPsec gateway (ipsec-gw). If there is match, the system optionally could use credentials configured in the matched client entry to authenticate the peer. If the authentication succeeds, then, optionally, the matched entry could also return certain IPsec parameters such as the private service ID which can be used for tunnel setup.

If the client database lookup failed to return a match result, then the system can either fall back to the ipsec-gw level configuration or fail the tunnel setup. The action to take depends on the CLI configuration.

The system supports one of the following as matching input:

  • the peer’s tunnel IP address

  • the peer’s IDi

  • a combination of both

The above matching input is defined in the match-list context in the client-db configuration. Each client entry contains client matching criteria that corresponds to the match list. The system correlates matching input with the client matching criteria of each client entry in the client-db configuration. The system supports the following matching methods:

  • for the peer's IDi

    • Any matches any IDi.

    • IPv4/IPv6 prefix matches the peer’s address type IDi to a configured prefix. It is considered a match if the IDi falls within the prefix.

    • FQDN matches the peer’s FQDN type IDi to a string. This supports a complete string match or a suffix string match.

    • RFC822 matches the peer’s RFC 822 type IDi to a string. This supports a complete string match or suffix string match.

  • for the peer's tunnel IP address

    • Matches the peer’s tunnel address to a configured prefix. It is a match if the IDi fall within the prefix.

    • IPv4 Any matches any IPv4 address.

    • IPv6 Any matches any IPv6 address.

Each client entry has a client index (an integer). This is different from a client identification. If there are multiple matched entries in a lookup, the client entry with the smallest client index is used. The client entry supports using a pre-shared key as the credential.

If the credential is not configured in the matched entry, the credential configured under the ipsec-gw context is used.

A client entry could optionally return the following IPsec parameters:

  • a private service ID

  • a private interface name

  • a tunnel-template ID

  • a Ts list

The returned parameter overrides the configuration of the ipsec-gw level.

There is only one client-db for each ipsec-gw, but different ipsec-gw configurations can use the same client-db.

Note that the encapsulated-ip-mtu command in the client-db returned tunnel-template is not applied to the IKE packet fragmentation. The encapsulated-ip-mtu command configured in the config>ipsec>tunnel-template context is used instead. However, the client-db returned encapsulated IP MTU value still applies to the ESP packet fragmentation.

Note:
  • A client entry in a shutdown state is skipped while the system performs the matching process.

  • If the configuration returned by client-db is invalid, the system fails the tunnel setup.

  • The reference of the client-db under the ipsec-gw context can be changed without shutting down ipsec-gw

  • Shutting down a referenced client-db without shutting down ipsec-gw is allowed and the established tunnel is not impacted. The system uses the configuration on the ipsec-gw level for new a tunnel request while the client-db is shutdown if a fallback is configured.

  • Adding a new client in a referenced client-db without shutting down ipsec-gw or client-db is allowed.

  • Removing a client in the referenced client-db without shutting down ipsec-gw or client-db is allowed. However, the shutdown of the client to be removed is required.

  • Changing an existing client of a referenced client-db without shutting down ipsec-gw or client-db is allowed. However, the shutdown of the client to be removed is required.

IPsec transport mode protected IP tunnel

Tunnel-group based GRE tunnels can be protected by applying IPsec transport mode encryption for the GRE tunnel packets. This is achieved by configuring an IPsec transport mode profile under the IP tunnel configuration. When the profile is enabled, the data path flow as follows in the private to public direction:

  • The payload packet is received on the private tunnel SAP.

  • Optionally perform pre-encapsulation fragmentation based on the payload packet size and ip-mtu configuration under the ip-tunnel context

  • The payload packet is encapsulated into a GRE tunnel packet.

  • The IPsec transport mode encryption is applied on the GRE tunnel packet which results in an IPsec ESP packet.

  • Optionally perform post-encapsulation fragmentation based on the ESP packet size and the configured encapsulated-ip-mtu under the ip-tunnel context

In the public to private direction, the data path flows as follows:

  1. The IPsec ESP packet is received on the public tunnel SAP.

  2. ESP packet reassembly is performed if it is fragmented.

  3. The ESP packet is decrypted, which results as a GRE tunnel packet.

  4. The GRE tunnel packet is decapsulated and the payload packet is forwarded out of the private tunnel SAP.

This feature uses IKEv2 to create an IKE_SA and a transport mode CHILD_SA for a specific GRE tunnel. The IKE/IPsec behaves similarly to an IPsec static LAN-to-LAN tunnel, with some transport-mode specific differences.

Packet format

The packet format of GRE with IPsec transport mode follows RFC 4303, IP Encapsulating Security Payload (ESP), Section 3.1.1. The following example shows an IPv4 GRE packet with IPsec transport mode enabled:

Figure 9. IPv4 GRE packet with IPsec transport mode enabled

The following example shows an IPv6 GRE packet with IPsec transport mode enabled:

Figure 10. IPv6 GRE packet with IPsec transport mode enabled

IKEv2 and SA

This feature only requires a single IKE_SA and CHILD_SA per GRE tunnel. Additional CHILD_SA creation requests from a CREATE_CHILD_SA peer exchange are rejected.

This feature uses IKEv2 USE_TRANSPORT_MODE notification to signal the use of the transport mode when the CHILD_SA is created. The system expects the notification to be included in both the request and response messages.

Traffic selector

As a CHILD_SA initiator, the traffic selector is proposed as follows:

  • address range (the source and destination GRE tunnel endpoint address, /32 or /128)

  • protocol (GRE)

  • port range (0 to 65535)

As a CHILD_SA responder, the system uses the same traffic selector to narrow the selection peer’s proposal.

Fragmentation and reassembly

ISA only fragments packets in the private to public direction. The following two types of fragmentation are used.

  • Fragment before GRE encapsulation is controlled by the ip-mtu in the ip-tunnel context.

  • Fragment after IPsec processing is controlled by the configured encapsulated-ip-mtu in the ip-tunnel context.

ISA only reassembles received ESP packets on the public side before IPsec decryption. The reassembly behavior is controlled by the reassembly command under the tunnel group.

QoS marking

QoS marking refers to the Type of Service field in IPv4 header or the Traffic Class field in the IPv6 header.

  • behavior in the private to the public direction

    If dscp dscp-name is configured under the IP tunnel, the configured value is used for the QoS marking in the GRE IP header. If DSCP is not configured, then the payload packet’s QoS marking is copied into the GRE IP header.

  • behavior in the public to private direction

    The received ESP packet is decrypted, and as a result, the GRE packet is decapsulated into a payload packet. The QoS marking of the original payload packet is preserved.

Configuring IPsec transport mode protected tunnels

For IPsec transport mode protected tunnels, include the following:

  • a GRE tunnel

  • IPsec parameters:

    • ike-policy ike-policy-id

    • ike-transform ike-transform-id

    • ipsec-transform transform-id

    • cert-profile profile-name or trust-anchor-profile name (the certificate authentication is required)

  • an ipsec-transport-mode-profile name referenced under the GRE tunnel

The following are Classic CLI configuration examples:

A:v70>config>ipsec# info
----------------------------------------------
        ike-transform 1 create
            dh-group 20
            ike-auth-algorithm auth-encryption
            ike-encryption-algorithm aes256-gcm16
            ike-prf-algorithm sha384
        exit
        ike-policy 1 create
            ike-version 2
            ike-transform 1
        exit
        ipsec-transform 1 create
            esp-auth-algorithm auth-encryption
            esp-encryption-algorithm aes256-gcm16
            pfs-dh-group 20
        exit
        ipsec-transport-mode-profile "test" create
            dynamic-keying
                ike-policy 1
                pre-shared-key "KrbVPnF6Dg13PM/biw6ErPl5XU7+" hash2
                transform 1
            exit
        exit


A:v70>config>service>vprn# info
----------------------------------------------
            interface "priv" tunnel create
                address 44.44.44.1/24
                sap tunnel-1.private:100 create
                    ip-tunnel "t1" create
                        dest-ip 44.44.44.2
                        gre-header
                        source 172.16.100.1
                        remote-ip 192.168.1.2
                        delivery-service 300
                        ipsec-transport-mode-profile "test"
                        no shutdown
                    exit
                exit
            exit

Configuring IPsec with CLI

Provisioning a tunnel ISA

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#

Configuring a tunnel group

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#

Configuring router interfaces for IPsec

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#


Configuring IPsec parameters

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 

Configuring IPsec in services

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#

Configuring X.509v3 certificate parameters

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

Configuring MC-IPsec

Configuring MIMP

The following is an MIMP configuration example.

config>redundancy>multi-chassis
----------------------------------------------
            peer 10.2.2.2 create
                mc-ipsec
                    bfd-enable
                    tunnel-group 1 create
                        peer-group 2
                        priority 120
                        no shutdown
                    exit
                exit
                no shutdown
            exit

The peer’s tunnel-group ID is not necessarily the same as the local tunnel-group ID. With bfd-enable, the BFD parameters are specified under the interface that the MIMP source address resides on, which must be a loopback interface in the base routing instance. The default source address of MIMP is the system address.

The keep-alive-interval and hold-on-neighbor-failure define the MIMP alive parameter, however, BFD could be used for faster chassis failure detection.

The SR OS also provides a tools command to manually trigger the switchover, for example:

tools perform redundancy multi-chassis mc-ipsec force-switchover tunnel-group 1

Configuring multi-chassis synchronization

The following displays an MCS for MC-IPsec configuration.

config>redundancy>multi-chassis>
----------------------------------------------
            peer 10.2.2.2 create
                sync
                    ipsec
                    tunnel-group 1 sync-tag "sync_tag_1" create
                    no shutdown
                exit

The following displays an MCS for MC-IPsec configuration with MCS encryption enabled.

config>redundancy>multi-chassis
            peer 10.20.1.2 create
                source-address 10.20.1.1
                sync
                    ipsec
                    tunnel-group 1 sync-tag "ipsec-t-grp-1" create
                    transport-encryption
                        application "ipsec" keychain "validMultiBi"
                        exit
                    exit
                    no shutdown
                exit
                mc-ipsec
                    bfd-enable
                    tunnel-group 1 create
                        peer-group 1
                        priority 255
                        no shutdown
                    exit
                exit
                no shutdown
            exit
        exit
----------------------------------------------

The sync-tag must match on both chassis for the corresponding tunnel groups.

Configuring routing for MC-IPsec

The following configuration is an example using a route policy to export /32 local tunnel address route:

config>router>policy-options>
----------------------------------------------
            policy-statement "exportOSPF"
                entry 10
                    from
                        protocol ipsec
                        state ipsec-master-with-peer
                    exit
                    action accept
                        metric set 500
                    exit
                exit
                entry 20
                    from
                        protocol ipsec
                        state ipsec-non-master
                    exit
                    action accept
                        metric set 1000
                    exit
                exit
                entry 30
                    from
                        protocol ipsec
                        state ipsec-master-without-peer
                    exit
                    action accept     
                        metric set 1000
                    exit
                exit
            exit

The following configuration shows shunting in public and private services.

Shunting in public service:

config>service>ies>
            interface "ipsec-pub" create
                address 172.16.100.254/24
                sap tunnel-1.public:100 create
                exit
                static-tunnel-redundant-next-hop 10.1.1.1
            exit

Shunting in private service:

config>service>vprn>
 interface "ipsec-priv" tunnel create
    …
                static-tunnel-redundant-next-hop 10.7.7.1
            exit

Shunting is enabled by configuring redundant next-hop on a public or private IPsec interface

static-tunnel-redundant-next-hop
shunting nexthop for a static tunnel
dynamic-tunnel-redundant-next-hop
shunting next-hop for a dynamic tunnel

Configuring MCS encryption

The following examples show the configuration for MCS encryption.

Keychain example 1

*A:vsim4>config>redundancy>multi-chassis>peer>sync>transport-encryption# 
----------------------------------------------
      application "ipsec" keychain ‟mcs”
      exit
----------------------------------------------
config>system>security# info
----------------------------------------------
   keychain "mcs"
      direction
        bi
          entry 2 key "KrbVPnF6Dg13PM/biw6ErIQyX4uD" hash2 algorithm aes-128-gcm-16
                begin-time 2019/03/22 18:50:00 UTC
          exit
       exit
     exit
     no shutdown
   exit

Keychain example 2

aes*A:vsim4>config>redundancy>multi-chassis>peer>sync>transport-encryption# 
----------------------------------------------
      application "ipsec" keychain ‟mcs”
      exit


*A:vsim4>config>system>security# info
----------------------------------------------
     per-peer-queuing
     keychain "mcs"
        direction
           bi
              entry 2 key "KrbVPnF6Dg13PM/biw6ErIQyX4uD" hash2 algorithm aes-128-gcm-16
                 begin-time 2019/03/22 18:50:00 UTC
              exit
              entry 3 key "/Ub6BWHC4DsEprLWutGaTcJz1zDPhw==" hash2 algorithm aes-128-gcm-16
                 begin-time 2019/03/22 21:30:00 UTC
              exit
              entry null-key
                 begin-time 2019/03/22 18:33:23 UTC
                 tolerance forever
              exit
           exit
        exit
        no shutdown
     exit

Configuring and using CMPv2

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.

Configuring OCSP

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

Configuring IKEv2 remote — access tunnel

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

Configuring IKEv2 remote — access tunnel with local address assignment

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

Configuring secured interfaces

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