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

Tue Jan 17 23:02:42 CET 2017

Andreas,

Are there any plans to add support for NULL\NONE?  I was looking through the code and I have never done object oriented C.  Where are child SAs managed and set up?  Would it be rather trivial to add support for NONE authentication?  I am not really concerned with security.  I am using this strictly as a transport mechanism.

Regards,
ssAdmin

Sent: Monday, January 09, 2017 at 7:53 PM
From: "Andreas Steffen" <andreas.steffen at strongswan.org>
To: "ss admin" <strongs8dmin at mail.com>
Cc: users at lists.strongswan.org
Subject: Re: [strongSwan] Resubmission as plaintext - Strongswan with ESP-NULL and ESP-NONE , NULL encryption and NONE integrity
Hi,

I did a test with strongswan-5.5.2dr4 and esp=null! and it surprisingly
it works. Please be aware that such an ESP tunnel doesn't offer any
security at all, i.e. neither confidentiality nor data integrity.

Regards

Andreas

On 07.01.2017 21:59, ss admin wrote:
> 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][http://www.strongswan.org[http://www.strongswan.org]]
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>
>

--
======================================================================
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]==