(No extra content from me, but I'm setting Followup-To: libvir-list@xxxxxxxxxx for this (and setting To: to the same), since this is talking about new development, so we want to make sure as many developers as possible see it...) On 12/05/2012 09:23 AM, Guido Winkelmann wrote: > Am Dienstag, 4. Dezember 2012, 19:18:01 schrieb Stefan Berger: >> On 12/04/2012 09:39 AM, Guido Winkelmann wrote: >>> Am Montag, 26. November 2012, 12:24:11 schrieb Stefan Berger: >>>> On 11/26/2012 10:41 AM, Laine Stump wrote: > [...] >>>> One problem I want to mention, though: A bigger problem would be if a >>>> machine wanted to use IPv4 and IPv6 (dual stack) and use DHCP for both , >>>> which in effect would result in two variables that need to have values >>>> detected which in turn would require partial instantiation of filters >>>> (since one variable may not have a value assigned while the other has), >>>> which does not currently work... >>> Hm, how do you even do it with one variable? Do you leave the firewall >>> undefined until you could detect the dhcp-answer package and then pull it >>> up? >> We assume that DHCP is being used and for example put a filter in that >> only allows DHCP traffic to pass and once we grab the IP address we >> instantiate the user-provided filter. For that we use $IP. The variable >> is set once the IP address has been detected. For IPv6 we should >> probably use $IPV6 (reserved variable). > How do you control this behavior? Can you just set the $IP to a value in the > filterref instantiation to disable it? Like so: > > <filterref filter='clean-traffic-with-v6'>" > <parameter name='MAC' value='11:11:11:11:11:11'/>"; > <parameter name='IP' value='192.168.0.10'/>"; > <parameter name='IP' value='192.168.0.11'/>"; > </filterref>" > > Anyway, I think combining DHCP and DHCPv6 is going to be a minor problem in > practice, because most people will probably use stateless autoconfiguration to > set the IPv6 address on a device and use DHCPv6 only for additional > information, like DNS servers or NTP servers. > > How about this approach instead for combining DHCP and DHCPv6: > > - Instead of putting up a special network filter for the detection phase, we > put up the actual user-requested filter, but with $IP and $IPV6 unset. (except > of course when these variables are specifically set by the user as above...) > - The default-shipped filters like clean-traffic should let DHCP(v6) through > in this configuration. If the user-requested filters don't, that's just a > configuration error. > - As soon as we detect an incoming DHCP or DHCPv6 packet for the guest, we add > that address to the filter parameters, reinitialize the filter with the new > parameters and stop detecting addresses for this particular L3 protocol. > >>>> Also as I recall for IPv4 the ARP-equivalent is NDP (Neighbor Discovery >>>> Protocol based on ICMPv6), which may need support in ebtables. At least >>>> a while ago there was no support for filtering that NDP subset of ICMPv6 >>>> in ebtables. >>> According to the ebtables man-page, you've got --ip6-icmp-type, which >>> should be enough for this. Router advertisements have ICMPv6 type 134 and >>> multicast router advertisements are 153. AFAICT, you can just filter by >>> those... >> I am not the expert on IPv6, but from reading on this page here >> >> http://www.tcpipguide.com/free/t_ICMPv6NeighborAdvertisementandNeighborSolic >> itation-2.htm > BTW, I wouldn't recommend this particular guide. Not only is it cluttered with > advertisements to the point of a major annoyance, there's at least one part > where it has simply plain wrong information: On > > http://www.tcpipguide.com/free/t_IPv6InterfaceIdentifiersandPhysicalAddressMapping-2.htm > > Bit 7 of the EUI-64 address needs to be flipped, not just set to 1. (It took > me a while to figure out why my code would arrvive at different autoconfigured > addresses than the linux kernel for virtualized machines...) > >> I get the impression that for example the target address should be >> verified for possible 'abuse'. > That's only for neighbor advertisements. Router advertisements can simply be > blocked wholesale. Normal network nodes have no business sending those under > any circumstances, and your actual routers are hopefully trusted enough to not > need their router advertisements checked for sanity... > > Then again, for neighbor advertisements, you're right. I was under the > impression that, for those, it was enough to check the source address in the > ipv6 header. Apparently I was wrong. > >> I don't think one can grab that field >> with ebtables and compare against allowed values. > No, but ip6tables has --u32, which possibly could be abused for that... > > Guido > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list