On Wed, 2009-07-08 at 21:41 -0500, Steven Stallion wrote: > Eric Cheng wrote: > > On Tue, Jul 07, 2009 at 06:19:08PM -0500, Steven Stallion wrote: > >> General comments: > >> > >> Why must ACL's be managed by dladm? Shouldn't this be handled by the > >> somewhat newly proposed ipadm? It seems to me that the gist of this > >> proposal is intended for network layer filtering (not link layer). > >> > > > > actually, this is intended for the link layer. we support > > IP antispoof too because implementation-wise it does not take much > > more work. > > All I see in the proposal that relates to the data link layer is the mac > spoofing bits.
This relates to the data-link layer because VMs hook in at that layer; not at the IP layer. Packets transmitted by VMs arrive directly at the link-layer. > My main worry here is dladm is being used for something that really has > very little to do with the link layer (this is a higher-level concern > which should be addressed somewhere higher in the stack). The packets being processed by these ACLs are not processed higher in the stack at all. They go directly from the link-layer to a VM, or from a VM to the link-layer. > >> It does not make sense to me to define an ethernet address filter on > >> something which is normally controlled higher up the stack. Why are you > >> suggesting that we protect outselves from... ourselves? If this is a case > >> of not allowing the user to re-program the default ethernet address for a > >> given PHY, then this should be controlled elsewhere (perhaps by ifconfig?). > >> Perhaps I misunderstood the need for this? > >> > > > > the common use case is when you host multiple VMs on your machine and > > you want to control what can be sent out of your VMs. you could have > > multiple customers each owning their VMs and you don't want to them > > to damage each other or your network. > > Perhaps I am a little confused, but how do you envision a user land > application spoofing an ethernet address when sending a packet? Besides guest VM transmitting garbage, any DLPI client that has enabled DLIOCRAW can formulate its own Ethernet frame with any combination of random 14 bytes, followed by any random sequence of bits it wishes, including an IP header that has nothing to do with the local IP stack. > > to switch on the protection, you do set-linkprop from the control > > domain (dom0/global zone). both the protection linkprop and associated > > ACLs are not accessible from within your customers' VMs so they are not > > able to bypass your policies. > > > > regarding why this isn't managed though ipadm, the reason is packets > > coming out of VMs go directly to the wire, they don't go through the > > control domain's network stack at all. this is why we need to intercept > > at the lowest level. > > This sounds like an xvm issue, not a data link issue. Currently, > linkprops are exactly that - datalink properties. This seems like more of a philosophical issue. Personally, I have no problem with centralizing this feature in the OS where OpenSolaris can have additional value-add. Duplicating a feature like this within each VM technology that runs on OpenSolaris doesn't seem scalable. -Seb
