[ovs-dev] Allowed Address Pairs - OVN

[Gal Sagie]

Hello Everyone,

As you might know, allowed address pairs in neutron is an extension to
allow port
to have more then a pair of MAC-IP addresses assigned to it.
This is useful for cases of where few VM's need to share virtual MAC/IP,
like
for VRRP, Load balancing, NFV use cases and so on...
(Aaron who implemented it as far as i know can maybe elaborate)

Its not urgent but i believe that we can support this in Neutron OVN (at
least for L2)
By adding all the MAC addresses configured to a certain logical port.

However, when L3 is going to be introduced, we cant just also add all the
IP addresses, because security wise this means that a certain IP must be
assigned to a certain MAC address (please correct me if i am wrong here)

Just wanted to put this here, so when L3 design is finalized these
connections
are also taken care of in OVN for port security.

Please share any comments/thoughts.

Thanks
Gal.

[Russell Bryant]

Post by Gal Sagie
Hello Everyone,
As you might know, allowed address pairs in neutron is an extension to
allow port
to have more then a pair of MAC-IP addresses assigned to it.
This is useful for cases of where few VM's need to share virtual MAC/IP,
like
for VRRP, Load balancing, NFV use cases and so on...
(Aaron who implemented it as far as i know can maybe elaborate)
Its not urgent but i believe that we can support this in Neutron OVN (at
least for L2)
By adding all the MAC addresses configured to a certain logical port.

You cant set the same MAC address on more than one logical port. The
behavior is undefined. Packets will go to 1 of them, but it's undefined
which one.

It's fine to set the same MAC address in port_security for multiple
logical ports like we do now, but I'm not sure it's useful yet.

What's the expected behavior? Is it that a set of ports is allowed a
MAC address, but we should do MAC learning to figure out which one is
actively using it?

Post by Gal Sagie
However, when L3 is going to be introduced, we cant just also add all
the IP addresses, because security wise this means that a certain IP
must be assigned to a certain MAC address (please correct me if i am
wrong here)
Just wanted to put this here, so when L3 design is finalized these
connections
are also taken care of in OVN for port security.
Please share any comments/thoughts.
Thanks
Gal.

[Ben Pfaff]

Post by Russell Bryant

Post by Gal Sagie
Hello Everyone,
As you might know, allowed address pairs in neutron is an extension to
allow port
to have more then a pair of MAC-IP addresses assigned to it.
This is useful for cases of where few VM's need to share virtual MAC/IP,
like
for VRRP, Load balancing, NFV use cases and so on...
(Aaron who implemented it as far as i know can maybe elaborate)
Its not urgent but i believe that we can support this in Neutron OVN (at
least for L2)
By adding all the MAC addresses configured to a certain logical port.

You cant set the same MAC address on more than one logical port. The
behavior is undefined. Packets will go to 1 of them, but it's undefined
which one.

There's no reason we couldn't support having a given MAC address on
multiple logical ports, if it is useful. Is it?

[Ben Pfaff]

Post by Gal Sagie
As you might know, allowed address pairs in neutron is an extension to
allow port
to have more then a pair of MAC-IP addresses assigned to it.
This is useful for cases of where few VM's need to share virtual MAC/IP,
like
for VRRP, Load balancing, NFV use cases and so on...
(Aaron who implemented it as far as i know can maybe elaborate)
Its not urgent but i believe that we can support this in Neutron OVN (at
least for L2)
By adding all the MAC addresses configured to a certain logical port.
However, when L3 is going to be introduced, we cant just also add all the
IP addresses, because security wise this means that a certain IP must be
assigned to a certain MAC address (please correct me if i am wrong here)
Just wanted to put this here, so when L3 design is finalized these
connections
are also taken care of in OVN for port security.

Where's the spec for allowed address pairs? It's probably pretty easy
to implement in OVN.

(As an aside, I originally specified OVN port security to be more
general and to handle L2 and L3, but I didn't like what I'd specified
and so I dropped back to something simple and L2-only, with the idea
being that we'd enhance it to match whatever Neutron actually wants
later. Now is the time, I guess.)

[Kyle Mestery]

Post by Ben Pfaff

Post by Gal Sagie
As you might know, allowed address pairs in neutron is an extension to
allow port
to have more then a pair of MAC-IP addresses assigned to it.
This is useful for cases of where few VM's need to share virtual MAC/IP,
like
for VRRP, Load balancing, NFV use cases and so on...
(Aaron who implemented it as far as i know can maybe elaborate)
Its not urgent but i believe that we can support this in Neutron OVN (at
least for L2)
By adding all the MAC addresses configured to a certain logical port.
However, when L3 is going to be introduced, we cant just also add all the
IP addresses, because security wise this means that a certain IP must be
assigned to a certain MAC address (please correct me if i am wrong here)
Just wanted to put this here, so when L3 design is finalized these
connections
are also taken care of in OVN for port security.

Where's the spec for allowed address pairs? It's probably pretty easy
to implement in OVN.

The API developer documentation is here [1]. The BP with a link to a google
doc (this was implemented in 2013) is here [2].

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/api/allowed_address_pairs.html
[2] https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs

Post by Ben Pfaff
(As an aside, I originally specified OVN port security to be more
general and to handle L2 and L3, but I didn't like what I'd specified
and so I dropped back to something simple and L2-only, with the idea
being that we'd enhance it to match whatever Neutron actually wants
later. Now is the time, I guess.)

[Ben Pfaff]

Post by Kyle Mestery

Post by Ben Pfaff
Where's the spec for allowed address pairs? It's probably pretty easy
to implement in OVN.

The API developer documentation is here [1]. The BP with a link to a google
doc (this was implemented in 2013) is here [2].
[1]
http://specs.openstack.org/openstack/neutron-specs/specs/api/allowed_address_pairs.html
[2] https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs

It's not as explicit about the meaning as I would like. Is the
following correct?

A packet is allowed if one of the following is true:

1. Its MAC address is 'mac_address' and, if it is an IP packet, its
IP address is one of those in 'fixed_ips'.

2. Its MAC address is in 'allowed_address_pairs' and, if it is an IP
packet, its IP address is in the same 'allowed_address_pairs'
pair.

How is IPv6 handled? I suppose that 'fixed_ips' and the 'ip_address'
part of an 'allowed_address_pairs' pair can be an IPv6?

What happens to an IPv6 packet if 'mac_address' matches but 'fixed_ips'
only lists IPv4 addresses? Conversely, what happens to an IPv4 packet
if 'mac_address' matches but 'fixed_ips' only lists IPv6 addresses?

Are ARP packets supposed to have their inner IPv4 and MAC addresses
filtered by these rules? How about IPv6 ND packets?

(All of the possibilities above, in either direction, are implementable
in OVN, but I didn't know what precedent had been set in Neutron or
whether that precedent was set for good reason or for convenience, so
I've only implemented L2 port security so far.)

Thanks a lot; this is a discussion I've been meaning to have for a
while.

[Aaron Rosen]

Hi,

The allowed address pair extension was added to the neutron api to allow
protocols like VRRP to work. All it dictates are
mac_address/ip_address(cidrs) that are allowed to pass through a neutron
port.

rest inline

Post by Kyle Mestery

Post by Kyle Mestery

Post by Ben Pfaff
Where's the spec for allowed address pairs? It's probably pretty easy
to implement in OVN.

The API developer documentation is here [1]. The BP with a link to a

google

Post by Kyle Mestery
doc (this was implemented in 2013) is here [2].
[1]

http://specs.openstack.org/openstack/neutron-specs/specs/api/allowed_address_pairs.html

Post by Kyle Mestery
[2] https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs

It's not as explicit about the meaning as I would like. Is the
following correct?
1. Its MAC address is 'mac_address' and, if it is an IP packet, its
IP address is one of those in 'fixed_ips'.
2. Its MAC address is in 'allowed_address_pairs' and, if it is an IP
packet, its IP address is in the same 'allowed_address_pairs'
pair.

Correct. Also fwiw the difference between fixed_ips and
allowed_address_pairs is that the dhcp-server on the network will hand out
the addresses for a port that matches it's fixed_ips +mac_address (the
allowed-address-pairs are just additional addresses that are allowed to
pass through).

Post by Kyle Mestery
How is IPv6 handled? I suppose that 'fixed_ips' and the 'ip_address'
part of an 'allowed_address_pairs' pair can be an IPv6?

Correct it could be an ipv6 address as well.

Post by Kyle Mestery
What happens to an IPv6 packet if 'mac_address' matches but 'fixed_ips'
only lists IPv4 addresses? Conversely, what happens to an IPv4 packet
if 'mac_address' matches but 'fixed_ips' only lists IPv6 addresses?

The packet is dropped in both cases if only the mac_address matches but the
ip doesn't match.

Post by Kyle Mestery
Are ARP packets supposed to have their inner IPv4 and MAC addresses
filtered by these rules? How about IPv6 ND packets?

This is a good question. Today we are only enforcing that the l2/l3 fields
match. That said, I think it probably makes sense for us to filter on this
too.

Post by Kyle Mestery
(All of the possibilities above, in either direction, are implementable
in OVN, but I didn't know what precedent had been set in Neutron or
whether that precedent was set for good reason or for convenience, so
I've only implemented L2 port security so far.)
Thanks a lot; this is a discussion I've been meaning to have for a
while.
_______________________________________________
dev mailing list
http://openvswitch.org/mailman/listinfo/dev

[Ben Pfaff]

Here's a proposal for an OVN port security specification. I tried to
specify it as carefully and completely as possible. This is not
implemented yet, only specified. Comments are welcome!

port_security: set of strings
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.

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 logi‐
cal port to any particular L3 addresses. The host is always
allowed to receive packets to multicast and broadcast Ethernet
addresses.

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, indi‐
cates that the host is allowed to use any addresses in the sub‐
net; if the host part is nonzero, the mask simply indicates the
size of the subnet. In addition:

* If no IPv4 address is given, the host is not allowed to
send or receive any IPv4 or ARP traffic.

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 broad‐
cast address in that specified subnet.

If any IPv4 address is given, the host is additionally
restricted to sending ARP packets with the specified
source address. (RARP is not restricted.)

* If no IPv6 address is given, the host is not allowed to
send or receive any IPv6 (including IPv6 Neighbor Discov‐
ery) traffic.

If any IPv6 address is given, the host is also allowed to
receive packets to IPv6 multicast addresses (ff00::/8).

If any IPv6 address is given, the host is additionally
restricted to sending IPv6 Neighbor Discovery Solicita‐
tion or Advertisement packets with the specified source
address or, for solicitations, the unspecified address.

Multiple elements act as a disjunction. That is, when multiple
elements exist, any packet that would be permitted by any indi‐
vidual element, as described by the policy above, is permitted
by the overall policy.

This column uses the same lexical syntax as the match column in
the OVN Southbound database’s Pipeline table. Multiple
addresses within an element may be space or comma separated.

Examples:

80:fa:5b:06:72:b7
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.

00:23:20:00:00:00/ff:ff:ff:00:00:00
Similar to the first example, except that any Ethernet
address in the Nicira OUI is allowed.

80:fa:5b:06:72:b7 192.168.1.10/24
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.

[Aaron Rosen]

Hi Ben,

This looks great to me. One thing I was wondering is if the ACL interface
that ovn will expose would also allow us to implement this? That said, I
think having this port_security column directly on the port will definitely
simplifies the integration work needed in neutron so I'm definitely a fan.

Best,

Aaron

Post by Ben Pfaff
Here's a proposal for an OVN port security specification. I tried to
specify it as carefully and completely as possible. This is not
implemented yet, only specified. Comments are welcome!
port_security: set of strings
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.
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 logi‐
cal port to any particular L3 addresses. The host is
always
allowed to receive packets to multicast and broadcast Ethernet
addresses.
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,
indi‐
cates that the host is allowed to use any addresses in the sub‐
net; if the host part is nonzero, the mask simply indicates
the
* If no IPv4 address is given, the host is not allowed to
send or receive any IPv4 or ARP traffic.
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 broad‐
cast address in that specified subnet.
If any IPv4 address is given, the host is additionally
restricted to sending ARP packets with the
specified
source address. (RARP is not restricted.)
* If no IPv6 address is given, the host is not allowed to
send or receive any IPv6 (including IPv6 Neighbor Discov‐
ery) traffic.
If any IPv6 address is given, the host is also allowed to
receive packets to IPv6 multicast addresses (ff00::/8).
If any IPv6 address is given, the host is
additionally
restricted to sending IPv6 Neighbor Discovery Solicita‐
tion or Advertisement packets with the specified
source
address or, for solicitations, the unspecified address.
Multiple elements act as a disjunction. That is, when multiple
elements exist, any packet that would be permitted by any
indi‐
vidual element, as described by the policy above, is permitted
by the overall policy.
This column uses the same lexical syntax as the match column in
the OVN Southbound database’s Pipeline table.
Multiple
addresses within an element may be space or comma separated.
80:fa:5b:06:72:b7
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.
00:23:20:00:00:00/ff:ff:ff:00:00:00
Similar to the first example, except that any Ethernet
address in the Nicira OUI is allowed.
80:fa:5b:06:72:b7 192.168.1.10/24
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.

_______________________________________________

Post by Ben Pfaff
dev mailing list
http://openvswitch.org/mailman/listinfo/dev

[Ben Pfaff]

Post by Aaron Rosen
This looks great to me. One thing I was wondering is if the ACL interface
that ovn will expose would also allow us to implement this? That said, I
think having this port_security column directly on the port will definitely
simplifies the integration work needed in neutron so I'm definitely a fan.

The ACL interface could implement the same features. The port_security
column is, thus, mainly a convenience for the CMS.

[Gurucharan Shetty]

Post by Ben Pfaff
Here's a proposal for an OVN port security specification. I tried to
specify it as carefully and completely as possible. This is not
implemented yet, only specified. Comments are welcome!
port_security: set of strings
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.
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 logi‐
cal port to any particular L3 addresses. The host is always
allowed to receive packets to multicast and broadcast Ethernet
addresses.
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, indi‐
cates that the host is allowed to use any addresses in the sub‐
net; if the host part is nonzero, the mask simply indicates the
* If no IPv4 address is given, the host is not allowed to
send or receive any IPv4 or ARP traffic.

I don't understand what the above means. Does it mean that if ipv6 is
specified and no ipv4 is specified the above rule holds true? (Because
if only mac address is specified then all IP addresses are allowed)

Post by Ben Pfaff
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 broad‐
cast address in that specified subnet.
If any IPv4 address is given, the host is additionally
restricted to sending ARP packets with the specified
source address. (RARP is not restricted.)
* If no IPv6 address is given, the host is not allowed to
send or receive any IPv6 (including IPv6 Neighbor Discov‐
ery) traffic.
If any IPv6 address is given, the host is also allowed to
receive packets to IPv6 multicast addresses (ff00::/8).
If any IPv6 address is given, the host is additionally
restricted to sending IPv6 Neighbor Discovery Solicita‐
tion or Advertisement packets with the specified source
address or, for solicitations, the unspecified address.
Multiple elements act as a disjunction. That is, when multiple
elements exist, any packet that would be permitted by any indi‐
vidual element, as described by the policy above, is permitted
by the overall policy.
This column uses the same lexical syntax as the match column in
the OVN Southbound database’s Pipeline table. Multiple
addresses within an element may be space or comma separated.
80:fa:5b:06:72:b7
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.
00:23:20:00:00:00/ff:ff:ff:00:00:00
Similar to the first example, except that any Ethernet
address in the Nicira OUI is allowed.
80:fa:5b:06:72:b7 192.168.1.10/24
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.
_______________________________________________
dev mailing list
http://openvswitch.org/mailman/listinfo/dev

[Ben Pfaff]

Post by Gurucharan Shetty

Post by Ben Pfaff
Here's a proposal for an OVN port security specification. I tried to
specify it as carefully and completely as possible. This is not
implemented yet, only specified. Comments are welcome!
port_security: set of strings
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.
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 logi‐
cal port to any particular L3 addresses. The host is always
allowed to receive packets to multicast and broadcast Ethernet
addresses.
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, indi‐
cates that the host is allowed to use any addresses in the sub‐
net; if the host part is nonzero, the mask simply indicates the
* If no IPv4 address is given, the host is not allowed to
send or receive any IPv4 or ARP traffic.

I don't understand what the above means. Does it mean that if ipv6 is
specified and no ipv4 is specified the above rule holds true? (Because
if only mac address is specified then all IP addresses are allowed)

Yes.

I guess it is not clear enough, so I'll rephrase it, thanks.

[Ben Pfaff]

Post by Ben Pfaff
Here's a proposal for an OVN port security specification. I tried to
specify it as carefully and completely as possible. This is not
implemented yet, only specified. Comments are welcome!

Here's a new version that incorporates feedback (clarification, really)
from Aaron and Guru,

port_security: set of strings
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.

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 logi‐
cal port to any particular L3 addresses. The host is always
allowed to receive packets to multicast and broadcast Ethernet
addresses.

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, indi‐
cates that the host is allowed to use any addresses in the sub‐
net; if the host part is nonzero, the mask simply indicates the
size of the subnet. In addition:

* 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 broad‐
cast address in that specified subnet.

If any IPv4 address is given, the host is additionally
restricted to sending ARP packets with the specified
source address. (RARP is not restricted.)

* If any IPv6 address is given, the host is also allowed to
receive packets to IPv6 multicast addresses (ff00::/8).

If any IPv6 address is given, the host is additionally
restricted to sending IPv6 Neighbor Discovery Solicita‐
tion or Advertisement packets with the specified source
address or, for solicitations, the unspecified address.

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.

Multiple elements act as a disjunction. That is, when multiple
elements exist, any packet that would be permitted by any indi‐
vidual element, as described above, is permitted by the overall
policy.

This column uses the same lexical syntax as the match column in
the OVN Southbound database’s Pipeline table. Multiple
addresses within an element may be space or comma separated.

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 ACL table.

Examples:

80:fa:5b:06:72:b7
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.

00:23:20:00:00:00/ff:ff:ff:00:00:00
Similar to the first example, except that any Ethernet
address in the Nicira OUI is allowed.

80:fa:5b:06:72:b7 192.168.1.10/24
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.

[Justin Pettit]

Sorry. I hadn't realized this was waiting for feedback.

Post by Ben Pfaff
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 ACL table.

This is true, but if "from-host" ACL processing happens after L3, then it won't have the benefit of the spoof protection afforded by the ARP restrictions. My guess is that ACL processing will happen before L3, but we should keep it in mind.

This looks like a good addition. Thanks.

--Justin

[Ben Pfaff]

Post by Justin Pettit
Sorry. I hadn't realized this was waiting for feedback.

Honestly I figured the next step was to produce a patch rather than a
document.

Post by Justin Pettit

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 ACL
table.

This is true, but if "from-host" ACL processing happens after L3, then
it won't have the benefit of the spoof protection afforded by the ARP
restrictions. My guess is that ACL processing will happen before L3,
but we should keep it in mind.

Good point, I'll be sure to revise that text before implementing this.

[Ben Pfaff]

I posted a patch (it still is just a proposal, no code):
http://openvswitch.org/pipermail/dev/2015-September/059861.html

Post by Ben Pfaff

Post by Justin Pettit

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 ACL
table.

This is true, but if "from-host" ACL processing happens after L3, then
it won't have the benefit of the spoof protection afforded by the ARP
restrictions. My guess is that ACL processing will happen before L3,
but we should keep it in mind.

Good point, I'll be sure to revise that text before implementing this.

I didn't know how to rephrase it so I left it as-is.