From patchwork Mon Nov 27 22:28:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Justin Pettit X-Patchwork-Id: 841882 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3ym1hF3RkFz9s74 for ; Tue, 28 Nov 2017 09:30:05 +1100 (AEDT) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id A6675C19; Mon, 27 Nov 2017 22:29:34 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1ADF7BF0 for ; Mon, 27 Nov 2017 22:29:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B0FFF4 for ; Mon, 27 Nov 2017 22:29:32 +0000 (UTC) X-Originating-IP: 208.91.3.26 Received: from localhost.localdomain (unknown [208.91.3.26]) (Authenticated sender: jpettit@ovn.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id C71FAFB887 for ; Mon, 27 Nov 2017 23:29:30 +0100 (CET) From: Justin Pettit To: dev@openvswitch.org Date: Mon, 27 Nov 2017 14:28:38 -0800 Message-Id: <1511821718-98985-2-git-send-email-jpettit@ovn.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1511821718-98985-1-git-send-email-jpettit@ovn.org> References: <1511821718-98985-1-git-send-email-jpettit@ovn.org> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [ovs-dev] [PATCH 2/2] ovn/TODO: Remove some completed items. X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org Signed-off-by: Justin Pettit Acked-by: Ben Pfaff --- ovn/TODO.rst | 69 ------------------------------------------------------------ 1 file changed, 69 deletions(-) diff --git a/ovn/TODO.rst b/ovn/TODO.rst index f8569b357281..34615b9bc7d4 100644 --- a/ovn/TODO.rst +++ b/ovn/TODO.rst @@ -27,22 +27,9 @@ OVN To-do List * Work out database for clustering or HA properly. -* Compromised chassis mitigation. - - Possibly depends on database solution. - - Latest discussion: - - https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/321649.html - * Get incremental updates in ovn-controller and ovn-northd in some sensible way. -* Testing improvements, possibly heavily based on ovn-trace. - - Justin Pettit: "I'm planning to write some ovn-trace tests for IPv6. - Hopefully we can get those into 2.6." - * Self-managing HA for ovn-northd (avoiding the need to set up independent tooling for fail-over). @@ -61,11 +48,6 @@ OVN To-do List Russell Bryant: "Today that would require creating 4096 ports for the VM and attach to 4096 OVN networks, so doable, but not quite ideal." -* Native DNS support - - Russell Bryant: "This is an OpenStack requirement to fully eliminate the DHCP - agent." - * Service function chaining. * MAC learning. @@ -119,42 +101,6 @@ OVN To-do List * MTU handling (fragmentation on output) -* 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. - * ovsdb-server ovsdb-server should have adequate features for OVN but it probably needs work @@ -220,23 +166,8 @@ OVN To-do List We need to find a proper solution to solve this issue instead of increasing the inactivity_probe value. -* Consider the use of BFD as tunnel monitor. - - The use of BFD for hypervisor-to-hypervisor tunnels is probably not worth it, - since there's no alternative to switch to if a tunnel goes down. It could - make sense at a slow rate if someone does OVN monitoring system integration, - but not otherwise. - - When OVN gets to supporting HA for gateways (see ovn/OVN-GW-HA.rst), BFD is - likely needed as a part of that solution. - - There's more commentary in this ML post: - https://mail.openvswitch.org/pipermail/ovs-dev/2015-November/305928.html - * ACL * Support FTP ALGs. * Support reject action. - - * Support log option.