[strongSwan] Resubmission as plaintext - Strongswan with ESP-NULL and ESP-NONE , NULL encryption and NONE integrity

Sat Jan 7 14:59:06 CET 2017

Andreas,

Thanks for the quick reply.  What I noticed though was when doing Strongswan<->Strongswan I was able to create a config with simply "esp=null" on both sides.  When the tunnel came up it did not appear to have an integrity algorithm per "ipsec statusall".  I also noticed a dramatic speed increase with esp=null as compared to esp=null-md5, esp=null-sha, and esp=null-sha256 as well as the various AES variants (only slowed things worse).  I can stand the Strongswan<->Strongswan config back up to get an exact snapshot but I believe ipsec statausall showed NULL with no integrity algorithm, something similar to:

---
 Security Associations (1 up, 0 connecting):
 thetun[1]: ESTABLISHED 112 seconds ago, 10.1.9.119[10.1.9.119]...10.1.9.50[10.1.9.50]
 thetun[1]: IKEv1 SPIs: 412c49ff4068e202_i 8e14130f46bfeb9d_r*, pre-shared key reauthentication in 53 minutes
 thetun[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
 thetun{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c0e9e639_i f99f86da_o
 thetun{1}: NULL, 10124 bytes_i (121 pkts, 1s ago), 0 bytes_o, rekeying in 12 minutes
 thetun{1}: 0.0.0.0/0 === 192.168.2.0/24
---

A tcpdump confirmed ESP traffic so it was working.

Regards,
SSAdmin 

Sent: Saturday, January 07, 2017 at 1:19 AM
From: "Andreas Steffen" <andreas.steffen at strongswan.org>
To: "ss admin" <strongs8dmin at mail.com>, users at lists.strongswan.org
Subject: Re: [strongSwan] Resubmission as plaintext - Strongswan with ESP-NULL and ESP-NONE , NULL encryption and NONE integrity
Hi,

strongSwan does not support NULL-NONE. Configuration of a data integrity
algorithm is mandatory.

Best regards

Andreas

On 07.01.2017 04:14, ss admin wrote:
> I am running Strongswan Linux strongSwan U5.4.0/K2.6.32-358.el6.i686. I am trying to create a tunnel from a Cisco ASA 5520 8.4(7). I am trying to create a tunnel with the transform set ESP-NULL and ESP-NONE, essentially I am going for pure performance and do not want any encryption or integrity. The data I am sending is end-to-end encrypted anyway. If the ASA supported GRE I would be using GRE for this purpose. I can get the tunnel to come up so long as I chose an integrity algorithim. Even performing the integrity imposes a signifigant performance hit over baseline with my limiting factor being the ASA.
>
> My config and log dumps are as follows:
>
> ASA:
> ----
> crypto ipsec ikev1 transform-set ESP-NULL-SHA esp-null esp-sha-hmac
> crypto ipsec ikev1 transform-set ESP-NULL-NONE esp-null esp-none
> crypto ipsec security-association lifetime kilobytes 999999999
> crypto map outside_map 1 match address outside_1_cryptomap
> crypto map outside_map 1 set peer 10.1.9.119
> crypto map outside_map 1 set ikev1 transform-set ESP-NULL-NONE
> crypto map outside_map interface outside
> crypto ikev1 enable outside
> crypto ikev1 policy 10
> authentication pre-share
> encryption aes-256
> hash sha
> group 2
> lifetime 86400
> ----
>
> The above tunnel does not come up. The tunnel with the following does come up:
>
> ---
> crypto map outside_map 1 set ikev1 transform-set ESP-NULL-SHA
> ---
>
> My Strongswan config is as follows:
>
> -----
> conn thetun
> keyexchange=ikev1
> aggressive=no
> authby=secret
> left=10.1.9.119
> leftsubnet=0.0.0.0/0
> right=10.1.9.50
> rightsubnet=192.168.2.0/24
> auto=add
> ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
> esp=null
> -----
>
> The above tunnel does not come up. When I use the following (in conjunction with ESP-NULL-SHA on the ASA it does come up):
>
> --
> esp=null-sha
> --
>
> What's odd is that a strongswan to strongswan setup comes up just fine with "esp=null".
> Here are my log dumps:
>
> Strongswan, with NULL-NONE:
> ----
> Jan 6 14:32:27 16[NET] <1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (172 bytes)
> Jan 6 14:32:27 16[ENC] <1> parsed ID_PROT request 0 [ SA V V V V ]
> Jan 6 14:32:27 16[IKE] <1> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
> Jan 6 14:32:27 16[IKE] <1> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
> Jan 6 14:32:27 16[IKE] <1> received NAT-T (RFC 3947) vendor ID
> Jan 6 14:32:27 16[IKE] <1> received FRAGMENTATION vendor ID
> Jan 6 14:32:27 16[IKE] <1> 10.1.9.50 is initiating a Main Mode IKE_SA
> Jan 6 14:32:27 16[ENC] <1> generating ID_PROT response 0 [ SA V V V ]
> Jan 6 14:32:27 16[NET] <1> sending packet: from 10.1.9.119[500] to 10.1.9.50[500] (140 bytes)
> Jan 6 14:32:27 14[NET] <1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (304 bytes)
> Jan 6 14:32:27 14[ENC] <1> parsed ID_PROT request 0 [ KE No V V V V NAT-D NAT-D ]
> Jan 6 14:32:27 14[IKE] <1> received Cisco Unity vendor ID
> Jan 6 14:32:27 14[IKE] <1> received XAuth vendor ID
> Jan 6 14:32:27 14[ENC] <1> received unknown vendor ID: 17:a9:c0:b2:e9:f7:2e:e0:34:25:8c:f6:5e:a5:58:28
> Jan 6 14:32:27 14[ENC] <1> received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
> Jan 6 14:32:27 14[ENC] <1> generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
> Jan 6 14:32:27 14[NET] <1> sending packet: from 10.1.9.119[500] to 10.1.9.50[500] (244 bytes)
> Jan 6 14:32:27 12[NET] <1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (92 bytes)
> Jan 6 14:32:27 12[ENC] <1> parsed ID_PROT request 0 [ ID HASH V ]
> Jan 6 14:32:27 12[IKE] <1> received DPD vendor ID
> Jan 6 14:32:27 12[CFG] <1> looking for pre-shared key peer configs matching 10.1.9.119...10.1.9.50[10.1.9.50]
> Jan 6 14:32:27 12[CFG] <1> selected peer config "thetun"
> Jan 6 14:32:27 12[IKE] <thetun|1> IKE_SA thetun[1] established between 10.1.9.119[10.1.9.119]...10.1.9.50[10.1.9.50]
> Jan 6 14:32:27 12[IKE] <thetun|1> scheduling reauthentication in 3241s
> Jan 6 14:32:27 12[IKE] <thetun|1> maximum IKE_SA lifetime 3421s
> Jan 6 14:32:27 12[ENC] <thetun|1> generating ID_PROT response 0 [ ID HASH ]
> Jan 6 14:32:27 12[NET] <thetun|1> sending packet: from 10.1.9.119[500] to 10.1.9.50[500] (76 bytes)
> Jan 6 14:32:27 10[NET] <thetun|1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (204 bytes)
> Jan 6 14:32:27 10[ENC] <thetun|1> parsed QUICK_MODE request 576741339 [ HASH SA No ID ID N(INITIAL_CONTACT) ]
> Jan 6 14:32:27 10[IKE] <thetun|1> received 28800s lifetime, configured 1200s
> Jan 6 14:32:27 10[IKE] <thetun|1> received 999999999000 lifebytes, configured 0
> Jan 6 14:32:27 10[ENC] <thetun|1> generating QUICK_MODE response 576741339 [ HASH SA No ID ID ]
> Jan 6 14:32:27 10[NET] <thetun|1> sending packet: from 10.1.9.119[500] to 10.1.9.50[500] (188 bytes)
> Jan 6 14:32:27 09[NET] <thetun|1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (76 bytes)
> Jan 6 14:32:27 09[ENC] <thetun|1> parsed INFORMATIONAL_V1 request 3090240294 [ HASH D ]
> Jan 6 14:32:27 09[IKE] <thetun|1> received DELETE for ESP CHILD_SA with SPI 891a112a
> Jan 6 14:32:27 09[IKE] <thetun|1> CHILD_SA not found, ignored
> Jan 6 14:32:27 16[NET] <thetun|1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (92 bytes)
> Jan 6 14:32:27 16[ENC] <thetun|1> parsed INFORMATIONAL_V1 request 3728127385 [ HASH D ]
> Jan 6 14:32:27 16[IKE] <thetun|1> received DELETE for IKE_SA thetun[1]
> Jan 6 14:32:27 16[IKE] <thetun|1> deleting IKE_SA thetun[1] between 10.1.9.119[10.1.9.119]...10.1.9.50[10.1.9.50]
> ---
>
> Strongswan, with NULL-SHA:
>
> ---
> Jan 6 14:35:15 01[NET] <1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (172 bytes)
> Jan 6 14:35:15 01[ENC] <1> parsed ID_PROT request 0 [ SA V V V V ]
> Jan 6 14:35:15 01[IKE] <1> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
> Jan 6 14:35:15 01[IKE] <1> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
> Jan 6 14:35:15 01[IKE] <1> received NAT-T (RFC 3947) vendor ID
> Jan 6 14:35:15 01[IKE] <1> received FRAGMENTATION vendor ID
> Jan 6 14:35:15 01[IKE] <1> 10.1.9.50 is initiating a Main Mode IKE_SA
> Jan 6 14:35:15 01[ENC] <1> generating ID_PROT response 0 [ SA V V V ]
> Jan 6 14:35:15 01[NET] <1> sending packet: from 10.1.9.119[500] to 10.1.9.50[500] (140 bytes)
> Jan 6 14:35:15 14[NET] <1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (304 bytes)
> Jan 6 14:35:15 14[ENC] <1> parsed ID_PROT request 0 [ KE No V V V V NAT-D NAT-D ]
> Jan 6 14:35:15 14[IKE] <1> received Cisco Unity vendor ID
> Jan 6 14:35:15 14[IKE] <1> received XAuth vendor ID
> Jan 6 14:35:15 14[ENC] <1> received unknown vendor ID: b4:eb:ee:e2:40:69:e2:02:6a:a3:54:71:7f:16:8f:35
> Jan 6 14:35:15 14[ENC] <1> received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
> Jan 6 14:35:15 14[ENC] <1> generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
> Jan 6 14:35:15 14[NET] <1> sending packet: from 10.1.9.119[500] to 10.1.9.50[500] (244 bytes)
> Jan 6 14:35:15 12[NET] <1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (92 bytes)
> Jan 6 14:35:15 12[ENC] <1> parsed ID_PROT request 0 [ ID HASH V ]
> Jan 6 14:35:15 12[IKE] <1> received DPD vendor ID
> Jan 6 14:35:15 12[CFG] <1> looking for pre-shared key peer configs matching 10.1.9.119...10.1.9.50[10.1.9.50]
> Jan 6 14:35:15 12[CFG] <1> selected peer config "thetun"
> Jan 6 14:35:15 12[IKE] <thetun|1> IKE_SA thetun[1] established between 10.1.9.119[10.1.9.119]...10.1.9.50[10.1.9.50]
> Jan 6 14:35:15 12[IKE] <thetun|1> scheduling reauthentication in 3342s
> Jan 6 14:35:15 12[IKE] <thetun|1> maximum IKE_SA lifetime 3522s
> Jan 6 14:35:15 12[ENC] <thetun|1> generating ID_PROT response 0 [ ID HASH ]
> Jan 6 14:35:15 12[NET] <thetun|1> sending packet: from 10.1.9.119[500] to 10.1.9.50[500] (76 bytes)
> Jan 6 14:35:15 10[NET] <thetun|1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (204 bytes)
> Jan 6 14:35:15 10[ENC] <thetun|1> parsed QUICK_MODE request 1268007489 [ HASH SA No ID ID N(INITIAL_CONTACT) ]
> Jan 6 14:35:15 10[IKE] <thetun|1> received 28800s lifetime, configured 1200s
> Jan 6 14:35:15 10[IKE] <thetun|1> received 999999999000 lifebytes, configured 0
> Jan 6 14:35:15 10[ENC] <thetun|1> generating QUICK_MODE response 1268007489 [ HASH SA No ID ID ]
> Jan 6 14:35:15 10[NET] <thetun|1> sending packet: from 10.1.9.119[500] to 10.1.9.50[500] (188 bytes)
> Jan 6 14:35:15 09[NET] <thetun|1> received packet: from 10.1.9.50[500] to 10.1.9.119[500] (76 bytes)
> Jan 6 14:35:15 09[ENC] <thetun|1> parsed QUICK_MODE request 1268007489 [ HASH ]
> Jan 6 14:35:15 09[IKE] <thetun|1> CHILD_SA thetun{1} established with SPIs c0e9e639_i f99f86da_o and TS 0.0.0.0/0 === 192.168.2.0/24
> STATUSALL shows:
> Security Associations (1 up, 0 connecting):
> thetun[1]: ESTABLISHED 112 seconds ago, 10.1.9.119[10.1.9.119]...10.1.9.50[10.1.9.50]
> thetun[1]: IKEv1 SPIs: 412c49ff4068e202_i 8e14130f46bfeb9d_r*, pre-shared key reauthentication in 53 minutes
> thetun[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
> thetun{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c0e9e639_i f99f86da_o
> thetun{1}: NULL/HMAC_SHA1_96, 10124 bytes_i (121 pkts, 1s ago), 0 bytes_o, rekeying in 12 minutes
> thetun{1}: 0.0.0.0/0 === 192.168.2.0/24
> ---
>
> ASA with NULL-NONE:
>
> ---
> ciscoasa(config)# Jan 06 16:17:41 [IKEv1]IP = 10.1.9.119, IKE Initiator: New Phase 1, Intf inside, IKE Peer 10.1.9.119 local Proxy Address 192.168.2.0, remote Proxy Address 0.0.0.0, Crypto map (outside_map)
> Jan 06 16:17:41 [IKEv1]IP = 10.1.9.119, Connection landed on tunnel_group 10.1.9.119
> Jan 06 16:17:41 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Automatic NAT Detection Status: Remote end is NOT behind a NAT device This end is NOT behind a NAT device
> Jan 06 16:17:41 [IKEv1]IP = 10.1.9.119, Connection landed on tunnel_group 10.1.9.119
> Jan 06 16:17:41 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, PHASE 1 COMPLETED
> Jan 06 16:17:41 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Generating secret keys: unknown encryption algorithm!
> Jan 06 16:17:41 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Generating secret keys: unknown encryption algorithm!
> Jan 06 16:17:41 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Security negotiation complete for LAN-to-LAN Group (10.1.9.119) Initiator, Inbound SPI = 0x068a607a, Outbound SPI = 0xc86c05d2
> Jan 06 16:17:41 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, QM FSM error (P2 struct &0x76f85318, mess id 0x3345b948)!
> Jan 06 16:17:41 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Removing peer from correlator table failed, no match!
> Jan 06 16:17:41 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Session is being torn down. Reason: Unknown
> ---
>
> ASA with NULL-SHA:
>
> ----
> ciscoasa(config)# Jan 06 16:19:44 [IKEv1]IP = 10.1.9.119, Connection landed on tunnel_group 10.1.9.119
> Jan 06 16:19:44 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Automatic NAT Detection Status: Remote end is NOT behind a NAT device This end is NOT behind a NAT device
> Jan 06 16:19:44 [IKEv1]IP = 10.1.9.119, Connection landed on tunnel_group 10.1.9.119
> Jan 06 16:19:44 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, PHASE 1 COMPLETED
> Jan 06 16:19:44 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Generating secret keys: unknown encryption algorithm!
> Jan 06 16:19:44 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Generating secret keys: unknown encryption algorithm!
> Jan 06 16:19:44 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, Security negotiation complete for LAN-to-LAN Group (10.1.9.119) Initiator, Inbound SPI = 0xae679c9a, Outbound SPI = 0xcef968c7
> Jan 06 16:19:44 [IKEv1]Group = 10.1.9.119, IP = 10.1.9.119, PHASE 2 COMPLETED (msgid=ee427ffd)
> ---
> 's

======================================================================
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Open Source VPN Solution! www.strongswan.org[http://www.strongswan.org]
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==