Cisco Cisco Packet Data Gateway (PDG) Guida Alla Risoluzione Dei Problemi

Pagina di 113
Engineering Rules   
▀  IKEv2/IPSec Restrictions 
 
▄  Cisco ASR 5000 Series Packet Data Interworking Function Administration Guide 
OL-22963-01   
IKEv2/IPSec Restrictions 
The following is a list of known restrictions for IKEv2 and IPSec: 
 
 
Each PDIF service must specify one crypto template. 
 
The PDIF supports traffic selectors with just IPv4 address values. IPv6 address values are not supported. 
 
The NAI must be unique per MS. If NAI is not unique, other attributes such IMSI must be unique per MS and 
are used for session management. 
 
The PDIF supports IKEv2 only between the Mobile Station (MS) and the PDIF. 
 
IKEv2 does not support PFS (perfect forward secrecy) of individual CHILD SAs. While the PFS for MS-
initiated IKE SA rekeying will be implemented, the rate for rekeying (with PFS enabled) shall not exceed the 
rate of the IKEv2 call setup rate. This is because PFS would require performing a new D-H exchange each time 
a rekey is negotiated, and a performance impact is expected. Also, note that the call setup rate and the rekeying 
rate are mutually exclusive. 
 
All IKEv2 packets are sent over IPv4. 
 
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 
configurable, except when the processing is noted as below. 
 
While [RFC-4306] Section 2.19 specifies “CP payload MUST be inserted before the SA payload,” the PDIF 
does not force strict ordering of this. The PDIF processes these payloads as long as the mobile 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),” PDIF does not force 
strict ordering of this and still can process these NOTIFY payloads. 
 
The PDIF supports transform selector payloads with only one traffic selector. The number in the TS field must 
be set to “1”. 
 
Traffic selector payloads from the MS 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. 
 
The Configuration Payload (CP) is specified in [RFC-4306], Section 2.19 (Requesting an Internal Address on a 
Remote Network) for the situation where dynamic IP address assignment is required. Since the PDIF does not 
support INTERNAL_IP6_ADDRESS, the CP must include at least the attribute INTERNAL_IP4_ADDRESS. 
 
As described above, when the PDIF receives IKEv2 messages, the PDIF does not enforce the payloads to be in 
order. However, when the PDIF sends the response or generates any IKEv2 messages, the PDIF will ensure 
that payloads are ordered according to [RFC-4306]. 
 
Only IKE and ESP protocol IDs are supported. AH is not supported since AH is deprecated in [RFC-4306]. 
 
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.