From 077328f988915f279e55bea8ac6222f7ec2bd7b0 Mon Sep 17 00:00:00 2001 From: Ihar Hrachyshka Date: Fri, 29 Oct 2021 16:09:51 -0400 Subject: [PATCH] Allowed Address Pair: support matching ANY MAC address Related-Bug: #1946251 Change-Id: I553ac57fc1e0325236282a6d218b0726a6693633 --- ...wed-address-pair-match-any-mac-address.rst | 93 +++++++++++++++++++ specs/yoga/placeholder.rst | 82 ---------------- 2 files changed, 93 insertions(+), 82 deletions(-) create mode 100644 specs/yoga/allowed-address-pair-match-any-mac-address.rst delete mode 100644 specs/yoga/placeholder.rst diff --git a/specs/yoga/allowed-address-pair-match-any-mac-address.rst b/specs/yoga/allowed-address-pair-match-any-mac-address.rst new file mode 100644 index 000000000..b2159d614 --- /dev/null +++ b/specs/yoga/allowed-address-pair-match-any-mac-address.rst @@ -0,0 +1,93 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +====================================================== +Allowed Address Pair: support matching ANY MAC address +====================================================== + +Include the URL of your launchpad RFE: + +https://bugs.launchpad.net/neutron/+bug/1946251 + +Allowed address pairs API allows to match against a subset of IP addresses, or +even all of them, by virtue of netmasks being part of 'ip_address' field +format. For example, using '0.0.0.0/0' means allowing any IP address used with +the corresponding MAC address. This proposal suggests extending the API so that +a user can allow any MAC address used with the corresponding IP address. + + +Problem Description +=================== + +An end user would like to configure their topology so that a port enforces +security group rules but allows any MAC addresses. To achieve this, the user: + +#. creates a security group with appropriate rules; +#. creates a port and assigns it to the security group; +#. adds allowed address pair for ANY MAC address and some IP address(es). + +Right now, the only way to disable MAC address enforcement is to set +port_security_enabled attribute to false. But this attribute also disables +security group rule enforcement. In this scenario, only anti-spoofing +enforcement should be disabled. + + +Proposed Change +=============== + +The proposal is to extend 'allowed_address_pairs' attribute for ports so that +its 'mac_address' field accepts a special value "ANY" that would disable MAC +anti-spoofing mechanism. IP address enforcement may still continue, based on +the corresponding 'ip_address' field value of the pair. + +Having multiple address pairs with "ANY" 'mac_address' field value is +supported. Having a list of pairs where some but not all 'mac_address' field +values are "ANY" is supported. + +A new Networking API extension will be introduced to indicate support for the +new special value. This support is backend specific, which means that ML2 may +need to offload decision to enable the extension to underlying drivers. + +Database model for allowed address pairs will not need adjustment to accept the +new special value because it already accepts all strings. + +Client library may need to be adjusted to support the new special value "ANY" +for the 'mac_address' field in the API validator module. + +For agent-based setups, there are two cases to handle where the firewall driver +chosen implements anti-spoofing / allowed_address_pair handling itself, and +where this task is left to the agent. The firewall driver indicates the former +by setting provides_arp_spoofing_protection attribute to True. In this +scenario, the driver will have to implement handling of the new "ANY" value set +for a MAC-IP pair. A new firewall driver flag (support_any_mac_anti_spoofing) +will be added to indicate support for the new feature, defaults to False. If +the flag is not set, the agent will filter out ANY address pairs before passing +them to the firewall driver. It will also log a warning about the issue. Each +driver that handles anti-spoofing itself will need to opt in receiving "ANY" +address pairs by setting the support_any_mac_anti_spoofing flag to True. + + +Alternatives +~~~~~~~~~~~~ + +Instead of using a new special value "ANY", we could introduce a masking scheme +for 'mac_address' field. For example, "de:ad:/32" would indicate "any MAC +address that starts with de:ad: prefix". But it's debatable whether using any +mask but /0 is generally useful, since MAC addresses are opaque values with no +inherent ordering or grouping (that said, traditionally vendors reuse the same +prefixes for their devices). + +Instead of reusing the existing allowed address pairs API attribute, we could +introduce a new port level attribute that would disable MAC address +anti-spoofing without disabling security group rules. Since SG API still allows +to match against particular IP addresses, this approach would be functionally +identical to this. That said, I think it's generally better to avoid +introducing new attributes to base resources, and it's better to keep +anti-spoofing related functionality under the same attribute. + + +References +========== diff --git a/specs/yoga/placeholder.rst b/specs/yoga/placeholder.rst deleted file mode 100644 index c5e39d9d6..000000000 --- a/specs/yoga/placeholder.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -==================================== -Example Spec - The title of your RFE -==================================== - -Include the URL of your launchpad RFE: - -https://bugs.launchpad.net/neutron/+bug/example-id - -Introduction paragraph -- why are we doing this feature? A single paragraph of -prose that **deployers, and developers, and operators** can understand. - -Do you even need to file a spec? Most features can be done by filing an RFE bug -and moving on with life. In most cases, filing an RFE and documenting your -design in the devref folder of neutron docs is sufficient. If the feature -seems very large or contentious, then the drivers team may request a spec, or -you can always file one if desired. - - -Problem Description -=================== - -A detailed description of the problem: - -* For a new feature this should be a list of use cases. Ensure that you are clear - about the actors in each use case: End User vs Deployer. Ensure that you identify - which area of the core is being affected; for something completely new, it - should be clear why you are considering it being part of the core. - -* For a major reworking of something existing it would describe the - problems in that feature that are being addressed. - -Note that the RFE filed for this feature will have a description already. This -section is not meant to simply duplicate that; you can simply refer to that -description if it is sufficient, and use this space to capture changes to -the description based on bug comments or feedback on the spec. - - -Proposed Change -=============== - -How do you propose to solve this problem? - -This section is optional, and provides an area to discuss your high-level -design at the same time as use cases, if desired. Note that by high-level, -we mean the "view from orbit" rough cut at how things will happen. - -This section should 'scope' the effort from a feature standpoint: how is the -'neutron end-to-end system' going to look like after this change? What Neutron -areas do you intend to touch and how do you intend to work on them? The list -below is not meant to be a template to fill in, but rather a jumpstart on the -sorts of areas to consider in your proposed change description. - -* Am I going to see new CLI commands? - * Is OpenStack CLI covered in addition to neutronclient? -* How do you intend to support or affect aspects like: - * Address Management, e.g. IPv6, DHCP - * Routing, e.g. DVR/HA - * Plugins, ML2 Drivers, e.g. OVS, LinuxBridge - * Agents, e.g. metadata - * High level services, e.g. \*-aas. - * Scheduling, quota, and policy management, e.g. admin vs user rights - * API and extensions - * Clients - * Impact on services or out-of-tree plugins/drivers -* What do you intend to not support in the initial release? - -You do not need to detail API or data model changes. Details at that level of -granularity belong in the neutron devref docs. - - -References -========== - -Please add any useful references here. You are not required to have any -reference. Moreover, this specification should still make sense when your -references are unavailable.