The proxy protocol specification states:
The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access. Otherwise it would open a major security breach by
allowing untrusted parties to spoof their connection addresses. The receiver
SHOULD ensure proper access filtering so that only trusted proxies are allowed
to use this protocol.
Given that MariaDB already breaks this by allowing non-proxy protocol connections on the same port, the specification could be interpreted as only allowing proxied connections from the list of IPs in proxy_protocol_networks. However, the specification also states that the way MariaDB works is safe:
Implementers should be very careful about not trying to automatically detect
whether they have to decode the header or not, but rather they must only rely
on a configuration parameter. Indeed, if the opportunity is left to a normal
client to use the protocol, he will be able to hide his activities or make them
appear as coming from someone else. However, accepting the header only from a
number of known sources should be safe.
The specification suggests the following for proxies:
If the announced transport protocol is "UNKNOWN", then the receiver knows that
the sender speaks the correct PROXY protocol with the appropriate version, and
SHOULD accept the connection and use the real connection's parameters as if
there were no PROXY protocol header on the wire. However, senders SHOULD not
use the "UNKNOWN" protocol when they are the initiators of outgoing connections
because some receivers may reject them. When a load balancing proxy has to send
health checks to a server, it SHOULD build a valid PROXY line which it will
fill with a getsockname()/getpeername() pair indicating the addresses used. It
is important to understand that doing so is not appropriate when some source
address translation is performed between the sender and the receiver.
Currently MaxScale relies on MariaDB allowing non-proxy protocol connections to be created from the same address that proxy procol connections are made. To more closely follow the recommendations of the specification, MaxScale should use the (currently undocumented) MARIADB_OPT_PROXY_HEADER option to send a proxy protocol header for the internal connections.