Figure 1
The rising mobility of users, and the advent of wireless networking services on the ever expanding Internet infrastructure, call for the adoption of authentication, integrity, and privacy as absolutely necessary features of a mobile network.
Our goal is to produce a Secure Mobile Network system that supports the establishment of secure enclaves or secure virtual networks among mobile workstations. To that end, we will create a secure network layer for mobile communication which will include authentication and encryption, combined with robust Mobile-IP. The use of two-way tunnels will allow remote networks or hosts to join a secure network across insecure topologies, and also allow remote secure enclave members to access a local secure enclave across an insecure network cloud. A robust mobile architecture must allow for redundancy in the case of component failure or hostile attack. A robust mobile architecure should also be flexible and allow for both centralized and de-centralized management of network layer entities. We will investigate and design solutions for distributed access control protocols. We will also develop redundant systems needed for overcoming the single point of failure problems found in the current Mobile-IP architecture. As part of the latter effort, we will focus on a relatively new problem called ``ad hoc'' routing. Ad hoc, from IEEE 802.11, refers to end systems communicating without a base station. A group of such systems should be able to form a secure enclave locally in an ad hoc fashion without manual intervention and in spite of runtime topological changes.
To achieve these goals, a number of technical problems must be overcome. In general, the IP community has limited experience with network layer security. Network layer security must be integrated with wireless Mobile-IP, another area in which the community has limited experience, and with other mechanisms needed to provide a suitably rich architectural environment to deal with access control and other security issues as well as redundancy and other reliability issues. We will follow a rigorous engineering approach guided by appropriate formal methods to attack these problems. We believe that security protocols should be formally analyzed and their implementations subjected to rigorous software engineering techniques. Many network security problems are due either to faulty protocols or to flawed implementations or both and we hope to avoid these problems in our work.
Our approach will be to incrementally design, formally analyze, and deploy a Secure Mobile Network system for a small group of real users on our campus. In addition to careful engineering and formal security analysis of protocols, real use is another key factor in learning if our systems function correctly. We intend to deploy a Secure Mobile Network in our CS/EE building and in classrooms across campus so that a number of faculty and graduate students can securely roam at will with their laptops.
A secure network layer has operating system architecture and network layer protocol components. For protocol components, we intend to follow the IETF IPSEC (IP Security) working group recommendations as closely as possible in order to maximize the potential for technology transfer. (Note: Current IPSEC work is closely coordinated with work on the IP next generation protocols. The security architectures will be similar.)
Figure 1
We will modify the network layer to add authentication and encryption. This will result in a modified IP that will have authentication and encryption payloads in the form of separate higher-layer packet headers. We will analyze all such authentication, encryption and other security related sub-protocols that we introduce into our integrated system. In general, the network layer will start with a plaintext IP header, followed by (possibly optional) authentication and encryption payloads, followed by other higher-level protocol headers and application data (Figure 1, Packet Headers). The plaintext header allows for the routing of packets across the current Internet routing infrastructure. Separate headers are used instead of IP options, because options require extra router processing and payload headers do not. The authentication layer encapsulates the encryption layer and certain parts of both the plaintext authentication layer and network layer (e.g,. addresses) will be included in the message digest. The current assumption is that the Message Digest 5 (MD5) algorithm, seeded with a key, will be used for authentication. Either symmetric (DES-CBC) or public-key (RSA) schemes may be used for encryption. In any case, a table-lookup identifier must be used within security protocol headers so that different cryptographic algorithms can be used and so that the network protocols can be independent of the algorithms.
Figure 2
The network architectural component includes access control and key management sub-systems at the network layer. Packets headed out of the system will first be looked up in an access control table (Figure 2, Network Layer Architecture), then if access is permitted, mapped into a key table that will determine the security encapsulation of the packet. Finally, as in current IP systems, the packet will be routed according to the destination address in the plaintext outer IP header. Inward bound packets are dealt with first according to access controls, then security processing, and may be delivered up to transport layers or forwarded where routing functionality exists.
We will create access and key management daemons (application-layer processes). This user-level daemon architecture is analogous to current intra-domain routing protocols such as OSPF or RIP where clean separation of policy and mechanism exists between daemons and IP-level lookup tables. The daemons will possess their own protocols for distributed access control or for key management. At runtime, normal network functionality will treat access control as a table lookup issue. However we will design and implement a distributed access-control protocol so that the user-level access daemons on all systems within a secure enclave or within a routing domain may dynamically change their access mechanisms. This will allow the grouping of hosts or routers to respond to an external threat, such as a hostile capture of a key unit during a military engagement. It will also allow for centralized control of a set of systems. In the past, firewall routers have been the principal systems for network layer access control mechanisms. Such mechanisms typically allow filtering based on source and destination TCP/UDP ports, IP source/destination addresses, input/output link layer interfaces, and also prevent certain other functions such as source-routing. Firewall routers are widely recognized as useful because they allow for centralization of security management for a wide set of insecure hosts. We propose to study and generalize such access controls and factor in requirements for IP mobility and ad hoc networking. Access control for mobile systems is an emerging issue. As previously protected personal computers become mobile, they will be moving out from behind their firewalls. Therefore, Secure Mobile Network systems should be capable of acting as their own firewalls}. For example, such a system may be a solitary node in hostile territory. Our access protocol must also permit centralized management when systems are in a team setting or when at "home". Our initial key management mechanism will be manual, however we are involved in other efforts including MCNC's key agile and (proposed) Blackbeard projects that address these issues and we will make provision in our design for the insertion of a scalable key management system as an option task.
We define a secure enclave as a set of hosts or networks reachable by one or more keys contained in the key table, possibly constrained by access controls. We will assume that a secure enclave will minimally always use authorization and that it may use encryption. We choose to not tie the enclave notion too tightly to network addresses. A battle group for maximum control might choose to have every member node exist in the same IP subnet. On the other hand, ad hoc groups will by definition consist of members with different IP subnet addresses on the same link. Moreover, the notion of tunnels and secure router-to-router communication across insecure networks allows enclaves to be topologically flexible. In the last analysis, uniformity comes from a shared set of keys.
Network layer security may be compared to link layer and application endpoint security. Link-layer security by definition applies to the local link only. Packets that cross routers may lose link layer security within the router when they emerge from the router and cross onto an unsecured physical medium. Link-layer security can prevent attacks on the exposed part of a network header during transmission on the link. On the other hand, if you assume the network layer architecture as outlined in Figure 1, the outer IP header cannot be encrypted if the packet must cross insecure routers not privy to the encryption. Certainly network layer security does not preclude link layer security. There may be some architectural advantages if the link layer encryption hardware can provide encryption facilities to the network layer as well.
Figure 3
Security at the network layer has a number of architectural advantages. A secure network layer can secure insecure applications on a host or network of hosts. A key can apply to a network, host, or application (since access control can deal with network addresses or ports). In addition, network layer security provides toplogical flexibility. Network layer security will allow one set of hosts or routers to communicate with other trusted hosts across a secure virtual point to point link (Figure 3, Secure Enclave). This allows a system high enclave. A secure router at one end can allow for insecure hosts to communicate with other insecure hosts at the other end behind another secure router. Such topological flexibility is the primary advantage of network layer security.
Finally, we should point out that network layer security does not rule out application layer security. System designers for the sake of redundancy might choose to design an application layer security system. Network layer security does give them the option of ignoring application layer security and it enables security in previously insecure applications. Of course, a successful network layer security attack would penetrate unprotected applications.
For the purposes of our research, we will assume single level hosts, but we will use encryption to create logically disjoint secure enclaves. We propose to use Message Digest 5 (MD5) and Data Encryption System with Cipher-Block Chaining Mode (DES-CBC), in hardware and/or software as performance dictates to implement the enclaves (but see Option 1) and we will make sure that our system can support asymmetric encryption as well. For the initial deployment, we will not implement an open ended authentication scheme, but will assume that all hosts are trusted by system components. Open ended scalable certificate based authentication as proposed in MCNC's Blackbeard system can be added later (Option 2). Given the number of years in the proposed project, and current interest in key management, we suspect that suitable IETF protocols may be available later in the project that we would like to integrate and verify as part of the work in Option 2. We would also want to experiment during Option 2 with local link layer key protocols based on broadcast that may be useful and suitable for face-to-face ad hoc networks.
Security protocols, such as those used in distributed systems for authentication and encryption, are prone to design errors of every kind. BAN and related logics have been used for reasoning about the security properties of the types of protocols we will use here. We are currently modeling the key agile key exchange protocols using these logics and have recently obtained protocol analysis tools from Mitre and NRL. We will use these techniques and others that may be appropriate in the modeling of the protocols that we develop in conjunction with the project.
Figure 4
Network layer security will be integrated with a Mobile-IP network architecture. The current proposed Mobile-IP architecture consists of a routing infrastructure containing three entity types: Home Agent (HA), Foreign Agent (FA), and Mobile Node (MN). A single organization's MNs will typically belong to one or more IP subnets (see Figure 4, Mobile-IP Architecture) where the MN's subnet address is topologically local to the organization. Upper layer protocols like TCP and applications like FTP do not allow for the IP address to change during connections. Unfortunately the current notion of an IP address is that it is topologically meaningful. That is, the network portion of it is located in a fixed location. The key idea in Mobile-IP is that the IP address of the MN does not change even when it moves. An intermediate forwarding mechanism must be created in order for that abstraction to remain true. Packets to the MN are routed to the home network by existing mechanisms. If the MN is not resident, the HA is in charge of routing packets from the rest of the network to an MN. The HA must track each MN via a registration protocol. When an MN moves from its home to a foreign subnet (or from one foreign subnet to another), it will send a registration packet to the HA via the current FA, which acts as a cell manager. After registration, the HA can forward incoming packets to the MN by encapsulating them in an outer IP wrapper with the FA as the destination and the HA as the source. This concept is referred to as a tunnel. (Please see Figure 1 again, and look at diagram 1.B which shows a tunnel packet; i.e., a packet with an additional outer IP layer. The outer packet's source IP address is the HA's sending interface ip address. The destination would typically be the FA, which would remove the outer IP address and deliver the packet. A tunnel may also run back from the MN to the HA. Hence tunnels might be one-way (simplex) or two-way (duplex).)
Mobile-IP assumes tunnels go one-way only from the HA to the FA. Packets outward bound from the MH to other hosts are sent from the MN to the FA via a link layer mechanism and then routed normally to correspondent hosts. However, a recent CERT advisory has pointed out the dangers of local network addresses crossing from an outside network to an inside network via a firewall. This appears to be a generic flaw in Mobile-IP and would prevent mobile systems from talking to local systems across current firewalls. We suggest that tunnels may also be used as two-way network bridges to allow remote mobile routers or hosts to convey their packets back across an insecure network to a secure router, thus forming a virtual secure network. A remote mobile node would need to first obtain a local IP address (this is known as a Care Of Address or COA in Mobile-IP) via a mechanism such as the Dynamic Host Configuration Protocol (DHCP). It could then essentially act as its own Foreign Agent and tunnel packets back to the Home Agent, which could forward the packets normally. A remote MN would place its network layer authentication and/or encryption just within the plaintext tunnel header of packets that it intends to tunnel back to the HA. As a result, remote systems could shield both their identity and their movement from intruders and observers. Careful analysis must be made of the security implications of full duplex tunneling in terms of insecure FAs and unknown tunnel endpoint addresses arriving at the HA.
We should point out that the current Mobile-IP draft allows for authentication between MNs and/or FAs and HAs as part of its registration protocol scheme. We will employ these mechanisms as part of Mobile-IP, logically verify them as a part of the whole Mobile-IP protocol, and add to them with full duplex secure tunnels and integrated network layer security.
Redundancy of access within the mobile cell is also an important topic, since loss of a local FA might mean loss of communication with home or worse, complete loss of communication within a local cell. IP currently assumes that the Address Resolution Protocol (ARP) cannot be used to establish communication between two hosts that are on the same link but are on different IP subnets (RFC 1122). Communication must be done through a router on the link (in Mobile-IP terms, the router would be the FA). We propose to develop an ad hoc protocol that would allow hosts within the same link to communicate directly whenever possible (as constrained by access control). This problem is not simple. Topologically, example systems could comprise a small mesh in which any system can address all other systems or a daisy chain in which each system can only address one or two other systems. It is always possible that systems might be able to talk to one system and not reach another; ``can communicate with'' is not transitive for radio. Furthermore, the topology of the system may change over time due to radio interference, changes in propagation, or loss of battery power. A routing protocol that would allow as many systems as possible to establish reachability and that conserves power is needed.
By definition, broadcast mechanisms will have to be used so that mobile nodes can find each other without a base station. Possible mechanisms may be divided into two categories: 1. link layer routing that establishes addressability when systems are directly reachable (IP address to MAC address), and 2. network layer routing mechanisms that must be used to allow inter-cell systems to communicate. ARP is a common example of a link layer routing protocol. RIP is a common example of a network layer interior gateway protocol. Both link layer and network layer ad hoc routing protocols are needed.
A possible starting point would be to implement the OSI End System - Intermediate System (ES-IS) algorithm, which does not suffer from ARP's inherent subnet problem. ES-IS is the OSI link layer routing algorithm. By default, hosts can talk to another ES through the local router (assume this is the FA). However the router can redirect them to talk to each other directly. Furthermore, if no router is present, two ESs can multicast to learn each others addresses and then communicate directly. ES-IS assumes that both ES and IS systems broadcast hello packets with periodically. Some have worried that such broadcasts might use up too much network bandwidth, but they have not noticed that ES hello packets are commonly only sent out once per minute and hence do not utilize much network bandwidth. Careful research would be needed here to determine how to optimize broadcasts. This would certainly be important in terms of preserving both as much radio broadcast spectrum as possible and in conserving battery power.
Figure 5
In addition to link-layer protocols, routing protocols are also needed to allow ad hoc networks to establish reachability at the network layer. For example, a roaming mobile system might move out of range of an FA. (See Figure 5, Ad Hoc Network). Hence it would be useful for a mobile system that can access a FA to be able to forward packets for mobile systems that cannot. A daisy chain of MNs could always come into being spontaneously as weak batteries or peculiar radio distribution patterns may result in network partition of a given radio cell. We propose that any MN (subject to access constraints) might become an ad hoc router. An entirely new intra-domain routing protocol needs to be created to deal with ad hoc routing issues. Current routing protocols can be divided into link-state or distance-vector protocols. Link-state requires a high amount of computation since the shortest path must be computed, but it uses the least amount of bandwidth and provides for rapid convergence, which may be an important quality for mobile systems. Distance-vector is easy to implement, but may use more bandwidth -- a precious resource in radio terms. Any ad hoc routing protocol should be able to prune itself down to the needed number of routers to make all members reachable. We will research such a protocol and deploy it in our mobile systems.
Resolution of the routerless routing problem is a key factor in facilitating ad hoc networks. We want to be able to create these anywhere two or more MNs can communicate, whether or not a HA or FA is reachable. We note (with some chagrin) that the only common ad hoc networks of which we are aware are those which occur when two or more Apple Powerbooks and a few short lengths of localtalk cable are present at the same conference table.
back to Proposal Outline
Email to Jim Binkley:
jrb@cs.pdx.edu