RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 621790 - [TAHI]openswan doesn't support auth alg with "ESP=3DES-CBC HMAC-SHA2-256" in transport mode
Summary: [TAHI]openswan doesn't support auth alg with "ESP=3DES-CBC HMAC-SHA2-256" in ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openswan
Version: 6.1
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Avesh Agarwal
QA Contact: Aleš Mareček
URL:
Whiteboard:
Depends On:
Blocks: 572236
TreeView+ depends on / blocked
 
Reported: 2010-08-06 07:04 UTC by Xiaoli Tian
Modified: 2011-05-19 13:55 UTC (History)
7 users (show)

Fixed In Version: openswan-2.6.32-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 13:55:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
test log of ahthentication algorithm testing (18.22 KB, text/html)
2010-08-06 07:04 UTC, Xiaoli Tian
no flags Details
package dump files of this case (146 bytes, application/octet-stream)
2010-08-06 07:06 UTC, Xiaoli Tian
no flags Details
out put of ipsec barf (26.81 KB, text/plain)
2010-09-09 08:17 UTC, Xiaoli Tian
no flags Details
Files in /etc/ipsec.d/ (1.51 KB, application/x-gzip)
2010-09-09 08:18 UTC, Xiaoli Tian
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0652 0 normal SHIPPED_LIVE openswan bug fix and enhancement update 2011-05-18 17:55:32 UTC

Description Xiaoli Tian 2010-08-06 07:04:45 UTC
Created attachment 437042 [details]
test log of ahthentication algorithm testing

Description of problem:
When using TAHI IPsec-self-test suit test ipsec, there's one case to test authentication algorithm with "ESP=3DES-CBC HMAC-SHA2-256" in transport mode,
After all the IPSec related settings(details could be found in the attached log) ,sent an echo request with ESP to the targeted machine, but received no echo reply. 

Version-Release number of selected component (if applicable):
kernel-2.6.32-47.el6.x86_64
openswan-2.6.24-8-el6_x86_64
v6eval-3.3.1,
IPSec_Self_Test_P2_1.10.0

How reproducible:
100%

Steps to Reproduce:
1.Setup all the required TAHI test suits 
2.Install openswan-2.6.24-8-el6_x86_64
3.execute initializing command:
./p2_HTR_Reset.seq -pkt ./p2_HTR_Reset.def 
4.execute authentication algorithm testing command:
./p2_HTR_E_Common.seq -pkt ./p2_HTR_E_ICMP_common.def test_type=ADVANCED support=3DES_CBC_HMAC_SHA2_256_SUPPORT ealgo=3des-cbc eauth=hmac-sha2-256 einkey=E_3descbc_in_key ainkey=A_hmacsha2256_in_key eoutkey=E_3descbc_out_key aoutkey=A_hmacsha2256_out_key ealgo_from=ealgo_3descbc_hmacsha2256_in ealgo_to=ealgo_3descbc_hmacsha2256_out
  
Actual results:
Failed to receive any echo reply.

Expected results:
could receive echo reply

Additional info:
The test log and packages dump file are attached, FYI.

Comment 1 Xiaoli Tian 2010-08-06 07:06:54 UTC
Created attachment 437044 [details]
package dump files of this case

Comment 3 RHEL Program Management 2010-08-06 07:27:39 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 10 Xiaoli Tian 2010-09-09 08:17:17 UTC
Created attachment 446163 [details]
out put of ipsec barf

Comment 11 Xiaoli Tian 2010-09-09 08:18:22 UTC
Created attachment 446165 [details]
Files in /etc/ipsec.d/

Comment 12 Avesh Agarwal 2010-09-09 12:34:54 UTC
I do not see any ipsec connection configured in your file. If you do not configure an ipsec connection, then how Openswan can process packets coming from the other end.

Comment 13 Xiaoli Tian 2010-09-10 01:14:22 UTC
(In reply to comment #12)
> I do not see any ipsec connection configured in your file. If you do not
> configure an ipsec connection, then how Openswan can process packets coming
> from the other end.

Hi,the ipsec connection is configured by remote control files when running each case,but not configured it well in advance .for this case ,you could see from the log http://focus.bne.redhat.com/~xtian/IPSec/Conformance/IPsec_Self_Test_P2_1-10-0-RHEL6.0RC-20100908/ipsec.p2/index.html at 14:30:28.

According to the log,you could see ipsec connection configuration is as following:

/sbin/ip xfrm state add src 3ffe:501:ffff:0001:0000:0000:0000:0001 dst 3ffe:501:ffff:0:21a:a0ff:febd:5d1 proto esp spi 0x1000  enc des3_ede 0x6970763672656164796c6f676f33646573636263696e3031 auth sha2-256 0x6970763672656164796c6f676f706832697073656373686132323536696e3031 mode transport sel src 3ffe:501:ffff:0001:0000:0000:0000:0001 dst 3ffe:501:ffff:0:21a:a0ff:febd:5d1
/sbin/ip xfrm state add src 3ffe:501:ffff:0001:0000:0000:00 00:0001 dst 3ffe:501:ffff:0:21a:a0ff:febd:5d1 proto esp spi 0x1000  enc des3_ede  0x6970763672656164796c6f676f33646573636263696e3031 auth sha2-256 0x697076367265 6164796c6f676f706832697073656373686132323536696e3031 mode transport sel src 3ffe :501:ffff:0001:0000:0000:0000:0001 dst 3ffe:501:ffff:0:21a:a0ff:febd:5d1

ip xfrm policy add dir in src 3ffe:501:ffff:0001:0000:0000:0000:0001 dst 3ffe:501:ffff:0:21a:a0ff:febd:5d1  tmpl src 3ffe:501:ffff:0001:0000:0000:0000:0001 dst 3ffe:501:ffff:0:21a:a0ff:febd:5d1 proto esp mode transport action allow '' command
ip xfrm policy add dir in src 3ffe:501:ffff:0001:0000:0000: 0000:0001 dst 3ffe:501:ffff:0:21a:a0ff:febd:5d1  tmpl src 3ffe:501:ffff:0001:000 0:0000:0000:0001 dst 3ffe:501:ffff:0:21a:a0ff:febd:5d1 proto esp mode transport  action allow

but as the log said,"RTNETLINK answers: Function not implemented"


Thank you.

Comment 14 Xiaoli Tian 2010-09-10 01:55:21 UTC
  you could find  command vRemote(ipsecSetSPD.rmt)  and  vRemote(ipsecSetSPD.rmt) in the log of  case 21 in above link to configure IPsec connetction.

Comment 17 Avesh Agarwal 2011-02-28 15:55:34 UTC
Your test commands seem to be wrong to me. Please check the following errors:

/sbin/ip xfrm state add src 3ffe:501:ffff:0001:0000:0000:000 0:0001 dst 3ffe:501:ffff:0:21d:9ff:fe23:a91f proto esp spi 0x1000  enc des3_ede  0x6970763672656164796c6f676f33646573636263696e3031 auth sha2-256 0x6970763672656 164796c6f676f706832697073656373686132323536696e3031 mode transport sel src 3ffe: 501:ffff:0001:0000:0000:0000:0001 dst 3ffe:501:ffff:0:21d:9ff:fe23:a91f
RTNETLINK answers: Function not implemented

seems like in "sel src" argument you have a space between "3ffe:" "501:ffff:0001:0000:0000:0000:0001" 

And may be because of this, your commands are failing. I saw similar errors in other places too. I would recommend you to check your test commands once again to make sure there is not error.


Moreover, I would like to tell you that it seems to me that the test cases you are running are not related to Openswan (IKE), because you are testing ipsec in kernel.

Comment 18 Avesh Agarwal 2011-02-28 16:32:40 UTC
In addition, for ip xfrm command, the string for sha2(256) is sha256 not sha2-256. Please correct this too and try again.

Comment 19 Xiaoli Tian 2011-03-01 01:59:36 UTC
 (In reply to comment #18)
> In addition, for ip xfrm command, the string for sha2(256) is sha256 not
> sha2-256. Please correct this too and try again.

Hi,Avesh

Thanks for your reminding. The real problem is the mapping of eauth algrithom hmac-sha2-256 from TAHI's hmac-sha2-256 to our sha256 in our remote control script.
I have changed the remote control script and test it again,it has been fixed,thanks again:)
FYI:
http://fileshare.englab.nay.redhat.com/pub/section2/ipv6cert/IPSec_EN/Conformance/bug_621790/21.html

Comment 20 errata-xmlrpc 2011-05-19 13:55:15 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0652.html


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