IP Tunnels
In This Section
This section provides an overview of IP Security (IPSec) software features for the IPSec ISA.
Topics in this section include:
IP Tunnels Overview
This section discusses IP Security (IPSec), GRE tunneling, and IP-IP tunneling features supported by the MS-ISA. In these applications, the MS-ISA/MS-ISA2 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: encrypted SDPs, video wholesale, site-to-site encrypted tunnel, and remote access VPN concentration.
Figure 33 shows an example of an IPSec deployment, and the way this would be supported inside a 7750 SR. GRE and IP-IP tunnel deployments are very similar. IP tunnels have two flavors GRE/IP-IP, in all but a few area the information for IP Tunnels applies to both types.
Figure 33: 7750 SR IPSec Implementation Architecture
Figure 33, 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 bi-directional 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
Data Plane:
- ESP (with authentication) Tunnel mode
- Authentication Algorithm: MD5/SHA1/SHA256/SHA384/SHA512/AES-XCBC
- Encryption Algorithm: DES/3DES/AES128/AES192/AES256
- Anti-Replay Protection
- N:M IPSec ISA card redundancy
SR OS will use a configured authentication algorithm in an ike-policy for Pseudorandom Function (PRF). IPsec features are supported on the 7750 SR and 7450 ESS running in mixed mode.
There are two types of tunnel interfaces and SAPs:
- 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:
- In the 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.
- In the 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 ISAs (each having mda-type isa-tunnel) or MS-ISA2s (mda-type isa2-tunnel) configured to handle the termination of one or more IPSec, GRE and/or IP-IP tunnels. Two example tunnel-group configurations are shown below:
A GRE, IP-IP, or IPSec tunnel belongs to only one tunnel group. There are two types of tunnel groups:
- 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.
- A multi-active tunnel-group can have multiple tunnel-ISAs designated as primary. This is only supported on 7750 SR-7/SR-12/SR-12E/c-12 with chassis mode D, 7450 ESS in mixed mode with IOM3, or 7750 SR c-12.
The show isa tunnel-group command allows the operator to view information about all configured tunnelgroups.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.
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.
Private Tunnel SAPs
The private service must have an IP interface to a GRE, IP-IP, or IPSec tunnel in order 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.
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 will not be 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 (prior to 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 will not come up. In the CLI sub-tree under ip-tunnel, there are commands to configure the following:
- The 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.
- The 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.
- The 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.
- The 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.
- The 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.
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 will be 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 will be avoided. In some cases, some of the IPv4 payload packets entering a tunnel may have their DF bit set. And if desired, 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 given 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 will fragment 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 will forward 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.
Operational Conditions
A tunnel group that is in use cannot be deleted. In single-active mode, changes to the primary ISA are allowed only in when the tunnel group is in a shutdown state. Change to the backup ISA (or the addition of a backup ISA) is allowed at any time unless the ISA is currently active for this tunnel group. When the backup module is active, changing the primary module is allowed without shutting down the tunnel group. If it is part of a multi-chassis configuration, you cannot change the mode until it is removed from this configuration as well.
A shutdown of tunnel-group is required to do the following:
- Change the mode between multi-active and single-active.
- Change the primary-isa in single-active mode.
- Change the active-mda-number in multi-active mode.
In multi-active mode, if the active member ISA goes down, system will replace it with backup ISA; however, if there is no backup ISA, the tunnel-group will be “oper-down”. A multi-active tunnel-group with MC-IPSec enabled cannot be changed into single active-mode unless it is removed from MC-IPSec configuration.
Changes to the ipsec-transform/ike-policy in-use are not allowed.
The public interface address can be changed at any time. However, if changed, tunnels that were configured to use it will require a configuration change. If the public subnet changed is still using an old subnet, the tunnels will be in an operationally down state until their configuration is corrected. The public service cannot be deleted while tunnels are configured to use it. A public service is the IES or VPRN service that hold the regular interface that connects the node to the public network. A private service connects to the private protected service.
A tunnel group ID or tag cannot be changed. To remove an tunnel group instance, it must be in a shutdown state (both front-door and back-door).
A change to the security policy is not allowed while a tunnel is active and using the policy.
The tunnel local-gateway-address, peer address, or delivery router parameters cannot be changed while the tunnel is operationally up (shutdown will make it both admin down and operationally down).
A tunnel security policy cannot be changed while the tunnel is operationally up. An IPSec transform policy or ike-policy assignments to a tunnel requires the tunnel to be shutdown.
QoS Interactions
The ISA can interact with the queuing functions on the IOM through the ingress/egress QoS provisioning in the IES or IP VPN service where the IPSec session is bound. Multiple IPSec sessions can be assigned into 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.
In order to keep marking relevant in the overall networking design, the ability to translate DSCP bit marking on packets into DSCP bit markings on the IPSec tunneled packets coming out of the tunnel is 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 tunnel, in multi-active mode, a ping requests to public tunnel address 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 certain 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 will be active for this tunnel group, and tunnels are spread across all active ISA MDAs. Additional ISA MDA in this tunnel group will be 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. Since 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, isa-tunnel 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 and/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.
In order 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).
In order 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 due to 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
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: 20.20.1.0 ® 20.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: 20.20.1.15 ® 20.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: 20.20.1.15 ® 20.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 will reject ts-negotiation and return 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 will create 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 will choose 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 the TS-list name configured via the CLI.
In the event of a CHILD_SA rekey, if the system is a rekey initiator, it will send 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 will do 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.
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 will be blocked for a configurable period of time. If a client is blocked, the system will drop 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.
X.509v3 Certificate Overview
X.509v3 is an ITU-T standard which consists of a hierarchical system of Certificate Authorities (CAs) that issue certificates that bind a public key to particular entity’s identification. The entity’s identification could be a distinguished name or an alternative name such as FQDN or IP address.
An end entity is an entity that is not CA. For example an end entity can be a web server, a VPN client, or a VPN gateway.
A CA issues a certificate by signing an entity’s public key with its own private key. A CA can issue certificates for an end entity as well as for another CA. In the case when a CA certificate is issued by itself (signed by its own private key), then this CA is called the root CA. Thus, an end entity’s certificate could be issued by the root CA or by a subordinate CA (this is issued by another subordinate CA or root CA). When there are multiple CA involved, it is called a chain of CAs.
A PKI also includes the mechanism for revoking certificates due to reasons such as a compromised private key.
The certificate can be used for different purposes. One purpose is authentication. Typically certificate authentication functions as following:
- The system trusts a CA as trust anchor CA (which typically is a root CA). This means that all certificates issued by a trust anchor CA, or the certificates issued by a sub CA issued by the trust anchor CA, are consider trusted.
- A peer to be authenticated presents its certificate along with a signature over some shared data between the peer and system, which is signed by using a private key.
- The signature is verified by using the public key in the certificate. And the certificate itself is verified that is issued by the trust anchor CA or a sub-CA in a chain up to the trust anchor CA. The system can also check if the peer’s certificate has been revoked. Only when all these verifications succeed, then the certificate authentication succeeds.
SROS X.509v3 Certificate Support
SR OS’s PKI implementation supports the following features:
- Certificate Enrollment:
- Locally generate RSA/DSA key
- Off-line enrollment via PKCS#10
- On-line enrollment via CMPv2
- Support CA chain
- Certificate revocation check:
- CRL for both EE (End Entity) and CA certificate
- OCSP for EE certificate only
Local Storage
The SR OS requires the following objects to be stored locally as file:
- CA Certificate
- CRL
- System’s own certificate
- System’s own key
All above objects must be imported before they can be used by the SR OS. This is performed by using the admin certificate import command. The import process converts the format of input file to DER, encrypts the key file and saves it in cf3:/system-pki directory.
The imported file can also be exported as one to use in the specified format by means of the admin certificate export command.
The admin certificate import and admin certificate export command supports following formats:
- Certificates can be import/export by using following formats:
- PKCS#12
- PKCS#7 (DER and PEM)
- PEM
- DER
If there are multiple certificates in the file, only the first one will be used. - Key pair can be import/export by using following formats:
- PKCS#12 (must along with certificate)
- PEM
- DER
- CRL can be import/export by using following formats:
- PKCS#7 (DER and PEM)
- PEM
- DER
- PKCS#12 file can be encrypted with a password
CA-Profile
In SR OS, CA-related configuration is stored in a CA-profile which contains following configurations:
- Name and description
- CA’s Certificate — An imported certificate
- CA’s CRL— An imported CRL
- Revocation check method — Specifies the way CA check the revocation status of the certificate it issued.
- CMPv2 — A CMPv2 server related configurations
- OCSP— An OCSP responder related configurations
When user enables a ca-profile (no shutdown), system will load the specified CA certificate and CRL into memory. And following checks are performed:
- For CA certificate:
- All non-optional fields defined in section 4.1 of RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, must exist and conform to the RFC 5280 defined format.
- Check the version field to see if its value is 0x2.
- Check the Validity field to see that if the certificate is still in validity period.
- X509 Basic Constraints extension must exist and CA Boolean must be True.
- If Key Usage extension exists, then at least keyCertSign and cRLSign should be asserted.
For CRL:
- All non-optional fields defined in section 5.1 of RFC 5280 must exist and conform to the RFC 5280 defined format.
- If the version field exists, the value must be 0x1.
- The delta CRL Indicator must not exist (Delta CRL is not supported).
- CRL must be signed by the configured CA certificate.
CRL, by default, is required to enable ca-profile, but it could be optional by changing the revocation check method configuration. For the revocation check method configuration, refer to Certificate Revocation Check.
CA Chain Computation
In case of verifying a certificate with a CA or a chain of CAs, the system needs to identify the issuer CA of the certificate in question. The SR OS will look through all configured ca-profiles to find the issuer CA. The following is the method system used to find the issuer CA:
- The issuer CA’s certificate subject must match the issuer field of the certificate in question.
- If present, the authority key identifier of the certificate in question must match the subject key identifier of the issuer CA’s certificate
- If present, the key usage extension of the issuer CA’s certificate must permit certificate signing.
Certificate Enrollment
The SR OS supports two certificate enrollment methods:
- Off-line method via PKCS#10
- On-line method via CMPv2
The off-line method works as follows:
- Generate a key pair via the command admin certificate gen-keypairExample:admin certificate gen-keypair cf3:/segw.key size 2048 type rsa
- Generate a PKCS#10 certificate signing request with the key generated in the step mentioned above via the admin certificate gen-local-cert-req command.Example:admin certificate gen-local-cert-req keypair cf3:/segw.key subject-dnC=US,ST=CA,O=ALU,CN=SeGW domain-name segw-1.alu.com file cf3:/segw.pkcs10The user specifies the subject of certificate request and optionally can also specify a FQDN and/or an IP address as SubjectAltName.
- Import the key file via the admin certificate import commandExample:admin certificate import type key input cf3:/segw.key output segw.key formatder
- Since the key is imported, remove the key file generated in the first step for security reasons.
- Send the PKCS#10 file to CA via an offline method such as E-MAIL.
- CA signs the request, and returns the certificate.
- Import the result certificate the admin certificate import command.Example:admin certificate import type cert input cf3:/segw.cert output segw.certformat pem
For CMPv2-based enrollment, refer to Certificate Management Protocol Version 2 (CMPv2).
Certificate Revocation Check
A revocation check is a process to see if a certificate has been revoked by the issuer CA.
The SR OS supports two methods for certificate revocation check:
- CRL
- OCSP
CRL can be used for both EE and CA certificate checks, while OCSP could only be used for an EE certificate.
With an IPSec application, users can configure multiple check methods with a priority order for an EE certificate. With the status-verify command in the ipsec-tunnel>ipsec-gw configuration context, a primary method, a secondary method and a default result can be configured. The primary and secondary method can be either OCSP or CRL. The default result is either good or revoked. If the system cannot get an answer from the primary method, then it will fall back to the secondary method. If secondary method also does not return an answer, then the system will use the default result.
By default, the system uses CRL to check the revocation status of a certificate, whether it is an end entity certificate or a CA certificate. This makes CRL a mandatory configuration in the ca-profile.
The revocation-check command in the ca-profile can change this behavior, with revocation-check crl-optional configured:
When a user enables the ca-profile (no shutdown), the system will try to load the configured CRL (specified by the crl-file command). But, if the system fails to load it for following reasons, then the system will still keep ca-profile oper-up, but treat the CRL as non-existent.
- The CRL file does not exist.
- The CRL is not properly encoded, possibly due to an interrupted file transfer.
- The CRL is not signed by the CA certificate configured in the CA profile.
- The wrong CRL version.
- The CRL expired or is not yet valid.
If the system needs to use the CRL of a specific ca-profile to check revocation status of an end entity certificate and CRL is non-existent due to the above reasons, then the system will treat it as unable to get an answer from CRL and fall back to the secondary status-verify method or default-result configured under the ipsec-gw/ipsec-tunnel.
If the system needs to check the revocation of a CA certificate in certificate chain, and if the CRL is non-existent due to the above reasons, then the system will skip checking the revocation status of the CA certificate. For example, the CA1 is issued by CA2, if CA2’s revocation-check is crl-optional and CA2’s CRL is non-existent, then the system will not check CA1 certificate’s revocation status and consider it as good.
The user must disable the ca-profile to change the revocation-check configuration.
For details about OCSP, refer to OCSP.
Certificate/CRL Expiration Warning
The system can optionally generate a warning message before a certificate or a CRL expires. The amount of time before expiration is configurable via two system-wide CLI commands (certificate-expiration-warning and crl-expiration-warning). The warning messages can also be optionally repeated at a configured interval. For details of the warning messages, refer to the corresponding command descriptions.
If a configured EE certificate expires, the system will not bring down an established ipsec-tunnel/ipsec-gw down, however future certificate authentication will fail.
If a CA certificate expires, the system will bring the ca-profile operationally down. This will not affect established tunnels, however future certificate authentication that uses the ca-profile will fail.
Certificate/CRL/Key Cache
Configured certificates, CRLs, and keys are cached in memory before they are used by the system.
- Every certificate/CRL/Key has one cache copy system-wide.
- For a CA certificate and CRL, the cache will be created when there is a ca-profile and when a no shutdown is performed, and removed.
- For an ipsec-tunnel or ipsec-gw using legacy cert and key configurations, the cache will be created only when the first tunnel using it is in a no shutdown state, and it will be cleared when the last tunnel that used it is shutdown.
- For an ipsec-tunnel or ipsec-gw using cert-profile, the cache will be created when the first cert-profile using it is in a no shutdown state, and removed when the last cert-profile that used it is shutdown.
- If a certificate or key is configured with both a cert-profile and legacy cert or key command, then the cache will be created when the first object (a ipsec-gw, ipsec-tunnel or cert-profile) using it is in a no shutdown state and removed the last object using it is shutdown.
In order to update a certificate or key without a shutdown ca-profile or ipsec-tunnel/ipsec-gw, there is a CLI command (admin certificate reload) to manually reload the certificate and key cache. For details about reload, refer to the command description for admin certificate reload.
Auto CRL Update
The SR OS provides an automatic mechanism to update a CRL file. The system will try to download the CRL from a list of configured HTTP URLs and replace existing CRL file when a qualified CRL is successfully downloaded. A qualified CRL is a valid CRL signed by the CA and is more recent than the existing CRL. To determine if a downloaded CRL is more recent than an existing CRL, the system will compare the This-Update field of the CRL first. If they are the same, the system will compare the CRL number extension if present.
The configured HTTP URL must point to a DER-encoded CRL file.
This features supports two types of downloading schedules:
- Periodic — The system will download a CRL periodically at the interval configured via the periodic-update-interval command. For example, if the periodic-update-interval is 1 day, then the system will download CRL every 1 day. The minimal periodic-update-interval is 1 hour.
- Next-update-based — The system will download a CRL at the time = Next_Update_time_of_current_CRL minus pre-update-time. For example, if the Nex-Update of current CRL is 2015-06-30 06:00 and pre-update-time is 1 hour, then the system will start the download at 2015-06-30, 05:00.
The system allows up to eight URLs to be configured for a given ca-profile. When downloading begins, URLs will be tried in order, and the first successfully downloaded qualified CRL will be used to update existing CRL. If the downloading fails or the downloaded CRL is not qualified, the system will move to the next URL in the list. If all URLs in the list fail to return a qualified URL, then:
- In case of next-update-based schedule, the system will wait for a configured retry-interval before retry from the first URL in the list again.
- In case of periodic schedule, the system will wait until the next scheduled time.
Upon executing a no shutdown of a ca-profile, if the auto-crl-update is enabled, then in case configures CRL file does not exist or is expired or invalid, then the system will start downloading right away.
The system also provides an admin command (admin certificate crl-update ca <ca-profile-name>) for users to manually trigger downloading. However, it requires a shutdown of the auto-crl-update command (no auto-crl-update).
HTTP transport can be over either IPv4 or IPv6.
This feature support Base/Management/VPRN routing instance. VPLS management is not supported.In the case of VPRN, the HTTP server port can only be 80 or 8080.
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 will be a configurable trust-anchor-profile which specifies the expecting CA(s) 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 will use the subject of the configured certificate as its ID by default.
 | Note:
IPsec application is subject to FIPS restrictions; for more information please refer to the Basic System guide. |
Trust-Anchor-Profile
Since R12.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 will build 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 will only support 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 will remain down with authentication failure.
The current trust-anchor command under ipsec-tunnel/ipsec-gw will be deprecated in a future release.
Cert-Profile
Since R12.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 will load 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 will be used in IKEv2 certificate authentication. If a chain computation cannot be completed for a configured certificate, then the corresponding compare-chain will be 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 the received cert-request payload 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 is the 1st configured entry in 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:
The system will build 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 will pick 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 will also send 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 will be the signing certificate, which is configured by the cert command in the chosen cert-profile entry. With the above example, the system will send three certificate payloads: cert-2, CA-1,CA-2.
The following CA chain-related enhancements are supported
- The no-shut of a ca-profile will trigger a re-computation of compute-chain in related cert-profiles. The system will also generate 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 will be generated if the send-chain in a cert-profile entry is not in compute-chain due to 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 will also generate log-2 as above.
- The system now allows changes of the configuration of send-chain without shutdown of cert-profile.
Cert-Profile/trust-anchor-profile versus cert/trust-anchor
Since R12.0R1, cert-profile/trust-anchor-profile provides a superset of function of current cert/trust-anchor commands. The current cert/trust-anchor commands will be deprecated in a future release.
To facilitate transition and also to update the certificate trust-anchor, the following is a list of user configuration actions and corresponding system behavior while the tunnel or ipsec-gw is enabled (no shutdown):
- trust-anchor-profile X —> trust-anchor-profile Y : allowed
- trust-anchor Z —> trust-anchor-profile Y : allowed
- trust-anchor-profile X —> no trust-anchor-profile : disallowed
- trust anchor W —> trust-anchor Z : disallowed
- cert-profile X —> cert-profile Y : allowed
- cert A + key B—> cert-profile Y : allowed
- cert-profile X —> no cert-profile : disallowed
- cert A —> cert B : disallowed
- key C —> key D : disallowed
Operational notes:
- The new configuration will only be used in subsequent tunnel authentication. Existing tunnel will not be affected.
- The CLI rollback might not always allow above behavior.
Certificate Management Protocol Version 2 (CMPv2)
CMPv2, RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) is a protocol between a Certificate Authority (CA) and an end entity. It provides multiple certificate management functions like certificate enrollment, certificate update, etc.
The SR OS supports following CMPv2 operations:
- Initial Registration — The process the SR OS uses to enroll a certificate with a certain CA for the first time.
- Public/Private key pair must be pre-provisioned before enrollment by means of local generation or other methods.
- Users can optionally include a certificate or certificate chain in the extraCerts field of the initial registration request.
- Key Pair Update — A process for SR OS to update an existing certificate due to reason like refreshes key/cert before it expires or any other reason
- Certificate Update — A process where an initialized SR OS system obtains additional certificates.
- Polling — In some cases, the CA may not return the certificate immediately for reasons such as request processing need manual intervention. In such cases, the SR OS supports polling requests and responds as described in Section 5.3.22, Polling Request and Response, in RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP).
The following lists some implementation details:
- HTTP is the only supported transport protocol for CMPv2. HTTP 1.1 and 1.0 are supported and configurable.
- All CMPv2 messages sent by SR OS consist of only one PKI Message. The size of the sequence for PKI Messages are 1 in all cases.
- Both the password-based MAC and the public key-based signature CMPv2 message protection are supported.
- SR OS only allows one outstanding ir/cr/kur request for each CMPv2 server. The means that no new requests are allowed if a pending request is present.
OCSP
Online Certificate Status Protocol (OCSP) (RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) is used by SR OS applications to determine the (revocation) state of an identified certificate. Unlike CRL, which relies on checking against an off-line file, OCSP provides timely, on-line information regarding the revocation status of a certificate.
IPSec is the only supported application to use OCSP. With introduction of OCSP, the system supports both CRL and OCSP as the certificate revocation status checking method. For a given ipsec-tunnel or ipsec-gw, the user could configure a primary method, a secondary method and a default result to achieve a hierarchical fallback mechanism. If the primary method fails to return a result, the system will fall back to the secondary method. If the secondary method fails, the fall back proceeds to a default result.
The following lists implementation details:
- Only an OCSP client function is supported.
- HTTP is the only supported transport protocol.
- OCSP server access via management routing instance is not supported.
- SR OS does not sign an OCSP Request.
- The OCSP response must be signed. The system will verify the response by using the signer’s certificate included in the response. If there is no such certificate, the CA certificate in the ca-profile will be used.
- If a nextUpdate exists in the OCSP response, the system will check the current time <= nextUpdate. If yes, then the response is valid, otherwise the response is considered unreliable. The system will move to next revocation checking method.
- The revocation status result from a valid OCSP response will be cached in the system.
- OCSP can only be used to verify the revocation status of the end-entity certificate. CRL is still needed for CA certificate’s status verification.
Video Wholesale Example
Figure 34: Video Wholesale Configuration
As satellite headend locations can be costly, many municipal and second tier operators cannot justify the investment in their own ground station in order 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.
Multi-Chassis IPSec Redundancy Overview
This section applies to the 7750 SR and 7450 ESS running in mixed mode.
Multi-Chassis IPSec redundancy (MC-IPSec) provides a 1:1 (active/standby) IPSec stateful failover mechanism between two chassis.
- This feature provides protection against MS-ISA failure and chassis failure.
- IKEv2 static LAN-to-LAN is supported in SR OS R10.0R5; IKEv2 dynamic LAN-to-LAN tunnel is supported in SR OS R10.0R8. IKEv2 remote-access tunnel is supported in SR OS R11.0R6.
- This feature is supported on following platforms:
- 7750 SR-7, SR-12 and SR-12E
- IOM3 and chassis mode D
- 7450 ESS mixed mode
- Multi-active tunnel-group only
- The granularity of failover is per tunnel-group, which means a specific tunnel-group could failover to standby chassis independent of other tunnel-groups on the master chassis.
- The following components are included in this feature:
- Master Election: MIMP (MC-IPSec Mastership Protocol) runs between chassis to elect master, MIMP run for each tunnel-group independently
- Synchronization: MCS (Multi-Chassis Synchronization) sync IPSec states between chassis
- Routing:
- MC-IPSec aware routing attract traffic to the master chassis
- Shunting support
- MC-IPSec aware VRRP (10.0R8)
Architecture
The overall MC-IPSec redundancy architecture is displayed in Figure 35.
Figure 35: MC-IPSec Architecture
MC-IPSec Mastership Protocol (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 (Table 23), chassis A and B, for tunnel-group 1, A is master, B is standby; for tunnel-group 2, A is standby, B is master.
Table 23: Master and Backup Chassis Example
Master | Standby | |
Tunnel Group 1 | A | B |
Tunnel Group 2 | B | A |
All IKEv2 negotiation and ESP traffic encryption/decryption only occurs on the master chassis. If the backup chassis receives such traffic, if possible, it will shunt them to the master.
There will be 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
discovery
- Upon MC-IPSec is enabled 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 MS-ISA and no shunting.
- If the peer is reached before the discovery-interval (configurable) has expired, then the state will be changed to whatever the MIMP decides
- If the peer is not reached before the discovery-interval has expired, then the state will be 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 MS-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 MS-ISA processes traffic.
standby
- Peer is reachable, elected standby.
- Functionally, this means blackhole traffic to MS-ISA and shunting if possible.
master
- Peer is reachable, elected master.
- Functionally, this means the MS-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.
First 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.
Then apply stickyness 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”.
Then elect based on priority and number of active ISA:
- 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’s 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 due to reasons such as 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 will use the configured value of the config>redundancy>multi-chassis>peer>source-address command as the source address. If not configured, then system address will be used.
- The priority range is from 0 to 255.
- When an mc-ipsec tunnel-group enters standby from acting master, the tunnel-group will be 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 will be deleted/reinstalled to the MS-ISAs.
- 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 will be shunt 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 will be shunt 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 will result unnecessary shunting traffic.
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 will be set to the configured value. Delta priority is not supported for this type of event.
Synchronization
In order 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 EXECHANGES is synced.
- Upon switchover, the new standby chassis will reboot the tunnel-group.
- The ESP sequence number is not synced.
- 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 will be initiated by the new master to reset the sequence number upon switchover.
Responder Only
With MC-IPSec, it is required that MC-IPSec pair could only act as IKEv2 responder (except for the automatic CHILD_SA rekey upon switchover). To enable this behavior, configure following command.
Refer to IPSec Deployment Requirements section for details
IPSec Deployment Requirements
The following describes requirements to deploy SR OS IPSec features.
IPSec General:
To avoid high CPU loads and some complex cases, the following are the requirements for configuring IKEv2 lifetime:
- The IKE_SA lifetime on one side should be approximately 2 times larger than the other side. he CHILD_SA lifetime on one side should be approximately 2 or 3 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 1st rule, on the side with smaller lifetime, the IKE_SA lifetime should be at least 3 times larger than CHILD_SA lifetime.
- The IKE protocol is the control plane of IPSec, thus, the IKE packet should be treated as high QoS priority in the end-to-end path of public service.
- On a public interface, a sap-ingress QoS policy should be configured to ensure the IKE packet treated as high QoS priority.
- Correct system time is required for certificate authentication to work properly.
MC-IPSec Specific:
- The IKEv2 lifetime requirements from the previous IPSec General section 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, 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 will not cause the MIMP to go down. Since 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/SNTP server.
IKEv2 Remote-Access Tunnel
Since 11.0R6, SROS 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 will authenticate 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 will also perform a RADIUS authentication or authorization and optionally send RADIUS accounting messages.
Figure 36 displays a typical call flow for psk-radius and cert-radius.
Figure 36: Call Flow for psk-radius/cert-radius
The Access-Request includes following attributes:
- Username: IDi
- User-Password: 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 (refer to 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 will not include 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).
- 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 RAIDIUS authentication is successful, then the RADIUS sever will an send 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
Once 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, refer to the SR OS RADIUS Attributed 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 will accept 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.
For security reasons, the system will only accept 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
Refer to the SROS RADIUS Attribute Reference Guide for more details about disconnect message support.
By default, the system will only return 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) will be 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.
Figure 37 shows a typical call flow of EAP authentication.
Figure 37: Typical Call Flow of EAP Authentication
EAP authentication is enabled by configuring authentication eap. Once 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 will return a method request and the system starts passing through between the client and AAA. (as shown in Figure 37).
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 will be 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 will also use own-auth-method to generate the 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-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.
The system will use auto-eap-own-method to generate the AUTH payload.
With auto-eap:
- If there is no AUTH payload in IKE_AUTH request, then the system uses EAP to authenticate the client and will also use 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 will use auto-eap-own-method to generate the AUTH payload.
IKEv2 Remote-Access Tunnel – Authentication without RADIUS
To achieve authentication without RADIUS, auth-method need to configured as psk or cert-auth and local address assignment must be configured under ipsec-gw.
Figure 38 shows a typical call flow of certificate or PSK authentication without RADIUS.
Figure 38: Typical Call Flow of Certificate or PSK Authentication without RADIUS
Figure 39 shows a typical call flow for EAP authentication.
Figure 39: Typical Call Flow for EAP Authentication
In this configuration, the radius-authentication-policy and radius-accounting-policy in the ipsec-gwcontext 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 will be removed. If LAA is shut down, the current established tunnel that used LAA will stay 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 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: 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: 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 in order for the interface to use a DHCPv4 address assignment. The system will ignore 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.
Since there are three methods for address assignment, the following is the priority order (descending) of sources to choose in the event that 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 will be 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 will still be 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:
- LAA — The configuration of config>redundancy>multi-chassis>peer >sync local-dhcp-server is not needed. This is because the assigned address will be synchronized as part of the IPSec tunnel states.
- 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 will 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 will 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 will send 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 will be processed normally.
- If the new master needs to assign an address for a new tunnel setup, it will send 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 will 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 will be 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:
- 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 will automatically create a v6 reverse route in the private VPRN based on the received TSi payload with the tunnel as the nexthop.
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 will be 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 will also be 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 will be 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 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 a given 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.