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

[Daniel Barbu]

Hi Martin,


The implementation needs changes both on initiator and responder. 

The responder is responsible for triggering a redirect message to initiator.


Yes, there is little to port in strongswan and more to implement but I have some background in debugging strongswan code.

I will take a look and think at a solution.


Do you have a list with the features in high demand to be implemented for strongswan in the future?


Regards,
Daniel.

________________________________
From: Martin Willi <martin at strongswan.org>
To: Daniel Barbu <barbu.danielstefan at yahoo.com> 
Cc: "dev at lists.strongswan.org" <dev at lists.strongswan.org> 
Sent: Wednesday, June 5, 2013 3:00 PM
Subject: Re: [strongSwan-dev] RFC 5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20130605/44bc2053/attachment.html>