netdev - Re: [PATCH - resubmit] igmp: Make igmp group member RFC 3376 compliant

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] [day] [month] [year] [list]

Date:   Mon, 02 Jan 2017 13:01:36 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     mtesar@...hat.com
Cc:     haliu@...hat.com, kuznet@....inr.ac.ru, jmorris@...ei.org,
        kaber@...sh.net, netdev@...r.kernel.org
Subject: Re: [PATCH - resubmit] igmp: Make igmp group member RFC 3376
 compliant

From: Michal Tesar <mtesar@...hat.com>
Date: Mon, 2 Jan 2017 14:38:36 +0100

> 5.2. Action on Reception of a Query
> 
>  When a system receives a Query, it does not respond immediately.
>  Instead, it delays its response by a random amount of time, bounded
>  by the Max Resp Time value derived from the Max Resp Code in the
>  received Query message.  A system may receive a variety of Queries on
>  different interfaces and of different kinds (e.g., General Queries,
>  Group-Specific Queries, and Group-and-Source-Specific Queries), each
>  of which may require its own delayed response.
> 
>  Before scheduling a response to a Query, the system must first
>  consider previously scheduled pending responses and in many cases
>  schedule a combined response.  Therefore, the system must be able to
>  maintain the following state:
> 
>  o A timer per interface for scheduling responses to General Queries.
> 
>  o A per-group and interface timer for scheduling responses to Group-
>    Specific and Group-and-Source-Specific Queries.
> 
>  o A per-group and interface list of sources to be reported in the
>    response to a Group-and-Source-Specific Query.
> 
>  When a new Query with the Router-Alert option arrives on an
>  interface, provided the system has state to report, a delay for a
>  response is randomly selected in the range (0, [Max Resp Time]) where
>  Max Resp Time is derived from Max Resp Code in the received Query
>  message.  The following rules are then used to determine if a Report
>  needs to be scheduled and the type of Report to schedule.  The rules
>  are considered in order and only the first matching rule is applied.
> 
>  1. If there is a pending response to a previous General Query
>     scheduled sooner than the selected delay, no additional response
>     needs to be scheduled.
> 
>  2. If the received Query is a General Query, the interface timer is
>     used to schedule a response to the General Query after the
>     selected delay.  Any previously pending response to a General
>     Query is canceled.
> --8<--
> 
> Currently the timer is rearmed with new random expiration time for
> every incoming query regardless of possibly already pending report.
> Which is not aligned with the above RFE.
> It also might happen that higher rate of incoming queries can
> postpone the report after the expiration time of the first query
> causing group membership loss.
> 
> Now the per interface general query timer is rearmed only
> when there is no pending report already scheduled on that interface or
> the newly selected expiration time is before the already pending
> scheduled report.
> 
> Signed-off-by: Michal Tesar <mtesar@...hat.com>

Applied and queued up for -stable, thanks.