On 01/28/2016 09:33 PM, Russell Bryant wrote: > 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. Sorry, I forgot to give a proper context. My question is for this case (where ipv6 address is given)
<<snip>> 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. <</snip>> >>> + </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. You are right. My bad. Please see above. > 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) > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
