On 01/28/2016 03:10 AM, Numan Siddique wrote: > From: Ben Pfaff <b...@nicira.com> > > Signed-off-by: Numan Siddique <nusid...@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. > + </dd> > + </dl> > + </column> > </group> > > <group title="Common Columns"> >
You raised another thread about the proposed syntax here: http://openvswitch.org/pipermail/dev/2016-January/064921.html Let's make sure we agree on that before proceeding. In that thread, Han suggested: > I would suggest to have the format ["MAC1 IP1-1 IP1-2 IP1-3 ...", "MAC2 > IP2-1 IP2-2 ...", ...] for both "port_security" and "addresses" columns. That mostly follows this proposal and means another patch is needed to change 'addresses'. That's not exactly backwards compatible, but I don't think that's a problem. In this port_security documentation, it seems to suggest that this form is also allowed: 1) ["MAC1 MAC2 MAC3 IP1 IP2 IP3"] Is that intentional? or should we require this instead which seems to be what you and Han were discussing? 2) ["MAC1 IP1 IP2 IP3", "MAC2 IP1 IP2 IP3", "MAC3 IP1 IP2 IP3"] The other alternative is to adopt how the addresses column works today, and require: 3) ["MAC1 IP1", "MAC1 IP2", "MAC1 IP3", "MAC2 IP1", "MAC2 IP2", "MAC2 IP3", "MAC3 IP1", "MAC3 IP2", "MAC3 IP3"] The thing I care about most is consistency. I think option #1 is the least clear. Option #3 is nicely explicit, but more verbose. #2 seems like a compromise on clarity and verbosity. My suggestion would be to adopt #2 and update this documentation to reflect that. It seems that #2 is actually what you have implemented in this series. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
