[strongSwan] rekeying IKEv2 SA

[Mike Taylor]

Hi Tobias,

I see now in the log that when StrongSwan attempts to rekey the IKEv2 SA there
seems to be some problem with the choice of the DH group:

01[JOB] got event, queuing job for execution
01[JOB] next event in 179s 999ms, waiting
05[MGR] checkout IKEv2 SA with SPIs 64c0f2607e106b9d_i 163156873ee97b60_r
05[MGR] IKE_SA rw[1] successfully checked out
05[IKE] queueing IKE_REKEY task
05[IKE] activating new tasks
05[IKE]   activating IKE_REKEY task
05[MGR] created IKE_SA (unnamed)[2]
05[IKE] IKE_SA rw[1] state change: ESTABLISHED => REKEYING
05[IKE] initiating IKE_SA rw[2] to 192.168.0.233
05[IKE] IKE_SA rw[2] state change: CREATED => CONNECTING
05[IKE] configured DH group CURVE_25519 not supported             <<< ????
05[ENC] order payloads in message
05[ENC] generating CREATE_CHILD_SA request 0 [ ]
05[ENC] generating payload of type HEADER

It says "configured DH group CURVE_25519 not supported".  But of course it does
not have this error upon initially establishing the IKEv2 SA and all works well until
it is time to rekey.  Here is the statusall output right before the attempted rekey

Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.4.0-78-generic, x86_64):
  uptime: 8 minutes, since Jun 30 14:05:39 2017
  malloc: sbrk 2433024, mmap 0, used 279424, free 2153600
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon nonce aes des sha1 sha2 md5 pem pkcs1 gmp random x509 revocation hmac xcbc stroke kernel-netlink socket-default updown openssl vici
Virtual IP pools (size/online/offline):
  10.3.0.0/16: 65534/1/0
Listening IP addresses:
  192.168.0.5
  10.1.0.100
Connections:
          rw:  192.168.0.5...192.168.0.233  IKEv2
          rw:   local:  [sgw.unicoi.com] uses pre-shared key authentication
          rw:   remote: [ike.unicoi.com] uses pre-shared key authentication
          rw:   child:  10.1.0.0/16 === dynamic TUNNEL
Security Associations (1 up, 0 connecting):
          rw[1]: ESTABLISHED 7 minutes ago, 192.168.0.5[sgw.unicoi.com]...192.168.0.233[ike.unicoi.com]
          rw[1]: IKEv2 SPIs: 64c0f2607e106b9d_i 163156873ee97b60_r*, rekeying in 2 seconds
          rw[1]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
          rw{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c701c5b0_i 64c0f262_o
          rw{1}:  NULL/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 48 minutes
          rw{1}:   10.1.0.0/16 === 10.3.0.1/32

This log result was obtained with this ipsec.conf and default (all commented out) swanctl.conf:

config setup
        strictcrlpolicy=no
        charondebug="ike 4, knl 3, cfg 0"

conn %default
        ikelifetime=12m
        lifetime=1h
        margintime=3m
        keyexchange=ikev2
        authby=secret
        reauth=no
        rekey=yes

conn rw
        left=192.168.0.5
        lefthostaccess=yes
        leftsubnet=10.1.0.0/16
        leftfirewall=yes
        leftid=@sgw.unicoi.com
        rightid=@ike.unicoi.com
        right=192.168.0.233
        rightsourceip=10.3.0.0/16
        esp=null-sha1
        type=tunnel
       auto=add

Again, the end result is that if I decrypt the packets with Wireshark I see  that
 StrongSwan sends an empty (except for padding) CREATE_CHILD_SA
request when it attempts to rekey and I guess that is obviously due to the error with the DH
group.  And in the log one can see that it only includes the HDR and the peer replies
with INVALID_SYNTAX as seen in decrypted Wireshark captures.

06[ENC] parsed content of encrypted payload
06[ENC] insert decrypted payload of type NOTIFY at end of list
06[ENC] verifying message structure
06[ENC] found payload of type NOTIFY
06[ENC] parsed CREATE_CHILD_SA response 0 [ N(INVAL_SYN) ] 

I will attempt to see if specifying the DH group explicitly in ipsec.conf
will correct the behavior.

Regards,

Mike

-----Original Message-----
From: Tobias Brunner [mailto:tobias at strongswan.org] 
Sent: Friday, June 30, 2017 12:07 AM
To: Mike Taylor; users at lists.strongswan.org
Subject: Re: [strongSwan] rekeying IKEv2 SA

Hi Mike,

>       ikelifetime=6m
>       margintime=3m

Not ideal as that, depending on rekeyfuzz and the randomization, could result in rekeying getting disabled (see the formula on the ExpiryRekey page).

> If I change reauth=yes to reauth=no

You definitely have to disable reauth to use rekeying, otherwise the IKE_SA is reauthenticated.

> then it gets worse and periodically
> Charon sends an empty (no payloads) CREATE_CHILD_SA packet which the 
> othe IKE naturally rejects as invalid syntax.

Check the logs.

> I tried to follow
> https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey.
> But I find it somewhat confusing about what goes where.

What did you find confusing?

Regards,
Tobias