netdev - Re: MLD maturity in kernel version 2.6.32.60

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <528DDD64.3020601@redhat.com>
Date:	Thu, 21 Nov 2013 11:16:04 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
CC:	netdev@...r.kernel.org, Simon Schneider <simon-schneider@....net>
Subject: Re: MLD maturity in kernel version 2.6.32.60

On 11/21/2013 05:04 AM, Hannes Frederic Sowa wrote:
> On Tue, Nov 19, 2013 at 01:12:36AM +0100, Daniel Borkmann wrote:
>> There's also still one issue which I am hesitant to implement, as i) I don't
>> think it's overly useful, ii) nobody complained so far. :-)
>>
>> In RFC2710 (MLD v1 spec), it says:
>>
>> 3.7. Other fields
>>
>>     The length of a received MLD message is computed by taking the IPv6
>>     Payload Length value and subtracting the length of any IPv6 extension
>>     headers present between the IPv6 header and the MLD message.  If that
>>     length is greater than 24 octets, that indicates that there are other
>>     fields present beyond the fields described above, perhaps belonging
>>     to a future backwards-compatible version of MLD.  An implementation
>>     of the version of MLD specified in this document MUST NOT send an MLD
>>     message longer than 24 octets and MUST ignore anything past the first
>>     24 octets of a received MLD message.  In all cases, the MLD checksum
>>     MUST be computed over the entire MLD message, not just the first 24
>>     octets.
>>
>> Then, RFC3810 which "updates" RFC2710 obviously has a bigger message length
>> than that. In igmp6_event_query(), we only check for len == MLD_V1_QUERY_LEN
>> and process MLD v1. Now, in case of MLD v1-only fallback, we MUST only
>> operate in v1 mode.
>>
>> Now, in case a v2 message comes in we could assume above statement "if
>> that length is greater than 24 octets, that indicates that there are other
>> fields present beyond the fields described above, perhaps belonging to a
>> future backwards-compatible version of MLD".
>>
>> But then on the other hand, we get completely wrong "Maximum Response Delay"
>> codes in the packet header as they are differently encoded in MLD v1 and MLD
>> v2 thus not really backwards compatible.
>
> Daniel, let's add something where we can easier export the per-interface
> mld status for net-next inclusive the timers either via netlink or procfs.
>
> I guess we cannot change /proc/net/igmp6 because of backward compatibility
> so I favor to add this via Nicolas netconf api.

Yes, sure sounds good to me. We can do that.
--
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