Red Hat Bugzilla – Bug 446551
[IPv6-DoD] IKEv2 testing fail according to IPv6DoD specs.
Last modified: 2008-06-04 08:11:51 EDT
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
• 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
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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
zhiyong, can you let us know which version of openswan you are using?
the version is
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
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.