[prev in list] [next in list] [prev in thread] [next in thread] 

List:       strongswan-users
Subject:    Re: [strongSwan] question on ikev2 rekey
From:       Kseniya Blashchuk <ksyblast () gmail ! com>
Date:       2018-11-12 16:39:29
Message-ID: CAMvGrGd0OxRUYoWFYCN02jQoDZBvXa7c==8v9G3FRyUkcCbLQw () mail ! gmail ! com
[Download RAW message or body]

Understood, thank you very much for the clarification!

On Mon, Nov 12, 2018, 6:48 PM Tobias Brunner <tobias@strongswan.org> wrote:

> > Honestly, I thought that for IKEv2 multiple traffic selectors
> > are possible anyway.
>
> Unfortunately, there are implementations that don't support it.
>
> > Also, I was confused about the subnets because with
> > ipsec statusall it shows different rekey time values for different
> > policies which include traffic selectors (ip.net1 === ip.net2).
>
> So you already have separate CHILD_SAs for these (possibly initiated by
> the peer, or narrowed by it).  But to make this work properly your
> config has to reflects that.
>
> > Strongswan also prints "creating rekey job for CHILD_SA ESP/0x12345678/"
> > to the log file, which made me think it should rekey only this
> > particular SA, with a particular SPI, matching specific source and
> > destination (TS).
>
> Single CHILD_SAs are rekeyed, but the complete local CHILD_SA config is
> used for the proposal (i.e. multiple TS if that's what you have
> configured locally).  If a responder that doesn't support multiple TS
> doesn't consider the TS of the rekeyed CHILD_SA, but just blindly uses
> the first proposed TS, that's problematic (i.e. you must change the
> config to reflect that limitation).
>
> Regards,
> Tobias
>
-- 

BR, Kseniya

[Attachment #3 (text/html)]

Understood, thank you very much for the clarification!<br><br><div \
class="gmail_quote"><div dir="ltr">On Mon, Nov 12, 2018, 6:48 PM Tobias Brunner \
&lt;<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Honestly, I thought that for \
IKEv2  multiple traffic selectors<br> &gt; are  possible anyway.<br>
<br>
Unfortunately, there are implementations that don&#39;t support it.<br>
<br>
&gt; Also, I was  confused about the subnets because with<br>
&gt; ipsec statusall it shows different rekey time values for different<br>
&gt; policies which include traffic selectors (ip.net1 === ip.net2).<br>
<br>
So you already have separate CHILD_SAs for these (possibly initiated by<br>
the peer, or narrowed by it).   But to make this work properly your<br>
config has to reflects that.<br>
<br>
&gt; Strongswan also prints &quot;creating rekey job for CHILD_SA \
ESP/0x12345678/&quot;<br> &gt; to the log file, which made me think it should rekey \
only this<br> &gt; particular SA, with a particular SPI, matching specific source \
and<br> &gt; destination (TS).<br>
<br>
Single CHILD_SAs are rekeyed, but the complete local CHILD_SA config is<br>
used for the proposal (i.e. multiple TS if that&#39;s what you have<br>
configured locally).   If a responder that doesn&#39;t support multiple TS<br>
doesn&#39;t consider the TS of the rekeyed CHILD_SA, but just blindly uses<br>
the first proposed TS, that&#39;s problematic (i.e. you must change the<br>
config to reflect that limitation).<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" \
data-smartmail="gmail_signature"><p dir="ltr">BR, Kseniya</p> </div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic