On Tue, Jul 07, 2009 at 11:56:04AM +0200, Erik Nordmark wrote: > >I agree that whitelist-in as of now is not too useful because we only > >support ipv4, v6, arp. but if in the future we expand whitelist support > >for more protocols (e.g. anything above ip), then there could be more > >potential use cases. > > But my point is that protecting the networks means limiting what can be > sent to the network; preventing receiving certain packets from the > network has nothing to do with protecting the network. > > I think we should constrain link protect just to the sending side. > Otherwise you are on a slippery slope towards reimplementing a full > packet filtering mechanism. >
ok. I agree with leaving out the inbound protection for now. but do you think it's ok to keep the outbound ACL named whitelist-out? this leaves room for supporting whitelist-in in the future in case people wants it. > >>Also, the whitelist name is a bit odd; it is really about allowed > >>Ethernet types, isn't it. (Has anybody looked at how it would be applied > >>to InfiniBand?) > >> > > > >yes this name is deliberately vague because as mentioned above I want > >to eventually filter more than just ether types to simplify > >administration, > >I felt that it's better to have the user specify a flat whitelist rather > >one whitelist per layer. this is also the reason this feature is called > >link protection rather than just l2 protection. > > Do you have specific examples of what higher level packets you want to > filter? > I was thinking of routing advertisments and DHCP replies. > Can you please clarify the relationship between this project and the L2 > filter project? The latter allows arbitrary packet filtering AFAIK. > Isn't link protection the more efficient, but less general, mechanism to > ensure that virtualization doesn't introduce new spoofing attacks > against the network? > yes, your summary is correct. link protection and l2 filter serve different needs. it's just that as of now link protection is enough to satisfy the majority of our customers' requirements so we're prioritizing this higher than l2 filter. > >>Do you have an idea what things might look like when we support DHCP? > >>The reason I'm asking is that if we need a completely different way to > >>specify the ipnospoof property then the proposed ipnospoof syntax might > >>be very short lived (I think we need DHCP support ASAP). > > > >to support dhcp, we would let the user add the 'dhcp' value to > >ipnospoof acl. we could also make it so that 'dhcp' is the default value > >in the ipnospoof acl. in this case (i.e. if the user only needs dhcp > >support), the user would only need to switch ipnospoof on without > >having to modify the acl. > > Would it also make sense to specify the allowed DHCP chaddr and/or > client-ID in the acl? > If a domU sends a DHCPv4 packet with somebody elses chaddr then the DHCP > server will send a reply with that somebody elses IP address, hence the > IP address would be stolen. Thus somehow you'd need to prevent the > client using the vnic from spoofing those parts of the DHCP packet. > we could possibly make macnospoof catch DHCP packets with spoofed chaddr. for client-ID, I am not so sure. usually it is the same as chaddr but for cases it is not we should not blindly drop the packet. do you know if the DHCP server could be told to look at both chaddr and client-ID when assigning an address? if that can be assumed then chaddr antispoof should be sufficient for preventing IP stealing. eric
