Router authentication, key management, and adjacency management for securing inter-router control messages
Introduction
When a client logs into her bank through online banking, information is transferred from the client to the bank (and back) through the Internet. The security of the end-to-end exchange is visible to the client, if she chooses to notice the https: prefix in the bank’s web address. However, the fact that the packets of the end-to-end exchange will traverse several routers on the Internet is invisible to the client.
Individual network segments are connected together through routers to form the global Internet. A router determines the “best path” through the Internet between two end systems by periodically exchanging routing updates with its neighbors. These exchanges constitute a routing protocol. If one or more of the (apparent) neighbors is an intruder, then the security of the end-to-end exchange can be compromised. The ability to compromise the security exists even if the https: prefix is present. Therefore, it is just as important to ensure the legitimacy of the intermediate routers on the path as it is to ensure the legitimacy of the client and the bank. This implies that the routing protocol exchanges must also be secured.
Methods for ensuring router-to-router security have been written into the specifications of routing protocols for many years. However, the authors of [1] note that “almost all [those who responded] report using one manually distributed key throughout the entire network. These same operators report that the single key has not been changed since it was originally installed, sometimes five or more years ago.” This leaves ample opportunity for the keys to be compromised. This could lead to an intruder router pretending to be a legitimate one and capturing confidential data.
In March 2006, the Internet Architecture Board (IAB) held a workshop on the topic “Unwanted Internet Traffic”. The report from that workshop is documented in [2]. Section 8.1 of that document states, “A simple risk analysis would suggest that an ideal attack target of minimal cost but maximal disruption is the core routing infrastructure”. Section 8.2 calls for “[t]ightening the security of the core routing infrastructure”.
One approach to achieving improved security is to automate the process of updating the security parameters. This will reduce the number of network management personnel needed and would potentially improve security for all users of the Internet. This leads us to the following requirements:
- •
Ensuring the authenticity and integrity of the routing protocol messages.
- •
Ensuring the legitimacy of the neighboring routers, by making sure that they are part of the “permitted adjacency” as explained below.
- •
Automation of the entire process of key and adjacency management.
The notion of “permitted adjacency” can be re-stated as providing answers to the following questions:
- •
Are you a legitimate member of my group? This is the question of authentication.
- •
Are you permitted to connect to me for the purposes of this routing protocol? This is the question of authorization.
Atwood [3] has presented motivation for router security and a description of an architecture for an authentication and key management system. The Keying and Authentication for Routing Protocols (KARP) working group of the Internet Engineering Task Force (IETF) has developed a Design document [4] and a Threats and Requirements document [1] to provide guidance for the work of improving routing protocol security.
This paper extends Atwood’s [3] design, and proposes a methodology for ensuring the authentication and authorization of a peer router, and conveying the necessary policy information to do so. The methodology includes a set of interactions that meet most of the security and operational requirements specified in [4], [1]. The protocols implied by this set of interactions have been formally validated for their security properties.
Section 2 explores the previous work on secure routing. Section 3 introduces our idea of Key Scopes. Section 4 outlines the specific problem that we are addressing. In Section 5, we compile the set of requirements to be satisfied by a secure, automated key management system. Following that, in Sections 6 Proposed architecture, 7 Proposed operation, a design is proposed that satisfies all of the compiled requirements. Sections 8 Validation, 9 Protocol model using HLPSL, 10 Results show the formal validation that proves the strength of our proposal. Section 11 concludes the paper.
Section snippets
Previous work
In this section, we shall see the background pertaining to the key management problem that we are trying to solve. We shall see the works in existence and the area where there is need for additional work. We shall also see some concepts and terminology used in the paper.
Keying groups (Key scopes)
Before we go into the details of our proposal, we introduce the concept of a keying group. [29] makes a brief mention of key scopes. However, this is a document that focuses on the issues to be considered when designing an operational and management model hence it does not talk about any particular design for automated key management. Referring to all routers having the same TEK as a ‘keying group’, we can have routers forming a ‘keying group’ as follows:
- •
A group per AD – This is the most
Problem statement
As noted in Section 1, all of the key management proposals discussed in Section 2 assume that if a peer router presents an acceptable credential, then it is authorized to be a neighbor. While the set of authorized neighbors can be controlled using preshared keys (between pairs of routers) or asymmetric keys and an authorization list [27], no mechanism other than manual installation is suggested in the KARP documents for establishing these controls.
As also noted in Section 1, if router exchanges
Solution requirements
In this section, we give precise details of the problem being addressed. As already mentioned, the overall aim is to design a system for automated key management so as to eliminate the disadvantages of the manual method of configuring keys. The basic function of this automated system is secure generation of keys, their distribution and regular update so as to protect against both active intruders as well as passive intruders.
Along with these basic goals, a key management system should satisfy
Proposed architecture
In this section, we propose an architecture for an automated key management and adjacency management system that can handle even the cases overlooked by the individual existing approaches. As already mentioned, this framework has been designed by building on top of the existing proposals and extending them to accommodate all of the requirements specified in Section 5.1. This design fits the existing proposals into their correct places in the overall architecture.
We present a global view of our
Proposed operation
In this section, we explain in detail our proposal of a protocol for automated key management. We also specify the details of the message exchanges along with the description.
Fig. 2 gives a closer look at the entities in our design as described in Section 6 and shows the interactions among them.
There is one centralized GCKS in the system (per routing protocol) and an LKS, local to each GM router. The GCKS and the LKS have the ability to generate SA parameters through a KMP, and to store them in
Validation
In the previous sections, we have seen the design of a system and the details of a protocol for automated key and adjacency management. We have also seen that this system handles, along with the basic requirement of key generation, distribution and update, many more security and operational requirements as outlined in Section 5.1. However, it is essential to prove the strength of the system using some time tested method. In order to achieve this, we use a method known as formal validation. This
Protocol model using HLPSL
In this section, let us discuss the details of formally validating our proposed protocol using AVISPA and HLPSL. We describe the major parts of our HLPSL code as well as some of the finer details that have been incorporated so that the model is as close as possible to the protocol as deployed in the real world.
Results
In the previous section, we have seen the details of the HLPSL model corresponding to our protocol. In this section, we shall see the results of the formal validation of our protocol using AVISPA. AVISPA has reported that our protocol is safe and free from attacks.
The tool used for the validation purpose was SPAN, which stands for ‘Security Protocol ANimator for AVISPA’. We executed the tests on a Windows 7 desktop, with 4 GB RAM. We carried out the tests on two of the back-ends of AVISPA,
Conclusion and future work
Today, there is definitely a great necessity for an automated key management solution that can meet as many of the requirements listed in Section 5.1 as possible. In this paper, we have proposed an architecture and a protocol for automated key management. We have introduced the concept of a keying group/key scope and have shown the variety of key scopes possible. The design we have proposed handles multiple variations of keying groups. It is a generic design that accommodates multicast as well
Acknowledgments
J. William Atwood acknowledges the support of the Natural Sciences and Engineering Research Council of Canada, through its Discovery Grants program. Revathi Bangalore Somanatha acknowledges the support of a Concordia Graduate Fellowship. This project has been made possible in part by a gift from the Cisco University Research Program Fund, a corporate advised fund of Silicon Valley Community Foundation.
Revathi Bangalore Somanatha graduated from R.V. College of Engineering, Bangalore, India in 2006 with a Bachelor of Engineering securing highest in the college and the 6th rank in the university (V.T.U). She graduated from Concordia University, Montreal, Canada in 2012 with a Master of Computer Science degree. During the period from 2006–2010, she was working with Cisco Systems India Pvt Ltd. She is currently working with the same company, where she resumed work after her Masters degree. Her
References (36)
Automated security protocol analysis with the AVISPA tool
Electron. Notes Theoret. Comp. Sci.
(2006)- G. Lebovitz, M. Bhatia, B. Weis, Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and...
- L. Andersson, E. Davies, L. Zhang, Report from the IAB workshop on Unwanted Traffic March 9-10, 2006, RFC 4948, IETH,...
- J. Atwood, Automated Key Management for Router Updates, in: 2009 First International Conference on Emerging Network...
- G. Lebovitz, M. Bhatia, Keying and Authentication for Routing Protocols (KARP) Design Guidelines, RFC 6518, IETF,...
- Y. Rekhter, T. Li, A Border Gateway Protocol 4 (BGP-4), RFC 1654, IETF,...
- KARP Working Group, KARP charter, IETF, 2010,...
- SIDR Working Group, SIDR charter, IETF, 2006,...
- B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol...
- S. Kent, K. Seo, Security Architecture for the Internet Protocol, RFC 4301, IETF,...
Computer Networks and Internets
Cited by (3)
Novel attacks in OSPF networks to poison routing table
2017, IEEE International Conference on CommunicationsRPsec: Managing routing protocol security
2016, Canadian Conference on Electrical and Computer EngineeringDiscovery of right binary pattern in key management using security matrix and magic cards
2016, ARPN Journal of Engineering and Applied Sciences
Revathi Bangalore Somanatha graduated from R.V. College of Engineering, Bangalore, India in 2006 with a Bachelor of Engineering securing highest in the college and the 6th rank in the university (V.T.U). She graduated from Concordia University, Montreal, Canada in 2012 with a Master of Computer Science degree. During the period from 2006–2010, she was working with Cisco Systems India Pvt Ltd. She is currently working with the same company, where she resumed work after her Masters degree. Her research interests include the design, analysis and validation of routing protocols.
J. William Atwood graduated from McGill University in 1963 with a Bachelor of Engineering, from the University of Toronto in 1965 with a Master of Applied Science and from the University of Illinois at Urbana–Champaign in 1970 with a Doctor of Philosophy, all in Electrical Engineering. He is a Distinguished Professor Emeritus in the Department of Computer Science and Software Engineering at Concordia University, Montreal. His research interests include the design, analysis, validation and deployment of protocols for secure multicast and secure routing.