Subject: Re: [magma] MRDISC last call comments

From: Brian Haberman <[email-masked]>
Date: Thu, 02 Sep 2004 09:54:04 -0400

Pekka,
      Thanks for the comments.  Responses are in-line...

On Aug 25, 2004, at 6:20, Pekka Savola wrote:

>
> Find below WG last call comments.  Sorry if some of these were
> discussed at IETF60; I had a conflicting session and there are no
> minutes yet.
>
> New or edited comments:
>
> 1) [editorial issue] It would be clearer to have IANA considerations
> in a presentation format like:
>
> IGMP Type        Section         Message Name
> X1               3.1             Multicast Router Advertisement
> Y1               4.1             Multicast Router Discovery
> Z1               5.1             Multicast Router Termination
>
> ICMPv6 Type      Section         Message Name
> X2               3.1             Multicast Router Advertisement
> Y2               4.1             Multicast Router Discovery
> Z2               5.1             Multicast Router Termination

Done.  This is a useful way of presenting IANA actions.

>
> 2) [semi-substantial issue] Security Considerations described MRT
> messages causing problems, and -01 removed an inaccurate sentence --
> however it still did not spell out the actual threat.
>
> To address this, I'd reword:
>
>     This issue stems from the fact that there is currently no mechanism
>     for hosts to authenticate and authorize messages being sent from
>     local routers. This problem is shared by all IGMP and ICMPv6
>     messages, as well as other protocols such as IPv6 Neighbor
>     Discovery.
>
> I'd say:
>
>     This issue stems from the fact that there is currently no mechanism
>     for hosts to authenticate and authorize messages being sent from
>     local routers; even the source address is not checked. This
>     problem is shared by all IGMP and ICMPv6
>     messages, as well as other protocols such as IPv6 Neighbor
>     Discovery.
>
> (or something like that, to clearly state that even spoofing in the
> local network is not necessary.)

Changed to "... and authorize messages being sent from local routers 
(e.g. source
addresses are not checked)."

>
> 3) [editorial] the last paragraph of section 1 includes unnecessary
> text.  There are not *'s in the text, nor square brackets used in that
> meaning.  So, just end the paragraph to the reference to RFC2119.

Removed.

>
> 4) [editorial] "MAX SOLICITATION_DELAY" is missing "_" after MAX in a
> couple of places.

Fixed.

>
> 5) [semi-substantial] The security consideration says:
>
>     [about SEND]                                           Should this
>     work prove successful, appropriate mechanisms will be incorporated
>     into a later extension to MRD.
>
> We can't really say much what *will* be done, so I'd suggest
> s/will/may/ ?

Changed.

>
>
> Some comments from the older email, those which I didn't see
> addressed:
>
> substantial
> -----------
>
>                        Multicast Router Discovery
>
> ==> I'd consider rewording this to "Link-local Multicast Router 
> Discovery"
> (LLMRD) or something like that, to better reinforce the applicability 
> from
> the start.  If done, this would have to be rippled through to the rest 
> of
> the document.
>
> [note: I think this would be a rather useful clarification, so folks
> won't think this would be of more general applicability than just on
> the local link]

I don't see much benefit in changing the name.  With destination 
addresses that
are link-local in scope, it is clear what the reach of the protocol is.

>
>    Solicitations are sent to the All-Routers multicast address and
>    SHOULD be rate-limited.
>
> ==> solicitations are sent only when MRD is enabled, or the interface
> is re-initialized.  It should be obvious as these don't happen all too
> often.  Therefore, I think we could remove this completely, but this
> is not a hot issue for me.

Unless someone else complains, I am going to leave this in.

>
> editorial
> ---------
>
>    Multicast Router Discovery messages are useful for determining which
>    nodes attached to a switch have multicast routing enabled.  This
>    capability is useful in a layer-2 bridging domain with snooping
>    switches.  By listening to MRD messages, layer-2 switches can
>    determine where to send multicast source data and group membership
>    messages [RFC1112][RFC2236].
>
> ==> yes, the switches need to "listen" to MRD messages as well, but 
> they can
> also send them -- maybe reword: s|listening|listening and/or sending| ?
>

Changed to "By utilizing MRD messages, layer-2..."

Regards,
Brian

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Sep 2004 21:39:11 +0300 (EEST)

>       Thanks for the comments.  Responses are in-line...

Thanks Brian -- looks sufficiently good.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings