[ovs-dev] [PATCH] ovn-northd: Handle IPv4 addresses with prefixes in lport port security
Numan Siddique
nusiddiq at redhat.com
Fri Apr 8 05:39:14 UTC 2016
>
> 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.
>
>
Sure. I will do that. Thanks for the suggestions and comments.
> Thanks for noticing these issues.
>
> --Justin
>
>
>
More information about the dev
mailing list