Cisco Cisco Packet Data Gateway (PDG)

Seite von 127
Evolved Packet Data Gateway Engineering Rules   
▀  IKEv2/IPSec Restrictions 
 
 
▄  ePDG Administration Guide, StarOS Release 18 
118 
   
IKEv2/IPSec Restrictions 
The following is a list of known restrictions for IKEv2 and IPSec: 
 
IKEv2 as per RFC 5996 is supported. IKEv1 is not supported. 
 
MOBIKE is not supported. 
 
Only one Child SA is supported.  
 
Each ePDG service must specify one crypto template. 
 
IKEv2 multiple authentication and fast re-authentication are not supported. 
 
Per RFC 4306 and RFC 4718, the following known restrictions apply with respect to the payload and its order. 
Violations result in INVALID_SYNTAX being returned which is being enabled or disabled through a 
configuration CLI. 
 
While RFC 4306 Section 2.19 specifies that the “CP payload MUST be inserted before the SA 
payload,” the ePDG does not force strict ordering of this. The ePDG processes these payloads as long 
as the UE sends a CP payload anywhere inside the encryption data. 
 
While RFC 4306 Section 2.23 specifies “The location of the payloads (Notify payloads of type 
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP) in the 
IKE_SA_INIT packets are just after the Ni and Nr payloads (before the optional CERTREQ 
payload),” the ePDG does not force strict ordering of this and still can process these NOTIFY 
payloads. 
 
ePDG egress processing will ensure that payloads are in order. 
 
As described above, when the ePDG receives IKEv2 messages, the ePDG does not enforce the payloads to be in 
order. However, when the ePDG sends the response or generates any IKEv2 messages, the ePDG will ensure 
that payloads are ordered according to RFC 4306. 
 
Traffic selector payloads from the UE support only traffic selectors by IP address range. In other words, the IP 
protocol ID must be 0. The start port must be 0 and the end port must be 65535. IP address range specification 
in the TSr payload is not supported. 
 
Only IKE and ESP protocol IDs are supported. AH is not supported. 
 
The IKE Protocol ID specification may not use the NONE algorithm for authentication or the ENCR_NULL 
algorithm for encryption as specified in Section 5 (Security Considerations) of RFC 4306. 
 
In ESP, ENCR_NULL encryption and NONE authentication cannot be simultaneously used. 
 
No more than 16 transform types may be present in a single IKE_SA_INIT or IKE_AUTH Request message. If a 
deviation from this format is used in the proposal format, the ePDG returns an error of INVALID_SYNTAX.