для Cisco Cisco Packet Data Gateway (PDG)

• Negotiation parameters in CHILDSA REKEY: Negotiation parameters in CHILDSA REKEY:

According to RFC 5996 on rekeying of a CHILD SA, the traffic selectors and algorithms match the ones
negotiated during the setting up of child SA. StarOS IKEv2 is enhanced to not send any new parameters
in CREATE_CHILD_SA for a childsa being rekeyed. However StarOS IKEv2 does not enforce any
restrictions on the peer for the same; this is done to minimize impact on IOT's with existing peer vendor
products, which may not be compliant to RFC 5996.

• NAT traversal:The Crypto engine accepts inbound udp-encapsulated IPSec ESP packets even if IKEv2

did not detect NATT. Inbound packets with udp_encap are accepted for processing.

• Certificates:RFC 5996 mandates configurability for sending and receiving HTTP method for

hash-and-URL lookup with CERT/CERTREQ payloads. If configured and if peer requests for CERT
using encoding type as "Hash and URL of X.509 certificate" and send
HTTP_CERT_LOOKUP_SUPPORTED using notify payload in the first IKE_AUTH, ASR shall send
the URL in the CERT payload instead of sending the entire certificate in the payload. If not configured
and CERTREQ is received with encoding type as "hash and URL for X.509 certificate". ASR should
respond with entire certificate even if peer had sent HTTP_CERT_LOOKUP_SUPPORTED.

When a UE attaches to a WiFi Access Point, the WiFi Access Point does assigns the UE an IP Address. Prior
to this feature development the IP address assigned was always an IPv4 address. With this feature now the
UE shall be provided an IPv4 or IPv6 address by the WiFi Access Point for initiating the IPsec connection to
the ePDG over IPv4/IPv6 transport accordingly. For IPv6 transport the IPv6 UDP checksum is mandatory
and is supported for IKEv2 establishment.

The ePDG now supports incoming IKEv2 requests from UE over an IPv6 transport as well. One epdg-service
can now bound to one IPv4 and IPv6 address which acts as IPsec tunnel endpoint addresses. ePDG continues
to support the inner IPv4, IPv6 and IPv4v6 traffic in both IPv4 and IPv6 outer IP SWu transport.

IPv6 NAT support is not standardized and there is no requirement to support the IPv6 NAT . If at all NAT
related parameters are present in the crypto template during configuration , it should not have any impact on
the tunnel setup and the data flow.

During traffic selector negotiation, ePDG by default responds with wildcard IP address, even if the UE is
requesting specific range in the TSr. The ePDG should allow to use specific sets of TSs to send traffic to
specific sets of address ranges for specific client policies. The ePDG also should respect the range requested
by UE and it should (according to the IKEv2 spec) be able to narrow down the UE's request.

IKE Responder performs narrowing As per RFC5996 as shown below:

If the responder's policy does not allow it to accept any part of the proposed Traffic Selectors, it responds
with a TS_UNACCEPTABLE Notify message.

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.

If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST
narrow the Traffic Selectors to a subset that includes the initiator's first choices.

If the responder's policy does not allow it to accept the first selector of TSi and TSr, the responder narrows
to an acceptable subset of TSi and TSr.