RFC 5685 - Redirect Mechanism

Introduction

RFC 5685 is a document that specifies guidelines for usage of Redirect Mechanism for Internet Key Exchange Version 2 (IKEv2). Basic idea is that responder peers should be able to redirect the initiators to a new address. RFC suggests that the main usage is intended for server-to-client architectures, where server could (e.g. when he is going down for maintenance or is overloaded) redirect clients to other servers.

Implementation

To allow the use of Redirect Mechanism in IKEv2, the following changes were made:

• Two new source code files were created: programs/pluto/ikev2_redirect.{h,c}.

• Added code in programs/pluto/ikev2_parent.c which deals with sending and processing of IKEv2 *REDIRECT* Notify payloads.

• Code for reading connection and config options was updated.

• New test cases were added. These can be found as ‘’ikev2-redirect-*’’ folders in testing/pluto/ directory.

Configuring the IKEv2 Redirect Mechanism in libreswan

Four connection options are added for this mechanism:

• send-redirect - specifies whether to send REDIRECT payload in IKE_AUTH response when peer receives REDIRECT_SUPPORTED notification. Allowed values are yes (always send), no (never send) and auto (the default, redirect if in DDoS mode).

• redirect-to - specify what address to put in REDIRECT payload, that is where to redirect the other end. Both IPv4 and IPv6 addresses are supported as well the FQDNs. Only one address should be specified. The value of this option is not considered if send-redirect is set to no.

• accept-redirect - specify whether to send REDIRECT_SUPPORTED notification (and process incoming REDIRECT notifications) to the other end when we initiate IKEv2 exchange. Allowed values are yes (always send) and no (the default, never send).

• accept-redirect-from - specify the address (or list of addresses) where we allow to be redirected to. Both IPv4 and IPv6 addresses are supported as well the FQDNs. The value %any, as well as not specifying any address, signifies that we will redirect to any address gateway sends us in REDIRECT Notify payload.

Examples:

   send-redirect=yes
   redirect-to=1.2.3.4

   accept-redirect=yes
   accept-redirect-from=1.1.1.1, 1.2.3.4, server.myserver.org

Two more options are added for config configuration:

• global-redirect - specifies whether to send REDIRECT payload in IKE_SA_INIT response when peer receives REDIRECT_SUPPORTED notification. Allowed values are on (redirect all requests), off (don’t redirect at all) and auto (redirect if busy - in DDoS mode).

• global-redirect-to - specify what address to put in REDIRECT payload, that is where to redirect the other end. Both IPv4 and IPv6 addresses are supported as well the FQDNs. Only one address should be specified.

Example:

config setup
   global-redirect=on
   global-redirect-to=1.2.3.4

Redirect during an active session

It is also possible to redirect specific peer during an active session (established IPsec tunnel). The whack command --redirect is used, followed by --peer-ip <ip-address> and --gateway <ip-address>, meaning that the peer with address specified after --peer-ip will be redirected to the gateway with IP address following the --gateway command.

ipsec whack --redirect --peer-ip 1.1.1.1 --gateway 2.2.2.2

Future work

There are two more things that would be nice to have: 1. (High priority) Redirect all peers connected to one connection with whack command. 2. (Low priority) Figure out a way to enable server to decide if to send REDIRECT payload based on multiple, custom, parameters.

Source code

The main developer of this feature is Vukasin Karadzic. Work on this project was done under the mentorship of Paul Wouters and sponsored by Google as part of Google Summer of Code 2018 Program.