Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
draft-ietf-magma-snoop-12

Steve Bellovin sent the following comments:

From: Steve Bellovin
To: mjc@tt.dk.karen.kimball@hp.com, solenskyf@acm.org
Subject: security considerations for draft-ietf-magma-snoop
cc: iesg@ietf.org
Date: Tue, 02 Sep 2003 15:53:40 -0400

The Security Considerations section for this document essentially
refers the readers to the security considerations sections of the
protocol definition documents.  It isn't clear to me that that's
adequate.  In particular, Section 9.2 of RFC 3376 says

  Forged
  Report messages from the local network are meaningless, since joining
  a group on a host is generally an unprivileged operation, so a local
  user may trivially gain the same result without forging any messages.

With snooping switches, that's no longer true -- the router is looking
at the IP address, but the switch is looking at the port.  Furthermore
(and this is based on a quick scan of 3376) 9.1 speaks of semantics
associated with the numeric value of the IP address; again, there's
a disconnect between address-based behavior and port-based behavior.

Does this sort of thing warrant additional text in this draft?

Hi All,

Sorry to arrive so late with comments and questions on this document,
but this is the first time I've read it.  In general, it looks pretty
good, and I think that the idea of defining IGMP snooping functionality
is quite valuable.

I have attached my comments and questions below.

Margaret

----

This document should have a table of contents.

In the Abstract:
>    IGMP are not the focus of this document.  Interested readers are
>    directed to [IGMPv3] for a thorough description of problem areas.

Abstracts should not include references.  I would remove this sentence
from the abstract and include it as part of the Introduction.

>1.  Introduction
>
>    When processing a packet whose destination MAC address is a
>    multicast address, the switch will forward a copy of the packet
>    into each of the remaining network interfaces that are in the
>    forwarding state in accordance with [BRIDGE].

This is an odd way to start a document.  You might consider including
some of the text from the abstract here, and offer some information
about what type of switch you are discussing (an L2 switch, I think?).
It also might be better to start with a very brief definition of
IGMP/MLD snooping.

>    Note that the IGMP snooping function should apply only to IPv4
>    multicasts.  Other multicast packets, such as IPv6, might be
>    suppressed by IGMP snooping if additional care is not taken in the
>    implementation. 

Would it make sense to describe what type of care needs to be taken?
Or is that care the subject of later sections?

>        The switch supporting IGMP snooping must maintain a list of
>        multicast routers and the ports on which they are attached.
>        This list can be constructed in any combination of the
>        following ways:

It might be clearer to include this requirement before the statement
that switches should only forward IGMP traffic to ports that have an
IGMP router attached.

I find the following section confusing:

>    3)  If a switch receives a non-IGMP IPv4 multicast packet without
>        having first processed Membership Reports for the group
>        address, it may forward the packet on all ports but it must
>        forward the packet on router ports.  A switch may forward an
>        unregistered packet only on router ports, but the switch must
>        have a configuration option that suppresses this restrictive
>        operation and forces flooding of unregistered packets on
>        selected ports.

The above paragraph could be worded much more clearly.  For example,
I assume that an "unregistered packet" is a packet that is addressed
to a group for which a Membership Report has not been received? 
Also it would be good to remove some of the more twisted logic. 
How about:

- Define the term "unregistered packet" in a terminology
        section.

3) If a switch receives an unregistered packet, it must forward
        that packet on all ports to which an IGMP routers is attached.
        A switch may default to forwarding unregistered packets on all
        ports.  Switches that default to forwarding unregistered packets
        on a restricted set of ports must include a configuration option
        to force the flooding of unregistered packets on selected ports.

>        In an environment where IGMPv3 hosts are mixed with snooping
>        switches that do not yet support IGMPv3, the switch's failure
>        to flood unregistered streams could prevent v3 hosts from
>        receiving their traffic. 

Explain why/how?

>    MLD messages are also not sent to packets in the address range
>    FF00::/15 (which encompasses both the reserved FF00::/16 and node-
>    local FF01::/16 IPv6 address spaces).  These addresses should never
>    appear in packets on the link.

s/sent to packets/sent to addresses/  ??

>    The IPv6 packet header does not include a checksum field.
>    Nevertheless, the switch should detect other packet integrity
>    issues.

What other packet integrity issues?  Layer 2 indications? 

>    6.  Security Considerations
>
>          Security considerations for IGMPv3 are accounted for in
>          [IGMPv3].  The introduction of IGMP snooping switches adds the
>          following considerations with regard to IP multicast.
>
>          -  The exclude source failure, which could cause traffic from
>              sources that are 'black listed' to reach hosts that have
>              requested otherwise.  This can also occur in certain
>              network topologies without IGMP snooping.

What is the "exclude source failure", and how does this affect the
security of the network?  Does this permit some type of DOS attack?

>          -  It is possible to generate packets which make the switch
>              wrongly believe that there is a multicast router on the
>              segment on which the source is attached.  This will
>              potentially lead to excessive flooding on that segment.
>              The authentication methods discussed in [IGMPv3] will also
>              provide protection in this case.
>
>          -  IGMP snooping switches which rely on the IP header of a
>              packet for their operation and which do not validate the
>              header checksum potentially will forward packets on the
>              wrong ports.  Even though the IP headers are protected by
>              the Ethernet checksum this is a potential vulnerability.

Earlier text indicates that switches that rely on IP header fields
should check the checksum.  So, this shouldn't happen in v4, right?
But, this could be a concern in IPv6?

Also, do you assume that all snooping switches will be on Ethernet?
If not, you might change this the "layer 2 integrity check" or
something generic like that.

>          -  In IGMP, there is no mechanism for denying recipients
>              access to groups (i.e. no "exclude receiver"
>              functionality).  Hence, apart from IP-level security
>              configuration outside the scope of IGMP, any multicast
>              stream may be received by any host without restriction.

Is this an issue with IGMP snooping, or with IGMP in general.

>          Generally, IGMP snooping must be considered insecure due to
>          the issues above. However, none of the these issues are any
>          worse for IGMP snooping than for IGMP implementations in
>          general.

This security considerations section doesn't mention IPv6/MLD at all.
Do all of the same issues apply?  Are there any differences or
additional issues?