Network Working Group M. Bagnulo Internet-Draft UC3M Expires: July 5, 2005 January 2005 Threat analysis for routing-bridges draft-bagnulo-trill-threats-pre Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo contains a threat analysis for routing bridges. Bagnulo Expires July 5, 2005 [Page 1] Internet-Draft Threat analysis for routing-bridges January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Vulnerabilities of current bridges . . . . . . . . . . . . . . 4 2.1 The attacker X wants to establish a new communication with a node B pretending to be node A . . . . . . . . . . 4 2.2 The attacker wants to impersonate node A in any new communication established by node B. . . . . . . . . . . . 5 2.3 The attacker wants to hijack an ongoing communication . . 5 2.4 Attacks to the spanning tree protocol . . . . . . . . . . 6 2.4.1 Becoming the Designated Bridge . . . . . . . . . . . . 6 2.4.2 Becoming the Root Bridge . . . . . . . . . . . . . . . 6 2.5 Cache overflow . . . . . . . . . . . . . . . . . . . . . . 7 3. Assumptions about the rbridges . . . . . . . . . . . . . . . . 8 4. Threats related to the End-node Location Discovery Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 On-campus attacker X that can send packets with spoofed link layer source address and spoofed IP source address. . . . . . . . . . . . . . . . . . . . . . 9 4.1.1 The attacker X wants to establish a new communication with a node B pretending to be node A. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2 The attacker wants to impersonate node A in any new communication established by node B. . . . . . . . 10 4.1.3 The attacker wants to hijack an ongoing communication . . . . . . . . . . . . . . . . . . . . 12 4.1.4 Attacks using forwarding header . . . . . . . . . . . 12 4.2 Off-campus attacker X sends packets with a spoofed IP source address. . . . . . . . . . . . . . . . . . . . . . 12 5. Threats related to the Link-State Protocol . . . . . . . . . . 14 6. Going beyond bridges . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1 Normative References . . . . . . . . . . . . . . . . . . . 18 9.2 Informative References . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Bagnulo Expires July 5, 2005 [Page 2] Internet-Draft Threat analysis for routing-bridges January 2005 1. Introduction Routing-bridges (a.k.a. rbridges) [1] provide bridge functionalities overcoming some of the limitations of the bridges. In particular, rbridges support load balancing over multiple paths, overcoming the limitation of only using the spanning tree to carry packets. In addition, when rbridges are used, packets are protected with a hop count, preventing packets storms due to temporary loops, making unnecessary to introduce artificial port start-up delays. In this note, we perform a threat analysis for rbridges. Before starting to consider particular threats, we define the goal in terms of security. In principle, rbridges are aimed to replace bridges in order to overcome the aforementioned limitations of bridges. So, the minimum security expected from rbridges is to provide the same level of protection than regular bridges i.e. that the introduction of rbridges in a bridged network does not introduce any new vulnerability. However, the new features provided by rbridges may enable the usage of rbridged beyond current bridge capabilities. In such cases, security considerations may (and probably will) limit the recommended scope of application of rbridges. The analysis contained in this note is divided in four parts: First, we identify possible attacks to current bridges. Second, we analyze the threats related to the End-node Location Discovery Mechanism of rbridges. Third, we consider threats related to the Link- State Protocol, which is a fundamental component of the rbridge architecture. Finally, we consider those security aspects that limit the usage of the rbridges beyond the scope of application of current bridges. Bagnulo Expires July 5, 2005 [Page 3] Internet-Draft Threat analysis for routing-bridges January 2005 2. Vulnerabilities of current bridges Current bridges learn end node locations using link layer source address of forwarded packets. In addition they use the spanning tree protocol to determine a spanning tree through which they forward packets. Attacks to a bridged network can be based on sending packets with spoofed link layer addresses in order to make the bridges believe that the spoofed link layer address is in some specific link. For the following attacks we will consider that the attacker X has IP address IPX and link layer address LLX. Two nodes A and B have IP addresses IPA and IPB and link layer addresses LLA and LLB respectively. We assume that attacker X, node A and node B are all in different links of the same bridged network, since the presented attacks are aimed to the bridging system. 2.1 The attacker X wants to establish a new communication with a node B pretending to be node A We assume that the attacker X knows the IP and link layer addresses of node A and node B. The attacker starts the communication with node B using IPA and LLA as source addresses and intermediate bridges will believe that node A is located in the attacker's link. Reply packets from node B will be forwarded by the bridges to the attacker's link. Depending on the state existent in the bridges of the cloud, some of the packets containing the addresses of node A as source address may reach the link of node A. In order to hide the attack from node A, the attacker needs to avoid that any packets carrying an address of node A is flooded through the network. For that, the attacker needs the bridges to learn node B location (so that packets addressed to node B are not flooded) and also the attacker needs to make the bridges believe that node A is located in the attacker's link. To accomplish these two tasks, the attacker can: issue an ARP request/NS asking for IPB using its own addresses IPX and LLX as source addresses, so that bridges learn the location of node B. This is a masquerading attack, where node B is convinced that it is communicating with node A while it is actually communicating with the attacker X. Bagnulo Expires July 5, 2005 [Page 4] Internet-Draft Threat analysis for routing-bridges January 2005 2.2 The attacker wants to impersonate node A in any new communication established by node B. In this case, the communication is established by node B (the victim), instead of being established by the attacker. So, the attacker can make the bridges believe that node A is located in the attacker's link by simply sending a packet containing node A address as source address (link layer). The attacker needs to send such packet to any node located in node B's link, in order to inform all the involved bridges. If the attacker wants to avoid node A to see such packet (becuase it carries node A address as source address), the attacker needs to take care that the packet is not broadcasted. This can be easily achieved by initially sending a packet using its own addresses IPX and LLX to the target address and then sending the packet to the same destination now using IPA and LLA as source addresses. However, when node B starts a new communication with node A, it will perform an ARP request/NS for IPA. Such message will be broadcasted to all links in the network, and node A will reply, reconfiguring some of the bridges, in particular, the designated bridge of node B's link. This means that after the ARP reply of node A, the bridges will learn the real location of node A. The result is that the attack would be annulled. There is still the possibility that the attacker X also replies to the ARP request/NS. In this case, the reply that arrives last wins. So, this means that the attacker can simply delay its ARP reply in order to make sure that its reply will arrive later than node A's reply. An alternative strategy for the attacker is to try to avoid the performance of ARP requests/NS. This can be achieved by simply sending packets (like pings) to node B containing IPA and LLA as source addresses. In this case, node B learns the link layer of node A without needing to perform ARP request/NS. Then any future communication with node A, even those initiated by node B will use this information about IPA and LLA stored in the ARP cache. This is a masquerading attack to node B, since node B believes that it is communicating with A while it is actually communicating with the attacker X and it is also a DoS attack to node A, since node A does not receive the traffic intended for him. In addition, this can be a DoS attack since the traffic generated by node B is flooding the path between node B and the attacker's link. 2.3 The attacker wants to hijack an ongoing communication Now, we consider the case where node A and node B have information Bagnulo Expires July 5, 2005 [Page 5] Internet-Draft Threat analysis for routing-bridges January 2005 about each other in their ARP cache and that all the intermediate bridges know the location of node A and node B. In this scenario, the attacker X wants to impersonate node A in the communication with node B. The attacker then sends a packet to any node located in the link of node B using IPA and LLA as source addresses. The result is that the bridges of the path between node B and the attacker will update the information about the location of node A, considering now that node A is located in the attacker's link. Following packets from node B to node A will be forwarded to the attacker's link. However, as soon as node A sends a new packet, the cache of the bridges will be updated again, with the real location of node A. The result is an unstable situation where some packets will be forwarded to node A and other will be forwarded to the attacker. The result is a semi-masquerading attack to node B and a semi-DoS attack to node A. 2.4 Attacks to the spanning tree protocol 2.4.1 Becoming the Designated Bridge A possible attack using the spanning tree protocol is to convince all the bridges in a link that the attacker is the Designated Bridge on that link. This would imply that no bridge will act as DB in the bridge, causing an DoS attack to the communications that involve nodes on that link. The attacker can become the DB of a given link by advertising configuration message with the lowest cost to the root. This s DoS attack. 2.4.2 Becoming the Root Bridge Another attack is for the attacker to actually become the root of the spanning tree, by advertising configuration messages with the lowest root ID. This actually wouldn't cause much harm, since all the spanning tree would still be reachable (I think). However, the reconfiguration of the spanning tree is costly and during the reconvergence of the spanning tree protocol packets won't flow normally. So the actual harm could be achieved by periodically becoming the Root Bridge for a while and then stop being it, imposing a spanning tree reconfiguration. This is a DoS attack. Bagnulo Expires July 5, 2005 [Page 6] Internet-Draft Threat analysis for routing-bridges January 2005 2.5 Cache overflow By simply sending packets with different (spoofed) source addresses, an attacker can cause the cache of the bridges to overflow. The consequence of this attack is that following packets, addressed to real addresses, will be flooded, increasing the traffic of the network. This is a DoS attacks. Bagnulo Expires July 5, 2005 [Page 7] Internet-Draft Threat analysis for routing-bridges January 2005 3. Assumptions about the rbridges We are assuming that when an rbridge has multiple available routes to a given end-node, it only forwards packets using one f the available paths, probably the shorter one. Bagnulo Expires July 5, 2005 [Page 8] Internet-Draft Threat analysis for routing-bridges January 2005 4. Threats related to the End-node Location Discovery Mechanism Rbridges use two mechanisms to learn end-node location: through data packets and through ARP/ND packets (in the case of IP packets). Essentially, when a Designated Rbridge receives a packet coming form a directly connected node, it inspects the included link layer source address. If the address is unknown to him (i.e. no information about this link layer address is available in his database), then it learns that this particular link layer address is in the directly connected link and propagates this information through the link-state protocol. In addition, it forwards the packet according to the destination address. This means that if the destination address is unicast and the rbridge has information about its location, then the rbridge will forward the packet to the link where the destination is located. This forwarding can be done based on the link layer address or the IP address: if the packet is a not an IP packet or if the destination address is off-campus, then the packet is forwarded according to the link layer address; if the packet is an IP packet and is addressed to an on-campus destination, then the packet is forwarded using the IP address. If the destination address is unknown or, if the destination address is the broadcast address (or an all nodes multicast address) then, the packet is forwarded through the spanning tree so that it reaches all nodes. The potential attacks against the described mechanisms consist in sending packets with spoofed source address (link layer and/or IP level). 4.1 On-campus attacker X that can send packets with spoofed link layer source address and spoofed IP source address. Consider a node a with a link layer address LLA and IP address IPA. Consider an attacker X that sends a packet with link layer source address LLA and an IP source address IPA. In order to be effective, the attacker needs to be located on-campus, since, if a router forwards the packet, then it rewrites the link layer address, becoming Scenario b). In addition, we suppose that the attacker is located in a different links than the victim, because if this is not the case, the attack won't have any effect on the rbridged network. We will next consider the different attacks analyzed for the bridged network. The main difference between the rbridge case and the bridge case is that in the first one, the location information is propagated with the link-state protocol while in the second one, the location information is propagated through data packets. Bagnulo Expires July 5, 2005 [Page 9] Internet-Draft Threat analysis for routing-bridges January 2005 4.1.1 The attacker X wants to establish a new communication with a node B pretending to be node A. The attacker sends packets using IPA and LLA as source addresses (IP and link layer respectively). Upon the reception of this packet by the designated rbridge of the attacker's link, the designated rbridge will propagate this information through the link- state protocol. Now if there were no information available for node A in the rbridged network the attack will succeed. If there were information about the location of node A in the rbridged network, the success of the attack depends on whether the attacker's link is closer to the link of node B than the link of node A. If the distance between the attacker's link and the link of node B is lower than the distance between the link of node B and the link of node A, then the attack will succeed, because reply packets from node B will be forwarded to the attacker's link. The result is a masquerading attack, similar to the one of the bridged case. Otherwise, the reply packet from node B will be forwarded to node A, becoming some form of flooding attack. As in the bridged case, the attacker can to hide any packets carrying node A addresses from node A. For that, it first needs to make rbridges learn node B location (so that packets addressed to node B are not flooded). The attacker may use the same technique than in the bridged case, i.e. send an ARP request/NS for address IPB using its own address IPX as source address. The result is that these type of attacks different than in the bridged case, but it is not clear (to me) which is worse. 4.1.2 The attacker wants to impersonate node A in any new communication established by node B. In this case, the communication is established by node B (the victim), instead of being established by the attacker. So the attacker makes the rbridges believe that node A is located in the attacker's link simply by sending a packet with IPA and LLA as source addresses. This is a difference with the bridged case. In this case, independently of the destination address of this packet, this location information is propagated to all the rbridges of the campus. This is so because upon the reception of the packet containing IPA and LLA, the designated rbridge of the attacker's link will propagate the information about the location of node A to all the rbridges. In the bridged case it is not so easy to reconfigure all the bridges without letting node A to see packets carrying its own (spoofed) address. Bagnulo Expires July 5, 2005 [Page 10] Internet-Draft Threat analysis for routing-bridges January 2005 The information about the location of node A propagated by the designated rbridge of the attacker's link will be processed according to the link-state protocol rules. This means that, as in the previous case, it will only affect to those links whose distance with the attacker's link is lower than its distance with the link of node A. Next, as in the bridged case, when node B needs to initiate a communication, it will issue an ARP request/NS looking for the IP address of node A. If no optimization is performed by rbridges, this means that the ARP request/NS is flooded to all the campus, then node A will reply to the request and it will establish its own state in the rbridge system. This implies that if node A was unknown for the rbridges, now it becomes known, implying that potentially some attacks will be annulled (those where node A is closer to node B than the attacker). However, if some optimization is made, like that when the rbridges know the location of the node, then the ARP request/NS is only forwarded to the proper link, then node A will not receive the request, and only X will receive it, allowing the attack to continue, independently of the relative locations of the involved parties. In this case, the attacker can avoid the transmission of ARP request/NS by installing state in node B, as in the bridged case. So the differences between the bridged case and rbridged case in this scenario are that: o It is easier to hide packets contained spoofed addresses from the owner of the address in the rbrdiged case than in the bridged case. (not clear how important is this, since as far as I know, nodes don't react if they see a packet carrying ots own address as source address) o In the case of the attack, in the bridged case it can succeed but it requires the attacker to answer using delayed ARP packets or installing some ARP state in the victim. In the rbridged case it is easier for the attacker since there are no timing requirements in the answers but the attack only affects to those nodes that are closer to the attacker than to its rightful peer. A related aspect is that in the rbrdige case, the attacker only needs one packet to affect all the part of the network that is closer to him than to node A, while in the bridged case, specific delayed ARP replies are required for each node affected. This is a masquerading attack to node B since it will be communicating with the attacker while it believes to be communicating with node A and it is a DoS to node A. In addition, this can be used Bagnulo Expires July 5, 2005 [Page 11] Internet-Draft Threat analysis for routing-bridges January 2005 as a DoS to the infrastructure, because it can be used to sink the communications to the attacker's link (repeating this attack for different target's (i.e. changing node A)). 4.1.3 The attacker wants to hijack an ongoing communication In this case, the attacker simply sends a packet to an previously cached off link destination using IPA and LLA as source address. The result is that all the nodes that are communicating with node A and that are located in link that is closer to the attacker's link than to the link of node A will be redirected to the attacker. Differently than in the bridged case, traffic sent by node A won't restitute the original path in the case that node A is farer than the attacker. This is a masquerading attack for node B since it will be communicating with the attacker while it believes to be communicating with node A (probably this won't be so easy because upper layer protocols will react) and it is a DoS to node A. In addition, this can be used as a DoS to the infrastructure, because it can be used to sink the communications to the attacker's link (repeating this attack for different target's (i.e. changing node A)). This last case is important, since the attack is massive, it may affect many communications to node A simultaneously. 4.1.4 Attacks using forwarding header The attacker can send encapsulated packets to perform an anonymous attack. The result of using encapsulated packets is that the rbridges will not learn the location of the source address, making the source of the attack harder to trace. 4.2 Off-campus attacker X sends packets with a spoofed IP source address. In a bridged scenario, this attack is simply not related to the bridged architecture since forwarding is performed based on link layer addresses. In this case, the packet introduced in the campus will contained the spoofed IP source address and the link layer source address of the ingress router. So, an attacker sending packets with spoofed IP source address can induce the rbridges to think that the spoofed IP address is located in the ingress router link. This attack will imply that the traffic of those nodes that are located in links that are closer to the Bagnulo Expires July 5, 2005 [Page 12] Internet-Draft Threat analysis for routing-bridges January 2005 ingress router than to the real owner of the spoofed address will be forwarded to the ingress router. The result is a double DoS attack: on one hand, the ingress router will receive all the generated traffic and on the other hand, the owners of the spoofed addresses won't receive the traffic. However, it seems that this type of attack can be addressed through ingress-filtering. Bagnulo Expires July 5, 2005 [Page 13] Internet-Draft Threat analysis for routing-bridges January 2005 5. Threats related to the Link-State Protocol The link state protocol is used for exchanging location information between rbridges. Clearly, an attack in the link state protocol may result in distorted visions of the topology, implying all kind of attacks. Detailed analysis of threats to routing protocols can be found in [2]. In particular, an analysis to the OSPF protocol can be found in [3]. Probably this implies that some form of authentication is required between the routers in order to prevent such attacks. However, this implies manual configuration of passwords in the routers, which beats the zero configuration goal of rbridges. In addition, there are some other attacks that are specific to the usage of the link state protocol to the rbrdiges. One of such attacks can be the transmission of multiple packets with different spoofed addresses. The results of such attacks are: memory exhaustion, similar to the cache overflow attack in the bridged case. In addition, this is also a CPU exhaustion attack, since upon the reception of each new spoofed address, the rbridges need to recalculate the shortest path for such destination. In addition, there may attacks to the spanning tree algorthm based on the link state porotocol, similar to those available in the bridged case. This requires further study. Bagnulo Expires July 5, 2005 [Page 14] Internet-Draft Threat analysis for routing-bridges January 2005 6. Going beyond bridges As mentioned earlier, the enhanced capabilities of rbridges may make users to consider the usage of rbridges beyond the scope of bridges. However, there are some security considerations that need to be taken into account when considering this situation: o Broadcast storms: All the campus is a single broadcast domain. This implies that for example, an ARP request/NS will be broadcast through all the campus, allowing off campus attackers to generate braodcast storms.(I think that is what Gabriel Motenegro meant) o Larger (campus-wide?) subnets means that spoofing inside a subnet is also easier, and ingress filtering granularity ("in-prefix spoofing") is more coarse, leading to more difficult user tracking. (Pekka Savola) o Larger subnets do not mean good for firewalling between segments. Do you do this at rbridges using MAC's then? I.e., modern enterprises *have* to include firewalling between different departments, or different classes of networks. The rbridge model appears to increase openness (which is good), but this will likely hamper the effects to keep the users separate and from harming each other. (consider e.g., virus/worm propagation inside a single rbridged subnet.) (Pekka Savola) Bagnulo Expires July 5, 2005 [Page 15] Internet-Draft Threat analysis for routing-bridges January 2005 7. Security Considerations Perhaps an analysis of SeND support could fit in here. Bagnulo Expires July 5, 2005 [Page 16] Internet-Draft Threat analysis for routing-bridges January 2005 8. Acknowledgements The initial version of this document benefited from discussions with Alberto Garcia Martinez and Manuel Uruena. Many of the ideas contained in this document are my interpretation of comments made by Pekka Savola, Gabriel Montenegro, Bill Sommerfeld, Radia Perlman, Erik Nordmark. Bagnulo Expires July 5, 2005 [Page 17] Internet-Draft Threat analysis for routing-bridges January 2005 9. References 9.1 Normative References [1] Perlman, R., Touch, J. and A. Yegin, "RBridges: Transparent Routing", Internet-Draft draft-perlman-rbridge-02, February 2005. 9.2 Informative References [2] Puig, JJ., Jones, E. and D. McPherson, "Generic Security Requirements for Routing Protocols", Internet-Draft draft-ietf-rpsec-generic-requirements-00, July 2004. [3] Jones, E. and O. Le Moigne, "OSPF Security Vulnerabilities Analysis", Internet-Draft draft-ietf-rpsec-ospf-vuln-01, December 2004. Author's Address Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo Expires July 5, 2005 [Page 18] Internet-Draft Threat analysis for routing-bridges January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bagnulo Expires July 5, 2005 [Page 19]