Bug 441714 - Racoon fails to create loopback SAs using existing SPD configuration
Summary: Racoon fails to create loopback SAs using existing SPD configuration
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: ipsec-tools
Version: 5.3
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 5.5
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 499522 533192
TreeView+ depends on / blocked
 
Reported: 2008-04-09 16:43 UTC by Paul Moore
Modified: 2018-11-14 18:07 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-16 15:31:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Racoon configuration [/etc/racoon/racoon.conf] (845 bytes, text/plain)
2008-04-09 16:44 UTC, Paul Moore
no flags Details
SPD entries [setkey -f setkey.loopback] (629 bytes, text/plain)
2008-04-09 16:45 UTC, Paul Moore
no flags Details
Working racoon.conf for rawhide (1.05 KB, text/plain)
2008-04-26 20:47 UTC, Joe Nall
no flags Details

Description Paul Moore 2008-04-09 16:43:30 UTC
Description of problem:
Using the attached configuration it was possible to create to create loopback 
SAs with the LSPP evaluated release of RHEL5.  However, using the RHEL5.2 
snapshot 3 it is no longer possible using the existing configuration.  The 
problem appears to be related to the ipsec-tools-0.6.5-loopback.patch which 
was included to address BZ 218386.  It appears that this patch hardcodes 
certain loopback SA attributes and no longer honors the user specified 
configuration which appears to be causing the problem.  There does not appear 
to be any documentation in the racoon or setkey man pages to indicate what the 
correct configuration would be to allow loopback SAs.

Version-Release number of selected component (if applicable):
ipsec-tools-0.6.5-8.el5

How reproducible:
Everytime

Steps to Reproduce:
0. Install a RHEL5.2 snapshot 3 system using the HP LSPP configuration
1. Configure racoon with the supplied configuration, restart
2. Configure the kernel's SPD using the supplied configuration
3. Attempt 'ping -c 3 127.0.0.1'
  
Actual results:
Relevant snippet from syslog ...
Apr  9 12:24:32 cert-i4 racoon: INFO: 127.0.0.1[500] used as isakmp port 
(fd=9)
Apr  9 12:24:32 cert-i4 racoon: INFO: 127.0.0.1[500] used for NAT-T
Apr  9 12:24:32 cert-i4 racoon: INFO: 16.116.90.34[500] used as isakmp port 
(fd=10)
Apr  9 12:24:32 cert-i4 racoon: INFO: 16.116.90.34[500] used for NAT-T
Apr  9 12:24:32 cert-i4 racoon: INFO: ::1[500] used as isakmp port (fd=11)
Apr  9 12:24:32 cert-i4 racoon: INFO: fd7b:826d:f2:0:217:a4ff:fe99:adc1[500] 
used as isakmp port (fd=12)
Apr  9 12:24:32 cert-i4 racoon: INFO: 2001:1890:1109:a01:217:a4ff:fe99:adc1
[500] used as isakmp port (fd=13)
Apr  9 12:24:32 cert-i4 racoon: INFO: fe80::217:a4ff:fe99:adc1%eth0[500] used 
as isakmp port (fd=14)
Apr  9 12:24:38 cert-i4 racoon: INFO: security context doi: 1
Apr  9 12:24:38 cert-i4 racoon: INFO: security context algorithm: 1
Apr  9 12:24:38 cert-i4 racoon: INFO: security context length: 51
Apr  9 12:24:38 cert-i4 racoon: INFO: security context: 
staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023
Apr  9 12:24:38 cert-i4 racoon: ERROR: pfkey UPDATE failed: No such file or 
directory

Expected results:
No errors in syslog and a usable IPsec SA.

Additional info:
This can be considered a regression against the RHEL5 LSPP evaluation.  
Documentation may make this less of an issue but none appears to exist in the 
usual places (man pages).

Comment 1 Paul Moore 2008-04-09 16:44:18 UTC
Created attachment 301847 [details]
Racoon configuration [/etc/racoon/racoon.conf]

Comment 2 Paul Moore 2008-04-09 16:45:03 UTC
Created attachment 301848 [details]
SPD entries [setkey -f setkey.loopback]

Comment 5 Joy Latten 2008-04-11 23:33:39 UTC
I will try and take a look at this during the weekend or Monday.

Comment 7 Joe Nall 2008-04-26 19:19:58 UTC
I can confirm the loopback ipsec failures on RH5.2.

We are also seeing very serious loopback/local IP SA creation issues on rawhide.
Some loopback/local IP SA creations are fast, some take minutes. The machine is
idle during the wait, so it looks like some sort of race condition.


Comment 8 Joe Nall 2008-04-26 20:47:20 UTC
Created attachment 303871 [details]
Working racoon.conf for rawhide

The attached racoon.conf works in rawhide. 192.168.20.101 is the IP address of
eth0. If hmac_sha1 is changed to non_auth in the two ip specific sainfo
clauses, no associations form. Loopback SA creation performance is poor.

Comment 9 Joe Nall 2008-04-26 20:49:35 UTC
The configuration above generates 2 SAs for each unique type/context. One is unused (by byte count).

Comment 10 Linda Knippers 2008-04-28 17:18:33 UTC
Joe, what version of ipsec-tools do you have when it works?  The version of
ipsec-tools in rhel5u2 appears to the be same version we included in our
evaluation (updated from rhel5) so now I'm confused about what's different.  
Have you been using the rhel5 version (0.6.5-6) or the one we evaluated
(0.6.5-8)?

Comment 11 Joy Latten 2008-04-28 22:31:31 UTC
I tried this in RHEL5.2 snap6, IBM LSPP config and it worked ok with Paul's
ipsec config files. The version of racoon is ipsec-tools-0.6.5-9.el5.

Paul, I am investigating the error message you got... according to the code, the
kernel failed to update the SA and sent an ENOENT... but I am baffled as to
where the ENOENT came from when doing an update so I need to look some more at
kernel code.  

I think the racoon code is the same from when I first added the change for LSPP.
I had hard-coded the attributes since it was a late patch and wanted to clean it
up but just never got the time.  

Comment 12 Joy Latten 2008-04-28 22:33:40 UTC
Joe, were you seeing the same problems in RHEL5.0?

Comment 13 Joy Latten 2008-04-28 22:34:33 UTC
This is odd since the userspace code should be exactly the same... 

Comment 14 Linda Knippers 2008-04-28 22:37:12 UTC
Joy, I'm puzzled by that too.  Is there any difference in the kernel code? 
Sounds like the attributes are still hard-coded in the user-space code?

I haven't looked at the latest snap but snap3 has 0.6.5-8 so what's
new in -9?



Comment 15 Joe Nall 2008-04-28 23:33:56 UTC
RHEL5.0 and 5.1 were fine. This is from a 5.1 VM:
[root@laptop ~]# !setk
setkey -D | grep context:
        security context: system_u:system_r:jcdx_qp_t:s0-s15:c0.c1023
        security context: system_u:system_r:inetd_t:s0-s15:c0.c1023
        security context: system_u:system_r:jcdx_qc_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_qm_t:s0-s15:c0.c1023
        security context: system_u:system_r:jcdx_qs_t:s0-s15:c0.c1023
        security context: system_u:system_r:jcdx_qalertd_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_ebee_t:s5:c0.c511
        security context: system_u:system_r:jcdx_ebe_t:s5:c0.c511
        security context: system_u:system_r:jcdx_procmon_db_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_cen_mon_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_procmon_alerts_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_qm_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_uniquenum_t:s5:c0.c511
        security context: system_u:system_r:jcdx_hta_t:s5:c0.c511
        security context: system_u:system_r:jcdx_dirchan_t:s5:c0.c511
        security context: system_u:system_r:jcdx_jetsindex_t:s5:c0.c511
        security context: system_u:system_r:jcdx_ped_t:s0-s5:c0.c511
        security context: system_u:system_r:jcdx_imf_t:s5:c0.c511
        security context: system_u:system_r:jcdx_ocm_t:s5:c0.c511
        security context: system_u:system_r:jcdx_olog_t:s5:c0.c511
        security context: system_u:system_r:jcdx_qp_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_icm_t:s5:c0.c511
        security context: system_u:system_r:jcdx_ilog_t:s5:c0.c511
        security context: system_u:system_r:inetd_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_qs_t:s15:c0.c1023
        security context: system_u:system_r:jcdx_tagd_t:s5:c0.c511
        security context: system_u:system_r:jcdx_tdbm_t:s5:c0.c511
        security context: system_u:system_r:jcdx_tagd_t:s0-s5:c0.c511
        security context: system_u:object_r:jcdx_mtdb_t:s0-s5:c0.c511
        security context: system_u:system_r:jcdx_tdbm_t:s5:c0.c511
        security context: system_u:system_r:ntpd_t:s0-s15:c0.c1023
        security context: system_u:system_r:sshd_t:s0-s15:c0.c1023
[root@laptop ~]# setkey -D | grep context: | wc -l
32
[root@laptop ~]# rpm -q ipsec-tools
ipsec-tools-0.6.5-8.el5
[root@laptop ~]# rpm -q kernel

Note the 1 SA per type/level.



Comment 16 Joe Nall 2008-04-28 23:39:33 UTC
rpm -q kernel for above
kernel-2.6.18-53.1.14.el5



Comment 17 Joe Nall 2008-04-28 23:40:51 UTC
[root@xw4100 ~]# more /etc/redhat-release 
Red Hat Enterprise Linux Client release 5.2 Beta (Tikanga)

[root@xw4100 ~]# setkey -D
127.0.0.1 127.0.0.1 
        esp mode=transport spi=66680689(0x03f97771) reqid=0(0x00000000)
        seq=0x00000000 replay=0 flags=0x00000000 state=larval 
        created: Apr 28 18:35:13 2008   current: Apr 28 18:35:35 2008
        diff: 22(s)     hard: 30(s)     soft: 0(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        security context doi: 1
        security context algorithm: 1
        security context length: 49
        security context: system_u:system_r:jcdx_talertd_t:s0-s15:c0.c1023
        sadb_seq=0 pid=11517 refcnt=0

[root@xw4100 ~]# rpm -q ipsec-tools
ipsec-tools-0.6.5-8.el5
[root@xw4100 ~]# rpm -q kernel
kernel-2.6.18-84.el5


Comment 18 Tomas Mraz 2008-07-29 18:07:02 UTC
This seems like a regression in kernel as evident from comments #15, #16, and #17.

The difference between RHEL-5 ipsec-tools version and current Fedora (rawhide)
is that the loopback patch in current RHEL-5 ipsec-tools automatically creates
the loopback SAs without the full ISAKMP negotiation. The rawhide patch just
allows to complete the regular negotiation of the racoon with itself. But I
wouldn't be surprised that the rawhide approach is racy.


Comment 19 Joe Nall 2008-07-29 18:51:01 UTC
Have you been able to duplicate the problem?

Comment 20 Tomas Mraz 2008-07-30 16:05:03 UTC
I am trying to reproduce the problem just now and unfortunately I was not able
to reproduce it on the RHEL-5.2 kernel:
Linux 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008

I will port the loopback patch from RHEL-5 to rawhide ipsec-tools version to try
it there.


Comment 22 RHEL Program Management 2009-02-16 15:41:25 UTC
Updating PM score.

Comment 23 Tomas Mraz 2009-04-21 18:18:39 UTC
Reporter, are you still able to reproduce the problem with 5.3 kernel & ipsec-tools versions?

Comment 24 Joe Nall 2009-04-21 19:38:14 UTC
Not immediately. I'll have to build a RH5.3 system. We've been using Fedora 10 lately.

Comment 33 Tomas Mraz 2010-02-16 15:31:59 UTC
Unfortunately I was not able to reproduce the problem and I do not have enough necessary information to do so and fix the bug.


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