[ovs-dev] [PATCH 1/3] ovn: Add port_security proposal
Numan Siddique
nusiddiq at redhat.com
Thu Jan 28 15:11:33 UTC 2016
On 01/28/2016 08:04 PM, Russell Bryant wrote:
> On 01/28/2016 03:10 AM, Numan Siddique wrote:
>> From: Ben Pfaff <blp at nicira.com>
>>
>> Signed-off-by: Numan Siddique <nusiddiq at 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.
More information about the dev
mailing list