Internet DRAFT - draft-bulut-ospf-trusted-plane
draft-bulut-ospf-trusted-plane
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]
