Bug 446551 - [IPv6-DoD] IKEv2 testing fail according to IPv6DoD specs.
[IPv6-DoD] IKEv2 testing fail according to IPv6DoD specs.
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openswan (Show other bugs)
5.2
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Neil Horman
:
Depends On:
Blocks: 253764
  Show dependency treegraph
 
Reported: 2008-05-14 22:01 EDT by Zhiyong Wu
Modified: 2008-06-04 08:11 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-04 08:11:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to provide esp with a modp_getbyname pointer (486 bytes, patch)
2008-06-03 08:40 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description Zhiyong Wu 2008-05-14 22:01:49 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
     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:
Comment 1 Paul Wouters 2008-05-23 12:15:30 EDT
what about esp=3des-sha1-96-modp1024  ?

I knwo the parser has some oddities in it that we should address at some point.
Comment 2 Zhiyong Wu 2008-05-28 01:45:28 EDT
paul, when setting esp=3des-sha1-96-modp1024, the result also fail and display the 

same info.
Comment 3 Linda Wang 2008-05-30 10:01:54 EDT
zhiyong, can you let us know which version of openswan you are using?
Comment 4 Zhiyong Wu 2008-05-30 11:10:29 EDT
Hi, Linda, 

the version is

(1) kernel-2.6.18-92.el5

(2) openswan-2.6.12-2.el5
Comment 5 Neil Horman 2008-05-30 11:34:26 EDT
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!
Comment 6 Zhiyong Wu 2008-06-02 04:45:53 EDT
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.
Comment 7 Neil Horman 2008-06-02 07:30:13 EDT
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!
Comment 9 Neil Horman 2008-06-02 11:15:58 EDT
copy that, thanks lawrence!
Comment 11 RHEL Product and Program Management 2008-06-02 15:59:46 EDT
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.
Comment 14 Herbert Xu 2008-06-03 00:57:57 EDT
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.
Comment 15 Neil Horman 2008-06-03 07:31:24 EDT
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!
Comment 16 Herbert Xu 2008-06-03 08:01:00 EDT
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.
Comment 17 Neil Horman 2008-06-03 08:40:21 EDT
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)?
Comment 18 Herbert Xu 2008-06-03 09:07:08 EDT
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.
Comment 23 Neil Horman 2008-06-04 08:11:51 EDT
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.

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