> On Apr 7, 2016, at 11:34 AM, Numan Siddique <nusid...@redhat.com> wrote:
>
> Hi Justin, there is still a problem with the below approach.
>
> In the case where port security has "10.0.0.4/24" it means that the logical
> port is restricted in sending and receiving IP traffic with ip address
> 10.0.0.4. IP traffic with any other ip address should be dropped. But with
> the below approach we would be allowing all the ip addresses in the
> 10.0.0.0/24.
Huh, there's a fair amount of subtlety there. What about logic similar to the
following (untested) code?
-=-=-=-=-=-=-=-=-
ovs_be32 mask = be32_prefix_mask(ps.ipv4_addrs[i].plen);
/* When the netmask is applied, if the host portion is
* non-zero, the host can only use the specified
* address. If zero, the host is allowed to use any
* address in the subnet. */
if (ps.ipv4_addrs[i].addr & ~mask) {
ds_put_format(&match, IP_FMT,
IP_ARGS(ps.ipv4_addrs[i].addr));
} else {
ip_format_masked(ps.ipv4_addrs[i].addr & mask, mask,
&match);
}
-=-=-=-=-=-=-=-=-
> Below is the port security description
>
> <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 which the host may send and to which it may receive
> packets to the specified addresses. A masked address, if the host
> part
> is zero, indicates that the host is allowed to use any address in
> the
> subnet; if the host part is nonzero, the mask simply indicates the
> size
> of the subnet. In addition:
> </p>
The next paragraph is interesting because it describes what should happen with
the subnet:
· 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.
Would you mind expanding the tests to make sure that we're testing these
different combinations both on the send and receive enforcement? We clearly
had some gaps before.
Thanks for noticing these issues.
--Justin
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
