[strongSwan-dev] RFC 5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2

[Martin Willi]

Hi Daniel,

> I would want to contribute with the implementation of RFC 5685:
> Redirect Mechanism for the Internet Key Exchange Protocol Version 2
> (IKEv2).

Should this be the initiator or the responder part, or both?

> Do you know if there is any work in progress with this
> specification?

I don't think so. However, we have a transparent HA solution [1] that
does not need any redirect, many responder scenarios of RFC 5685 are
therefore not that important. Of course, there are others beside load
balancing or high availability.

As initiator, charon can handle Unity load balance messages, which are
very similar. It uses a separate Informational exchange (see
ikev1/tasks/informational.c).

> I implemented it [...] for some other project and I would want to
> port it in strongswan project too.

Given that our architecture probably differs significantly, I don't
think that there is that much to port directly.

> can you suggest me some preliminary guidance that I should be worry
> about before begining to port it in strongswan?

First, have a look at our contributor requirements [2]. If you want to
bringt your code upstream, it should follow our coding conventions and
should fit into the architecture of charon.

You could extend the existing ike_init/ike_auth tasks, but maybe it is
better to implement dedicated tasks that can be queued during tunnel
setup.

Regards
Martin

[1]http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability
[2]http://wiki.strongswan.org/projects/strongswan/wiki/Contributions