[pim] mboned: mroutesec: "pim passive" -mode (fwd)
Pekka Savola <pekkas@netcore.fi> Tue, 17 August 2004 14:46 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20366 for <pim-archive@lists.ietf.org>; Tue, 17 Aug 2004 10:46:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx55r-0007yW-0V; Tue, 17 Aug 2004 10:37:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bx51F-0006sh-4t for pim@megatron.ietf.org; Tue, 17 Aug 2004 10:32:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19274 for <pim@ietf.org>; Tue, 17 Aug 2004 10:32:54 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bx57D-000569-0I for pim@ietf.org; Tue, 17 Aug 2004 10:39:10 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7HEWKl28599; Tue, 17 Aug 2004 17:32:20 +0300
Date: Tue, 17 Aug 2004 17:32:20 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: pim@ietf.org
Message-ID: <Pine.LNX.4.44.0408171728210.28510-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: mboned@lists.uoregon.edu
Subject: [pim] mboned: mroutesec: "pim passive" -mode (fwd)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
Sender: pim-bounces@ietf.org
Errors-To: pim-bounces@ietf.org
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 <pekkas@netcore.fi> To: mboned@lists.uoregon.edu 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 pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim
- [pim] mboned: mroutesec: "pim passive" -mode (fwd) Pekka Savola