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.