On 01/28/2016 10:53 AM, Numan Siddique wrote: > On 01/28/2016 01:40 PM, 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. > > 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.
You don't need any IPv6 specific flows here, right? It's just that port security is now more specific and is only matching IPv4 packets in this example, so IPv6 is not allowed as a side effect. More work would indeed be required to support restricting IPv6 beyond just "MAC", which would allow any traffic with a given source MAC address. (I also CC'd Justin, who has been working on IPv6 support) -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
