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.
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.
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.
-
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.
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.
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.
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.
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.
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.
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:
-
system starts up
-
no shutdown MC-IPsec peer
-
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.
-
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.
-
-
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.
-
-
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”.
-
-
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.
-
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.
-
-
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.
-
- 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.
-
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.
-
-
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.
-
-
- 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.
Redundancy domain
-
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.
-
DA is preferred over DS.
-
With the same designated role, the node with a higher priority is preferred.
-
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:
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.
-
First, node A fails over to node B, because B is DA and C and D are DS. DA is preferred over DS.
-
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.
-
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:
-
The domain must be configured as revertive on the challenger.
-
The challenger must continuously have been in a redundancy state, which means on standby for the last 60 seconds.
-
The challenger must continuously have been in a protection status, that is, nominal for the last 60 seconds.
-
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.
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
-
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
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.
Provisioning requirements
There are specific provisioning requirement for N:M to work properly, see IPsec deployment requirements for details.
Configuring N:M
-
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.
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.
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.
Typical call flow for EAP authentication shows a typical call flow for EAP authentication.
In this configuration, the radius-authentication-policy and radius-accounting-policy in the ipsec-gw context are ignored.
RADIUS disconnect messages are supported in this case. Only the following tunnel identification methods are supported:
Nas-Port-Id + Framed-Ip-Addr(Framed-Ipv6-Prefix) + Alc-IPsec-Serv-Id
User-Name
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.
-
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:
-
The IPsec ESP packet is received on the public tunnel SAP.
-
ESP packet reassembly is performed if it is fragmented.
-
The ESP packet is decrypted, which results as a GRE tunnel packet.
-
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:
The following example shows an 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:
Generate a key.
admin certificate gen-keypair cf3:/key_plain_rsa2048 size 2048 type rsa
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
Send the certificate request to CA-1 to sign and get the signed certificate.
Import the key.
admin certificate import type key input cf3:/ key_plain_rsa2048 output key1_rsa2048 format der
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.
Import the CA certificate.
admin certificate import type cert input cf3:/ CA_1_cert.pem output ca_cert format pem
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