@@ -189,21 +189,124 @@
<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
+ 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. Logical ports are always allowed to receive packets
- addressed to multicast and broadcast 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>.
+ 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.
+ 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 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.
+ </dd>
+ </dl>
</column>
<group title="Common Columns">
The "obvious" implementation of port security based on this proposal would be a single long match expression. For example, suppose that the port_security expression is "00:00:00:00:00:01 192.168.0.1". Then one might naturally write: eth.src == 00:00:00:00:00:01 && (!arp || (arp && arp.sha == 00:00:00:00:00:01 && arp.spa == 192.168.0.1)) && (!ip || (ip && ip.src == 192.168.0.1)), actions=next However this fails because 'arp' and 'ip' may not be negated, which is in turn because OVS does not allow bitwise matching on Ethertype. The following solutions have occurred to me: * Allow bitwise matching on Ethertype. I don't think this is a good idea. First, the OpenFlow Ethertype does not come directly from a wire protocol header, so bitwise matches don't necessarily make any sense. But even if we solve that, "eth.type != 0x800" (for example) requires 16 OpenFlow flows, each of which ends up in a different classifier subtable. Thus, this would be a very expensive solution, classification-wise. * Rewrite the single OVN flow as a series of OVN flows with different priorities, e.g.: priority=100, eth.src == 00:00:00:00:00:01 && arp && arp.sha == 00:00:00:00:00:01 && arp.spa == 192.168.0.1, actions=next priority=100, eth.src == 00:00:00:00:00:01 && ip && ip.src == 192.168.0.1, actions=next priority=90, eth.src == 00:00:00:00:00:01 && (ip || arp), actions=drop priority=80, eth.src == 00:00:00:00:00:01, actions=next This will obviously work but it might make it harder to write up all the expressions. * Add support to OVN for handling specific negated matches. For example, the first OpenFlow flow table could have flows that look something like this: ip, actions=load:1->NXM_NX_REG0[0], resubmit(,1) arp, actions=load:1->NXM_NX_REG0[1], resubmit(,1) and then later flow tables could implement !ip as a match on reg0[0] == 0 and !arp as a match on reg0[1] == 0. This has nice properties and the only question I have is whether it's worth the implementation work. Signed-off-by: Ben Pfaff <blp@nicira.com> --- This is unchanged from http://openvswitch.org/pipermail/dev/2015-July/057141.html except that it is provided as a source patch instead of formatted plaintext. ovn/ovn-nb.xml | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 110 insertions(+), 7 deletions(-)