[ovs-discuss] OVN - Opaque metadata on logical switch ports to simplify network policies

[Mark Michelson]

On 4/2/20 7:30 AM, Dumitru Ceara wrote:
> Hi all,
> 
> I'd like to bring up to discussion the following feature request that
> would make the life of some CMSs easier when implementing network
> policies with OVN ACLs.
> 
> If OVN would allow a CMS to attach an opaque metadata value to logical
> switch ports (e.g., a 32-bit integer) and also support defining ACLs
> that match on a specific value of that opaque metadata then the
> following type of policies would result in less openflow entries and
> would also be easier to configure.
> 
> Let's assume the logical topology:
> 
> Logical_Switch LS1 --- Logical_Router LR --- Logical_Switch LS2
>     |         |                                  |         |
>     |         |                                  |         |
>    VM1.1     VM1.2                              VM2.1     VM2.2
> 
> And a default, drop-all-traffic, policy:
> 
> PortGroup:
> - name: "pg_drop_all"
> - ports: VM1.1, VM1.2, VM2.1, VM2.2
> 
> ACL:
> - priority: 1000
> - direction: to-lport
> - match: "outport == @pg_drop_all && ipv4"
> - action: "drop"
> - applied on PortGroup "pg_drop_all".
> 
> With the current OVN implementation, if we want to allow traffic between
> VM1.1 and VM2.1, for example, for TCP port 80 we have to add something like:
> 
> PortGroup:
> - name: "pg_allow"
> - ports: VM1.1, VM2.1
> 
> AddressSet:
> - name: "as_allow"
> - IPs: IP-VM1.1, IP-VM2.1
> 
> ACL:
> - priority: 2000
> - direction: to-lport
> - match: "ipv4.src == @as_allow && outport == @pg_allow && tcp.dest == 80"
> - action: "allow"/"allow-related"
> - applied on PortGroup "pg_allow"
> 
> Assuming that we could attach some opaque metadata to traffic received
> on specific logical switch ports, e.g. value 42:
> 
> ovn-nbctl set-lsp-metadata VM1.1 42
> ovn-nbctl set-lsp-metadata VM2.1 42
> 
> The configuration required to enforce the same type of allow network
> policy would change to:
> 
> ACL:
> - priority: 2000
> - direction: to-lport
> - match "lsp-metadata == 42 && outport == @pg_allow && tcp.dest == 80"
> - action: "allow"/"allow-related"
> - applied on PortGroup "pg_allow"
> 
> This would generate 50% less openflow entries because we don't need to
> validate that traffic comes from IPs in AddressSet "as_allow" as that's
> implicitly done by matching on the "lsp-metadata" value.
> 
>  From an implementation perspective as far as I see we'd need to:
> - in openflow table 0: store the lsp-metadata value in an unused 32 bit
> register (e.g., REG7). This is either passed through tunnel header
> fields or read from the port_binding associated with the ingress logical
> switch port.
> - in openflow table 34: when moving the packet to the egress pipeline,
> skip clearing the register used to store lsp-metadata (e.g., REG7)
> - in openflow table 32: when packets need to be tunneled to a remote
> hypervisor, put_encapsulation() should also encode the lsp-metadata.
> 
> Do you think there would be any major problems with such an approach?
> 
> Thanks,
> Dumitru

Hi Dumitru,

The proposal is essentially a way of expressing a port group as a 
user-defined "hash". Instead of having to check for set membership of a 
port in this port group, the user can express an integer that represents 
the group instead. A single integer check is more efficient than having 
to generate multiple flows to check for set membership.

The first thing that came to mind here is that we probably need to 
consider both the source lsp metadata and the destination lsp metadata. 
In the proposal, the source lsp metadata is all that is considered, but 
the destination lsp metadata could be just as important. This would mean 
needing two registers to store the values instead of one, and 
potentially encapulsating two values instead of one.

There are other thoughts I have about this, but I think it muddies the 
scope of what you've proposed. For instance, could there be a way to set 
multiple metadata values on a switch port and choose which to use for a 
particular packet based on certain criteria? Could this metadata concept 
be used internally as a method of implementing port group matches?

Mark Michelson