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 678582 - ping traffic (icmp) sends xfrm ACQUIRE msgs with protocol 17 (UDP)
Summary: ping traffic (icmp) sends xfrm ACQUIRE msgs with protocol 17 (UDP)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.1
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: rc
: ---
Assignee: Herbert Xu
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: RHEL62CCC 846801 846802
TreeView+ depends on / blocked
 
Reported: 2011-02-18 14:18 UTC by Avesh Agarwal
Modified: 2012-08-08 18:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-09 14:17:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Avesh Agarwal 2011-02-18 14:18:36 UTC 
Description of problem:
We have observed an issue with ping (ICMP) traffic. When an ipsec policy specific to UDP protocol is added to kernel (in SPD) and ping traffic is initiated, kernel sends ACQUIRE messages with protocol 17. Due to this, wrong ipsec's security associations (SA) are being established.

I have tested and found this issue on RHEL6.1 kernel (2.6.32-113.el6.x86_64), and also with ipsec-tools too on RHEL5.5/5.6 kernels too. 

However, we tested this on upstream kernel 2.6.36, and this issue is not found.

Version-Release number of selected component (if applicable):
2.6.32-113.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Add an ipsec policy specific to UDP protocol
2. Start ping traffic to the destination
3. Observe ACQUIRE messages in user space 
  
Actual results:
ACQUIRE mesgs with protocol UDP

Expected results:
ACQUIRE mesgs with protocol ICMP

Additional info:
Comment 3 Joy Latten 2011-02-22 18:07:19 UTC 
Before sending icmp-echo-request, ping gets the source address via opening a DGRAM socket and doing a connect(). This results in a __xfrm_lookup() in ip_route_output_flow(), which can trigger an ACQUIRE depending on ipsec policy.
However, ping opening this dgram socket, does not result in an outgoing pkt, 
just in it acquiring some info it needs to form and then send the 
icmp-echo-request pkt.
 
So, this is not a kernel problem, but rather a side effect of ping.
"ping -I <srcaddr> dstaddr" will give ping the src addr and it does
not have to open the dgram socket to get src addr info. And thus an
ACQUIRE won't be triggered.
Comment 4 Avesh Agarwal 2011-02-23 12:48:59 UTC 
> 
> However, we tested this on upstream kernel 2.6.36, and this issue is not found.
> 

Also found from discussion with Joy that the behaviour is same with upstream kernel, and the issue is found. However as Joy noted in comment 3 that this seems more likely related to behaviour of Ping command.
Comment 5 Avesh Agarwal 2011-02-23 14:57:09 UTC 
I would like to ask that even though it seems its a side effect of Ping command, is the kernel behaviour, of sending ACQUIRE for UDP policy when ping opens a dgram (UDP) socket, right? Because dgram (UDP) socket seems local to the machine and the UDP ipsec policy we have is for a outside box. So I am wondering why the kernel is matching this local dgram stuff with the ipsec policy specific to UDP?
Just curious? If we know that kernel is doing it right, then perhaps we can close this bz.
Comment 6 Joy Latten 2011-02-23 18:59:31 UTC 
Avesh,
I had thought about that too. 
It's the connect() that ping does after it opens the dgram socket that results in the ACQUIRE. It does something similar to, 
connect(socket_fd, dst, sizeof(dst))  
since we do the connect with the dst, the guy we want to ping... then 
we are planning on querying routes to see which route to use for our source
address using dst. The ip_route_output_flow, calls __xfrm_lookup() which results
in that ACQUIRE.  

here is what my dump looked like from upstream kernel...

km_query
xfrm_state_find
xfrm_resolve_and_create_bundle
xfrm_bundle_lookup
flow_cache_lookup
__xfrm_lookup
ip_route_output_flow
ip4_datagram_connect
inet_dgram_connect
sys_connect
Comment 7 Herbert Xu 2011-03-04 07:15:14 UTC 
So I think you guys have figured this out already :)

Ping does a connect to obtain routing information for the actual ICMP packets.  It does so using a UDP socket.  That's why you end up with a UDP ACQUIRE message.

IOW I don't think we have a bug here at all.
Note You need to log in before you can comment on or make changes to this bug.