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

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Aug 2004 17:32:20 +0300 (EEST)

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 <[email-masked]>
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 17 Aug 2004 15:22:48 -0700

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

Thanks,
Tom