[ovs-dev] [PATCH 1/3] ovn: Add port_security proposal

Numan Siddique nusiddiq at redhat.com
Thu Jan 28 15:53:33 UTC 2016


On 01/28/2016 01:40 PM, Numan Siddique wrote:
> From: Ben Pfaff <blp at nicira.com>
>
> Signed-off-by: Numan Siddique <nusiddiq at redhat.com>
> ---
>  ovn/ovn-nb.xml | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 118 insertions(+), 15 deletions(-)
>
> diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> index 4e414ce..e79a42d 100644
> --- a/ovn/ovn-nb.xml
> +++ b/ovn/ovn-nb.xml
> @@ -305,23 +305,126 @@
>        </column>
>  
>        <column name="port_security">
> -        <p>
> -          A set of L2 (Ethernet) addresses from which the logical port is
> -          allowed to send packets and to which it is allowed to receive
> -          packets.  If this column is empty, all addresses are permitted.
> -          Logical ports are always allowed to receive packets addressed to
> -          multicast and broadcast addresses.
> -        </p>
> +      <p>
> +        This column controls the addresses from which the host attached to the
> +        logical port (``the host'') is allowed to send packets and to which it
> +        is allowed to receive packets.  If this column is empty, all addresses
> +        are permitted.
> +      </p>
>  
> -        <p>
> -          Each member of the set is an Ethernet address in the form
> -          <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
> -        </p>
> +      <p>
> +        Each element in the set must contain one or more Ethernet addresses,
> +        optionally masked.  An element that contains only Ethernet addresses
> +        restricts the host to sending packets from and receiving packets to
> +        those addresses.  It also restricts the inner source MAC addresses that
> +        the host may send in ARP and IPv6 Neighbor Discovery packets.  It does
> +        not restrict the logical port to any particular L3 addresses.  The host
> +        is always allowed to receive packets to multicast and broadcast
> +        Ethernet addresses.
> +      </p>
>  
> -        <p>
> -          This specification will be extended to support L3 port security.
> -        </p>
> -      </column>
> +      <p>
> +        Each element in the set may additionally contain one or more IPv4 or
> +        IPv6 addresses (or both), with optional masks.  If a mask is given, it
> +        must be a CIDR mask.  In addition to the restrictions described for
> +        Ethernet addresses above, such an element restricts the IPv4 or IPv6
> +        addresses from the host may send and to which it may receive to packets
> +        to the specified addresses.  A masked address, if the host part is
> +        zero, indicates that the host is allowed to use any addresses in the
> +        subnet; if the host part is nonzero, the mask simply indicates the size
> +        of the subnet.  In addition:
> +      </p>
> +
> +      <ul>
> +        <li>
> +          <p>
> +            If any IPv4 address is given, the host is also allowed to receive
> +            packets to the IPv4 local broadcast address 255.255.255.255 and to
> +            IPv4 multicast addresses (224.0.0.0/4).  If an IPv4 address with a
> +            mask is given, the host is also allowed to receive packets to the
> +            broadcast address in that specified subnet.
> +          </p>
> +
> +          <p>
> +            If any IPv4 address is given, the host is additionally restricted
> +            to sending ARP packets with the specified source IPv4 address.
> +            (RARP is not restricted.)
> +          </p>
> +        </li>
> +
> +        <li>
> +          <p>
> +            If any IPv6 address is given, the host is also allowed to receive
> +            packets to IPv6 multicast addresses (ff00::/8).
> +          </p>
> +
> +          <p>
> +            If any IPv6 address is given, the host is additionally restricted
> +            to sending IPv6 Neighbor Discovery Solicitation or Advertisement
> +            packets with the specified source address or, for solicitations,
> +            the unspecified address.
> +          </p>
> +        </li>
> +      </ul>
> +
> +      <p>
> +        If an element includes an IPv4 address, but no IPv6 addresses, then
> +        IPv6 traffic is not allowed.  If an element includes an IPv6 address,
> +        but no IPv4 address, then IPv4 and ARP traffic is not allowed.
> +      </p>
> +
> +      <p>
> +        Multiple elements act as a disjunction.  That is, when multiple
> +        elements exist, any packet that would be permitted by any individual
> +        element, as described above, is permitted by the overall policy.
> +      </p>
> +
> +      <p>
> +        This column uses the same lexical syntax as the <ref column="match"
> +        table="Pipeline" db="OVN_Southbound"/> column in the OVN Southbound
> +        database's <ref table="Pipeline" db="OVN_Southbound"/> table.  Multiple
> +        addresses within an element may be space or comma separated.
> +      </p>
> +
> +      <p>
> +        This column is provided as a convenience to cloud management systems,
> +        but all of the features that it implements can be implemented as ACLs
> +        using the <ref table="ACL"/> table.
> +      </p>
> +
> +      <p>
> +        Examples:
> +      </p>
> +
> +      <dl>
> +        <dt><code>80:fa:5b:06:72:b7</code></dt>
> +        <dd>
> +          The host may send traffic from and receive traffic to the specified
> +          MAC address, and to receive traffic to Ethernet multicast and
> +          broadcast addresses, but not otherwise.  The host may not send ARP or
> +          IPv6 Neighbor Discovery packets with inner source Ethernet addresses
> +          other than the one specified.
> +        </dd>
> +
> +        <dt><code>00:23:20:00:00:00/ff:ff:ff:00:00:00</code></dt>
> +        <dd>
> +          Similar to the first example, except that any Ethernet address in the
> +          Nicira OUI is allowed.
> +        </dd>
> +
> +        <dt><code>80:fa:5b:06:72:b7 192.168.1.10/24</code></dt>
> +        <dd>
> +          This adds further restrictions to the first example.  The host may
> +          send IPv4 packets from or receive IPv4 packets to only 192.168.1.10,
> +          except that it may also receive IPv4 packets to 192.168.1.255 (based
> +          on the subnet mask), 255.255.255.255, and any address n 224.0.0.0/4.
> +          The host may not send ARPs with a source Ethernet address other than
> +          80:fa:5b:06:72:b7 or source IPv4 address other than 192.168.1.10.
> +          The host may not send or receive any IPv6 (including IPv6 Neighbor
> +          Discovery) traffic.

I would like to know if it is really required to restrict Neighbor discovery traffic for IPv6.
A vm might send ipv6 ND packets with its
  - configured ipv6 address(es) or
  - its link local address or
  - with zero source address and ff02 multicast destination address,
This would result in lot of openflow flows just to restrict ND traffic.

I am an amateur in IPv6, so please correct me if I am wrong.


> +        </dd>
> +      </dl>
> +    </column>
>      </group>
>  
>      <group title="Common Columns">




More information about the dev mailing list