RE: draft-ietf-idmr-igmp-mrdisc-10.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

                     Yes    No-Objection  Discuss *  Abstain  
Bert Wijnen         [   ]     [ x ]       [   ]      [   ] 

During the call/telchat I'd say: no further objection.
I am amazed that Randy needs to take the DISCUSS for the
security considerations sections while both Security ADs
have a No-Ob (albeit with comments).

Thanks,
Bert 

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: donderdag 3 april 2003 8:37
> To: iesg-secretary@ietf.org
> Cc: iesg@ietf.org
> Subject: draft-ietf-idmr-igmp-mrdisc-10.txt
> 
> 
>                     Yes    No-Objection  Discuss *  Abstain  
> Randy Bush          [   ]     [   ]       [ x ]      [   ] 
>     
> 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. 
>