kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process.

[Bruce M. Simpson]

Chris Buechler wrote:
>>
>> This PR is bogus because:
>> ICMP has no concept of datagrams being "owned" by a process. There is 
>> no field in the ICMP protocol which differentiates ICMP "sessions" on 
>> a per-process basis, and this is because ICMP has no concept of 
>> "sessions" -- ICMP messages are directed at IP endpoints.
>
> ICMP echo and echo replies do have "sessions" of sorts, at least 
> unique identifying fields - identifier and sequence number.

These fields do exist in ICMP, and as you point out, they are sometimes 
used to implement session-like behaviour.  Many NAT implementations use 
them in this way.

However there is no way of specifying them in a bind() call -- ICMP can 
only be received on a raw socket, and raw sockets will not filter these 
things on behalf of a user process, nor have they ever done to the best 
of my knowledge. They are not part of the address structures for a raw 
socket (SOCK_RAW, PF_INET, * or IPPROTO_ICMP).

>
> This was opened by a pfSense maintainer because it's a change in 
> behavior from 6.x releases where this was never an issue, and is 
> something we feel is a regression.

Robert has replied outlining a few situations where the behaviour might 
have changed.

Raw sockets do support binding laddr/faddr, there is the possibility 
this could have changed, however there is no notion of processes 
"owning" streams of ICMP messages, this has never been part of the ICMP 
protocol and to think in these terms is misleading.

It sounds to me as though the application is relying on a form of 
filtering which isn't happening, and the way to track this down is to 
carefully note what, if anything, changed in the expected behaviour 
between releases.

For example, does the application bind() to any given host addresses? 
This is the only form of filtering, apart from multicast SSM, that raw 
sockets would support, and SSM ain't in the tree [yet].

thanks
BMS