Re: [pim] mboned: mroutesec: "pim passive" -mode (fwd)

[Tom Pusateri <[e-mail]>]

This is a great operational tool.
Several implementations already have this ability.

Thanks,
Tom

In message <[e-mail]> you write:
>PIM folks,
>
>We're considering adding a paragraph to
>draft-ietf-mboned-mroutesec-02.txt to send a pointer to the
>implementors that a "passive" PIM mode could be very useful (compare
>this to "passive" OSPF), as below.
>
>Are the objections to this?  Does this sound like a good idea to point 
>out?  Quick comments would be appreciated ;-)
>
>5.4 Passive mode for PIM 
>
>  As described in the last paragraph of section 3, hosts are also able
>  to form PIM adjacencies and send disrupting traffic unless great
>  care is observed at the routers.  This stems from the fact that most
>  implementations require that stub LANs with only one PIM
>  router must also have PIM enabled (to enable PIM processing of the
>  sourced data etc.)  Such stub networks however do not require to
>  actually run the PIM protocol on the link. Therefore such
>  implementations should provide an option to specify that the
>  interface is "passive" with regard to PIM: no PIM packets are sent 
>  or processed (if received), but hosts can still send and receive 
>  multicast on that interface.
>
>(draft-ietf-mboned-mroutesec-02.txt is already past the IESG
>Evaluation so I'd be extra interested in getting quick feedback
>whether folks would find this objectionable).
>
>
>---------- Forwarded message ----------
>Date: Sun, 1 Aug 2004 07:06:15 +0300 (EEST)
>From: Pekka Savola <[e-mail]>
>To: [e-mail]
>Subject: mboned: mroutesec: "pim passive" -mode
>
>Hi,
>
>mroutesec-02 is already pretty much done, only lacking approval from 
>the AD, but I thought of one last-minute addition that could possibly 
>be quite useful.
>
>See below for the problem of hosts interfering with PIM messaging:
>
>   PIM-SM can be abused in the cases where RPF checks are not
>   applicable, in particular, in the stub LAN networks -- as spoofing
>   the on-link traffic is very simple.  For example, a host could get
>   elected to become DR for the subnet, but not perform any of its
>   functions.  A host can also easily make PIM routers on the link stop
>   forwarding multicast by sending PIM Assert messages.  This implies
>   that a willful attacker will be able to circumvent many of the
>   potential rate-limiting functions performed at the DR (as one can
>   always send the messages yourself).  The PIM-SM specification,
>   however, states that these messages should only be accepted from
>   known PIM neighbors; if this is performed, the hosts would first have
>   to establish a PIM adjacency with the router.  Typically, adjacencies
>   are formed with anyone on the link, so a willful attacker would have
>   a high probability of success in forming a protocol adjacency.  These
>   are described at some length in [1], but are also considered out of
>   scope of this memo.
>
>My suggestion is to add a recommendation that implementations include 
>a feature to designate an interface "passive": multicast routing is 
>still enabled, but no PIM messages will be processed.  This would be 
>very applicable in stub networks with only one PIM router.  (This 
>could be achieved with ACLs as well -- just blocking all PIM packets, 
>but this would be cumbersome).
>
>Opinions?  Would this be useful?
>
>(Recently, a nice document on MLD problems was also written -- I also
>though to add a pointer to that in th eprocess:  
>draft-daley-magma-smld-prob-00.txt)
>
>-- 
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>_______________________________________________________________
>user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
>web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
>
>
>
>_______________________________________________
>pim mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/pim

_______________________________________________
pim mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pim