[strongSwan-dev] High Availability

[Daniel Palomares]

Hi Again;

As you may know Im trying to code some features to make some test concerning
High Availability.

I wanted to launch my own "ipsec get <connection name>" command in order to
get a whole ESTABLISHED IKE_SA.

I first wanted to understand how the keywords (concerning *stroke* backend)
works.
When I launched the following command: "ipsec up <myconnection>" I see that
the ipsec script invokes the "${IPSEC_DIR}/stroke up $1", then, once inside
*stroke.c* at the *main *function, there is a *switch(token->kw)* for each
keyword depending if the stroke invocation was an add , delete, up, down,
etc. Inside this switch I added my own "STROKE_GET"  keyword, as well as in
the others keywords files concerned (in order to recognize the keyword
itself *stroke_keywords.c*, etc).

Having a look to STROKE_UP case, I noticed that it calls a function named  *
initiate_connection()* which sends the *STR_INITIATE msg.type* . What I
don't get is: How the connection is launched then?
By the way, I could see that the message is sent through the socket *
send_stroke_msn(&msg).**

*I believed that the *process()* function (in
libcharon/plugins/stroke/stroke_socket.c) concerning the stroke request has
to be called in order to launch an STR_INITIATE. But I cannot say what's
happening once *send_stroke_msg() *returns.

Does strongswan invokes the stroke_control_t.initiate implementation in
order to send a IKE_INIT?

Well, hope you could help me guys!
Thanks in advance;

Daniel


2011/4/26 Yaron Sheffer <yaronf.ietf at gmail.com>

> Hi Daniel,
>
> the draft should be approved by the IESG (the main governing body of the
> IETF) in the next few weeks, and possibly earlier. After that, it may take a
> few months for it to be published as an RFC, but it will not (cannot) be
> changed significantly, or we will have to go through the approval process
> again. In other words, after IESG approval it is stable enough to be
> implemented safely.
>
> No, it wasn't developed under StrongSwan. Most of the ideas originated with
> my Cisco co-authors.
>
> The IPsec standards work takes place on the ipsec at ietf.org mailing list,
> which you might want to follow.
>
> Thanks,
>        Yaron
>
>
> On 04/26/2011 11:55 AM, Daniel Palomares wrote:
>
>> Hi Yaron,
>>
>> Ok, I will take a look.
>>
>> Do you know (more or less) when would you have the response concerning
>> the draft turning to RFC? And have you developed this proposed draft
>> under strongswan?
>>
>> Thank you again,
>>
>>
>> Daniel Palomares
>>
>>
>> 2011/4/24 Yaron Sheffer <yaronf.ietf at gmail.com
>> <mailto:yaronf.ietf at gmail.com>>
>>
>>
>>    Hi,
>>
>>    we have an Internet draft that deals with exactly these issues:
>>    http://tools.ietf.org/html/draft-ietf-ipsecme-ipsecha-protocol-05
>>
>>    This is a bit late in the game (we are already past IETF Last Call),
>>    but I suggest that you take a look, and I would appreciate any
>> comments.
>>
>>    Thanks,
>>            Yaron
>>
>>
>>    On 04/22/2011 10:53 AM, Martin Willi wrote:
>>
>>        Hi Daniel,
>>
>>            In the other hand, I don't get why a HA_IKE_ADD
>>            synchronization type
>>            message would be generated from a "ike_keys" listener?
>>              Could someone
>>            help me on this?
>>
>>
>>        We follow the IKEv2 protocol relatively strict to synchronize
>>        IKE_SAs,
>>        we synchronize the information as soon as we get it. This allows
>>        us to
>>        keep as little additional state as possible for synchronization,
>>        and it
>>        was relatively easy to implement into the existing code base.
>>
>>        The HA_IKE_ADD messages is triggered during the IKE_SA_INIT
>>        exchange,
>>        where the key material is generated. This won't synchronize a
>>        complete
>>        IKE_SA yet, just what we get during IKE_SA_INIT. After
>>        establishment, we
>>        pass all the remaining state using HA_IKE_UPDATE.
>>
>>            So I'm working on the transfer of a Security Association
>>            from one node
>>            to another, for achieving this I'm taking ideas from the
>>            ha_plugin of
>>            course.
>>            My goal is not to synchronize every SA on a cluster but to
>>            take a SA
>>            whenever I want and then been able to install it anywhere else.
>>
>>
>>        We explicitly synchronize only basic information for kernel
>>        level SAs,
>>        but not the sequence numbers. They are moving just to fast if
>>        you have
>>        traffic on the tunnel. If a node fails and you reuse the sequence
>>        numbers from a single second ago, your outgoing sequence numbers
>> are
>>        already outdated and your traffic gets dropped. Therefore we use
>> our
>>        extended ClusterIP functionality to keep sequence numbers in sync.
>>
>>        Best regards
>>        Martin
>>
>>
>>        _______________________________________________
>>        Dev mailing list
>>        Dev at lists.strongswan.org <mailto:Dev at lists.strongswan.org>
>>
>>        https://lists.strongswan.org/mailman/listinfo/dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20110428/e9a74973/attachment.html>