Description of problem: IPv6 DoD specification is shown as below: • Change the encryption algorithms on both the DUT and remote host to test all required algorithms and repeat the ICMP test. Required algorithms are: o Encrypted Payload Algorithms - Must implement 3DES-CBC for confidentiality and HMAC-SHA1 for Integrity o Diffie-Hellman Groups - Must implement Group 2 o IKEv2 Transform Type 1 Algorithms - Must implement ENCR_3DES o IKEv2 Transform Type 2 Algorithms - Must implement PRF_HMAC_SHA1 o IKEv2 Transform Type 3 Algorithms - Must Implement AUTH_HMAC_SHA1_96 • Record the results and archive all packet captures and screen shots. when setting "esp=3des-sha1 ike=3des-sha1" in ipsec.conf , the ipsec tunnel will be ok. But when setting "esp=3des_cbc-sha1 ike=3des-sha1", "esp=3des-sha1-modp1024", or "esp=3des-sha1-modp1024 ikev2=propose", ipsec tunnel can not be established, and it will display the following info: [root@localhost etc]# ipsec auto --verbose --up tunnelipsec 000 initiating all conns with alias='tunnelipsec' 021 no connection named "tunnelipsec" [root@localhost etc]# ipsec auto --add tunnelipsec 034 esp string error: Non initial digit found for auth keylen, just after "3des-sha1-" (old_state=ST_AA_END) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
what about esp=3des-sha1-96-modp1024 ? I knwo the parser has some oddities in it that we should address at some point.
paul, when setting esp=3des-sha1-96-modp1024, the result also fail and display the same info.
zhiyong, can you let us know which version of openswan you are using?
Hi, Linda, the version is (1) kernel-2.6.18-92.el5 (2) openswan-2.6.12-2.el5
It looks like all the needced bits to properly parse that prefix are in place in that version. Can you provide the name of the system you're testing on. I'd like to hop on and run this through the debugger if I could please. Thanks!
sorry, nhorman, two test machines used by us in testing IKEv2 dont attach to internet or intranet, so u can not login in and run.
Ok, then can you send me config file, and some details on the test sequence, please? I'll try to set it up here in RHTS and reproduce from scratch. Thanks!
copy that, thanks lawrence!
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
modp1024 is meaningless for a child SA since DH is used for parent SAs only. So no wonder this doesn't work. This isn't a bug at all.
Herbert, could you please clarify the above statement? I understand what your saying about the modp option not making sense for anything other than a DH-exchange, but the ipsec man page indicates that the esp configuration option (or more specifically, the successor option phase2alg accepts modp<N> as an optional 3rd argument. Thanks!
OK, what I said was crap :) A second DH is supported for child SAs, just like the old phase 2 PFS option. The only problem is that the syntax is "esp=3des-sha1;modp1024" (note the semicolon!) which works for me.
Created attachment 308224 [details] patch to provide esp with a modp_getbyname pointer Ok, thought I was loosing it for a second :) I think our situation is, at this point, that we have 2 problems here: 1) The ipsec.conf syntax was wrong in the initial test (the use of the semicolon is required when using the esp keyword. This seems to be working properly when the proper syntax is used (as herbert notes above) 2) My patch in referenced in comment 12 may still be needed for support of the phase2alg configuration directive (which supports the '-' syntax, rather than the ';' syntax. Paul, can we get your opinion on the correctess of the patch (which I am attaching)?
Sorry but this patch can't work. The function alg_info_esp_add just throws away the modp ID that's collected. So you need to change it to set the PFS group.
As per conversation with Paul and Herbet, given that the ';'syntax works properly (comment #16) and that the use of the '-' syntax for specify dh groups is ambiguous with some other configuration directives, We're going to update the ipsec.conf documentation to more clearly indicate the use of the former syntax. The lack of operation using the latter syntax is not a bug.