ComCom-Hetero-Sec-Paper

From ResiliNetsWiki
Jump to: navigation, search

DO NOT EDIT! The final version of this paper is now in tex form and has been submitted for review.

This paper is targeting the Computer Communications Special Edition on Heterogeneous Networks CFP

Presentation: File:Rohrej Security 01.pdf

Contents

Homogeneous Security in Heterogeneous Networks: Towards a Generic Security Management Protocol

Justin P. Rohrer, Weichao Wang and James P.G. Sterbenz

Information and Telecommunications Technology Center,

Department of Electrical Engineering and Computer Science,

University of Kansas,

Lawrence, KS 66045-7621, USA

E-mail: {rohrej,weichaow,jpgs}@ittc.ku.edu

Abstract

The promises of next-generation Internet architectures are many and varied. Key among these are increased flexibility and diversity. What this translates into is increased variety not only in protocols and technology, but in the performance characteristics and services provided by these composite or heterogeneous networks. This is certainly true of the plurality of networking technologies being deployed in the current and next generation Internet environments. One conspicuous issue is the need for a generic security protocol which is not tied to specific types of layer 1 and 2 networks. Based on lessons learned from the current Internet architecture we can see that this protocol needs to be able to communicate beyond trust boundaries (i.e. the borders of Autonomous Systems). We propose a high-level architecture for such a Generic Security Protocol and use simulation to demonstrate the benefits of having inter-domain communication in the context of the next-generation public Internet.

Keywords

network security, heterogeneous network, management, resilience, survivability

Principles (do not include)

Security should to be integrated in a lightweight and flexible manner in all components on the next-generation Internet.

Logical Constructs (do not include)

IF realms are uniquely identified, AND realms have a unified administrative policy, THEN each realm may be treated as a single entity by the security protocol.

IF realms are defined as using a common physical/transport layer, THEN significant bandwidth discontinuities will only occur at realm borders.

Introduction

The promises of next-generation Internet architectures are many and varied. Key among these are increased flexibility and diversity. What this translates into is increased variety not only in protocols and technology, but in the performance characteristics and services provided by these composite or "heterogeneous" networks.

According to Merriam-Webster, the term heterogeneous means "consisting of dissimilar or diverse ingredients or constituents". This is certainly true of the plurality of networking technologies currently being deployed in the Internet environment, so among lessons learned from current internetworking technology we can safely say that heterogeneous network designs are becoming the norm not the exception, and that we can only expect this trend to continue into the future. We are seeing ad-hoc sensor networks with specialized multi-layer protocol solutions as well as networking technologies designed for use in space[3] and interplanetary[4] applications which add even more heterogeneity to the network in terms of long round trip times and highly asymmetric links. Along with the many benefits of enabling heterogeneous networks come numerous risks and challenges. One conspicuous issue is the need for a generic security protocol [1]. Previously proposed solutions to security concerns are generally designed to address particular scenarios and continuing with this piecemeal approach is not a scalable long term solution.

As the future of the Internet comes into focus we see that there is a tendency for policy, trust, and technology boundaries to coincide within the network topology. Since organizational units will determine both policy and implementation within their own boundaries and may differ significantly from the policy and technology choices made by bordering organizational units, this phenomenon is natural. However, it exacerbates a weakness which has already become apparent in the current, relatively homogeneous, Internet which is the lack of ability to effectively communicate policy beyond trust boundaries (namely past the borders of Autonomous Systems). This is part of the problem known as Tussle [14]. To counteract this the generic security implementation of the next-generation Internet must explicitly provide mechanisms to facilitate policy dissemination across organizational boundaries.

In this article we focus on the problem of developing a generic security management protocol or service for heterogeneous networks, which will scale with the increasing diversity of network techniques and applications. This protocol will serve as a common 'language' with which diverse heterogeneous network realms can exchange the appropriate security information and deploy generic and scalable security mechanisms.

Background

This work is an extension of proposed next generation Internet designs such as the Postmodern Internet Architecture (PoMo) internetwork layer[2] which is being developing under the NSF NeTS-FIND project. The security and performance issues we are addressing in this article are not new ones, however most of the previous work in this area has been constrained by the need for backward-compatibility. With the PoMo project we self-consciously eschew the limitations imposed by backward-compatibility with the current Internet architecture. We consider security, survivability and resilience to be necessary features of all network components. We also believe that explicit provision needs to be made for the communication of security policy across trust boundaries. The term security can be used with varying scope in mind. For the purposes of this article we are defining security as those measures taken to ensure the health of the network as a whole and links individually.

Related Work

Pioneering research on security issues in heterogeneous networks falls into three main categories, namely, authentication, collaboration incentives, and denial of service (DOS) prevention [1]. The research on authentication [5, 6, 7] and collaboration incentives [8, 9] shares much in common with that targeted towards mobile and ad-hock networks. DOS prevention falls into two categories: improved resource management [10, 11] and avoidance mechanisms [12, 13]. Improving resource management is part of the natural evolution of technology over time. As it applies to low-capacity networks it can help reduce the disparity when they are connected to high-capacity networks. However, it must be realized that high-capacity network technologies are also continuing to be improved over time and generally at a faster pace so ultimately the principles of improved resource management lead to increased heterogeneity in the network and increased potential for DOS disruptions. This is because low capacity links can be saturated much more easily when high-capacity nodes are also present in the network. It is our belief that DOS prevention as well as remediation[16] must be addressed explicitly in the context of the next-generation Internet and our proposed solution is an attempt to do exactly that.

Security Categories

As mentioned in the previous section, the security challenges driven by heterogeneous environments can be grouped under three main concepts, each of which need to be addressed for security to be possible. In this article we are primarily concerned with the last of these three.

Authentication

Authentication is a necessary service for the establishment of trust. It can be handled in a distributed or centralized manner. Authentication paradigms have been rigorously studied in varied networking scenarios some of which we perceive to be much more challenging than the next-generation Internet environment which is expected to include trusted entities which lend themselves to the establishment of signed pubic key type authentication schemes. For this reason we do not intend to re-invent authentication mechanisms for this protocol but will rely on those that already exist.

Collaboration Incentives

Incentives can be either a positive reward for correct behavior or a negative penalty for mis-behavior. In the current Internet these incentives are generally negative and implemented at layer 8 i.e. through policy. Access to network resources is treated as a privilege which may be withdrawn if certain requirements are not met. While this is certainly not the only means available to ensure cooperation, there is a lot of momentum behind this mindset so for the purposes of this article we will assume that future Internet architectures will operate on similar principles.

Denial of Service Prevention

Classically DOS occurs as the result of intentional malicious behavior. In this article we also want to recognize the DOS like symptoms can result as a byproduct of the heterogeneity inherent in network designs due to congestion and saturation and is a possible disruption in any scenario where a source or set of sources have the ability to generate more traffic than the lowest capacity link on the network path to an intended destination can support. The more disparity of resources between different realms in the PoMo framework, the more frequently such disruptions are likely to occur.

PoMo Model

Environmental Model

The Postmodern Internetwork (PoMo) [2] and other next-generation Internet architectures such as NewArch[17] and the ANA-Project[18] use the concept of realms ('compartments' in ANA) to be collections of nodes that share mechanisms and define trust/policy boundaries.

Assumptions

Based on the principles of PoMo, we can make certain assumptions. One is that there will be a set of established core infrastructure and centralized management. Another is that packets will be authenticated in such a way that their origin and path cannot be spoofed. The third is that there will be cross-layer mechanisms to transfer policy information between end-users, administrative entities, and the network itself.

Design Goals

Our fundamental goal is to provide a generic security protocol (GSP) to both unify policy implementation within each administrative realm and facilitate inter-realm policy communication to enhance the performance, resilience, and survivability of the network as a whole.

Proposed Solution

The Generic Security Protocol operates within the OSI stack influencing routing and forwarding decisions based on explicit policy configuration as well as input from outside applications such as firewalls. It relies on the services provided by the PoMo internetwork and lower layers in order to function properly, yet is not an end-to-end protocol for users nor will it necessarily exist on all nodes in the network. The placement could be considered similar to that of BGP, although the functionality is entirely different.

Framework

Each realm will run a Security Agent (SA) service which may be implemented in a centralized or distributed manner. There are also optional Security Client (SC) services which run on individual nodes to allow then to receive policy information from the network in order to optimize their link usage. These entities share information using Security Packets (SP).

Security Agents

SAs run on devices typically associated with the establishment or enforcement of security policies, i.e. gateways, firewalls, intrusion prevention systems, etc. Policy is defined around the basic link element and automatically distributed to all SAs within a given realm to enable cooperative enforcement. The SA then interprets that policy to trigger a response when certain events occur. For example if the firewall detects malicious traffic it can not only block the traffic itself but also signal the SA with the flow ID and source of the traffic and the SA will respond according to the local realm policy for that event type.

Security Clients

Implementation of SCs on a given node is optional in that the decision is left to the end user or realm administration. The purpose of the SC is to receive relevant policy information from SAs within its realm and relay it upwards to the application and possibly the user.

Security Packets

GSP signals using security packets (SP). The SP includes fields for authentication, GSP code, and content. Authentication will authenticate both the source and the message contents; GSP codes will be defined for specific types of messages; while content is an optional flexible field which could contain anything from an application specific command to a text directive such as "do not download copywrited music files". SPs will be encapsulated in PoMo packets with will provide source, destination, and routing/forwarding information.

Intra-Realm Security

Within each realm, the primary concern of the GSP is the coordination of security measures and appliances to implement a unified security policy.

Inter-Realm Security

One of the threats to network stability which we are addressing with the GSP is Denial of Service (DOS). Because GSP packets are a relatively small percentage of the network traffic and would likely be dropped in a DOS scenario, we determined that GSP traffic would be prioritized above other types of traffic to ensure delivery.

Security for the Generic Security Protocol

With any type of automated policy enforcement comes the risk of exploitation through various types of attack. We intend to mitigate this threat as much as possible through the use of public key encryption for authentication and strict requirements on GSP traffic behavior before it is allowed to enter the network or cross trust boundaries.

Simulation Model

Proof of Concept

While there are many scenarios that need to be tested and evaluated, we decided to investigate one particular area where inter-realm cooperation is essential for the prevention of network service degradation, namely Denial of Service (DOS) challenges, whether resulting from deliberate attacks or legitimate traffic beyond a link's intended capacity. To evaluate this we generated a simulation environment composed of three realms of different bandwidth capacities. The first realm (nodes 8-15) represents a set of end users or subscribers connected via low-bandwidth links. The second realm (nodes 0-3) represents a high-capacity provider realm. The third (nodes 4-7) contains a high-performance server farm (red). We then ran simulations to examine the disruption caused to well-behaving HTTP 1.1 traffic when misbehaving traffic is encountered on the low-capacity links both with and without the GSP.

No CBR Traffic

Simulations

We created our simulation model using the open source ns-2 platform [19]. Each link was modeled using the symmetric duplex-link model and had drop-tail queuing implemented in both directions. The simulated legitimate traffic was generated using the built in PackMime HTTP-1.1 traffic generation agents with the default parameter set. Nodes 8-15 were set up as clients and nodes 4-7 as servers. "Misbehaving" traffic was simulated by creating Constant Bitrate (CBR) connection between node 4 and node 14. This could represent many types of unwanted traffic, such as a Real Time Protocol (RTP) multimedia download or a malicious DOS attack. Traffic was monitored for a duration of 30 seconds.

Results

Results were collected in the form of ns trace files, and Network Animator (nam) format files, to allow both visual and numerical analysis of the simulations. Simulations were run to compare performance and response to disruptive traffic both with and without the GSP protocol operating. A control scenario without disruptive traffic was also evaluated.

Control Case

For the control case we ran the simulation with only well-behaved web traffic in the network. Successive iterations of this simulation allowed us to tune the frequency of HTTP 1.1 requests such that only occasional packet loss was observed in the network as would be expected during normal use. This frequency was about one request per node per second. The flow of HTTP traffic was then maintained as a constant throughout the simulation in the other scenarios.

Without GSP

Without GSP

For the case with no GSP operating we setup node 15 to act as an ordinary firewall which detects and blocks the CBR traffic based on some rule set specified by the realm administrator. Because it has no way to signal upstream nodes there is little it can do to prevent the unwanted traffic from clogging it's downstream link from the service provider. In the figure the upper cur represents the total traffic traversing the congested link, while the lower curve represents the well-behaved HTTP traffic. We can see from the figure that the goodput of the link drops dramatically when the CBR stream starts. This is not only due to the packets being dropped due to congestion, but also because the TCP streams automatically back-off when the detect packet loss. We ran this with a variety of combinations of link speeds and CBR stream rates and found that the greater the disparity in resources, the more pronounced this effect became.

With GSP

With GSP

In the case where GSP Agents are running on all three realms we again set node 15 to act as a firewall. This time however, node 7 was also set as a firewall with egress filtering. Using an equivalent rule set as in the previous scenario node 15 is again able to detect and block the CBR traffic. In this case since all three realms are running Security Agents node 15 is able to send signals upstream to node 7 which in turn can block the flow of unwanted traffic with minimal delay. If node 4 were running a Security Client node 7 would also be able to signal it to automatically stop the flow at it's source, however this option was not included in our simulation. In this case we can see a downward spike in goodput at the time the traffic disruption begins which rapidly returns to normal after the CBR flow is stopped. Comparing this to the graph from the control case we can see that it is much more similar than the graph from the simulation without GSP.

Analysis

The idea of extending the communication of security policy beyond trust boundaries in the internetwork environment is a very powerful one. From this example we see dramatic improvement in the usability of the low-bandwidth network access link. The parameter values chosen (low bitrate = 128Kbps, high bitrate = 1Mbps, CBR bitrate = 320 Kbps, HTTP request freq. = 1/sec, GSP reaction time = 1 sec.) for the simulations are relatively conservative. Much larger bandwidth disparities already exist in the Internet and that differential will continue to grow. As they grow the benefit of implementing a protocol like GSP will also increase.

Conclusions and Future Work

The simulation scenario presented here has demonstrated the potential power and flexibility of this approach. We believe that the same procedure could be used to prevent spam flooding or SSH brute-force attacks as was applied to DOS in this case. It is not especially difficult to see that stopping traffic that is disruptive to network operation close to the source is more desirable than blocking it close to the destination. The difficulty is overcoming the lack of trust between administrative domains, and also the issue of spoofed source addresses in the current Internet environment. The next-generation Internet architectures such as PoMo have proposed solutions to overcome the latter issue which should in turn go a long way to overcoming the former. Because of its reliance on these proposed solutions, published technical specifications for them are needed before our Generic Security Protocol can be defined in much more detail than what is presented in this article. Detection mechanisms for malicious traffic is a whole area of research beyond the scope of this paper. In the future we will investigate ways to integrate with existing traffic filtering solutions such as firewalls.

Security for the Generic Security Protocol

As mentioned previously it is imperative that any type of automated policy enforcement protocol such as this one be secured from the possibility of exploitation. We intend to throughly investigate the security measures necessary to achieve this using public key infrastructure, and traffic class management. We also intend to investigate the validity of using self-policing methods with compartmentalization for applications such as this one.

Acknowledgements

The authors gratefully acknowledge the comments and feedback of Abdul Jabbar Mohammad, member of the ResiliNets initiative [15].

References

[1] Evans, J.B., Wang, W. and Ewy, B.J. (2006) ‘Wireless networking security: open issues in trust, management, interoperation and measurement’, Int. J. Security and Networks, Vol. 1, Nos. ½, pp. 84-94

[2] Bhattacharjee, B., Calvert, K., Griffioen, J., Spring, N., and Sterbenz, J. (2006) ‘NeTS-FIND: Postmodern Internetwork Architecture’, NSF Proposal, Funded 10/2006

[3] Durst, R.C., Miller, G.J., Travis, E.J., ‘TCP Extensions for Space Communications’, Proceedings of the 2nd annual international conference on Mobile computing and Networking, pp. 15 - 26, ACM Press, November 1996, ISBN:0-89791-872-X

[4] Burleigh, S., Hooke, A., Torgerson, L., Fall, K., Cerf, V., Durst, B., Scott, K., Weiss, H., ‘Delay-Tolerant Networking: An Approach to Interplanetary Internet’, Communications Magazine, IEEE, Volume 41, Issue 6, June 2003 pp. 128 - 136

[5] Bhargava, B., Wu, X., Lu, Y. and Wang, W. (2004) ‘Integrating heterogeneous wireless technologies: a cellular-assisted mobile ad hoc networks’, Mobile Network and Applications, Vol. 9, No. 4, pp.393-408

[6] Wang, W., Liang, W. and Agarwal, A. (2005) ‘Integration of authentication and mobility management in third generation and WLAN data networks’, Journal of Wireless Communications and Mobile Computing, Vol. 5, No. 6, pp.665-678

[7] Yang, H. and Lu, S. (2002) ‘Self-organized network layer security in mobile ad hoc networks’, Proceedings of the First ACM Workshop on Wireless Security (WISE), pp.11-20

[8] Lamparter, B., Paul, K. and Westhoff, D. (2003) ‘Charging support for ad hoc stub networks’, Journal of Computer Communication, Vol. 26, No. 13, pp. 1504-1515

[9] Ben Salem, N., Buttyan, L., Hubaux, J-P. and Jakobsson, M. (2003) ‘A charging and rewarding scheme for packet forwarding in multi-hop cellular networks’, Proceedings of Fourth ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc), pp.13-24

[10] Bhatia, R., Li, L.E., Luo, H. and Ramjee, R. (2006) ‘ICAM: integrated cellular and ad-hoc multicast’, IEEE Transactions on Mobile Computing, Vol. 5, No. 8, pp. 1004-1015

[11] Bali, S., 'Mitigating scheduler-induced starvation in 3G wireless networks', All-Hands Meeting Presentation at ITTC 2006.11.09

[12] Traynor, P., Enck, W., McDaniel, P., and La Porta, T. (2006) ‘Mitigating attacks on open functionality in SMS-capable cellular networks’, Proceedings of the 12th Annual international Conference on Mobile Computing and Networking (MobiCom), pp. 182-193

[13] Enck, W., Traynor, P., McDaniel, P. and La Porta, T. (2005) ‘Exploiting open functionality in SMS-capable cellular networks’, Proceedings of the 12th ACM Conference on Computer and Communications Security (CCS), pp.393-404

[14] Clark, D., Wroclawski, J., Sollins, K., Braden, R., 'Tussle in Cyberspace: Defining Tomorrows Internet', SIGCOMM '02: Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 347-356

[15] ResiliNets Initiative website: http://wiki.ittc.ku.edu/resilinets.

[16] ResiliNets Strategy D2R3: http://wiki.ittc.ku.edu/resilinets_wiki/index.php/ResiliNets_Strategy.

[17] Clark, D., Braden, R., Falk, A., and Pingali, V., (2003) 'FARA: reorganizing the addressing architecture', SIGCOMM Comput. Commun. Rev. 33, 4 (Oct. 2003), pp. 313-321

[18] Autonomic Network Architecture: A European Union funded project in Situated and Autonomic Communications, Website: http://www.ana-project.org.

[19] The Network Simulator: ns-2, Website: http://www.isi.edu/nsnam/ns/.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox