-* ovn-nbd
-
-** Monitor OVN_Northbound database, trigger Pipeline recomputation on change.
-
-** Translate each OVN_Northbound entity into Pipeline logical datapath flows.
-
- We have to first sit down and figure out what the general
- translation of each entity is. The original OVN architecture
- description at
- http://openvswitch.org/pipermail/dev/2015-January/050380.html had
- some sketches of these, but they need to be completed and
- elaborated.
-
- Initially, the simplest way to do this is probably to write
- straight C code to do a full translation of the entire
- OVN_Northbound database into the format for the Pipeline table in
- the OVN database. As scale increases, this will probably be too
- inefficient since a small change in OVN_Northbound requires a full
- recomputation. At that point, we probably want to adopt a more
- systematic approach, such as something akin to the "nlog" system
- used in NVP (see Koponen et al. "Network Virtualization in
- Multi-tenant Datacenters", NSDI 2014).
-
-** Push logical datapath flows to Pipeline table.
-
-** Monitor OVN database Bindings table.
-
- Sync rows in the OVN Bindings table to the "up" column in the
- OVN_Northbound database.
+** Security
+
+*** Limiting the impact of a compromised chassis.
+
+ Every instance of ovn-controller has the same full access to the central
+ OVN_Southbound database. This means that a compromised chassis can
+ interfere with the normal operation of the rest of the deployment. Some
+ specific examples include writing to the logical flow table to alter
+ traffic handling or updating the port binding table to claim ports that are
+ actually present on a different chassis. In practice, the compromised host
+ would be fighting against ovn-northd and other instances of ovn-controller
+ that would be trying to restore the correct state. The impact could include
+ at least temporarily redirecting traffic (so the compromised host could
+ receive traffic that it shouldn't) and potentially a more general denial of
+ service.
+
+ There are different potential improvements to this area. The first would be
+ to add some sort of ACL scheme to ovsdb-server. A proposal for this should
+ first include an ACL scheme for ovn-controller. An example policy would
+ be to make Logical_Flow read-only. Table-level control is needed, but is
+ not enough. For example, ovn-controller must be able to update the Chassis
+ and Encap tables, but should only be able to modify the rows associated with
+ that chassis and no others.
+
+ A more complex example is the Port_Binding table. Currently, ovn-controller
+ is the source of truth of where a port is located. There seems to be no
+ policy that can prevent malicious behavior of a compromised host with this
+ table.
+
+ An alternative scheme for port bindings would be to provide an optional mode
+ where an external entity controls port bindings and make them read-only to
+ ovn-controller. This is actually how OpenStack works today, for example.
+ The part of OpenStack that manages VMs (Nova) tells the networking component
+ (Neutron) where a port will be located, as opposed to the networking
+ component discovering it.