From sac-owner Wed May 31 14:29:26 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VLTQa1024565 for ; Wed, 31 May 2006 14:29:26 -0700 (PDT) Received: (from noaccess@localhost) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) id k4VLTQe18274 for one-pager-not-2b-used-directly; Wed, 31 May 2006 14:29:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k4VLTPY18260; Wed, 31 May 2006 14:29:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J0500J07FOZ0V00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 31 May 2006 14:29:23 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.56.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J0500CFJFOYBY40@nwk-avmta-1.sfbay.Sun.COM>; Wed, 31 May 2006 14:29:22 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4VLTHVb773659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 31 May 2006 14:29:19 -0700 (PDT) Date: Wed, 31 May 2006 14:29:16 -0700 From: Erik Nordmark Subject: [/]Stack instances: Exclusive IP stack per zone To: one-pager@Sun.Com Message-id: <447E0AAC.1010900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 32525 Template Version: @(#)onepager.txt 1.29 04/11/15 SMI Copyright 2007 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: Stack instances: Exclusive IP stack per zone 1.2. Name of Document Author/Supplier: Erik Nordmark 1.3. Date of This Document: 05/29/2006 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Diann.Olden@sun.com 1.4.4. The name of your business unit: Software 1.5. Email Aliases: 1.5.1. Responsible Manager: Diann.Olden@sun.com 1.5.2. Responsible Engineer: Erik.Nordmark@sun.com 1.5.3. Marketing Manager: Paul.Steeves@sun.com 1.5.4. Interest List: stack-instance-interest@sun.com, crossbow-interest@sun.com 2. Project Summary 2.1. Project Description: Provide the option for a zone to have its own IP stack, so that the zones IP routing, ARP, IPsec, IP Filter, and other configuration is completely disjoint from those configurations for other zones. Enables separation without network security issues for customers that connect separate (V)LANs to separate zones; something we can not currently provide. 2.2. Risks and Assumptions: The following set of assumptions constrain the problem we are trying to solve. We assume that we only need to provide support for network interfaces that have a separate entry in /dev/ for each NIC. Currently Sun is shipping some drivers, such as 'ce', which do not provide this. This project by itself is deemed complete even if separate 'ce' instances (e.g., ce1, ce3) can not be assigned to separate zones that use exclusive stacks. (ce will continue to usable as today both in the global zone and in the shared stack.) The above is likely to be a temporary condition. The Clearview project will unify all drivers, including legacy drivers like 'ce', under the GLDv3 framework, which will make an entry in /dev/ for each instance. We assume that we do not need to virtualize the IPPF (IP Policy Framework, used for IPQoS) across different stack instances. IPQoS has close to zero usage among our customers, hence there is no business need to address this. IPQoS will continue to work in the shared stack just as well as it works in Solaris 10 today. The lack of packet resource management capabilities is likely to be a temporary condition. The Crossbow project is working on providing efficient ways to manage the resources (CPU and bandwidth) associated with inbound and outbound packet processing. Since the goal is to provide for server consolidation where the servers being consolidated have different connectivity requirements (connected to different LANs or VLANs), there is no requirement for two separate stacks to be able to share the same NIC. Thus the NIC (and its MAC address can be assigned to one stack instance.) [The Crossbow project is designing and implementing notion of VNICs, which are /dev/ entrypoints that refer to different MAC addresses on a single NIC, that GLD might provide in the future. Stack instances would combine well with such a technology, since it would allow multiple stacks to share the same NIC without resorting to VLANs.) We assume that the stack instance concept only need to apply to kernel code that is "near" IP, because IP is the thing that is shared in the Solaris 10 zones model for networking. For instance, network applications are automatically separated for zones since each process runs in a zone. Furthermore, if kernel networking pieces that sit above UDP, TCP, SCTP, or RAWIP need to be virtualized for zones, they do not need to be aware of stack instances; such software can be virtualized by using the zoneid as the discriminator which applies whether or not IP is virtualized. Kernel software that is below IP, such a GLD or other network device drivers, doesn't have a need to be aware of stack instances either. Zones uses the /dev/ entry points as the way to control what each zone can access, and the device drivers already keep different instances (bge0 vs. bge1) apart. The only implication of this assumption is that is it sufficient to make the internal support routines (netstack framework) be consolidation private. We assume that there is no business need to make 3rd party software that sit between IP and the device drivers aware of zones and/or stack instances. This means that things like Firewall-1 and the Cisco VPN client can only be used in the shared stack (used by the global zone.) The project will not address any kernel components above the transport layer (such as NFS, KSSL, NL7C). Such components, when and if they are made zones aware, do not and should not be aware of stack instances; whether the IP addresses assigned to a zone is from an exclusive or shared stack is immaterial to components above the transport layer. 3. Business Summary 3.1. Problem Area: Server consolidation, where the different servers that are consolidated are connected to different physical networks, or to different VLANs on the same network. Customer's have repeatedly been told by Sun that separate Zones do networking separate (even though in reality they just have a separate IP address as part of the same shared IP) and as a result they (as well as many Zones experts at Sun) believe that if a system with Zones are connected to different (V)LANs, that the (V)LANs are kept separate. The only way we can ensure such separation is to design it in; efforts to patch more and more separation into existence (by tweaking IP routing) leads to swiss cheese "security". 3.2. Market/Requester: Several customer's have already stretched the shared IP stack with zones beyond its limits, and have been filing bugs and RFEs to enable higher degree of separation between the traffic for different zones, and/or more control for each zone over its IP stack configuration. At least one customer expressed the need for IKE/IPsec support in zones. 3.3. Business Justification: As customers are starting to deploy using Zones, some of the see a good fit was the design center for the Zones networking support; the servers to be consolidated are on the same IP subnet. Other customers see some problem or limitation. The problems stem from desiring to consolidate servers that are on different subnets (e.g., because different departments in a company "own" different IP subnets), or that different zones should be connected to different VLANs or different LANs. The customer's we've talked that express the need for - separate routing per zone - prevent loopback traffic between zones inside the box all have the expectation (and in some cases the explicit requirement) that the network traffic for the different zones must be completely separate from the traffic for other zones; they might share the same physical NIC using VLANs, but that's the only allowed degree of sharing. In many cases folks try to make the cases of different subnets and different (V)LANs work, through some combination of manual tweaking. But the Zones networking support was designed with a share IP stack in mind. This implies that - we can not guarantee that packets can not accidentally show up in a different zone than some security policy requires; there are just too many protocol features and code paths in IP, ARP, TCP, etc that can cause such "leakage", and - the behavior after the manual tweaking isn't guaranteed to work; we have no way to ensure that some customer invented approach or some blog suggestion will continue to work after a patch. Note that some of the customers currently express the issues they see as "it is too difficult to configure", but the more fundamental issue seems to be that the expect secure separation (which is why they are using separate LANs or VLANs on the network), but they don't seem to see the security holes implicit in sharing the same IP and ARP for all the zones. Thus one aspect of the business justification is that me most stop the bleeding and avoid wandering further into a support problem by providing an alternative to the S10 "shared stack" model. That way we have a chance to move customers that want to use separate LANs and/or VLANs for zones to using an exclusive IP stack for those zones. An other aspect of the business justification is that we have an opportunity to set us apart from the competition by leveraging the exclusive stacks to provide new capability such as: - easier testing of Solaris networking; can run multiple exclusive stacks inside one box and run automated testing that today requires several systems that are manually cabled together - the potential to build more secure infrastructure by having a zones sole connection to the network be an IPsec tunnel that is provided by the global zone - the potential to leverage more of the security including packet filtering capability for Zones as well as for Xen virtualization - the potential to have OEMs use this to build virtual routers or other virtual network appliances where each appliance has an presence on the network which is independent of other appliances on the same box. Finally, the BrandZ team desires a supported way to run NAT in the global zone for a branded zone, so that only one IP address is needed for the system. Other approaches to providing NAT functionality in such configurations do not appear to be supportable due to the complex interdependencies that one would have to create inside the single IP stack. Thus the shortest time to market for such supported functionality is having an exclusive stack for the BrandZ zone, and have that communicate via the NAT in the global zone using an local-to-the box pseudo Ethernet (called vSwitch). Note that in order to apply this approach to BrandZ, the branded zone has to do its own IP layer configuration (i.e., issue ifconfig or DHCP operations) since the global zone will not configure IP for a zone with an exclusive stack. 3.4. Competitive Analysis: VmWare and Xen provide different forms of virtualization. While they lack the ability to do fine grain and statistical sharing of the machines resources (CPU, memory) that are possible to do with Zones combined with resource pools, they do provide each domain with full control of the TCP/IP features that it can use. 3.5. Opportunity Window/Exposure: It is strongly desirable that BrandZ have a way to provide NAT in the global zone for the branded zones. Stack instances is the only way we know to do this that we think is supportable. 3.6. How will you know when you are done?: The TCP/IP stack features (with the exceptions of those listed in the assumptions in section 2.2) work in a non-global zone that uses stack instances. This list includes (but is not limited to) the following items: DHCPv4 and IPv6 stateless address autoconfiguration IP Filter including its NAT capability IPMP and CGTP IP routing ndd for setting transport as well as IP configuration IPsec We have a GLDv3 vSwitch driver that can be used to connect different stacks together inside the machine. Using the vSwitch capability, be able to use the global zone as virtual networking box sitting between the non-global zones and the external network, and have that virtual networking box be capable of being an IP router and/or a NAT, and be able to filter (using IP Filter) the same way as a separate Solaris instance could do that functionality between different network interfaces. 4. Technical Description: 4.1. Details: The approach consists of several pieces. 1. Split off a new PRIV_SYS_IP_CONFIG privilege from PRIV_SYS_NET_CONFIG that allows IP layer configuration, but not autopush, soconfig, etc configuration. That way PRIV_SYS_IP_CONFIG can be given to a zone that has an exclusive stack. 2. Changes to the networking SMF method scripts which today skip sections of the script of "zonename != global", to not skip those sections if the non-global zone has an exclusive stack. This test requires a way for a script to be able to ask "does this zone have an exlusive stack". The current approach is do to this with a new option for zonename(1m) - zonename -t. 3. Small modifications to zonecfg, zoneadm, zoneadmd, libzonecfg to handle - the new stacktype property, which is passed to the kernel as part of the zone_create() call. - the new router resource (which allows giving static default routes to a zone with an exclusive stack) - be able to specify that an exclusive stack zone be configured using DHCP and/or IPv6 stateless autoconfiguration (this introduces an 'af' property for the 'net' resource to be able to specify whether IPv4 and/or IPv6 should be autoconfigured) - a new 'restrict' boolean property for the 'net' resource which is passed to the kernel in form of an exact match of the network interface name and the IP address. When set, this prevents a non-global zone that has an exclusive stack from "stealing" somebody else's IP address. 4. Finding the all the global OBJT symbols in each kernel module in question (e.g., 'ip'), verifying which are never modified (e.g., each module has a streamtab which is statically initialized), and moving the remaining globals into a new data structure: typically named foo_stack_t for the foo module. 5. Semi-automatic modification of the common/inet source files so that what used to be a reference to e.g., tcp_some_global becomes tcps->tcps_some_global. 6. A "netstack" kernel framework (netstack.h/netstack.c) which isolates the TCP/IP kernel modules from the mapping between zones and stacks, and provides things like kstat_create_netstack() analogous to kstat_create_zone(). For further details on this, see the upcoming design document. 7. Having each TCP/IP kernel module register with the netstack framework, and provide foo_stack_init(), foo_stack_shutdown(), and foo_stack_fini() (analogous to zone_key_create, but being called for each stack instead of each zone.) 8. Having the open routines (foo_open()) determine the stack using netstack_find_by_cred(), and saving the netstack pointer (or the foo_stack_t pointer) in its q_ptr per instance data structure (such as tcp_t). 9. Passing around netstack_t or foo_stack_t as extra arguments in the cases where it isn't present in the per-instance data structure (such as tcp_t) until the thing compiles and lint is happy. 10.The few places in the kernel TCP/IP code where things should be shared, some local changes are necessary. The only two cases of this is the squeue data structures and the ipsec loader logic; these are scheduling (tied to the number of CPUs in the system) and kernel module loading, respectively, thus should not be done separately for different exclusive stacks. 11. Have the stream head be zoneid aware so that a streams anchor that is added by one zone (e.g., the global zone) can't be removed by another zone. 4.2. Bug/RFE Number(s): Some of these RFEs and bugs might make sense to apply to the current shared stack model in addition to being addressed implicitly by the exclusive stack. Which ones to address in the shared stack model is partly a business decision, since additional specific effort is needed for those in the shared stack model. Unless otherwise noted, this bugs and RFEs will be addressed as a side effect of having an exclusive stack without any additional effort. 6364643 RFE: allow persistent setting of interface flags per zone 6307539 RFE: Invalid network address causes zone boot failure Will work just as a server (global zone) with a bad address in /etc/hostname. 5041214 Allow IPMP configuration with zones 6358521 RFE: zoneadm should check for IPv6 link-local address when IPv6 global address exists Doesn't change zoneadm, but the link-local will be automatically setup in the exclusive stack zone 5005887 RFE: zoneadmd should support plumbing an interface via DHCP 4991139 RFE: zones should provide a mechanism to configure a defaultrouter for a zone 6367840 Zones does not boot if configured for a failed network interface Same behavior as for a separate server (global zone) 6218378 zoneadmd doesn't set the netmask for non-loopback addresses hosted on lo0 No change in zoneadmd. lo0 works as in the global zone. 6391685: Source interface selection is flawed when sending via default route within a zone. Being escalated and fixed for shared stacks as well. 4963280 zones: need to virtualize the IPv6 default address selection mechanism 4963285 zones: need support of stateless address autoconfiguration for IPv6 5048068 zones don't boot if one of its interfaces has failed 5057154 RFE: ability to change interface status from within a zone 6289221 RFE: Need virtualized ip-stack for each local zone 4963287 zones should support the plumbing of the first (and only) logical interface 4963327 CGTP support in zones 4978517 TCP privileged port space should be partitioned per zone 5023347 zones don't work well with network routes other than default 4963372 investigate whether global zone can act as a router for local zones 4950897 RFE: IPFilter should filter between zones This is already pursued (and necessary) for zones using the shared stacks. For exclusive stacks IP Filter will work as separate servers. 6378364 RFE: Allow each zone to have its own virtual IPFilter 4963315 Should make IKE work for local zones 4619504 in.iked cannot handle a big number of network interfaces Stack instances doesn't fix the root cause (stdio 256 limit) but might remove the need to address this because as long as each stack instance has at most O(200) IP addresses, then the current iked runs. With the shared stack, iked runs in the global zone and needs to handle the sum of all the IP addresses across all the zones. 6218826 need to be able to tunnel into a zone Probably also need Sebastian's tunnel rewrite (which integrates IP-in-IP tunnels into GLDv3) 6339536 global zone should be able to delegate IPsec key management to non-global zones The exclusive-stack zone has full control of its IPsec. 6339553 global zone should be able to delegate IPsec policy management to non-global zones The exclusive-stack zone has full control of its IPsec. 6423486 Solaris should include an option to disable loopback traffic routing between non-global zones. 4.3. In Scope: The project will deliver virtualized kernel components for the following kernel modules: IP, ARP, TCP, ICMP, UDP, SCTP, RTS KEYSOCK, SPDSOCK, IPSECAH, IPSECESP IPF, PFIL The project will deliver a virtualized Ethernet driver (as a Nemo MAC driver) for communication between different stack instances in the same Solaris instance. The creation of the virtual wires and creating of link layer attachments to them will most likely be done using extensions to dladm(1m). The project will use (and not deliver anything new) any existing datalink drivers that have a name per instance in /dev. The project will deliver additions to zonecfg and related parts to allow the administrator to specify whether a zone should use the shared stack, or have its own exclusive networking stack. A result of this will be a number of capabilities that fall out without any additional code changes or administrative changes such as - Each exclusive-stack zone being able to configure IP using DHCP and IPv6 stateless address autoconfiguration. - Each exclusive-stack zone being able to control its own routing, its own IPsec policies, IPsec security associations, IP filter, ARP table, TCP/IP ndd settings, netstat, etc. - Being able to run NAT in the global zone for the exclusive-stack zones. - Being able to run an IP router in the global zone for the exclusive-stack zones. 4.4. Out of Scope: This project does not modify any device drivers or the GLD framework. The project works with device drivers (current and future) that provide a /dev name for the interface e.g., /dev/bge0 or /dev/net/bge3001. Separate projects are underway to provide such names for existing style 2 DLPI device drivers (such as /dev/ce), and also provide virtual NIC interface (names) so that different MAC addresses on the same physical NIC will have a separate /dev name. Such improvements in GLD will further enhance the applicability of stack instances, but there are no technical dependencies between the projects. Providing a virtualized IPPF/IPQoS for each stack instance is out of scope. Additional restrictions are specified in the assumptions in section 2.2. 4.5. Interfaces: The project adds a few things to the zonecfg syntax: - a 'stacktype' global property which can be set to either 'exclusive' or 'shared' - an 'af' property for the 'net' resource ('inet' or 'inet6' for IPv4 and IPv6, respectively) - a 'restrict' property for the 'net' resource (true/false) - a new 'router' resource which takes the property 'address'. Applies to zones with an exclusive stack. The project will deliver a GLDv3 vSwitch Ethernet driver, which isn't associated with any Ethernet hardware. This driver will behave as an Ethernet driver from all software aspects, and will be used to connect different stack instances together inside the machine. The driver will be used when the global zone wants to run as a router and/or NAT for a non-global zone. Some networking SMF scripts today run in all zones and make a distinction between the global zone and a non-global zone. For this the scripts compare the result of zonename(1m) with 'global'. With stack instances those scripts need to make a distinction between a non-global zone with an exclusive stack and a shared stack. The needed result is that the scripts do the same thing for the global zone and for any non-global zone that has an exclusive stack. The current prototype handles this by introducing an option {-t} to zonename(1m), which makes it print the string 'shared' or 'exclusive'. Advise is actively sought whether there are better ways to provide this information to the SMF scripts. 4.6. Doc Impact: zonecfg(1M), zones(5), zonename(1) Some tweaks to "System Administration Guide: IP Services" New material in zones part of "System Administration Guide: Solaris Containers-Resource Management and Solaris Zones" to explain the differences between shared and exclusive IP stacks. 4.7. Admin/Config Impact: An administrator that wishes to give a zone an exclusive IP stack needs to assign a set of physical NIC or VLANs to that zone. Once the administrator has that network interface name or names, it proceeds with zonecfg as normal except adding this set stacktype=exclusive With exclusive stacks the administrator has the choice to use DHCPv6 or IPv6 stateless address autoconfiguration. If this is desired, then administrator doesn't specify an address property in the net property in zonecfg, and instead specifies the 'af' (for "address family") property. Thus instead of add net set physical=bge1 set address=1.2.3.4 the administrator would do add net set physical=bge1 set af=inet and for IPv6 add net set physical=bge1 set af=inet6 There is a slight difference in the semantics of the IP configuration between shared and exclusive stack zones. With shared stack zones, each time the zone is booted the 'net' resources are used to configure the IP address. With exclusive stack zones, when the zone is *installed*, the 'net' resources are used to setup the initial /etc/hostname{,6}., /etc/dhcp/, and /etc/defaultrouter files. But after that, the administrator of the local zone is in control of the IP addresses she uses, and can modify those files just as on a separate server. Since we do not yet have a sane (SMF) way to keep separate properites apart (e.g., the local admin could add "mtu 1200" to its /etc/hostname. file), it isn't feasible to have zonecfg change the IP configuration of an already installed zone. It is important for the administrator to remember that even with exclusive stack instances, there is still a single kernel. Thus there is a single /etc/system file (and network tunable values from there apply to all the stacks on the machine). And it is the global zone administrator who control which kernel modules are available for loading into the kernel. With shared stacks some aspects of a non-global zones network configuration is visible in the global zone, and other parts are not. For example, ifconfig -a shows the IP addresses for all the zones, while netstat only shows what is in the global zone. For stack instances, any of these commands when invoked in the global zone will only report things about the shared stack. Zones using shared stacks can be inspected using zlogin other-zone netstat -a The primary reason to not add options to ifconfig, netstat, etc to show things for *all* stacks is that this can be very confusing; different stacks are free to use overlapping IP address space e.g., a network interface could be 192.168.0.3 in more than one stack. Reporting connections, routes, interfaces, etc together will be confusing. The primary reason to not add an extra option to ifconfig, netstat, etc., to show things in a *single* exclusive stack is that the semantics of the names (returned by gethostbyaddr() etc) wouldn't be obvious; should and would the reverse lookups be done in the zone in question, or should they be done in the global zone. Explicit usage of zlogin answers this question by saying "it is run in the zone in question" thus the reverse lookups occur inside that zone. 4.8. HA Impact: Need to investigate how rcm would handle this; perhaps rcm is the wrong long-term approach to network interface failures (in a world of virtualization it might make sense to see the same bahevior when a NIC is removed as when a Ethernet capable is unplugged - the NIC driver sending a DL_NOTE_LINK_DOWN. RCM thinks it needs to explicitly go and down an ifconfig unplumb.) Need to verify that the fmd doesn't trigger any SMF scripts related to the IP configuration in the global zone. The clustering folks might want to look into using exclusive stack instances if it makes it easier to run their software on a zone in that manner. 4.9. I18N/L10N Impact: Minimal impact: some new and changes messages from zonecfg and zoneadm need to be translated. 4.10. Packaging & Delivery: The code lives in the usual places (SUNWcsr, SUNWcsu). For IPsec to work, we will most likely need to install SUNWcnetr in the non-global zone, since this package contains some configuration files needed for handling certificates in iked. No impact on upgrade. The default value for 'stacktype' in the xml files that describe the zone configuration is set to 'shared', so any existing zone will function the same way after the upgrade as before. 4.11. Security Impact: The proposal relies on zoneadmd's ability to control which /dev/ entries appear in each zone, so that a zone with an exclusive stack can gain access to the network devices that have been specified in the 'net' resource(s). An zone with an exclusive stack is also given the /dev/ entries for the network components that are virtualized (such as /dev/ip, and also all the IP Filter /dev/ entries). A zone with an exclusive stack is given a larger set of privileges that for a shared stack: it is given PRIV_NET_RAWACCESS and PRIV_SYS_IP_CONFIG. Note that those privileges doesn't allow the zone to interfere with any other zone or the global zone, since the TCP/IP configuration (that PRIV_SYS_IP_CONFIG enables) is local to the stack instances, and RAWACCESS only applies to the network interfaces that the zone can access in its /dev. Thus the zone doesn't have any more power than a separate server connected to the same Ethernet switch as other zones on the same machine. Customer's that require separate IP instances for separate (V)LANs seem to comfortable with root in those zones having the same power to disrupt the network as does root on a separate machine being connected to that (V)LAN. However, there is some utility in being able to restrict this because: - ARP spoofing (to steal somebody else's IP address) is trivial for root on hosts on the same Ethernet - just ifconfig to use somebody else's IP address. - The shared stack zones can not cause ARP spoofing, either for other machines on the network or for other zones on the same machine since the global zone controls the IP address assignment. - With stack instances, root in an exclusive-stack zone has the same ability to do ARP spoofing, but only for the Ethernets to which the global zone allows it to connect. The new 'restrict' property can be set to 'true' for an exclusive stack's 'net' resource(s), which makes IP check that the address set with the SIOCS{,L}IFADDR ioctls against what was specified in zonecfg. Potentially other similar restrictions can be placed on other freedoms in the exclusive-stack zones, but an initial threat analysis indicates that the threats by restricting the netmask settings, routes, etc are not very significant in that they don't cause harm to other zones or other hosts on the network; they can only be used by root in the non-global zone to mess up its own zone. In addition, the stack instance architecture allows the model where the global zone runs IP Filter between the exclusive-stack zones and the wire, which provides flexible restrictions on that the zone can and can not send to the network. For instance, today with shared stacks the non-global root can send arbitrary RIP packets in an attempt to mess up IP routing. We can filter such attempts uniformly between Zones and Xen with IP Filter, in particular if IP Filter is extended to have filter hooks in GLD. 4.12. Dependencies: None known. The vSwitch functionality might be removed from this project and be delivered separately. 5. Reference Documents: 6. Resources and Schedule: 6.1. Projected Availability: Q3CY2006 6.2. Cost of Effort: Engineering: 6 staff months Process: 12 staff months Documentation: TBD Testing: TBD 6.3. Cost of Capital Resources: No additional capital resources are needed. Leveraging existing shared build and test machines. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: // Give the document's URL http://.... 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: // See dependencies section above. 6.4.7. Target RTI Date/Release: Nevada Q3 CY06 S10 Update 4 if possible 6.4.8. Target Code Design Review Date: 6.4.9. Update approval addition: // Did this project have prior Solaris PAC approval for a // Marketing Release and now your requesting to go into an // Update Release or Early Access CD? 6.5. ARC review type: Standard 7. Prototype Availability: 7.1. Prototype Availability: Available today from /net/nptbld-x.sfbay/disk1/si-gate 7.2. Prototype Cost: Approximately 3 staff months have been spent on the prototyping, with some additional effort to stay in sync with S10 and onnv.