RE: [Xen-API] XCP antispoofing (idea and working patch)

[George Shuklin <george.shuklin@xxxxxxxxx>]

> > The main concern is usage of configuration file instead xapi. I think
> > it
> > must be placed somewhere to vif's other config (but it far beyond my
> > knowledge, and I except some help with this). xapi shall place
> > ip_restriction to other-config and copy it to xenstore for vif to be
> > readable from scripts/vif script.
> 
> This part needs a bit more thought. I was wondering if we wanted to have 
> first-class fields for this kind of VIF/switch configuration... something like
> 
> Network.default_secure: bool -- if true then unconfigured VIFs have no 
> access, otherwise they have full access
> VIF.allowed_addresses: some encoding of values like
>   Some (list of (MAC, IPv4) pairs) -- specific addresses to limit the VIF to. 
> Probably need '*, *'
>   None -- no configuration


Nice idea!

But why only two choices? If we really starts to thinking about security
model I see following:

1) Allow all  - No security (current state, allow regardless restriction
configuration)
3) Deny denied, allow other (use restriction according configuration,
allow non-configured) - the mode in my path.
2) Allow allowed, deny other (default mode for most ACL in network
equipment)
4) Deny All (some like network-shutdown) - if we thinking about options
this may be interesting)


Now, about restriction. 

1) L2 address:  'native' VIF MAC address can be found via xenstore, so
we need to have two special values: any, self. 
2) L2 protocol-num: Allowed protocol number: ipv4, ipv6, arp (does
anyone still use something else?)

2) L3 address: ipv4 (shall we support CIDR notation X.X.X.X/Y ? In this
case we can skip '*'/'any' value just replacing it 0/0).
3) IPv6 address support (...I'm lack of knowledge here)


... and one more idea: if we have 'own' ip-address for vif, can we
create some kind of 'external configurable' IP-address for guest VM
interfaces?
Agent will waiting subscribing for modification event of some variable
in xenstore in VM. It will change network interface settings accordingly
(IP, netmask).


> Also adding explicit openflow rules will conflict with any attached openflow 
> controller (eg nox) so we should make it an explicit choice: disable these 
> rules and enable a controller, or disable a controller and enable these rules.

... and here 2nd option for network security: what to do if openflow
controller down/not available: shutdown network/allow all.

 


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api