[prev in list] [next in list] [prev in thread] [next in thread]
List: strongswan-announce
Subject: Re: [strongSwan-dev] RFC 5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2
From: Daniel Barbu <barbu.danielstefan () yahoo ! com>
Date: 2013-06-05 12:46:37
Message-ID: 1370436397.96537.YahooMailNeo () web121606 ! mail ! ne1 ! yahoo ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@strongswan.org>
To: Daniel Barbu <barbu.danielstefan@yahoo.com>
Cc: "dev@lists.strongswan.org" <dev@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
[Attachment #5 (text/html)]
<html><body><div style="color:#000; background-color:#fff; font-family:times new \
roman, new york, times, serif;font-size:12pt"><br>Hi \
Martin,<br><div><span><br></span></div><div>The implementation needs changes both on \
initiator and responder. <br></div><div>The responder is responsible for triggering a \
redirect message to initiator.<br></div><div style="color: rgb(0, 0, 0); font-size: \
16px; font-family: times new roman,new york,times,serif; background-color: \
transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); \
font-size: 16px; font-family: times new roman,new york,times,serif; background-color: \
transparent; font-style: normal;">Yes, there is little to port in strongswan and more \
to implement but I have some background in debugging strongswan code.<br></div><div \
style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new \
york,times,serif; background-color: transparent; font-style: normal;">I will take a \
look and think at a solution.<br></div><div style="color: rgb(0, 0, 0); font-size: \
16px; font-family: times new roman,new york,times,serif; background-color: \
transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); \
font-size: 16px; font-family: times new roman,new york,times,serif; background-color: \
transparent; font-style: normal;">Do you have a list with the features in high demand \
to be implemented for strongswan in the future?<br></div><div style="color: rgb(0, 0, \
0); font-size: 16px; font-family: times new roman,new york,times,serif; \
background-color: transparent; font-style: normal;"><br></div><div style="color: \
rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; \
background-color: transparent; font-style: normal;">Regards,</div><div style="color: \
rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; \
background-color: transparent; font-style: normal;">Daniel.</div><div style="color: \
rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; \
background-color: transparent; font-style: \
normal;"><br>________________________________<br> From: Martin Willi \
<martin@strongswan.org><br>To: Daniel Barbu \
<barbu.danielstefan@yahoo.com> <br>Cc: "dev@lists.strongswan.org" \
<dev@lists.strongswan.org> <br>Sent: Wednesday, June 5, 2013 3:00 \
PM<br>Subject: Re: [strongSwan-dev] RFC 5685: Redirect Mechanism for the Internet Key \
Exchange Protocol Version 2<br><br><br>Hi Daniel,<br><br>> I would want to \
contribute with the implementation of RFC 5685:<br>> Redirect Mechanism for the \
Internet Key Exchange Protocol Version 2<br>> (IKEv2).<br><br>Should this be the \
initiator or the responder part, or both?<br><br>> Do you know if there is any \
work in progress with this<br>> specification?<br><br>I don't think so. However, \
we have a transparent HA solution [1] that<br>does not need any redirect, many \
responder scenarios of RFC 5685 are<br>therefore not that important. Of course, there \
are others beside load<br>balancing or high availability.<br><br>As initiator, charon \
can handle Unity load balance messages, which are<br>very similar. It uses a separate \
Informational exchange (see<br>ikev1/tasks/informational.c).<br><br>> I \
implemented it [...] for some other project and I would want to<br>> port it in \
strongswan project too.<br><br>Given that our architecture probably differs \
significantly, I don't<br>think that there is that much to port directly.<br><br>> \
can you suggest me some preliminary guidance that I should be worry<br>> about \
before begining to port it in strongswan?<br><br>First, have a look at our \
contributor requirements [2]. If you want to<br>bringt your code upstream, it should \
follow our coding conventions and<br>should fit into the architecture of \
charon.<br><br>You could extend the existing ike_init/ike_auth tasks, but maybe it \
is<br>better to implement dedicated tasks that can be queued during \
tunnel<br>setup.<br><br>Regards<br>Martin<br><br>[1]<a target="_blank" \
href="http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability">http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability</a><br>[2]<a \
target="_blank" href="http://wiki.strongswan.org/projects/strongswan/wiki/Contributions">http://wiki.strongswan.org/projects/strongswan/wiki/Contributions</a></div> \
</div></body></html>
_______________________________________________
Dev mailing list
Dev@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic