[libvirt] [libvirt-users] NWFilter and IPv6

[Laine Stump]

(No extra content from me, but I'm setting Followup-To:
libvir-list at redhat.com 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
>
>