Bug 524191

have reported a same bug on bugs.openswan.org, the link: https://gsoc.xelerance.com/issues/1064

Hi, Avesh

It's not a request from customer, just because we want to go through the IPv6 certification of IKEV2.

As you known, we must use the test suite((http://cert.v6pc.jp/ikev2/) from TAHI to get the certification, it means we use the test suite from TAHI on the tester node, and openswan on the testee node, which is a RHEL5.4.

now caused by openswan doesn't support the message digest algorithm the test suite from TAHI uses, which is HMAC-SHA1-96, so the testing can't be processed, and we can't get the certification of IKEV2 for RHEL5.4

thanks.

Hi, Avesh.

    I have setup two virtual machines, both are RHEL5.4, and updated the openswan to latest version (openswan-2.6.21-6.el5). with the configuration listed  as follows, and I have two questions.


========================================
config setup
        crlcheckinterval="180"
        strictcrlpolicy=no
        protostack=netkey
        plutodebug=all
        nat_traversal=yes

conn %default
        ikelifetime="60m"
        keylife="20m"
        rekeymargin="3m"
        keyingtries=1
        ike=3des-sha1-modp1024
        esp=3des-sha1
        authby=secret
        ikev2=yes
        rekey=yes

conn host-host
        connaddrfamily=ipv6
        left=3ffe:501:ffff:100:216:3eff:fe76:b919
        right=3ffe:501:ffff:100:216:3eff:fe4f:60a
        leftid=3ffe:501:ffff:100:216:3eff:fe76:b919
        rightid=3ffe:501:ffff:100:216:3eff:fe4f:60a
        type=transport
        compress=no
        auto=add

========================================

[QUESTION 1]:
I got these messages when start the connection "host-host":
[root@dhcp-66-70-173 Desktop]# ipsec auto --up host-host
133 "host-host" #1: STATE_PARENT_I1: initiate
133 "host-host" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
134 "host-host" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=oakley_sha group=modp1024}
004 "host-host" #2: STATE_PARENT_I3: PARENT SA established transport mode {ESP=>0x169b183d <0x8662c352 xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none}

that means "ike=3des-sha1-modp1024" in ipsec.conf is parsed into " {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=oakley_sha group=modp1024}", right? moreover, it means "sha1" is translated into "sha1_96".

and in the next line of ipsec.conf, "esp=3des-sha1", is parsed into "{ESP=>0x169b183d <0x8662c352 xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none}", we can see here the "sha1" is translated into "sha1", but not "sha1_96".

so my question is if I want to use sha1 but not sha-96 instead. how could I write the value of "ike"? because as you see, in "ike=3des-sha1-modp1024", sha1 is translated into sha1-96.

and it make the user very confused because just in the next line (esp="3des-sha1"), "sha1" is translated into "sha1".


[QUESTION 2].
could you please take a look at the 23th page of http://www.ipv6ready.org/docs/Phase2_IKEv2_Conformance_Latest.pdf, you can see both it has requirements of the value of both "ike" and "esp". thanks very much.


[QUESTION 3]
how could we config the ipsec.conf to be consistent with the message digest algrithom the TAHI test suite use, just as "ike=3des-sha1-modp1024" and "esp=3des-sha1"? because I didn't see update of the documents of openswan to tell the user how to config the ipsec.conf to support sha1-96. 

And actullay, I use the same config to test using TAHI test suite,  the cases didn't pass.

Hi, Avesh

    Thanks for your explaination, clear about those questions now. but I have another question, :)

    I have downgrade openswan to (openswan-2.6.21-5.el5) on one of the virtual machine, and using the same ipsec.conf. the tunnel could also be setup successfully, and it looks like works well too. 


    on virtual machine A:
[root@dhcp-66-70-173 Desktop]# rpm -qa | grep openswan
openswan-2.6.21-6.el5
openswan-doc-2.6.21-6.el5
openswan-debuginfo-2.6.21-6.el5

    on virtual machine B:
[root@dhcp-66-70-136 ~]# rpm -qa | grep openswan
openswan-2.6.21-5.el5
openswan-doc-2.6.21-5.el5

    on virtual machine A:
[root@dhcp-66-70-173 Desktop]# !ser
service ipsec restart
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
ipsec_setup: Stopping Openswan IPsec...
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
ipsec_setup: Starting Openswan IPsec U2.6.21/K2.6.18-164.el5PAE...
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled

[root@dhcp-66-70-173 Desktop]# ipsec auto --up host-host
133 "host-host" #1: STATE_PARENT_I1: initiate
133 "host-host" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
134 "host-host" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=oakley_sha group=modp1024}
004 "host-host" #2: STATE_PARENT_I3: PARENT SA established transport mode {ESP=>0xbb6f8e03 <0x2fbbc90e xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none}

    on virtual machine B:
[root@dhcp-66-70-136 ~]# !ser
service ipsec restart
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
ipsec_setup: Stopping Openswan IPsec...
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
/usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
ipsec_setup: Starting Openswan IPsec U2.6.21/K2.6.18-164.el5PAE...
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled

[root@dhcp-66-70-136 ~]# !ipsec
ipsec auto --up host-host
133 "host-host" #1: STATE_PARENT_I1: initiate
133 "host-host" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
134 "host-host" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1 prf=oakley_sha group=modp1024}
004 "host-host" #2: STATE_PARENT_I3: PARENT SA established transport mode {ESP=>0x73cfaee7 <0xa4a14abb xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none}

    on virtual machine A:
[root@dhcp-66-70-173 Desktop]# !ping6
ping6 3ffe:501:ffff:100:216:3eff:fe4f:60a
PING 3ffe:501:ffff:100:216:3eff:fe4f:60a(3ffe:501:ffff:100:216:3eff:fe4f:60a) 56 data bytes
64 bytes from 3ffe:501:ffff:100:216:3eff:fe4f:60a: icmp_seq=0 ttl=64 time=0.558 ms
64 bytes from 3ffe:501:ffff:100:216:3eff:fe4f:60a: icmp_seq=1 ttl=64 time=0.688 ms


    on virtual machine B:
[root@dhcp-66-70-173 ~]# tcpdump -i eth0 ip6 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:49:22.733185 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ESP(spi=0xa4a14abb,seq=0x7), length 140
10:49:22.737937 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ICMP6, echo request, length 64, seq 0
10:49:22.737974 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe4f:60a > 3ffe:501:ffff:100:216:3eff:fe76:b919: ESP(spi=0x73cfaee7,seq=0x7), length 140
10:49:23.930796 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ESP(spi=0xa4a14abb,seq=0x8), length 140
10:49:23.930796 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ICMP6, echo request, length 64, seq 1
10:49:23.930898 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe4f:60a > 3ffe:501:ffff:100:216:3eff:fe76:b919: ESP(spi=0x73cfaee7,seq=0x8), length 140
10:49:25.082251 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ESP(spi=0xa4a14abb,seq=0x9), length 140
10:49:25.082251 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ICMP6, echo request, length 64, seq 2
10:49:25.082379 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe4f:60a > 3ffe:501:ffff:100:216:3eff:fe76:b919: ESP(spi=0x73cfaee7,seq=0x9), length 140
10:49:26.306730 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ESP(spi=0xa4a14abb,seq=0xa), length 140
10:49:26.306730 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ICMP6, echo request, length 64, seq 3
10:49:26.306835 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe4f:60a > 3ffe:501:ffff:100:216:3eff:fe76:b919: ESP(spi=0x73cfaee7,seq=0xa), length 140


As you can see, A and B use the diffrent integ algorithom, A use sha1_96, B use sha1, but the tunnel was setup successfully, and works well.

Hi, Avesh.
    thanks for your suggestion, I'm always in #eng-china, and the time zone is "Asia -> China -> Chongqing", and available from 9am to 7pm in the week days. 

    Jiabo Wang will help to test the TAHI, because I'm busy in other work. but may be I can help to provide some information you need. 

    thanks.

comment #18
  
   we did the test, but still have failed, we can not get SPD and SAD, I think the problem from Remote files.
we will focus on remote files writing.
thanks Avesh and Jyang.

comment #18
  
   we did the test, but still have failed, we can not get SPD and SAD, I think the problem from Remote files.
we will focus on remote files writing.
thanks Avesh and Jyang.

  Hi, Avesh. 
     the attachments are the log of pluto and TAHI, you can take reference if have time, because I'm not very farmiliar with the IKEV2, so may be you can detect what exactly the problem is. thanks.

Created attachment 365670 [details]
the log generated by TAHI test suite

Created attachment 365671 [details]
the log generated by testee machine(RHEL5.4 with the latest openswan)

Hi, Avesh
    the TAHI using perl script to constuct the packet. there is no configuration file on TAHI side. this is the ipsec.conf on openswan side, actually it's generated by remote files which are perl scripts called by TAHI test suite.

config setup
        crlcheckinterval="180"
        strictcrlpolicy=no
        protostack=netkey
        interfaces=%defaultroute
        plutostderrlog=/var/log/pluto.log

conn %default
        ikelifetime="60m"
        keylife="20m"
        rekeymargin="3m"
        keyingtries=1
        phase2=esp
        ike=3des-sha1-modp1024
        phase2alg=3des-sha1
        authby=secret
        ikev2=yes
        rekey=yes
        keyexchange=ike

conn host-host
        connaddrfamily=ipv6
        left=2001:0db8:0001:0001::1234
        right=2001:0db8:000f:0001::1
        leftid=2001:0db8:0001:0001::1234
        rightid=2001:0db8:000f:0001::1
        type=transport
        compress=no
        auto=start

Hi Avesh.

   seems klips is obselete? remeber that I saw in some document.

Osier
Thanks and Regards

Hi, Avesh
   please wait a little while. the case is running.

Created attachment 365710 [details]
the output on openswan side of ipsec barf

Hi Avesh

have uploaded the output of "ispec barf", unlucky the machine I logined IRC is down. 

Thanks
Osier

Created attachment 365720 [details]
the newer barf out

Created attachment 365722 [details]
newer pluto.log

Created attachment 365727 [details]
tahi document to show the algrithom

Hi, Avesh. the error msg "bind: Address already in use" may be caused by the connection wasn't closed correctly. 

% netstat -ant
....................
....................
....................
....................
Active UNIX domain sockets
Address  Type   Recv-Q Send-Q    Inode     Conn     Refs  Nextref Addr
c6c35000 stream      0      0        0 c6c352d0        0        0
c6c352d0 stream      0      0        0 c6c35000        0        0
c6c356c0 stream      0      0 c6c2e880        0        0        0 /var/run/devd.pipe
c6c35480 dgram       0      0        0 c6c35120        0 c6c35090
c6c35240 dgram       0      0        0 c6c351b0        0        0
c6c35090 dgram       0      0        0 c6c35120        0        0
c6c35120 dgram       0      0 c6c24220        0 c6c35480        0 /var/run/logpriv
c6c351b0 dgram       0      0 c6e30110        0 c6c35240        0 /var/run/log

Hi Avesh

"sendMessagesSync: never got /sbin/setkey -D"
"sendMessagesSync: never got /sbin/setkey -FP"
"sendMessagesSync: never got /bin/ps -ax | /bin/grep -e pluto"

the messages like so is caused by TAHI always checks echo back from the remote system with the serial line,  and it seems the echo back is disabled on NUT. 

I asked Jiabo Wang before,  he said that this will influnce the test result. because the dhcp and other protocal test suite also print that messages.

whatever, I didn't find a way to enable the echo back of the serial line. 

Could Jiabo Wang please help us setup an enthenet connection instead of serial line to see what will happen?  thanks


Osier
Thanks and Regards

Created attachment 366534 [details]
tcpdump info

please look the attachment from 373 line.
NUT(RHEL5.4) is 1:db8:1:1::1234, TN(Freebsd) is 1:db8:1:1::f.
1:db8:1:1::1(I'm no sure the ip from where) can ping 1:db8:1:1::1234(NUT).
NUT can send IKE_SA_INIT, but 1:db8:1:1::1 report port unreachable.
another thing: TN can send NS to NUT, and NUT can send NA to TN
so the problem maybe from configuration.
I will check with Jyang

Hi Jiabo, Avesh
    that's caused by avesh modified /usr/ipv6_test/IKEv2_Self_Test_1-0-3/config.pl, avesh, is it right?

======diff of the original config.pl and modified config.pl=========
testcore# diff config.pl /usr/ipv6_test/IKEv2_Self_Test_1-0-3/config.pl 
55c55
< $ikev2_prefixA        = '2001:0db8:0001:0001';
---
> $ikev2_prefixA        = '1:0db8:0001:0001';
62c62
< $ikev2_prefixB        = '2001:0db8:0001:0002';
---
> $ikev2_prefixB        = '1:0db8:0001:0002';
71c71
< $ikev2_prefixX        = '2001:0db8:000f:0001';
---
> $ikev2_prefixX        = '1:0db8:000f:0001';
78c78
< $ikev2_prefixY        = '2001:0db8:000f:0002';
---
> $ikev2_prefixY        = '1:0db8:000f:0002';

Hi, Avesh

    It's so great. have seen you sent a patch to TAHI, hope they can give the feedback quickly, thanks very much. :)

Thanks and Regards
Osier

Hi Avesh
    
     As you known, our work is blocked by some problem of TAHI test suite currently. What we can do is just waiting for their response. 

     And now we will say your patch works well, just because with other test methods like openswan-to-openswan, it's okay.
  
     Hope this won't block your work process anymore.

Thanks and Regards
Osier

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0211.html