8:38 a.m.
(No extra content from me, but I'm setting Followup-To:
libvir-list(a)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_IPv6InterfaceIdentifiersandPhysicalAddre...
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