Multicast Router Discovery
draft-ietf-idmr-igmp-mrdisc-10

[Ballot discuss]
The options defined in section 7 doesn't match the option format used
in RFC 2461. The draft has an option length measured in bytes while
RFC 2461 has:
Length 8-bit unsigned integer. The length of the option
      (including the type and length fields) in units of
            8 octets. The value 0 is invalid. Nodes MUST
            silently discard an ND packet that contains an
            option with length zero.

I don't understand my the IPv4 messages need to be sent
to all-hosts (224.0.0.1) when only the snooping switches want the
messages. Why not define a all-snoopers multicast address?


At a meta-level I also have a question about whether this and
magma-snoop-06 is sufficient to get the snooping switches under
control or whether we are likely to continue to inject clue and help
to those building snooping switches.

[Ballot discuss]
Two things, both pretty minor. The first is that the Introduction
and protocol overview deal pretty much entirely with the IGMP
mechanism described; the mechanism described in section
8 is pretty much left out of both. Fixing that would help scope
the document. Similarly, a reader may assume that IGMP
snooping will work in all multicast environments; note that
some vendors have PIM-snooping switches to deal with
environments like exchange points. An applicability statement
on those environments would be useful.

[Ballot discuss]
i am not impressed by

The following are justifications for inventing another router
      discovery protocol:
 
    ¡ Using ICMP router discovery is not an appropriate solution
        for multicast router discovery because: 1.) It may confuse
        hosts listening to ICMP router advertisements; unicast and
        multicast topologies may not be congruent. 2.) There is
        no way to tell from an ICMP router advertisement if a
        router is running a multicast routing protocol.

but an icmp-based protocol could work
       
      ¡ By making multicast router discovery messages extensible,
        future enhancements can be made.

completely bogus
       
      ¡ By inventing a generic IP layer message, multiple types of
        messages per link layer are not needed (i.e. including
        this functionality as part of IP is better than inventing
        N discovery protocols for N layer-2 technologies).

agree, but a new icmp could do it

what could be said is that, because this discovery mechanism uses
multicast, discovery problems will be congruent with payload problems,
which is cool.

but the following is just way to bogus, and is worth a discuss

9. Security Considerations
       
      The Multicast Router Advertisement message may allow rogue
machines to masquerade as multicast routers. This could allow
those machines to eavesdrop on multicast data transmission or
create a denial of service attack on multicast flows. However,
these new messages are extensible and that allows for the
introduction of security associations into the protocol. These
security extensions could be used to authenticate or encrypt
the messages.
------
further comment on this from ops-dir reviewer.

randy

---

- the document does not conform to editorial guidelines (use of
some '¡' instead of '-')

- I dislike IPv6 sections being only waved off in one section
even though the rest; also, the technical solution needs
justification, as it was stated that:

--8<--
The following are justifications for inventing another router
discovery protocol:
 
                ¡ Using ICMP router discovery is not an appropriate
    solution for multicast router discovery because:
          1.) It may confuse hosts listening to ICMP router
    advertisements; unicast and multicast topologies
    may not be congruent. 2.) There is no way to tell
    from an ICMP router advertisement if a router is
    running a multicast routing protocol.
[...]
--8<--

.. it appears to me that (ab)using NDP falls within this category
(at least sub-item 1).

- Also, this consumes 2 precious bits from IPv6 router advertisement
messages; if this is really the approach that seems best, at least
it needs a round of review in e.g. IPv6 w.g. or the like..

- as an operational/security aspect, security considerations lists the
possibility of rogue nodes masquarading as multicast routers to get
all data. This should be expanded a bit. The reason for this seems to
be that snooping switches would mark the incoming port of such
advertisements as "router port" and push all the multicast there.
Additionally, one might explicitly say something to the extent of
"Therefore, administratively disabling Multicast Router Advertisement
processing SHOULD be possible." (or MAY).

Subject: draft-ietf-idmr-igmp-mrdisc progress
Date: Fri, 11 Apr 2003 12:38:35 -0700
To: bkhabs@nc.rr.com

Reviewing the messages, it looks like they all made it into the ballot
( http://www.ietf.org/IESG/EVALUATIONS/draft-ietf-idmr-igmp-mrdisc.bal ).
Ted has withdrawn his DISCUSS, so those are not blocking comments, but
still worth mentioning.

Here's my summary; for details check the ballot:

- Security.  Actually, one comment that Steve had that didn't make it
  into the ballot: the document could mention that since the messages
  are sent to a group that the routers listen to, the routers can detect
  forged or conflicting messages so that alleviates some of the concerns -
  so mentioning that would be a great help.  Otherwise, I think following
  Russ's comments makes sense.

  (The TTL = 1 instead of = 255 thing was because there was never a
  real spec that defined the IPv4 link-local multicast groups so sending
  with TTL=255 was not guaranteed to stay on the link)

- v6 stuff.
  - Ted: abstract and intro shouldn't be v6-specific.
  - Erik: check router discovery option format.
  - ops-reviewer and Harald: has this been run by v6 wg?  (It's been so long
    that I don't remember the answer to that question)
  - ops-reviewer: justify why it's not OK to use ICMP and is OK to use ND

- why-not-ICMP stuff.  The real reason why not ICMP is that IGMP originally
  wanted to be part of ICMP, but Jon Postel didn't want to allow that
  (I don't know the exact reason, whether it was that he didn't want to
  allocate ICMP type codes or he was worried about the semantics of
  multicasted ICMP).  The rest kind of follows -- multicast uses IGMP,
  unicast uses ICMP.  That's not a real strong thing to put in a spec,
  but that history might be enough to address Randy's (or his reviewer's)
  concerns.

Other stuff: I talked with Erik about the 224.0.0.1 thing being because
it can supply info like SSM range to hosts; he kind of said "hmm" so I'm
not sure if that means he's OK with it or wants to talk more.

To move forward, I think you should update the draft with security
and v6 stuff and run it by the ADs who have put in comments.

I'm going to be out next week.  I'm sorry for not getting to this sooner
so that we could have more time to converge.

  Bill

To: cotton@icann.org
Subject: Re: draft-ietf-idmr-igmp-mrdisc-10.txt
Cc: iesg@ietf.org iana@iana.org
Fcc: +outgoing

Michelle,

This document needs a couple of *registrations* from igmp-type-numbers
(and I requested specific values; even though it's an IANA registry
this document dates from when I was the de facto IGMP registrar
and I had given out values to it -- so if it's not too out of proper
could you assign 0x24 for Multicast Router Advertisement Message,
0x25 for Multicast Router Solicitation Message, 0x26 for Multicast
Router Termination Message?)

It needs a new registry, for IPv4 Multicast Router Discovery
message options.  The document registers 1 and 2 (Query Interval
Advertisement and Robustness Variable Advertisement) and requests
that the space be allocated using IESG Approval or Standards
Action.  This space is 0-255, presumably with 0 and 255 reserved.

It requests two Neighbor Discovery Option Types (this is the
subheading "IPv6 NEIGHBOR DISCOVERY OPTION FORMATS" in
http://www.iana.org/assignments/icmpv6-parameters) be assigned
for the Query Interval Advertisement and Robustness Variable
Advertisement in IPv6.

Finally, it requests a new IANA registry for the Multicast Router
Discovery Code Values.  This would probably actually belong in
http://www.iana.org/assignments/igmp-type-numbers -- e.g.
type 0x11, 0x13 and 0x14 have codes registered, so that
seems to make sense; so this fourth request is probably just
estabilshing the policy for such allocations.

  Bill

Don't forget to ask IANA for assignments from draft -05
(0x24 for Multicast Router Advertisement Message, 0x25 for Multicast Router Solicitation Message, 0x26 for Multicast Router Termination Message)

State Changes to New Version Needed (WG/Author)                    from AD Evaluation                                    by fenner

State Changes to AD Evaluation                                    from Token@wg or Author                                by IESG Member