Bug 1028201 - ikev2 and gcm not working in openswan 2.6.39
ikev2 and gcm not working in openswan 2.6.39
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openswan (Show other bugs)
6.4
x86_64 Linux
unspecified Severity urgent
: rc
: ---
Assigned To: Paul Wouters
BaseOS QE Security Team
:
Depends On:
Blocks: 1057564
  Show dependency treegraph
 
Reported: 2013-11-07 16:54 EST by maswank
Modified: 2014-01-31 12:14 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-31 12:14:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description maswank 2013-11-07 16:54:38 EST
Linux NODE2 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
I am using certificates in this example but also happens if using psk.

ikev2 and gcm are independent bugs. Even when I use IKEv1 only gcm will never work.
note: IKEv2 was working using openswan 2.6.32 and broke when I installed .39 from source. I have never seen GCM working in any version of openswan.

I could swich to using libreswan but will loose the FIPS validation if I do so REALLY REALLY need this fixed :)


config setup
interfaces=%none 
plutoopts="--interface=eth0 --perpeerlog" 
protostack=netkey
nat_traversal=yes
force_keepalive=yes
keep_alive=300
oe=off
nhelpers=1 
plutostderrlog=/var/log/pluto.log
plutorestartoncrash=true
dumpdir=/tmp
plutowait=yes
plutodebug="all" 
listen=10.154.25.150

conn tunnel_10.154.25.149
left=10.154.25.150    
leftsubnet=10.154.25.150/32    
leftsourceip=10.154.25.150    
leftid="CN=NODE2.acme.com"     
leftcert=node2    
leftrsasigkey=%cert

right=10.154.25.149
rightsubnet=10.154.25.149/32    
rightsourceip=10.154.25.149    
rightid="CN=NODE1.cisco.com"     
rightrsasigkey=%cert    
auto=start    
type=transport    
authby=rsasig     
ikev2=insist     #COMMENT ME OUT AND IKEv1 WILL WORK . need to remove GCM below and switch to phase2alg=aes256-sha2_256;modp2048      
ike=aes256-sha2_256-modp2048    
#phase2alg=aes256-sha2_256;modp2048 # THIS WORKS    
phase2alg=aes_gcm_c-256-null        # THIS DOES NOT WORK    
pfs=yes    
phase2=esp    
rekey=yes    
ikelifetime=24h    
salifetime=28800s     
keyingtries=3     
compress=yes    
forceencaps=no     
dpddelay=5    
dpdtimeout=5    
dpdaction=restart    
failureshunt=reject    
rekeyfuzz=100%     
rekeymargin=14400s     
mtu=1492


--------------------------------------------------------------------------------

000 using kernel interface: netkey
000 interface eth0/eth0 10.154.25.150
000 interface eth0/eth0 10.154.25.150
000 myid = (none)
000 debug raw+crypt+parsing+emitting+control+lifecycle+klips+dns+oppo+controlmore+pfkey+nattraversal+x509+dpd+oppoinfo
000 
000 virtual_private (%priv):
000 - allowed 0 subnets: 
000 - disallowed 0 subnets: 
000 WARNING: Either virtual_private= is not specified, or there is a syntax 
000 error in that line. 'left/rightsubnet=vhost:%priv' will not work!
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have 
000 private address space in internal use, it should be excluded!
000 
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=12, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=16, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=AUTH_ALGORITHM_NULL_KAME, keysizemin=0, keysizemax=0
000 
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
000 
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,8,64} trans={0,8,3072} attrs={0,8,2048} 
000 
000 "tunnel_10.154.25.149": 10.154.25.150/32===10.154.25.150<10.154.25.150>[CN=NODE2.cisco.com]...10.154.25.149<10.154.25.149>[CN=NODE1.cisco.com]===10.154.25.149/32; erouted HOLD; eroute owner: #0
000 "tunnel_10.154.25.149": myip=10.154.25.150; hisip=10.154.25.149; mycert=tomcat;
000 "tunnel_10.154.25.149": CAs: 'DC=corp, DC=Krooz, CN=Krooz-KROOZSRV1DC08-CA'...'%any'
000 "tunnel_10.154.25.149": ike_life: 86400s; ipsec_life: 28800s; rekey_margin: 14400s; rekey_fuzz: 100; keyingtries: 3 
000 "tunnel_10.154.25.149": policy: RSASIG+ENCRYPT+COMPRESS+PFS+UP+!IKEv1+IKEv2ALLOW+IKEv2Init+SAREFTRACK; prio: 32,32; interface: eth0; 
000 "tunnel_10.154.25.149": network params: metric:0; mtu:1492; 
000 "tunnel_10.154.25.149": dpd: action:restart; delay:5; timeout:5; 
000 "tunnel_10.154.25.149": newest ISAKMP SA: #0; newest IPsec SA: #0; 
000 "tunnel_10.154.25.149": IKE algorithms wanted: AES_CBC(7)_256-SHA2_256(4)_000-MODP2048; flags=-strict
000 "tunnel_10.154.25.149": IKE algorithms found: AES_CBC(7)_256-SHA2_256(4)_256-MODP2048
000 "tunnel_10.154.25.149": ESP algorithms wanted: AES_GCM_C(20)_288-NONE_000; flags=-strict
000 "tunnel_10.154.25.149": ESP algorithms loaded: none
000 
000 #17: "tunnel_10.154.25.149":500 STATE_PARENT_I1 (sent v2I1, expected v2R1); EVENT_v2_RETRANSMIT in 30s; nodpd; idle; import:local rekey
Comment 2 RHEL Product and Program Management 2013-11-10 18:15:17 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 3 maswank 2013-11-10 23:12:40 EST
A patch will suffice.
Comment 4 Eric Paris 2013-12-04 11:45:10 EST
As this was (obviously) not addressed in RHEL 6.5 I am moving this to be proposed for consideration in RHEL 6.6
Comment 5 Paul Wouters 2014-01-24 11:54:35 EST
openswan 2.6.39 is not and will not be in any RHEL release.

Our rhel6 packages are based on 2.6.32. They do have aes-ccm/aes-gcm support.

(in fedora, libreswan obsoletes openswan, so it also does not have 2.6.39)
Comment 6 maswank 2014-01-25 11:20:06 EST
I could use .32 but there was another bug creating duplicate spd entries every 2 minutes. I would end up with a ton of invalid spi's that would clear themselves when there lifetime expired. Any chance the many spi bug fix was fixed in a patch?
Comment 7 Paul Wouters 2014-01-28 11:46:23 EST
If you can give us a way to reproduce your many spi's bug, we can see about fixing it. Could you open a separate bugzilla item for that?

You might also want to try the EPEL6 version of libreswan, or the RHEL7 beta version of libreswan. libreswan forked from libreswan around 2.6.37 two years ago. It has seen a lot of development, where openswan has just been in maintance mode and only backported a few libreswan patches/features into 2.6.38 (while breaking some ID handling)
Comment 8 Eric Paris 2014-01-31 12:14:10 EST
Since I see this is a request to make changes in code Red Hat does not ship or support I am going to close this bug.  (besides, going to 2.6.39 source invalidated your FIPS cert as well)

Please, feel free to open a new bug with the information about the "many spi's" you were experiencing using the software we ship and support (aka our version of .32).

Please note that opening a bug through a support contract may influence our ability to prioritize work.

Note You need to log in before you can comment on or make changes to this bug.