[zones-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
[EMAIL PROTECTED] wrote: Erik, Here are my belated comments on the IP Instances design. And here are my belated responses. But we've already acted on the comments that affect the design and code, and I'll make sure the Zones documentation covers the other documentation items. There are two documents which describe the design si-interfaces - a high-level design focusing on the problem the project solves, and what the user-visible changes are A general comment that in both documents page numbers seem to be missing. Good point. But I suspect the remaining shelf-life of the design document is very limited. I'll definitely take your comments on missing pieces in the documents as strong hints that we should ensure that the zones book be clear on these points. Figures 1 and 2 - I think the pictures are a little misleading the second picture displays an example of two applications (web servers?) both binding to INADDR_ANY on port 80. Of course, that's also a very viable example for the current zones model. Perhaps a better example might be one of those applications designated as Internet facing and another might be Intranet-facing or Internal. Figure 1 shows how zones can be used today. Figure 2 shows what customers want from IP-level isolation between VLANs (and the white space between the two instances of IP is critical). Clearly zones today doesn't provide that isolation. Even if we ignore that (a bit foolish it might be), in figure two the two different zones use different IP subnets and as a side effect they need to use different (default or otherwise) routes. AFAIK we don't actually claim to support different routes for different zones. Do you still think this is misleading? Page 6, Section 4 - I'm not sure if this is the proper place for a discussion on security or if it warrants a separate section, but I think the document should discuss the security implications of a zone using a shared stack versus an exclusive stack. For example, I think including the table you had sent in private email some time ago which documented the various attack vectors and how each type of zone addresses the type of attack would be helpful in understanding the trade-offs. We'll put this in the zones book. We need to describe the tradeoffs between using shared-IP and exclusive-IP zones there, and the network security differences is one part of that. Page 6, Section 5 - In the second paragraph, you mention there are no planned layer two changes. Does that mean for the initial design that there will be no filtering done at that layer? Again, perhaps this merits discussion in a separate Security section but it's important to understand what sorts of capabilities a privileged user in an exclusive stack zone has versus one in a zone using the shared stack. Correct. I'll make sure the zones book covers this topic. Page 7, Section 6 - In #4, leveraging zonename(1) in this way does seem strange. I know we discussed at one time a command to retrieve and interpret the values of ZONE_ATTR_* kernel attributes although in this particular case, it seems the only one that makes sense from inside the zone itself is whether this zone is tied to an exclusive stack. We've discussed this in a separate email thread. As your college indicated given that this is a private interface it isn't a big deal. If some new general command for getting ZONE_ATTR_* is created we can just switch to using that instead. (The only place which calls zonename -t is in smf_include.sh thus it would be easy to change when that day comes.) What about using /sbin/netstrategy and smf_netstrategy() in /lib/svc/share/smf_include.sh for this purpose? Overloading them would probably be a mistake. We also have Xen adding its own mechanisms to net-physical. Once we get a perspective across all of the virtualization technologies then we can try to refactor how we do configuration. Page 7, Section 7 - Given the recent discussion with a customer, would it make sense to make it clear here that there is a *single* shared IP and the project does not allow for islands of shared IP instances? Will do in the zones book. Page 8, Section 9 - When does the enforcement of only allowing a physical property for exclusive IP zones? Does it occur when one tries to complete the addition of a net resource by specifying end subcommand? Or does it occur when verify is performed on the whole configuration (either the explicit command or the implicit verification that takes place prior to commit?) The latter. (It is done is the verify command in zonecfg.) In the example given for the shared IP zone, I would specify add the /24 prefix length to the address parameter (it's not required but definitely encourage it) and also the missing end subcommand. In the example given for the exclusive IP zone, there is also a missing end subcommand. I'll make sure the examples in the zones book are correct on these points. Page 9,
re: [zones-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Should these functions be dealing with link names rather than interfaces to avoid confusion with the interfaces that ifconfig(1M) deals with? Good point. We've renamed them to have datalink in their names. Jerry also pointed out that we should be more careful about terminology like ifname and interface name in the code, so we have done that as well. (Basically the general concept which corresponds to physical=bge0 is something we call network interface (name). Those could be for shared-, or exclusive-IP zones. But when it comes to adding a datalink name for an exclusive IP zone we call the zone_add_datalink() syscall.) Glad to hear this. Consistent and correct use of these terms will be increasingly important given upcoming technologies like datalink vanity naming and VNICs (among others). -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Erik, Here are my belated comments on the IP Instances design. There are two documents which describe the design si-interfaces - a high-level design focusing on the problem the project solves, and what the user-visible changes are A general comment that in both documents page numbers seem to be missing. Figures 1 and 2 - I think the pictures are a little misleading the second picture displays an example of two applications (web servers?) both binding to INADDR_ANY on port 80. Of course, that's also a very viable example for the current zones model. Perhaps a better example might be one of those applications designated as Internet facing and another might be Intranet-facing or Internal. Page 6, Section 4 - I'm not sure if this is the proper place for a discussion on security or if it warrants a separate section, but I think the document should discuss the security implications of a zone using a shared stack versus an exclusive stack. For example, I think including the table you had sent in private email some time ago which documented the various attack vectors and how each type of zone addresses the type of attack would be helpful in understanding the trade-offs. (I know some of this is headed to be discussed in Section 9 of the second document but it seems at least some of the discussion belongs here as well.) Page 6, Section 5 - In the second paragraph, you mention there are no planned layer two changes. Does that mean for the initial design that there will be no filtering done at that layer? Again, perhaps this merits discussion in a separate Security section but it's important to understand what sorts of capabilities a privileged user in an exclusive stack zone has versus one in a zone using the shared stack. Page 7, Section 6 - In #4, leveraging zonename(1) in this way does seem strange. I know we discussed at one time a command to retrieve and interpret the values of ZONE_ATTR_* kernel attributes although in this particular case, it seems the only one that makes sense from inside the zone itself is whether this zone is tied to an exclusive stack. What about using /sbin/netstrategy and smf_netstrategy() in /lib/svc/share/smf_include.sh for this purpose? Page 7, Section 7 - Given the recent discussion with a customer, would it make sense to make it clear here that there is a *single* shared IP and the project does not allow for islands of shared IP instances? Page 8, Section 9 - When does the enforcement of only allowing a physical property for exclusive IP zones? Does it occur when one tries to complete the addition of a net resource by specifying end subcommand? Or does it occur when verify is performed on the whole configuration (either the explicit command or the implicit verification that takes place prior to commit?) In the example given for the shared IP zone, I would specify add the /24 prefix length to the address parameter (it's not required but definitely encourage it) and also the missing end subcommand. In the example given for the exclusive IP zone, there is also a missing end subcommand. Page 9, Section 10 - BrandZ added their BRAND column after the existing PATH column but you're introducing it before. It seems the IP TYPE should follow both PATH and BRAND. Also, updating the output for first two list examples to account for the merge with BrandZ would be helpful. In the third example, the command listed is list -i but earlier -l is defined for this purpose. With respect to list -l, I'm not sure if this really belongs in zoneadm(1M) or somewhere else. In some ways, I'd rather see it as a new option to dladm(1M) instead. Will the list of link names printed be the ones actually registered with the kernel though zone_add_ifname() or the subset of those link names actually plumbed by the zone with the exclusive stack? I assume the former but please verify that. In this respect, it seems that list -l is printing one of that several pieces of zone runtime state which we don't currently print through zoneadm(1M) or any other command. The zones team has discussed in the past introducing a more general zoneadm status or zoneadm info facility but that's not yet designed. Another alternative is to begin supporting a list -o format in zoneadm(1M) and allow the link names to be a supported type there. Finally, in the case where multiple net resources have been specified with an exclusive IP zone, are the link names separated by whitespace? Page 9, Section 11 - As I mentioned earlier, zonename(1) seems the wrong interface for obtaining this information. What about using /sbin/netstrategy and smf_netstrategy()? Page 9, Section 12 - There should be some discussion of the packaging changes somewhere in one or both of the documents. In the particular case of IP Filter, is the proposal to move all of the contents of SUNWipfr into a non-hollow package? Page 15, Section 14 - This is more of a code review question but are the additional privileges
[zones-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Erik, One additional comment I meant to include is that I think it would be useful to add a paragraph on what is possible today with the current stack in terms of sharing a link versus what will be possible with IP instances (using separate physical NICs or VLANs) versus what will be possible once VNIC support is introduced. Once VNICs are available, there will be a lot more flexibility but until then, the use of IP instances will be limited by the physical hardware or the use of VLANs. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
