On 01/28/2016 08:04 PM, Russell Bryant wrote: > 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. >
Thanks Russel for the comments. Yes, I assumed #2. I will update the documentation. Is your suggestion (#2) for both port security and addresses or just for port security ? Numan. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev