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



On Thu, Jul 2, 2015 at 12:42 PM, Ben Pfaff <b...@nicira.com> wrote:

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

_______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to