[strongSwan] swanctl -l - loses transport info?

[Noel Kuntze]

Hi,

> - the initial SA doesn't need to do a key exchange because it was just done by IKE

Yes.

> - rekeying does, and uses that configured ECP256 (or DH groups etc.)

Yes.

Kind regards

Noel


Am 04.04.19 um 20:45 schrieb Kostya Vasilyev:
> On Thu, Apr 4, 2019, at 9:42 PM, Noel Kuntze wrote:
>> Hi,
>>
>> In IKEv2, the KEX in P2 is only displayed when it actually occurs. In 
>> any case, in the first CHILD_SA of a new IKE_SA, there's no KEX when it 
>> is negotiated, so it's not displayed, because the KEX algorithm and 
>> keylength are unknown. When a new CHILD_SA is negotiated (which 
>> rekeying uses), a KEX is made, thus the algorithm and keylengtha re 
>> known and it is displayed. You can easily recreate that scenario with 
>> `swanctl --rekey [...]`.
> 
> Thank you. Exactly what I just discovered too :)
> 
> So I guess another way to look at this is - 
> 
> - the initial SA doesn't need to do a key exchange because it was just done by IKE
> 
> - rekeying does, and uses that configured ECP256 (or DH groups etc.)
> 
> Correct (more or less)?
> 
> -- K
> 
>>
>> Kind regards
>>
>> Noel
>>
>> Am 04.04.19 um 20:32 schrieb Kostya Vasilyev:
>>> Hi,
>>>
>>> I'm seeing something weird with the output of "swanctl -l".
>>>
>>> Sometimes the SA's are output like this:
>>>
>>> home_gre: #3, reqid 3, INSTALLED, TRANSPORT, ESP:AES_CTR-128/HMAC_SHA2_256_128
>>>
>>> linode: #4, reqid 4, INSTALLED, TRANSPORT, ESP:AES_GCM_16-128
>>>
>>> And sometimes like this:
>>>
>>> home_gre: #6, reqid 6, INSTALLED, TRANSPORT, ESP:AES_CTR-128/HMAC_SHA2_256_128/ECP_256
>>>
>>> linode: #4, reqid 4, INSTALLED, TRANSPORT, ESP:AES_GCM_16-128/ECP_256
>>>
>>> The variation is in the "/ECP256" at the end.
>>>
>>> I think this varies depending on how I start strongSwan (swanctl -q vs. systemctl restart) or maybe rekeying.
>>>
>>> But my server and client configs don't change.
>>>
>>> My server config is like this:
>>>
>>> connections {
>>> 	ec_tunnel {
>>> 		version = 2
>>> 		proposals = aes128-sha256-ecp256
>>>
>>> 		// local, remote adds and auth omitted
>>> 		
>>> 		children {
>>> 			home_gre {
>>> 				local_ts  = dynamic[gre]
>>> 				remote_ts = dynamic[gre]
>>>
>>> 				mode = transport
>>> 				esp_proposals = aes128ctr-sha256-ecp256
>>> 			}
>>>
>>> 			linode {
>>> 				mode = transport
>>> 				esp_proposals = aes128gcm128-ecp256
>>> 			}
>>> 		}
>>> 	}
>>> }
>>>
>>> Client config for "linode" clinets:
>>>
>>> connections {
>>> 	ecdsa_tunnel {
>>> 		version = 2
>>> 		proposals = aes128-sha256-ecp256
>>>
>>> 		// local, remote adds and auth omitted
>>> 		
>>> 		children {
>>> 			fra  {
>>> 				mode = transport
>>> 				esp_proposals = aes128gcm128-ecp256
>>> 				start_action = start
>>> 				close_action = start
>>> 				dpd_action = restart
>>> 			}
>>> 		}
>>> 	}
>>> }
>>>
>>> Client "home_gre" (AES CTR) is a Miktotik at home and it also has ECP256 in its SA encryption config.
>>>
>>> Does this look like a bug in swanctl -l ?
>>>
>>> Or - most likely - user error?
>>>
>>> I got ideas for my crypto settings from here:
>>>
>>> https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
>>>
>>> Suite-B-GCM-128:
>>> IKEv2: aes128gcm16-prfsha256-ecp256
>>> ESP: aes128gcm16-ecp256
>>>
>>> Except I can't use GCM or PRF for IKE because of the Mikrotik client.
>>>
>>
>>
>> Attachments:
>> * signature.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190404/e350a268/attachment.sig>