[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec-tools-devel
Subject:    Re: [Ipsec-tools-devel] ERROR: pfkey DELETE received
From:       Rainer Weikusat <rweikusat () mobileactivedefense ! com>
Date:       2016-05-23 14:35:39
Message-ID: 87h9doon9g.fsf () doppelsaurus ! mobileactivedefense ! com
[Download RAW message or body]

"Eugene M. Zheganin" <emz@norma.perm.ru> writes:
>
> On 23.10.2015 20:38, Rainer Weikusat wrote:
>> "Eugene M. Zheganin" <emz@norma.perm.ru> writes:
>>
>>> Hi.
>>>
>>> I'm seeing the message "ERROR: pfkey DELETE received" quite periodically
>>> in logs. However, it does not seem it to cause any problems. What does
>>> this mean ?
>> It means racoon has received a PF_KEY SADB_DELETE message whose process
>> ID differed from its own, ie, one which was apparently not sent by
>> itself.
>>
> Sorry for this grave digging, but I'm forced to reinvestigate this 
> issue. Given that I have in the logs a record like
>
> May  1 19:00:02 balancer1 racoon: ERROR: pfkey DELETE received: ESP 
> XXX.XX.XXX.XX[500]->ZZZ.ZZ.ZZZ.ZZ[500] spi=831488614(0x318f8266)
>
> - what can it mean ? XXX.XX.XXX.XX is a local IP of the server that 
> logged this message. I think the '->' represents the direction, but if 
> some message is "received" why the direction is outgoing ?

That's logged by this code (in pfkey.c/ pk_recvdelete)

        iph2 = getph2bysaidx(src, dst, proto_id, sa->sadb_sa_spi);
        if (iph2 == NULL) {
                /* ignore */
                plog(LLV_ERROR, LOCATION, NULL,
                        "no iph2 found: %s\n",
                        sadbsecas2str(src, dst, msg->sadb_msg_satype,
                                sa->sadb_sa_spi, IPSEC_MODE_ANY));
                return 0;
        }

        plog(LLV_ERROR, LOCATION, NULL,
                "pfkey DELETE received: %s\n",
                sadbsecas2str(src, dst,
                        msg->sadb_msg_satype, sa->sadb_sa_spi, IPSEC_MODE_ANY));

The addresses represent source and destination address of the ph2 SA the
delete message referred to and the spi= is it's spi. The message is
'received' because it's a PF_KEY message (local IPsec configuration
management protocol message sent by the kernel). More to the top of this
function, you'll find the following code:


        /* the message has to be processed or not ? */
        if (msg->sadb_msg_pid == getpid()) {
                plog(LLV_DEBUG, LOCATION, NULL,
                        "%s message is not interesting "
                        "because the message was originated by me.\n",
                        s_pfkey_type(msg->sadb_msg_type));
                return -1;
        }

Communication generally works as follows:

	1. Something sends a PF_KEY delete message to the kernel. This
 	   instructs the kernel to delete the SAs specified in the
 	   message. That something is supposed to send its process ID as
 	   part of the message meta-information.

	2. The kernel resends the PF_KEY messages to all registered
	   PF_KEY listeners to inform them about the fact. A listener
	   can determine if the original message was sent by itself or
	   by some other entity by comparings its pid with the pid in
	   the received message (that's what the check above does).

You could change the LLV_ERROR message to include the received pid, eg,
to something like (untested)

        plog(LLV_ERROR, LOCATION, NULL,
                "pfkey DELETE received: %s (%u)\n",
                sadbsecas2str(src, dst,
                        msg->sadb_msg_satype, sa->sadb_sa_spi, IPSEC_MODE_ANY), msg->sadb_msg_pid);

This would give you the process ID of the entity which sent the message
which ought to be helpful for identifying the sender of the message.

A conceivable scenario (conjecture which doesn't contradict know facts):
A racoon process sends a delete and then crashes. It's restarted
automatically and the new process receives the delete.

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Ipsec-tools-devel mailing list
Ipsec-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
[prev in list] [next in list] [prev in thread] [next in thread]