> > 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 [email protected] http://lists.xensource.com/mailman/listinfo/xen-api
