Subject: mboned: mroutesec: "pim passive" -mode

From: Pekka Savola <[email-masked]>
Date: Sun, 1 Aug 2004 07:06:15 +0300 (EEST)

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/

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 31 Jul 2004 23:15:21 -0700

Can you point to text in IS-IS, OSPF or RIP that is discussing this
problem ? It's exactly the same problem, and it really doesn't make
sense to come up with new text for what should be a generic description
or at best a clone of the same text. Or is there no text about
passive interfaces for IGPs ? Then why should we have one for PIM ?

I for once wouldn't want to promote one choice of interface policy over
the other. I think for example protocol security + neighbor aware hello
interval selection is a much more generic solution to the problem at
hand than passive-interfaces...

Cheers
	Toerless

---

From: Pekka Savola <[email-masked]>
Date: Sun, 1 Aug 2004 18:14:02 +0300 (EEST)

> passive interfaces for IGPs ? Then why should we have one for PIM ?

Those protocols do not have an OPS WG dedicated to discussing them, 
and don't have Informational documents suggesting how to make them 
more secure ;-).  And those protocols are actually deployed, so we 
don't need to work on geting them adopted ;-).
 
> hand than passive-interfaces...

I think this is the problem.  There are ways how to solve this already
-- more generic ways -- but because they are more generic, they aren't
adopted by the operators, because they don't even figure out they have
to do something, and even if they did, if it's too difficult, they
won't do it (compare this to the adoption (or lack thereof) of ingress
filtering -- this is a bit of exaggaration, but by the same logic one
could argue there is no need for strict uRPF).

What I'd personally like to see is that PIM would be "passive" by 
default on all interfaces unless completely disabled or completely 
enabled when the PIM process is enabled on a router.

That would bring reasonably-safe-by-default defaults which would 
require very little config from the operators.

How to get there is another topic.  THere could be some words in he
informational RFC.  This could be a customer request to some vendors
(but this isn't good as it doesn't bring it up with everyone).  Or
whatever.  That's what I'm looking for input on.

---

From: Ahmed Bashandy <[email-masked]>
Date: Sun, 01 Aug 2004 09:53:58 -0700

There are already authentication mechanisms to avoid many of these DOS attacks, at least in OSPF. These techniques are already 
deployed. I believe we can "borrow" most of them.

Thanks

Ahmed

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 1 Aug 2004 16:29:18 -0700

> require very little config from the operators.

It's in line with the thought process of many ISPs, yes, but not necessarily
typical enterprises that do not use tools to fully automated configure
routers consistently. I also tend to believe that ISPs would actually
prefer to have real protocol security if just the bloody key management
would become more easy.

I am the first to support putting passive interfaces into actual
products, i just do not feel overwhelmed to specifically promote it in
the IETF especially not when it happens in a context that does not set it in
par with alternative and more secure solutions that would get us closer
to zero-config for the actual IP multicast service.