[libvirt-users] NWFilter and IPv6

[Guido Winkelmann]

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