Subject: [magma] MRDISC last call comments

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Aug 2004 13:20:21 +0300 (EEST)

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

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.)

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.

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

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/ ?

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]

   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.

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| ?

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