9. Security Considerations

VRRP for IPvX does not currently include any type of authentication.
Earlier versions of the VRRP (for IPv4) specification included
several types of authentication ranging from none to strong.
Operational experience and further analysis determined that these did
not provide sufficient security to overcome the vulnerability of
misconfigured secrets, causing multiple Masters to be elected. Due
to the nature of the VRRP protocol, even if VRRP messages are
cryptographically protected, it does not prevent hostile nodes from
behaving as if they are a VRRP Master, creating multiple Masters.
Authentication of VRRP messages could have prevented a hostile node
from causing all properly functioning routers from going into Backup
state. However, having multiple Masters can cause as much disruption
as no routers, which authentication cannot prevent. Also, even if a
hostile node could not disrupt VRRP, it can disrupt ARP and create
the same effect as having all routers go into Backup.

Some L2 switches provide the capability to filter out, for example,
ARP and/or ND messages from end-hosts on a switch-port basis. This
mechanism could also filter VRRP messages from switch ports
associated with end-hosts and can be considered for deployments with
untrusted hosts.

It should be noted that these attacks are not worse and are a subset
of the attacks that any node attached to a LAN can do independently
of VRRP. The kind of attacks a malicious node on a LAN can do
include promiscuously receiving packets for any router's MAC address;
sending packets with the router's MAC address as the source MAC
address in the L2 header to tell the L2 switches to send packets
addressed to the router to the malicious node instead of the router;
send redirects to tell the hosts to send their traffic somewhere
else; send unsolicited ND replies; answer ND requests; etc. All of
this can be done independently of implementing VRRP. VRRP does not
add to these vulnerabilities.

Independent of any authentication type, VRRP includes a mechanism
(setting TTL = 255, checking on receipt) that protects against VRRP
packets being injected from another remote network. This limits most
vulnerabilities to local attacks.

VRRP does not provide any confidentiality. Confidentiality is not
necessary for the correct operation of VRRP, and there is no
information in the VRRP messages that must be kept secret from other
nodes on the LAN.

In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND)
is deployed, VRRP is compatible with the "trust anchor" and "trust
anchor or cga" modes of SEND [RFC3971]. The SEND configuration needs
to give the Master and Backup routers the same prefix delegation in
the certificates so that Master and Backup routers advertise the same
set of subnet prefixes. However, the Master and Backup routers
should have their own key pairs to avoid private key sharing.

The idea with the bridge sounds weird, have you ever seen that live?

Ok but filtering ND and vrrp on the customer ports denies my customers the change to run vrrp on their own.

Bit of a long shot....
Bridge your "crossover" link with your LAN uplink on each router. This is the long shot bit...can you apply a filter to just the LAN uplink that would block VRRP on that interface?