RE: [pim] last-hop threats by hosts to PIM (fwd)
James Lingard <James.Lingard@dataconnection.com> Fri, 07 January 2005 16:45 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 LAA26227 for <pim-archive@lists.ietf.org>; Fri, 7 Jan 2005 11:45:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmx3l-0006Ai-GF; Fri, 07 Jan 2005 11:33:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmwts-0002qN-1c for pim@megatron.ietf.org; Fri, 07 Jan 2005 11:23:44 -0500
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 LAA24161 for <pim@ietf.org>; Fri, 7 Jan 2005 11:23:41 -0500 (EST)
Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmx6s-0003Jr-PV for pim@ietf.org; Fri, 07 Jan 2005 11:37:11 -0500
Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id <CPA9TVWM>; Fri, 7 Jan 2005 16:22:57 -0000
Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80358130D@baker.datcon.co.uk>
From: James Lingard <James.Lingard@dataconnection.com>
To: 'Pekka Savola' <pekkas@netcore.fi>
Subject: RE: [pim] last-hop threats by hosts to PIM (fwd)
Date: Fri, 07 Jan 2005 16:22:51 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027
Cc: pim@ietf.org
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
Pekka, I'm not sure that this draft makes a useful contribution, given the existing Security Considerations section of draft-ietf-pim-sm-v2-new and draft-ietf-mboned-mroutesec. There seems to be very little here that is not in one of those two documents. And although this document does bring together the material into one place, I fear that the creation of a third document may only confuse matters. Secondly, I find it hard to understand what assumption you are making about the level of PIM knowledge of the reader. I feel that someone without a reasonable knowledge of the protocol would be unable to understand the document, yet in several places it attempts to give explanation that would be unnecessary to a more knowledgeable reader. Perhaps an up-front statement of assumptions would be useful. More specific comments are inline below. Regards, James. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: 04 January 2005 18:46 To: pim@ietf.org Subject: [pim] last-hop threats by hosts to PIM (fwd) > I received no comments to this, so re-sending again.. > > Please, do read and send comments for: > http://www.ietf.org/internet-drafts/draft-savola-pim-lasthop-threats-00.txt > > It's very short, only about 5 pages, but could be very useful work as > Informational. 2. Last-hop PIM Vulnerabilities This section describes briefly the main attacks against last-hop PIM signalling, before we get to the actual threats and mitigation methods in the next sections. ## The distinction between Sections 2 and 3 isn't at all clear to me. ## Perhaps they should be merged? 2.1 Sending PIM Register Messages on Your Own PIM Register messages are sent as unicast-encapsulated messages. ## I should hope that readers would already be aware of this fact. Maliscious hosts could also send registers themselves for example to get around the rate-limiters, to interfere with foreign RPs, etc. ## Is this really a "last-hop" vulnerability? Perhaps you should define in ## the introduction precisely what you mean by this. 2.2 Becoming an Illegitimate PIM Neighbor When PIM has been enabled on a router's "host" interface, any host can also become a PIM neighbor using PIM Hello messages unless special, rare precautions, such as protecting all the PIM traffic on the link using IPsec, have been taken. ## I think that in this section you should assume the mitigation steps ## described below are not taken; hence the second half of this sentence ## is unnecessary. Further PIM messaged should not be accepted except from valid PIM neighbors; if implementations are compliant to this recommendation in the PIM-SM specification, becoming a PIM Neighbor using Hello messages is the first step to be able to send other PIM messages. ## I'm not sure this needs stating at all: I think this knowledge ## could be assumed. 2.3 Becoming an Illegitimate PIM DR Designated Router is in "charge" of a particular LAN, for example, for registering new sources, generating PIM Join/Prune messages and forwarding multicast traffic. A host which can became a PIM neighbor, can also, as part of becoming the neighbor, influence the DR election process: basically, if at least one neighbor did not have "DR Priority" field in the Hello message (a "bidding-down" attack), the neighbor with the numerically highest IP address wins the election; if DR priority existed, the DR priority is first checked and only then the IP addresses are compared. ## I don't think it's necessary to describe the details of DR election ## here. You could simply state that a host that can become a PIM ## neighbor is able to cause itself to be elected DR (either with or ## without the DR Priority Hello option). Further, it is not sufficient to secure DR election, because Assert messages can be used to obtain the responsibility for forwarding upstream traffic as described in the next section. ## This paragraph is unnecessary here since it's described in the next ## section. It seems that a DR can send PIM messages (like Prune/Join) to the non-DR to be forwarded upstream on behalf of directly connected (to both DR and non-DR) sources. In other words, a host on a stub LAN can be elected as a DR and act as a "man-in-the-middle" between the other hosts and the real PIM router. ## I don't understand what the threat is here. You don't get any special ## privileges from being the DR, just the ability to deny service. [XXX: Is this correct? Should non-DRs reject forwarding upstream messages from downstream LAN's DRs, because a real DR should have its own upstream connectivity?] ## This is correct. There is no requirement for a DR to have ## connectivity. 2.4 Becoming an Illegitimate PIM Asserted Forwarder With a PIM Assert, a router can be elected to be in charge of handling all traffic from a particular (S,G) (where S might also be all of S? [XXX: true?]). This overrides DR behaviour. ## Yes, true. [snipped] As noted before, it is also possible to spoof an Assert on someone else's behalf to cause a temporary disruption on the LAN. However, it is not 100% clear what happens when the router which was spoofed receives "it's own assert" and CouldAssert(S,G,I) is False? [XXX: a PIM expert should say something? Is this an issue in the state machine?] ## The PIM-SM spec says nothing explicitly about what to do when receiving ## messages that supposedly come from yourself (and I don't think that it ## should). I suspect that most implementations will drop such messages ## since (a) they may be caused by local loopback of your own packets, and ## (b) you are not a neighbor of yourself. [snipped] 3.1 Denial-of-Service Attack on the Link The easiest attack is to deny the multicast service on the link. This could mean either not forwarding all (or parts of) multicast from upstream on the link, or not registering or forwarding the multicast transmissions originated on the link upstream. These attacks can be done multiple ways: the most typical one would be becoming the DR through becoming a neighbor with Hello messages and winning the DR election: after that, one could just not send any PIM Join/Prune messages based on the IGMP reports, not forward or Register any sourced packets, and maybe even send PIM Prune messages to cut off existings transmissions because Prune messages are accepted from downstream interfaces even if the router is not a DR. ## The text "because Prune messages..." is another example of ## explanation that should be unnecessary for the readership. [snipped] 3.3 Confidentiality, Integrity or Authorization Violations If a node can get to be a DR or craft an appropriate Assert, in addition to or instead of performing Denial-of-Service, it can also just operate as normal for some traffic, while violating confidentiality, integrity or authorization for some other traffic. Some packets, whether sent by received, could be modified (possibly in a subtle, unnoticable ways) in transit resulting in an integrity violation. ## This assumes that the "host" has connectivity to the source of the ## traffic by an alternative route, which I suspect is unlikely to be ## the case. The packets can obviously be observed as well, so any data sent can be compromised. ## Even if the host is not the DR, it is still able to observe the ## packets; I don't think anything is gained by being the DR. A more elaborate attack is on authorization. There are some models [I-D.hayashi-igap] where the current multicast architecture is used to provide paid multicast service, and where the authorization/authentication is added to the group management protocols such as IGMP. Needless to say, if a host would be able to act as a router, it might be possible to perform all kinds of attacks: subscribe to multicast service without using IGMP (i.e., without having to pay for it), deny the service of the others on the same link, etc. ## I'll second Beau's comments on that. [snipped] 4.3 IP Filtering PIM Messages To eliminate the PIM messages, and other PIM signalling, in the similar scenarios as with PIM Passive Mode, it might be possible to block IP protocol 103 (all PIM messages) as an input access-list. ## This seems to be about the only original contribution made by this ## draft, so you should spell out that this filtering has benefits ## even if you're using PIM passive mode, in that this would also ## filter out Register messages. This is also acceptable when IPsec is used with more than just one PIM router on the link. ## Only if the Register messages are also being sent with IPsec, or if ## you can ensure that no unicast messages would ever be routed from ## one of the PIM routers to another of the PIM routers via the LAN. 4.4 Summary of Vulnerabilities and Mitigation Methods This section summarizes the vulnerabilities, and how well the mitigation methods are able to cope with them. Summary of vulnerabilities and mitigations: +-----+--------------------+-----------------+----------------+ | Sec | Vulnerability | One stub router |>1 stub routers | | | | PASV|IPsec|Filt |PASV|IPsec|Filt | +-----+--------------------+-----+-----+-----+----+-----+-----+ | 2.1 | Hosts Registering | N | N | Y | N | N | * | +-----+--------------------+-----+-----+-----+----+-----+-----+ | 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | * | +-----+--------------------+-----+-----+-----+----+-----+-----+ | 2.3 | Invalid DR | Y | Y | Y | * | Y | * | +-----+--------------------+-----+-----+-----+----+-----+-----+ | 2.3 | Adjacency not reqd | Y | Y | Y | * | Y | * | +-----+--------------------+-----+-----+-----+----+-----+-----+ | 2.4 | Invalid Forwarder | Y | Y | Y | * | Y | * | +-----+--------------------+-----+-----+-----+----+-----+-----+ Figure 1 ## What is the "Adjacency not reqd" line in this table referring to? -- James Lingard Data Connection Ltd (DCL) http://www.dataconnection.com/ _______________________________________________ pim mailing list pim@ietf.org https://www1.ietf.org/mailman/listinfo/pim
- [pim] last-hop threats by hosts to PIM Pekka Savola
- [pim] last-hop threats by hosts to PIM (fwd) Pekka Savola
- Re: [pim] last-hop threats by hosts to PIM (fwd) Beau Williamson
- RE: [pim] last-hop threats by hosts to PIM (fwd) James Lingard
- RE: [pim] last-hop threats by hosts to PIM (fwd) Pekka Savola