Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (30)
Anycast addresses are used instead of a list of unicast VPN gateway addresses in DNS so that clients can send IKE_SA_INIT to a single well-known anycast address; the receiving gateway then redirects the client to a specific unicast address, enabling load-based assignment without requiring the client to enumerate individual gateways.
The redirect mechanism enables redirection before any Mobile IPv6 binding cache state is created on the home agent, which is an advantage over the existing Home Agent Switch mechanism (RFC 5142) that requires an established binding before it can redirect a mobile node.
The redirect protocol is asymmetric: only the original responder can redirect the original initiator to another server. It cannot be used for initiator-driven or mutual redirection between two IKEv2 peers.
When IKE_SA_INIT response contains a REDIRECT notification, the exchange does not result in the creation of an IKE_SA and the responder SPI will be zero. Implementations must not treat this as a completed IKE_SA_INIT.
During a gateway-initiated redirect via an INFORMATIONAL message, the REDIRECT payload MUST NOT include nonce data, since the exchange is already protected by the established IKEv2 security association.
During an IKE_AUTH exchange redirect, the gateway MUST verify the client's AUTH payload before sending the REDIRECT payload, and the client MUST verify the gateway's AUTH payload before acting on the REDIRECT payload.
Gateway-initiated REDIRECT notifications received in INFORMATIONAL exchanges MUST NOT result in updating any Mobile IPv6 state; in such cases the Home Agent Switch message (RFC 5142) is used instead.
If the destination address on an IKE_SA_INIT request is an anycast address, the receiving VPN gateway MUST include the REDIRECT payload to redirect the client to a unicast address. The gateway MAY redirect to its own unicast address if not overloaded.
If the IKE_SA_INIT request did not include REDIRECT_SUPPORTED, the responder MUST NOT send the REDIRECT payload to the VPN client. This applies to all REDIRECT scenarios (IKE_SA_INIT, IKE_AUTH, and gateway-initiated INFORMATIONAL).
The client MUST accept the REDIRECT notification only in the first or last IKE_AUTH response; it MUST NOT accept a REDIRECT notification in an intermediate IKE_AUTH response (e.g., during multi-round EAP exchanges).
The client MUST include the REDIRECTED_FROM payload in the IKE_SA_INIT exchange with the new VPN gateway after being redirected, carrying the IP address of the original gateway that redirected it.
The Nonce Data field in the REDIRECT payload MUST be between 16 and 256 bytes (as per IKEv2 nonce size constraints from RFC 4306 Section 3.9), and MUST NOT be included in REDIRECT payloads sent in IKE_AUTH responses or in gateway-initiated redirects.
The redirect mechanism MUST NOT update any state on the client apart from the VPN gateway information.
To prevent redirect loops, clients SHOULD be configured to not accept more than MAX_REDIRECTS (default: 5) redirects within REDIRECT_LOOP_DETECT_PERIOD (default: 300 seconds) for a particular IKEv2 SA setup.
When EAP is used and the gateway redirects based on unauthenticated identity in the first IKE_AUTH exchange, the server MUST still include its own AUTH payload and the client MUST verify it before acting on the REDIRECT, even though no IKEv2 SA is created.
When the client is redirected, it MUST use the same PAD and SPD entries as it would have used with the original gateway. Receiving a REDIRECT notification MUST NOT result in the modification of any PAD or SPD entries.
When the client receives an IKE_SA_INIT response containing a REDIRECT payload, it MUST verify that the nonce data in the REDIRECT payload matches the Ni value it sent. If the values do not match, the client MUST silently discard the response to prevent DoS attacks via injected REDIRECT payloads.
When using the redirect mechanism with Mobile IPv6, if the mobile node has authenticated information about its home agent, it MUST NOT update that information based on the IKE_SA_INIT response containing a REDIRECT.
REDIRECT is an IKEv2 Notify payload (type 16407) sent by the responder in an IKE_SA_INIT response or an INFORMATIONAL message to redirect the initiator to a new VPN gateway. It contains a GW Identity Type field (1=IPv4, 2=IPv6, 3=FQDN), a GW Identity Len field, the New Responder GW Identity, and optionally Nonce Data (only present in IKE_SA_INIT responses).
REDIRECT_SUPPORTED is an IKEv2 Notify payload (type 16406) included in the initial IKE_SA_INIT request by the initiator to signal willingness to be redirected. It carries no notification data beyond the standard Notify header; Protocol ID and SPI Size are both set to 0.
REDIRECTED_FROM is an IKEv2 Notify payload (type 16408) included by the initiator in its IKE_SA_INIT request to the new VPN gateway to identify the original gateway that performed the redirect. It contains a GW Identity Type (1=IPv4, 2=IPv6) and the original gateway's IP address, and also implicitly signals redirect mechanism support to the new gateway.
A new 'Gateway Identity Type' namespace is created for use in REDIRECT and REDIRECTED_FROM payloads. Assigned values: 1=IPv4 address, 2=IPv6 address, 3=FQDN (FQDN only valid in REDIRECT, not REDIRECTED_FROM). Value 0 is reserved; 4–240 are unassigned (allocation by Expert Review); 241–255 are for private use.
Three new IKEv2 Notify Message Types are registered: 16406 (REDIRECT_SUPPORTED), 16407 (REDIRECT), and 16408 (REDIRECTED_FROM).
An on-path eavesdropper can inject IKE_SA_INIT responses with REDIRECT payloads to redirect many clients to a victim gateway, flooding it with IKE_SA_INIT requests. The nonce-matching requirement mitigates spoofed redirects but does not fully prevent this amplification attack against third parties.
Redirecting based on unauthenticated client identities can leak user-specific information: an active attacker posing as a VPN client can probe which gateway a real user was redirected to, potentially exposing internal routing or user-classification information. Redirection based on unauthenticated IDs should be avoided and performed only after client authentication.
The REDIRECTED_FROM payload is intended to discourage rogue VPN gateways from redirecting large numbers of clients to a victim gateway by making the source of the redirect traceable, but it does not cryptographically prevent such a DoS attack.
Active-session gateway-initiated redirect flow: (1) Gateway sends INFORMATIONAL with REDIRECT (no nonce); (2) Client sends empty INFORMATIONAL response; (3) Client SHOULD delete existing SAs with old gateway via INFORMATIONAL with DELETE; (4) Client establishes new SAs with new gateway.
IKE_SA_INIT redirect flow: (1) Initiator sends IKE_SA_INIT with REDIRECT_SUPPORTED; (2) Responder replies with REDIRECT (no IKE_SA is created, responder SPI=0); (3) Initiator verifies nonce, then initiates a new IKE_SA_INIT to the new gateway with REDIRECTED_FROM; (4) Normal IKE_AUTH exchange proceeds with the new gateway.
The REDIRECT payload wire format includes the standard IKEv2 Notify header (Next Payload, C bit, RESERVED, Payload Length, Protocol ID=0, SPI Size=0, Notify Message Type=16407), followed by GW Ident Type (1 octet), GW Ident Len (1 octet), New Responder GW Identity (variable), and Nonce Data (variable, 16–256 bytes, present only in IKE_SA_INIT responses).
The REDIRECTED_FROM payload wire format includes the standard IKEv2 Notify header (Protocol ID=0, SPI Size=0, Notify Message Type=16408), followed by GW Ident Type (1 octet, values 1 or 2 for IPv4/IPv6 only), GW Ident Len (1 octet), and the Original Responder GW Identity (variable). FQDN is not a valid identity type here.