Allowed Address Pair: support matching ANY MAC address
Related-Bug: #1946251 Change-Id: I553ac57fc1e0325236282a6d218b0726a6693633
This commit is contained in:
Ihar Hrachyshka
parent
89c638cd71
commit
077328f988
|
|
@ -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
|
||||
==========
|
||||
|
|
@ -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.
|
||||
Loading…
Reference in New Issue