Routing Protocol Security E. Bulut, Ed. Internet-Draft E. Onfroy Intended status: Informational Alcatel-Lucent Bell Labs Expires: December 27, 2008 June 25, 2008 Trusted plane for routing equipment embedding a tamper-resistant device draft-bulut-ospf-trusted-plane-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 27, 2008. Abstract Due to their critical role in a network, the protection of routing equipements is crucial, particularly against subversion attacks. For this purpose, we integrate a trusted plane in the network equipments related to the routing protocols (e.g. OSPF, BGP, RIP). This trusted plane is realized by a trusted element embedded or connected to the network equipment. Bulut & Onfroy Expires December 27, 2008 [Page 1] Internet-Draft Trusted Routing June 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Router Architecture . . . . . . . . . . . . . . . . . . . . . . 3 3. Routing protocol vulnerabilities . . . . . . . . . . . . . . . 4 3.1. OSPF vulnerabilities . . . . . . . . . . . . . . . . . . . 4 4. Trusted Plane . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Trusted Plane Definition . . . . . . . . . . . . . . . . . 5 4.2. Isolation of subverted equipment . . . . . . . . . . . . . 6 4.3. Trusted relationship over the network . . . . . . . . . . . 6 5. Routing Protocols Critical Data and Functions . . . . . . . . . 6 6. Trusted plane Realization . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Bulut & Onfroy Expires December 27, 2008 [Page 2] Internet-Draft Trusted Routing June 2008 1. Introduction Telecommunication and IT infrastructures are exposed to a continuously and permanently increasing set of risks, security threats and attacks. Different network equipments, such as routers, have very critical role, since they ensure the junction between several networks, forwarding data packets from one network to another. A router disruption is also highly embarrassing, since it can cause a network outage, and directly impact consumers activities and engender many costs and a negative publicity. Unfortunately the attackers often target routers due their critical role in the network and developed different types of attack: Man In The Middle attack for traffic monitoring, denial of service attack, or subversion attack RFC 4593 [RFC4593]. In case of subversion attacks, the attacker is connected to equipment with current user rights or even administrator rights. These rights allow the attacker to modify the equipment configuration and control all processes running on the equipment. The attacker can also insert wrong information, that could be shared by other equipments. The routing messages could be altered and new routes inserted, in order to route traffic through the attacker equipment. In order to prevent from such attacks, we define a trusted plane over the existing planes. This plane is responsible of the storage of critical data and execution of critical functions used during the routing process. 2. Router Architecture Traditionnally a router is organized into three different planes (Figure 1). o Control plane : this plane is in charge of routing table computation based on the routing information collected by the routing processes (OSPF, BGP, RIP, etc.) o Data plane (Forwarding plane) : this plane groups together the forwarding functionalities to route the packets towards their destination. o Management plane : this plane manages the router from a command line interface or from a network manager. Bulut & Onfroy Expires December 27, 2008 [Page 3] Internet-Draft Trusted Routing June 2008 +------------------------------------------------------------------+ | Control plane | Management Plane | | +-------------------------+ | | | | Routing Protocols | | | | | (OSPF, BGP, RIP, etc.) | | | | +-------------------------+ | | +------------------------------------------------------------------+ | Data Plane | +------------------------------------------------------------------+ Figure 1: Router Architecture 3. Routing protocol vulnerabilities This draft aims to define a trusted plane to enhance the security of all routing protocols. Each protocol has different vulnerabilities. The following section focuses on the OSPF vulnerabilities, that will be used in this draft as a use case. 3.1. OSPF vulnerabilities The draft [draft-ietf-rpsec-ospf-vuln-02] describes different OSPF vulnerabilities. One of vulnerabilities is the message modification if the router is attacked by an insider (attacker having secret key) or if the Cryptographic Authentication is disabled. So to protect from this attack, and if the Cryptographic Authentication is enabled then the keys must be stored in a tamper-resistant and an unreadable memory. The Cryptographic Sequence Number can be manipulate by an attacker in order to make a replay attack. This attack will be successful if the secret keys have not been changed. In general errors in Hello message parameters such as incorrect AreaID, RouterDeadInterval, HelloInterval and so on will cause the Hello to be silently discarded with no further impact. A Router LSA carrying the E bit set to 1 automatically allows a router to introduce External LSAs in the routing domain. This could be exploited to escalate a normal router into an ASBR. There are many other examples, but the important is to protect the router from these attacks. All information, such as critical data or algorithms, must come from a trusted source. The insider must not access and tamper these information. Bulut & Onfroy Expires December 27, 2008 [Page 4] Internet-Draft Trusted Routing June 2008 4. Trusted Plane 4.1. Trusted Plane Definition The trusted plane is built over the control, data and management planes (Figure 2). The trusted plane embeds all the critical data and functions of routing process. We mean by "critical data and functions" all the data and functions that an attacker could use to succeed its subversion attack. +------------------------------------------------------------------+ | Trusted Plane | | +-------------------------+ | | | | | +----| Routing Protocols |-----------------------------------+ | | (OSPF, BGP, RIP, etc.) | Control plane | Management Plane | | | | | | | +-------------------------+ | | | | | +------------------------------------------------------------------+ | Data Plane | +------------------------------------------------------------------+ Figure 2: Trusted Plane Hence, the routing protocol functionnalities are distributed to the trusted plane and the control plane. The control plane embeds all the non-critical data and functions of routing protocol. This plane can be realized with any trusted device, but providing security features (e.g. hardware independence, tamper-resistance,) as a Smart Card for example. All critical data stored in the trusted device come from either a pre-configuration or an message exchange with the neighbor. The pre- configuration is done by a hardware provider or an operator on a dedicated configuration platform. Some information will be transmitted from the trusted device to the router in order to exploit it and establish the routing table. The router can never modify data located on the trusted device. Once on the router, these information cannot be used to generate other critical data for the routing protocol. In case of the OSPF protocol for instance, the critical data could be the secret keys, the AreaID, RouterDeadInterval, HelloInterval, etc. Bulut & Onfroy Expires December 27, 2008 [Page 5] Internet-Draft Trusted Routing June 2008 The critical algorithms or functions could be the authentication algorithms, Hello protocol, Database Description protocol. 4.2. Isolation of subverted equipment The integration of the trusted plane aims to isolate the equipment in order to avoid the propagation of the attack to the whole of the network. To avoid the propagation of wrong information introducing by attacker. Since the trusted plane has only trusted information (e.g. authentication keys, link-state database, routing table) and the authentication mechanism is executed in a trusted environment, the trusted plane can reject or accept this incoming message. When a subversion attack occurs, the attacker can modify the content of incoming messages and add wrong routes. But, this message will be rejected by the trusted plane and this message is not taken into account. Hence, the trusted plane will not more authenticate the modified messages coming from this router and the router can no more reply to this message and will be isolated because other routers know it any more. For instance, in case of the OSPF routing protocol, an incoming message is authenticated by the neighbor trusted plane and checked by the host trusted device. If it detects a wrong authentication, the message will be ignored and it does not respond to its requests. With Hello protocol, no response will be send to the neighbor. The attacked equipment will be ignored by the dynamic routing protocol process in other routers. 4.3. Trusted relationship over the network A trusted relationship is built over the network thanks to the elementary trusted planes integrated to every network equipments and thanks to trusted manager, that provides a centralized monitoring. A secure communication channel is established between each trusted plane and the trusted manager, using protocols such as TLS or IPSec. 5. Routing Protocols Critical Data and Functions A detailed analysis of the routing protocol has to be performed in order to identify what we called critical data (e.g. routing table, link-state database, authentication keys)and functions (messages generation, authentication, reception, sending, routing table construction,etc.) to be moved to the trusted plane and the part staying at the control plane level. We classify these assets into Bulut & Onfroy Expires December 27, 2008 [Page 6] Internet-Draft Trusted Routing June 2008 three groups: o Trusted Element Secrets: the secrets for the communication between the network equipment and the trusted element in the trusted plane. These secrets avoid running the trusted element on any other equipment. o Routing Protocol Secrets: the secrets of routing protocol installed on the network equipment. They are used to encrypt or authenticate the routing protocol messages. An administrator on dedicated equipment installs them. o Trusted Part of the Routing Protocol: functionalities for the routing protocol located on the trusted plane. They could implement all or a part, or a complement of the routing protocol. 6. Trusted plane Realization The trusted plane can be realized with any trusted device, but respecting certain constraints: o The trusted device must be a tamper-resistant device. o The trusted device must povide advanced cryptographic functions. o The trusted device must be easily integrated to the router environment. o Since, routers run real-time, the trusted device must not decrease the equipment performances. o Configuration and update of the trusted device must be easy. 7. Acknowledgements We would like to acknowledge all the partners of the French National Agency funded project ESTER. 8. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. 9. References Bulut & Onfroy Expires December 27, 2008 [Page 7] Internet-Draft Trusted Routing June 2008 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. 9.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. [draft-ietf-rpsec-ospf-vuln-02] Jones, E. and O. Le Moigne, "OSPF Security Vulnerabilities Analysis", June 2006. Authors' Addresses Evren Bulut (editor) Alcatel-Lucent Bell Labs Route de Villejust Nozay, 91625 FR Email: evren.bulut@alcatel-lucent.fr Emmanuel Onfroy Alcatel-Lucent Bell Labs Route de Villejust Nozay, 91625 FR Email: emmanuel.onfroy@alcatel-lucent.fr Bulut & Onfroy Expires December 27, 2008 [Page 8] Internet-Draft Trusted Routing June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Bulut & Onfroy Expires December 27, 2008 [Page 9]