On 2/11/26 10:37 AM, Ales Musil wrote: > The RFC defines a Virtual Router Redundancy Protocol [0], in order > for that protocol to work the workload might "spoof" MAC address > within ARP or ND request/response. This wasn't allowed as the port > security is specifically designed against spoofing and checks if > the port security MAC address is the same for source of ARP/ND > and the inner source/target address. To make the port security > compliant add a special literal which when specified will allow > user to add any/all MAC addresses defined by VRRPv3. The traffic > from and to those additional MAC addresses will be allowed as > well as permutations of ARP/ND inner MACs combined with the > physical MAC as a source. > > [0] https://datatracker.ietf.org/doc/html/rfc9568 > Reported-at: https://issues.redhat.com/browse/FDP-2979 > Signed-off-by: Ales Musil <[email protected]> > --- > v4: Rebase on top of latest main. > Update the RFC url. > Add Jacob's ack. > v5: Rebase on top of latest main. > Address nits pointed out by Dumitru. > Add extra test for invalid VRRPv3 MAC. > Update the wording in documentation. > Remove acks as the code changed. > Do not populate flows for physical MAC when VRRP is specified. > v6: Rebase on top of latest main. > Update the documentation formatting. > Update the behavior when masked portion of MAC is non-zero. > Address some nits. > Update testing. > Remove all acks as the patch has changed. > v7: Update the tests. > Update the documentation according to Ilya's suggestion. > v8: Rebase on top of latest main. > Address nits. > Adjust the test. > ---
Hi Ales, [...] > diff --git a/ovn-nb.xml b/ovn-nb.xml > index aab091883..85ac7b61b 100644 > --- a/ovn-nb.xml > +++ b/ovn-nb.xml > @@ -2057,6 +2057,23 @@ > addresses within an element may be space or comma separated. > </p> > > + <p> > + Each element in the set also supports the special prefix "VRRPv3" > + that allows specification of single physical MAC and multiple > + VRRPv3 MAC addresses. As for non VRRPv3 entries, multiple IP > + addresses can be associated with the specified MACs. "VRRPv3" with > + a single physical MAC translates to allowing traffic for the whole > + "VRRPv3" range of MACs. See more in the examples. > + > + When the port security configuration entry contains the VRRPv3 > label, > + the behavior for physical MAC (the first specified) is different. > + The installed flows will allow traffic from/to VRRP MACs + IPs. > + The physical MAC is there to properly allow ARP/ND with given > + VRRP MACs. To allow traffic that is not related to virtual router, > + e.g., IP traffic with a physical MAC as a source, a regular port > + security entry should be added separately. > + </p> > + > <p> > This column is provided as a convenience to cloud management > systems, > but all of the features that it implements can be implemented as > ACLs > @@ -2102,6 +2119,44 @@ > 255.255.255.255, and any address in 224.0.0.0/4. The host may > not > send or receive any IPv6 (including IPv6 Neighbor Discovery) > traffic. > </dd> > + > + <dt><code>"VRRPv3 <PHYSICAL_MAC>"</code></dt> > + <dd> > + The host may send ARP/ND packets with physical MAC as a source > and > + any of the VRRPv3 MACs as inner SHA/TLL/SLL - > 00:00:5e:00:01:00/40 > + for IPv4 and 00:00:5E:00:02:00/40 for IPv6. It may also send or Nit: we're a bit inconsistent here, either both addresses should be "00:00:5E..." or "00:00:5e". Probably the latter. With this addressed and with Ilya's comments addressed I think we're finally good: Acked-by: Dumitru Ceara <[email protected]> > + receive any traffic with any of VRRPv3 MAC addresses as a source > + or destination. But not with the physical MAC address. > + </dd> > + > + <dt><code>"VRRPv3 <PHYSICAL_MAC></code> > + <code><VRRPV3_MACv4_1>/[<MASK1>]</code> > + <code><VRRPV3_MACv4_N></code> > + <code><VRRPV3_MACv6_1>/[<MASK2>]</code> > + <code><VRRPV3_MACv6_N>"</code></dt> > + <dd> > + Same as the previous example, but allowed VRRPv3 MAC addresses > are > + limited to the specified ones. The specified VRRPv3 MAC > addresses > + must have a correct prefix - 00:00:5e:00:01 for IPv4 and > + 00:00:5e:00:02 for IPv6. VRRPv3 MACs can be provided with a mask > + with a prefix between /40 and /48. > + </dd> > + > + <dt><code>"VRRPv3 <PHYSICAL_MAC></code> > + <code><VRRPV3_MACv4_1>/[<MASK1>]</code> > + <code><VRRPV3_MACv4_N></code> > + <code><VRRPV3_MACv6_1>/[<MASK2>]</code> > + <code><VRRPV3_MACv6_N></code> > + <code><VRRPV3_IPv4_1>/[<MASK1>]</code> > + <code><VRRPV3_IPv4_N></code> > + <code><VRRPV3_IPv6_1>/[<MASK2>]</code> > + <code><VRRPV3_IPv6_N>"</code></dt> > + <dd> > + The same as the previous example, but the provided IP addresses > + further restrict the inner IP for ARP/ND. As well as IP/IPv6 > + traffic to/from given VRRPv3 MACs. The IP address format is the > + same as for the regular port security entry. > + </dd> > </dl> > </column> > </group> Thanks, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
