On 10/07/09 04:57 AM, Erik Nordmark wrote: > Darren Reed wrote: > > ... >> Except that that something simpler has a real risk of exploding out >> from being something simple to something complex if it continues to >> grow as a result of further RFEs (because people can do X with >> ipfilter or something else and want to do it with the layer 2 >> filtering in dladm too.) > > I agree we need to be very clear on the scope of the fixed anti-spoof > mechanisms in L2. > > That is why I think the general notion of acls is misplaced. We just > need three things AFAIK: > - verify the source MAC address > - only the normal set of three Ethernet types (I actually don't think > that list needs to be configurable - an on/off switch might make > sense) to prevent bad domUs from messing with Bridge PDUs or VLAN tags > themselves. > - prevent ARP/DHCP spoofing
I think this is the start of something that should have been presented in the original document and that is a discussion of what the threat model is and what we need to do to provide protection. At least in the original document, it wasn't clear why DHCP protection was required but the discussion has brought that into focus. Because there is more than one way in which DHCP can be deployed and used, it might be worthwhile going into some detail about the different uses of it. Separately, should we also be thinking about implementing support for 802.1x? For reference: http://en.wikipedia.org/wiki/IEEE_802.1X The challenge for us is that I'm not aware of any client support for 802.1X in Solaris, so Solaris domU's could be challenged if that path was taken. Are there other, dominant, host operating systems that people want to run in the cloud that do not support 802.1X? > BTW: Can IP Filter be used to prevent a client from spoofing the DHCP > client ID or chaddr? No and it would require a DHCP proxy for that. Darren
