Re: Question about IGMP host implementation

This is a multi-part message in MIME format.
--===============6822980039833842354==
Content-Type: multipart/alternative;
 boundary="------------020507060806080000000703"

This is a multi-part message in MIME format.
--------------020507060806080000000703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

Obviously there is no legitimate case where a query would come from=20
another subnet.
The question is how to avoiding such queries from being processed...

IGMPv3 specs talks a bit about this aspect ;  RFC3376, section 9.1,=20
Security Considerations, Query message:

  There are three measures necessary to defend against externally forged =
Queries:

    o Routers SHOULD NOT forward Queries.  This is easier for a router to
      accomplish if the Query carries the Router-Alert option.

    o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert
      option.

    o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a
      multicast address other than 224.0.0.1, the all-systems address.

If a host enforces these rules, AFAICT there is no case were it would=20
process a Query from another subnet.
Even though RFC2236 is silent on this aspect, an RFC3376 host=20
implementation in IGMPv2 compatibility mode would be expected to apply=20
these checks.

On the other hand, RFC3376 also says, in 4.1.12. IP Destination=20
Addresses for Queries:

    In IGMPv3, General Queries are sent with an IP destination address of
    224.0.0.1, the all-systems multicast address.  Group-Specific and
    Group-and-Source-Specific Queries are sent with an IP destination
    address equal to the  multicast address of interest.  *However*, a
    system MUST accept and  process any Query whose IP Destination Addres=
s
           ^^^^^^^^^^^^^^^
    field contains *any* of the addresses (unicast or multicast)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^
    assigned to the interface on which the Query arrives.


This rule contradicts the third rule above (which would in itself=20
deserve a discussion), but the two first rules are possibly enough: if=20
an attacker forges a Query, under the assumption that at least one=20
Router on the path to the victim supports the Router Alert option and=20
implements IGMP and enforces the first of the three rules above, if=20
hosts apply the second rule, then no forged packet will be processed by=20
hosts...  The issue is that it may not be reasonable to count on all=20
this to be true (eg. there are IGMP Querier implementations in the wild=20
that do not set the RA option in Query messages...).

The most reasonable thing to do, as suggested below, is to drop Queries=20
whose source address is from another subnet.

A nicer solution would be to apply GTSM (RFC5082) to IGMP, but=20
transitioning to it is absolutely not trivial.

-Thomas



Bharat Joshi a =E9crit :
> Kunal,
>
>          What I am suggesting is that though RFC does not explicitly su=
ggest it, it might be better to do this for broadcast interfaces.
>
>          But yes, RFC does not suggest anything on this so a host can p=
rocess a query message with a source address from any other subnet as wel=
l.
>
> Regards,
> Bharat
> ________________________________________
> From: Kunal Shah [[email protected]]
> Sent: Wednesday, October 12, 2011 9:17 PM
> To: Bharat Joshi;[email protected]
> Subject: RE: Question about IGMP host implementation
>
> Hi Bharat,
>
> The security consideration addresses the processing of a report from a =
different subnet on the router. My question pertains to the processing of=
 a Query from a different subnet on the host.
>
> Kunal
>
> -----Original Message-----
> From: Bharat Joshi [mailto:[email protected]]
> Sent: Wednesday, October 12, 2011 4:20 AM
> To: Kunal Shah;[email protected]
> Subject: RE: Question about IGMP host implementation
>
> Hi Kunal,
>
>          I think to keep the security tight, it is better to not respon=
d to queries received from a source address which does not fall on a subn=
et on that interface. Please note that this should be done only broadcast=
 interfaces. It may not work on point-to-point links.
>
>          If you look at the security consideration in RFC 2236, it is m=
entioned that for reports, the above check should be done.
>
> Regards,
> Bharat
> ________________________________________
> From:[email protected]  [[email protected]] On Behalf Of Kuna=
l Shah [[email protected]]
> Sent: Wednesday, October 12, 2011 6:08 AM
> To:[email protected]
> Subject: [magma] Question about IGMP host implementation
>
> Hi all,
>
> Can an IGMPv2 host respond to a general query originated from a subnet =
other then its own?? RFC 2236 states:
>
> ""query received" occurs when the host receives either a valid
>       General Membership Query message, or a valid Group-Specific
>       Membership Query message.  To be valid, the Query message must be
>       at least 8 octets long, and have a correct IGMP checksum.  The
>       group address in the IGMP header must either be zero (a General
>       Query) or a valid multicast group address (a Group-Specific Query=
)"
>
> There is no requirement for the source address to be on the same subnet=
 as the host.
>
> Thanks,
> Kunal
>
>
> **************** CAUTION - Disclaimer ***************** This e-mail con=
tains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use=
 of the addressee(s). If you are not the intended recipient, please notif=
y the sender by e-mail and delete the original message. Further, you are =
not to copy, disclose, or distribute this e-mail or its contents to any o=
ther person and any such actions are unlawful. This e-mail may contain vi=
ruses. Infosys has taken every reasonable precaution to minimize this ris=
k, but is not liable for any damage you may sustain as a result of any vi=
rus in this e-mail. You should carry out your own virus checks before ope=
ning the e-mail or attachment. Infosys reserves the right to monitor and =
review the content of all messages sent to or from this e-mail address. M=
essages sent to or from this e-mail address may be stored on the Infosys =
e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> _______________________________________________
> magma mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/magma



--------------020507060806080000000703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    Obviously there is no legitimate case where a query would come from
    another subnet.<br>
    The question is how to avoiding such queries from being processed...<br>
    <br>
    IGMPv3 specs talks a bit about this aspect ;&nbsp; RFC3376, section 9.1,
    Security Considerations, Query message:
    <br>
    <pre class="newpage"> There are three measures necessary to defend against externally forged Queries:

   o Routers SHOULD NOT forward Queries.  This is easier for a router to
     accomplish if the Query carries the Router-Alert option.

   o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert
     option.

   o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a
     multicast address other than 224.0.0.1, the all-systems address.
</pre>
    If a host enforces these rules, AFAICT there is no case were it
    would process a Query from another subnet.<br>
    Even though RFC2236 is silent on this aspect, an RFC3376 host
    implementation in IGMPv2 compatibility mode would be expected to
    apply these checks.<br>
    <br>
    On the other hand, RFC3376 also says, in <a name="section-4.1.12">4.1.12</a>.
    IP Destination Addresses for Queries<span class="h4"></span>:<br>
    <pre class="newpage">   In IGMPv3, General Queries are sent with an IP destination address of
   224.0.0.1, the all-systems multicast address.  Group-Specific and
   Group-and-Source-Specific Queries are sent with an IP destination
   address equal to the  multicast address of interest.  *However*, a
   system MUST accept and  process any Query whose IP Destination Address
          ^^^^^^^^^^^^^^^
  &nbsp;field contains *any* of the addresses (unicast or multicast)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^                  
  &nbsp;assigned to the interface on which the Query arrives.
</pre>
    <br>
    This rule contradicts the third rule above (which would in itself
    deserve a discussion), but the two first rules are possibly enough:
    if an attacker forges a Query, under the assumption that at least
    one Router on the path to the victim supports the Router Alert
    option and implements IGMP and enforces the first of the three rules
    above, if hosts apply the second rule, then no forged packet will be
    processed by hosts...&nbsp; The issue is that it may not be reasonable to
    count on all this to be true (eg. there are IGMP Querier
    implementations in the wild that do not set the RA option in Query
    messages...).<br>
    <br>
    The most reasonable thing to do, as suggested below, is to drop
    Queries whose source address is from another subnet.<br>
    <br>
    A nicer solution would be to apply GTSM (RFC5082) to IGMP, but
    transitioning to it is absolutely not trivial.<br>
    <br>
    -Thomas<br>
    <br>
    <br>
    <br>
    Bharat Joshi a &eacute;crit&nbsp;:
    <blockquote
cite="mid:31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com"
      type="cite">
      <pre wrap="">Kunal,

        What I am suggesting is that though RFC does not explicitly suggest it, it might be better to do this for broadcast interfaces.

        But yes, RFC does not suggest anything on this so a host can process a query message with a source address from any other subnet as well.

Regards,
Bharat
________________________________________
From: Kunal Shah [<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>]
Sent: Wednesday, October 12, 2011 9:17 PM
To: Bharat Joshi; <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
Subject: RE: Question about IGMP host implementation

Hi Bharat,

The security consideration addresses the processing of a report from a different subnet on the router. My question pertains to the processing of a Query from a different subnet on the host.

Kunal

-----Original Message-----
From: Bharat Joshi [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>]
Sent: Wednesday, October 12, 2011 4:20 AM
To: Kunal Shah; <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
Subject: RE: Question about IGMP host implementation

Hi Kunal,

        I think to keep the security tight, it is better to not respond to queries received from a source address which does not fall on a subnet on that interface. Please note that this should be done only broadcast interfaces. It may not work on point-to-point links.

        If you look at the security consideration in RFC 2236, it is mentioned that for reports, the above check should be done.

Regards,
Bharat
________________________________________
From: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>] On Behalf Of Kunal Shah [<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>]
Sent: Wednesday, October 12, 2011 6:08 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
Subject: [magma] Question about IGMP host implementation

Hi all,

Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states:

""query received" occurs when the host receives either a valid
     General Membership Query message, or a valid Group-Specific
     Membership Query message.  To be valid, the Query message must be
     at least 8 octets long, and have a correct IGMP checksum.  The
     group address in the IGMP header must either be zero (a General
     Query) or a valid multicast group address (a Group-Specific Query)"

There is no requirement for the source address to be on the same subnet as the host.

Thanks,
Kunal


**************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. 
 Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
magma mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/magma">https://www.ietf.org/mailman/listinfo/magma</a>
</pre>
    </blockquote>
    <br>
    <br>
  </body>
</html>

--------------020507060806080000000703--

--===============6822980039833842354==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
magma mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/magma

--===============6822980039833842354==--