Consider phase2 selector configured on FortiGate as follows:
config vpn ipsec phase2-interface
   edit <phase2_name>
       set phase1name <phase1_name>
       set proposal aes256-sha256
   next
end
   When traffic is initiated from the third party, and the FortiGate receives the following proposals:
Subnet 172.18.10.0/24 , 10.0.10.0/24, 172.19.0.0/16
ike V=root:0:VPN-TAC-FTNT: received create-child request
ike V=root:0:VPN-TAC-FTNT: responder received CREATE_CHILD exchange
ike V=root:0:VPN-TAC-FTNT: responder creating new child
ike V=root:0:VPN-TAC-FTNT:133713: peer proposal:
ike V=root:0:VPN-TAC-FTNT:133713: TSi_0 0:172.18.10.0-172.18.10.255:0
ike V=root:0:VPN-TAC-FTNT:133713: TSi_1 0:10.0.10.0-10.0.10.255:0
ike V=root:0:VPN-TAC-FTNT:133713: TSr_0 0:172.19.0.0-172.19.255.255:0
ike V=root:0:VPN-TAC-FTNT:VPN-TAC-FTNT:133713: comparing selectors
ike V=root:0:VPN-TAC-FTNT:VPN-TAC-FTNT:133713: matched by rfc-rule-2
ike V=root:0:VPN-TAC-FTNT:VPN-TAC-FTNT:133713: phase2 matched by subset
ike V=root:0:VPN-TAC-FTNT:VPN-TAC-FTNT:133713: accepted proposal:
ike V=root:0:VPN-TAC-FTNT:VPN-TAC-FTNT:133713: TSi_0 0:172.18.10.0-172.18.10.255:0
ike V=root:0:VPN-TAC-FTNT:VPN-TAC-FTNT:133713: TSi_1 0:10.0.10.0-10.0.10.255:0
ike V=root:0:VPN-TAC-FTNT:VPN-TAC-FTNT:133713: TSr_0 0:172.19.0.0-172.19.255.255:0
Â
In this case, as shown in the Debug, the FortiGate will accept the proposals, due to rfc-rule-2 this means is compliance with RFC7296.
Refer to RFC 7296 section 2.9, which states: If the responder's policy allows the entire set of traffic covered by TSi and TSr, no narrowing is necessary, and the responder can return the same TSi and TSr values.
  Note: As a best practice, it is recommended to narrow the phase 2 selectors in the configuration; it is up to the administrator if it is necessary to add this extra layer of security or will only use the firewall policy and routing to control the traffic. |