Bug 497591 - ping incorrectly triggers ipsec acquire
ping incorrectly triggers ipsec acquire
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: iputils (Show other bugs)
5.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Jan Synacek
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-24 17:35 EDT by paul.moore
Modified: 2013-03-13 08:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-13 08:13:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description paul.moore 2009-04-24 17:35:02 EDT
I have ipsec SPD entries that say

spdadd 0.0.0.0/0  192.168.218.129 icmp -P in priority 34603265 none;
spdadd 192.168.218.129  0.0.0.0/0 icmp -P out priority 34603264 none;
spdadd 0.0.0.0/0  192.168.218.129 any -P in priority 34603009 ipsec esp/transport//unique:1 ;
spdadd 192.168.218.129  0.0.0.0/0 any -P out priority 34603008 ipsec esp/transport//unique:2 ;


ie all traffic except icmp needs to be encrypted (a common configuration)

I then do ping 192.168.218.128

this results in an acquire from the kernel and an attempt to establish an ipsec SA to the remote machine - this is clearly unexpected behavior. If the ipsec SA cannot be established the then ping will fail - note we are talking transport mode here

This happens becuase ping does a udp connect to the remote machine. And although that does not results in any network traffic it triggers the kernel to establish the ipsec SA for the packets that it assumes it will be asked to send

I can avoid this by doing ping -I 192.168.218.129 192.168.218.128 but most users will not know to do this and will be using the ping as a diagnostic aid (hence the exception rule for icmp). They will get very confused if the ping fails due to ipsec failure. I know I was
Comment 1 Herbert Xu 2009-05-14 20:42:02 EDT
Try reversing the priorities.
Comment 2 paul.moore 2009-05-14 20:47:16 EDT
that would give me exactly the behaviour I dont want. ICMP traffic would be forced to use esp because that rule would match first

the rules are correct. The problem is that ping goes

UDP bind to remote
then ICMP

the -i option supresses the UDP bind - which is why it works
Comment 3 Herbert Xu 2009-05-14 21:18:57 EDT
First of all your priorities are definitely the wrong way around, try it please because I did.  We always use the policy with the lowest numerical priority value.  In any case, I failed to reproduce your problem with the upstream kernel, but it does happen in RHEL5.  So I'll try to find out what's broken it in RHEL5.
Comment 4 paul.moore 2009-05-14 21:22:22 EDT
setkey inverts the priorities

as i said - the problem is that ping does a UDP bind first

I suspect that you fixed the kernel so that a UDP bind doesnt cause a flow setup until a packet is actually sent. On rhel5 the UDP bind triggers an acquire even though no packets are ever sent
Comment 5 paul.moore 2009-05-14 21:30:35 EDT
here is the inversion

spdadd 192.168.218.0/24  192.168.218.0/24 any -P out priority 2 ipsec esp/transport//unique:1 
spdadd 192.168.218.0/24  192.168.218.0/24 any -P in priority 1 ipsec esp/transport//unique:2 

xfrm output

src 192.168.218.0/24 dst 192.168.218.0/24 
        dir in priority 2147483647 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 2 mode transport
src 192.168.218.0/24 dst 192.168.218.0/24 
        dir out priority 2147483646 
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 1 mode transport

pri 1 rule gets xfrm pri = 2147483647 
pri 2 rule gets xfrm pri = 2147483646
Comment 6 Herbert Xu 2009-06-09 23:38:55 EDT
I see why it works upstream.  It's because we added non-blocking IPsec route lookups so it just blows through.

Anyway, this really is a bug in ping.  Because the ideal state for the IPsec route lookup is for it to block, just like ARP.  If ping is going to use connect to do route lookups, it should specify the right protocol (which may be possible through RAW).  Alternatively it should just use netlink to get the information that it needs.

So we should reassign this away from the kernel because it's not doing anything wrong.
Comment 8 RHEL Product and Program Management 2010-08-09 14:24:36 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 9 RHEL Product and Program Management 2011-01-11 15:33:53 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 10 RHEL Product and Program Management 2011-01-11 17:39:18 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 11 RHEL Product and Program Management 2011-05-31 09:26:26 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 12 Jan Synacek 2013-03-13 08:13:42 EDT
Red Hat Enterprise Linux 5 has entered Production 2 phase. For more details see https://access.redhat.com/support/policy/updates/errata/. As this bug is not qualified as critical, it is closed as WONTFIX.

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