lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 3 Aug 2012 09:00:26 -0400 From: David Stevens <dlstevens@...ibm.com> To: Dragos Ilie <dragos.ilie@...il.com> Cc: netdev@...r.kernel.org, netdev-owner@...r.kernel.org Subject: Re: Premature timeout for MLDv1 Host compatibility mode? Dragos Ilie <dragos.ilie@...il.com> wrote on 08/03/2012 04:54:09 AM: > a) Section 5.1.9 states that the QQIC field is meant for other > multicast routers that are not the current querier. I "grep-ed" after > mld2q_qqic in the entire kernel source tree and it is not being used > at all. I take this as a sign that the field is not to be interpreted > by listeners. Of course, that does not mean we cannot use it, but see > b) below The kernel doesn't use it because it doesn't use the QI in the timer to switch back to MLDv2 -- the problem you're trying to address. If you think that's a bug (and I agree it is), the QQIC is how we determine the QI. Missing functionality isn't evidence we shouldn't use the QQIC. :-) > b) Section 8.3.1 says that "if an MLDv1 router is present on the link, > the Querier MUST use the lowest version of MLD present on the > network". Also, "if an MLDv1 router is present on the link, the system > administrator must explicitly configure all MLDv2 routers to act in > MLDv1 mode". It seems to me that these statements together preclude a > scenario with MLDv1 and MLDv2 routers mixed together on the same link, > unless all routers speak MLDv1. MLDv2 requires MLDv1 compatibility mode so there's no such thing as an MLDv2 implementation that doesn't support MLDv1. The mechanism for falling back to MLDv1 is required for exactly the case when there is a mix of versions on the link; if that could never happen, none of this code would be necessary or required by RFC. > The current implementation for MLDv1 compatibility mode works very > badly. The listeners fail most of the time to join the groups on the > MLDv1 server. I'm not sure what you mean here. Certainly you can, as suggested above, force all hosts on the subnet to use MLDv1 using the "force_mld_version" sysctl and an MLDv1 querier will also do that. They'll switch back to MLDv2 too soon, if the v1 queries happen infrequently which you can trivially work around by querying more often. >I suggest that my patch sent earlier this week is > pushed upstream, unless there are concerns that it will make things > worse than they are today. This will improve the behavior of MLDv2 > listeners with MLDv1 routers and keep us compliant with the RFC. What > do you think? I think it should be correct, and a fixed QI isn't. If we're going to do a hack, I think a v2-based QI is better than a fixed value. However, I was thinking we could directly measure the v1 QI based on received v1 queries. The main problem with that is you don't know if you lost one or not, but we could work around that by using the min of a saved QI and the measured interval since the last query from the same source. The measured QI with losses is always a multiple of the actual QI. So, when we get a v1 query, save a timestamp of it and use the timestamp, if set, to compute the interval since the last query. If the interval is less than our current QI, it's the new QI. For the switchback time, we use QI if set and 125 if not, where not being set would indicate we haven't gotten more than 2 v1 queries. Finally, periodically (e.g., based on query counts, or multiple larger QIs) reset in case an admin has increased the QI without a reboot. The QI value only matters if it's the same querier, so also with the timestamp save the source querier IP address and reset if you get a general query from a different querier. +-DLS -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists