Re: [strongSwan] make before break and default activation

2017-07-24 Thread Tobias Brunner
Hi Emeric,

> Two peers try to renegotiate an IKE SA, they both use strongSwan >=5.3.0
> The first peer has the make-before-break authentication enabled
> The second peer does not have the make-before-break authentication enabled
> 
> What happens if the first peer initiates first? 

What's unclear about that?

Regards,
Tobias


Re: [strongSwan] make before break and default activation

2017-07-24 Thread Emeric POUPON
Hi,

> Hi Emeric,
> 
 To be more specific:
 - what happens exactly if it is enabled only on one side?
>>>
>>> It only has an effect on the peer that initiates the reauthentication.
>>> Enabling it on a host that's always responder has no effect at all.
>> 
>> What happens on strongSwan>=5.3.0 if the peer that has the make-before-break
>> option set initiates the reauthentication first?
> 
> I don't understand the question.

Two peers try to renegotiate an IKE SA, they both use strongSwan >=5.3.0
The first peer has the make-before-break authentication enabled
The second peer does not have the make-before-break authentication enabled

What happens if the first peer initiates first? 
Regards,

Emeric


Re: [strongSwan] make before break and default activation

2017-07-24 Thread Tobias Brunner
Hi Emeric,

>>> To be more specific:
>>> - what happens exactly if it is enabled only on one side?
>>
>> It only has an effect on the peer that initiates the reauthentication.
>> Enabling it on a host that's always responder has no effect at all.
> 
> What happens on strongSwan>=5.3.0 if the peer that has the make-before-break 
> option set initiates the reauthentication first?

I don't understand the question.

Regards,
Tobias



Re: [strongSwan] make before break and default activation

2017-07-20 Thread Emeric POUPON
> Hi Emeric,
> 
>> To be more specific:
>> - what happens exactly if it is enabled only on one side?
> 
> It only has an effect on the peer that initiates the reauthentication.
> Enabling it on a host that's always responder has no effect at all.

What happens on strongSwan>=5.3.0 if the peer that has the make-before-break 
option set initiates the reauthentication first?

Regards,

Emeric


Re: [strongSwan] make before break and default activation

2017-07-18 Thread Tobias Brunner
>>> - what happens with other IKEv2 implementations?
>>
>> That's the big question and the reason it is disabled by default (well,
>> actually that old strongSwan version don't support it).  It only works
>> if the responder can handle this properly so you have to experiment.
> 
> Do you mean that strongSwan version <5.3.0 cannot interoperate with 
> strongSwan version>=5.3.0 if make before break is enabled?

Yep (unless you use rekeying and not reauthentication).

Regards,
Tobias


Re: [strongSwan] make before break and default activation

2017-07-18 Thread Emeric POUPON

> 
>> - what happens with other IKEv2 implementations?
> 
> That's the big question and the reason it is disabled by default (well,
> actually that old strongSwan version don't support it).  It only works
> if the responder can handle this properly so you have to experiment.

Do you mean that strongSwan version <5.3.0 cannot interoperate with strongSwan 
version>=5.3.0 if make before break is enabled?


Regards,

Emeric


Re: [strongSwan] make before break and default activation

2017-07-18 Thread Tobias Brunner
Hi Emeric,

> To be more specific:
> - what happens exactly if it is enabled only on one side?

It only has an effect on the peer that initiates the reauthentication.
Enabling it on a host that's always responder has no effect at all.

> - what happens with other IKEv2 implementations?

That's the big question and the reason it is disabled by default (well,
actually that old strongSwan version don't support it).  It only works
if the responder can handle this properly so you have to experiment.
strongSwan only does so since 5.3.0 (e.g. in regards to duplicate
policies/reqids, virtual IP handling etc.).  But only recently (#2373)
an issue in the farp plugin was found that also affects responders of
make-before-break reauthentications.

Regards,
Tobias