| Message ID | 56A9CD03.8040403@redhat.com |
|---|---|
| State | Not Applicable |
| Headers | show |
On 01/28/2016 03:10 AM, Numan Siddique wrote: > From: Ben Pfaff <blp@nicira.com> > > Signed-off-by: Numan Siddique <nusiddiq@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.
On 01/28/2016 08:04 PM, Russell Bryant wrote: > On 01/28/2016 03:10 AM, Numan Siddique wrote: >> From: Ben Pfaff <blp@nicira.com> >> >> Signed-off-by: Numan Siddique <nusiddiq@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.
On 01/28/2016 10:11 AM, Numan Siddique wrote: > On 01/28/2016 08:04 PM, Russell Bryant wrote: >> 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 ? I suggest that whatever we adopt here, we make 'addresses' consistent with it, so it would be for both. The change to 'addresses' can be done in another patch series, though.
On 01/28/2016 01:40 PM, Numan Siddique wrote: > From: Ben Pfaff <blp@nicira.com> > > Signed-off-by: Numan Siddique <nusiddiq@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. > + </dd> > + </dl> > + </column> > </group> > > <group title="Common Columns">
On 01/28/2016 10:53 AM, Numan Siddique wrote: > On 01/28/2016 01:40 PM, Numan Siddique wrote: >> From: Ben Pfaff <blp@nicira.com> >> >> Signed-off-by: Numan Siddique <nusiddiq@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)
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 <blp@nicira.com> >>> >>> Signed-off-by: Numan Siddique <nusiddiq@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) >
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">