Cisco Cisco Packet Data Gateway (PDG)
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.
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.
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.
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.
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.
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.