Bug 462731 - invalid behaviour of NETKEY / XFRM deleting SPD
invalid behaviour of NETKEY / XFRM deleting SPD
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: rc
: ---
Assigned To: Herbert Xu
Red Hat Kernel QE team
Depends On:
  Show dependency treegraph
Reported: 2008-09-18 12:14 EDT by Johannes Russek
Modified: 2009-09-02 04:45 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 04:45:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output from strace -f -s 8096 during ipsec status (8.22 KB, application/octet-stream)
2009-06-23 11:34 EDT, Johannes Russek
no flags Details
ipsec: Add missing braces to fix policy querying (1023 bytes, patch)
2009-07-02 03:41 EDT, Herbert Xu
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1243 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.4 kernel security and bug fix update 2009-09-01 04:53:34 EDT

  None (edit)
Description Johannes Russek 2008-09-18 12:14:46 EDT
Description of problem:

calls to netkey / xfrm lead to unexpected behaviour. more specific: when strongswan calls XFRM_GET_POLICY to gather information about a current SPD, no valid data is returned and the SPD is instead getting deleted. This leads to loosing an ipsec tunnel when performing "ipsec status" but also to DPD packets destroying a tunnel (as the xfrm_get_policy get's called when a DPD packet arrives).

Version-Release number of selected component (if applicable):

strongswan 4.1.11, 4.2.6, 4.2.7

How reproducible:


Steps to Reproduce:

compile strongswan, configure tunnel, run ipsec up tunnel. ip xfrm policy shows multiple spds. now run ipsec status or configure DPD and wait for the first DPD event and run ip xfrm policy again, the SPDs are lost.

Additional info:

a better description is avaible in the strongswan mailing list at https://lists.strongswan.org/pipermail/users/2008-February/002262.html
apparently this might be an issue with xfrm.h from 2.6.18 but nailing this down goes over my head :/
Comment 1 Linda Wang 2008-11-05 21:46:04 EST
we don't support strongswan, can you give openswan a try?
Comment 2 Johannes Russek 2008-11-12 07:46:24 EST
strongswan is just considered to be the more secure and elaborate solution. stuff like ikev2 and mobike is in strongswan but not in openswan, as well as sophisticated pki infrastructure support (like scep, ocsp, crl cache etc..) which is what we like about it (we are using the redhat / dogtag pki which works very well together with strongswan!).
also, as far as i can nail it doen, this actually has been working pre 5.2!
Comment 3 Herbert Xu 2009-04-08 02:58:43 EDT
Johannes, we need to determine whether this is a bug in Stronswan or the kernel.  Could you please strace strongswan when you perform the action that leads to the policies being deleted? Please run strace with -s 4096 so we get the complete netlink messages.  This should tell us what netlink commands it issued and hence whether the bug is in the kernel or Strongswan.  Thanks!
Comment 4 Johannes Russek 2009-06-23 11:34:59 EDT
Created attachment 349106 [details]
output from strace -f -s 8096 during ipsec status

This is the output of

strace -f -o pluto.out -s 8096 ipsec start

then after the connection is being brought up with 

ipsec up testconnection

i created the attachment with fail -f pluto.out >> pluto_status.out

and issued ipsec status, which then leads to the described behaviour.
this is the latest strongswan (4.3.1) as well as the latest kernel (2.6.18-128.1.14.el5).

I've set up a test environment for this kind of testing within qemu now, so if you need anything else, please just let me know, i will be able to supply you with that much faster than before.

Comment 5 Johannes Russek 2009-06-23 11:39:53 EDT
I'm sorry, that's of course supposed to say "tail -f pluto.out".
Comment 6 Herbert Xu 2009-06-26 02:22:45 EDT
OK the strace doesn't show any problems.  pluto does getpolicy three times and get valid results each time.

Can you run ip xfrm monitor in addition to strace to see if something else is deleting the policies?

Comment 7 Johannes Russek 2009-06-26 05:53:14 EDT
ip xfrm monitor doesn't show anything when ipsec status is issued.

before that, i get a lot of those: 

Unknown message: 00000096 0x0000001e 0x00000000
Unknown message: 00000096 0x0000001e 0x00000000
Unknown message: 00000096 0x0000001e 0x00000000

but i don't think that's a problem since the ipsec is up and running while i'm getting those.

anything else i can do?

Comment 8 Herbert Xu 2009-06-26 21:10:34 EDT
What does ip -s x p say when the policies are present? What does it say immediately after you run ipsec status?

Can you try to replicate what pluto is sending by using ip xfrm? For example,
does ip xfrm policy get dir in SELECTOR (you'll have to spell this out with your selector) cause the policy to be deleted?

If not please strace ip xfrm policy get so I can see what's different between its message and that sent from pluto.

Comment 9 Johannes Russek 2009-06-30 05:54:14 EDT
Hello Herbert,
sorry i wasn't in the lab untill now.
However, this confirmed that the error indeed appears not to be in pluto:

[root@fw01 ~]# ip xfrm policy get dir out src dst
src dst 
	dir out priority 2344 
	tmpl src dst
		proto esp reqid 16385 mode tunnel
[root@fw01 ~]# ip xfrm policy get dir out src dst
RTNETLINK answers: No such file or directory

there was absolutely nothing done inbetween, both commands were applied right after each other. 
Thanks for your help so far.
For more info ask as usual :)
Comment 10 Herbert Xu 2009-06-30 06:34:27 EDT
Hmm, indeed I can reproduce this too on a RHEL5 kernel.  Let me investigate.
Comment 11 Herbert Xu 2009-07-02 03:41:49 EDT
Created attachment 350249 [details]
ipsec: Add missing braces to fix policy querying

Braces were missing in the policy querying functions causing the queried policies to be deleted.
Comment 13 RHEL Product and Program Management 2009-07-02 15:03:39 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
Comment 15 Don Zickus 2009-07-14 16:56:52 EDT
in kernel-2.6.18-158.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 19 Johannes Russek 2009-08-12 10:15:17 EDT
was able to verify the fix in the test kernel :)
Comment 20 errata-xmlrpc 2009-09-02 04:45:40 EDT
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.


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