You are on page 1of 6

SECURING AD-HOC NETWORKS USING IPSEC

Abhrajit Ghosh Telcordia Technologies Applied Research Piscataway, NJ

Rajesh Talpade Telcordia Technologies Applied Research Piscataway, NJ

Moncef Elaoud Telcordia Technologies Applied Research Piscataway, NJ

Michael Bereschinsky U. S. Army CERDEC Ft. Monmouth, NJ

ABSTRACT:

The use of IPSec for securing communication between nodes of wireless and mobile ad hoc networks has traditionally been considered difficult. We describe an IPSec-based architecture and implementation for ad hoc networks that can seamlessly handle node mobility and IP address change. The approach can be used for securing application traffic as well as configuration and mobility management protocol traffic. A certificate-based approach that aids dynamic key generation and distribution is used for creating security associations between nodes. Simple and backward compatible extensions to the IPSec and PKIX protocols that do not violate existing and proposed standards are described, and an existing implementation is discussed. Initial experimental evaluation reveals that the per- packet latency overhead at the end-host for using our proposed mechanisms is tolerable.

Keyword:

Security

Mobility,

Ad-hoc

networks,

INTRODUCTION

IPSec,

IP-based wireless ad-hoc networks are increasingly finding applications in various domains such as tactical combat and disaster relief. Such networks allow mobile users to continually avail of network services. While the wireless environment allows rapid deployment of the network infrastructure, IP and associated network services ensure flexible communication between network nodes. The presence of wireless links and assumption of routing functionality by all nodes makes ad hoc networks more vulnerable than wire-line networks to various forms of attack such as source spoofing, eavesdropping, data transformation, and packet drop/replay. IETF’s IPSec protocol suite [1] has traditionally been useful in protecting wire-line networks from

these attacks. We describe an IPSec-based security architecture and implementation for ad hoc networks that can seamlessly handle node mobility and IP address change. The approach can be used for securing application traffic as well as configuration and mobility management protocol traffic.

IPSEC FOR AD HOC NETWORKS

The IPSec protocol suite has been designed to ensure authentication, confidentiality, replay- protection and non-repudiation of IP traffic. These services are provided by establishing Security Associations (SAs) between IPSec- enabled nodes in the network. The establishment of SAs typically requires a key negotiation process between the communicating nodes. This may be achieved using the IKE [2] protocol. Once SAs are established, all traffic between the nodes could be encrypted and authenticated using ESP [3], only authenticated using AH [4], or both ESP and AH could be used together. IPSec services are provided to all entities that operate above the IP layer at a particular node, that is, security does not need to be incorporated piecemeal into upper-layer entities. [6] specify protocols for management of certificates as part of an X.509 [5] Public Key Infrastructure. X.509 based certificates have been used to authenticate the key distribution process for IPSec operating in a static network environment.

A Ad Hoc Network Architectural Assumptions

The term “ad-hoc network” can apply to various network configurations. In some cases (such as Mobile IP) this refers to simple terminal mobility, where a node moves from one access network to another. Once in the access network, the node is essentially communicating with an Access Point and from a routing perspective the situation is not very different from a statically deployed node. At the other end of the spectrum,

2

a mobile ad-hoc network (MANET) is

an

autonomous system of mobile nodes with all routing within the domain occurring in a highly dynamic manner.

IP BACKBONE Border Router Border Router Node A Node B MANET Domain MANET Domain
IP BACKBONE
Border Router
Border Router
Node A
Node B
MANET Domain
MANET Domain

Figure 1:Ad-hoc network architecture Our ad-hoc network architecture lies somewhere in between a simple wireless Access Network and the highly dynamic and autonomous MANET environment. The basic services provided are auto-configuration of network nodes, mobility management and routing. The architecture is depicted in Figure 1. While intra- domain routing may be achieved using any one of the possible MANET protocols, inter-domain communication requires use of the backbone network. When a node moves from one domain to another, there is a need for allocation of a domain specific routing address using an address configuration protocol. Since a node’s routable address may change during the course of time, there is a need for an application layer entity to be able to identify a node by means other than its routable address. This requirement is met by associating a permanent IP address (PIP) with each node. In Figure 1, an application layer entity (e.g. a video conferencing source) on Node A uses Node B’s PIP address to identify it as a traffic destination. On the other hand, the routing and address configuration protocols make use of Node B’s domain specific routing address, also referred to as its Temporary IP address (TIP), to route packets to it. Thus, application layer packets need address translation before they can be routed to their destination. For this purpose, the backbone network contains an address translation database that maintains PIP to TIP translation tables. Every node is responsible for querying the database and replacing the destination PIP address on each application generated IP packet with a routable TIP address. We refer to this address translation and replacement process as

packet mangling. We do not discuss the relative merits and demerits of such an architecture, instead we point the interested reader to [7]. Our focus will be on securing traffic generated by application and network protocol entities resident on nodes in this particular flavor of ad- hoc networks.

B Why use IPsec?

IPSec

is

used

extensively

in

wire-line

IP

networks, and can also be used in ad hoc networks for the following reasons.

It is an open standard that is freely available for implementation.

It

is

modular.

New

encryption

and

authentication algorithms

can

be

incorporated without changes to the system

architecture.

 

IPSec

integrates

with

existing

IP

infrastructure. IPSec traffic can be carried on existing IP networks without modification independent of the underlying physical layer or interconnection topology. IPSec operation is transparent to application layer entities. IPSec is required functionality for IPv6 implementations, so it is forward compatible in case IPv6 is finally deployed.

SECURITY ARCHITECTURE

In an ad-hoc environment, IPSec may be used to set up either end-to-end or hop-by-hop SAs. In the end-to-end case (Figure 2A), SAs are established between every pair of communicating nodes, with no participation of intermediate nodes on the path between the communicating nodes. In the hop-by-hop case (Figure 2B), a node needs to have SAs with each of its immediate link-level neighbors. Thus communication between a pair of nodes will involve the use of SAs between each pair of nodes on the path between the communicating nodes. Table below summarizes the key differences between the two approaches for the ad hoc environment. We decided to adopt end- to-end as opposed to the hop-by-hop SAs in the interests of minimizing SA negotiation overhead and encryption/decryption overhead. Once established, end-to-end SAs are sufficient for peer-to-peer communication, while hop-by-hop SAs require negotiation every time there is a change in the set of immediate link-level neighbors of a node.

3

IPSec may operate either in tunnel or transport mode. In tunnel mode operation, the entire IP packet is encapsulated within a new IP packet, while in transport mode, additions/modifications are made to the IP payload. Per packet overhead is somewhat higher in the tunnel mode of operation because of the need to create a completely new set of IP headers, possibly replicating some of the fields of the inner IP header. The tunnel mode of IPSec operation is primarily intended to prevent traffic analysis when used on IPSec gateways that are located between communicating nodes. Since we adopt the use of end-to-end SAs between communicating nodes, the tunnel mode adds needless encapsulation overhead. We thus decided to adopt end-to-end SAs operating in transport mode.

A:

3 IPSec may operate either in tunnel or transport mode. In tunnel mode operation, the entire

B:

3 IPSec may operate either in tunnel or transport mode. In tunnel mode operation, the entire

Figure 2: A: End-to-End IPSec, B: Hop-by-Hop IPSec

3 IPSec may operate either in tunnel or transport mode. In tunnel mode operation, the entire

A Handling IP Address Change

In our assumed ad-hoc network architecture, the TIP of a node can change when it moves from one domain to another. The packet mangling

functionality discussed in the earlier section interacts with IPSec as shown in Figure 3. An application at Node A generates a packet with PIP source and destination addresses. Once the

packet mangling has been completed, the destination PIP address is replaced with the corresponding TIP address. The IPSec modules then add on ESP/AH headers to the packet and encrypt the data payload. The packet is then transmitted on the network. At Node B, the reverse process occurs. The packet is first decrypted by the receiver IPSec module. The Mangler module then replaces the destination TIP with the PIP address. Finally the packet is received by the peer application on Node B. An RFC-XX compliant IPSec implementation will not work with the mangling process as described here. The next section describes additional configurations and IPSec modifications required to permit IPSec operation in our mobile ad-hoc environment.

Node A Node B Application S(PIP-A)+D(PIP-B)+Data Mangler S(PIP-A)+D(TIP-B)+Data IPSec IPSec S(PIP-A)+D(TIP-B)+ESP/AH+Encrypted(Data) Intermediate Intermediate Node Node
Node A
Node B
Application
S(PIP-A)+D(PIP-B)+Data
Mangler
S(PIP-A)+D(TIP-B)+Data
IPSec
IPSec
S(PIP-A)+D(TIP-B)+ESP/AH+Encrypted(Data)
Intermediate
Intermediate
Node
Node

Figure 3:End-to-End IPSec and Address Mangling

IMPLEMENTATION

IKE protocol message exchanges are used to negotiate SA parameters between nodes A and B. These parameters include the type of security protocol being used (ESP/AH), the keys to be used for encryption and authentication and the desired lifetime of the SA. Once the IKE negotiation completes successfully, the SA has been established between A and B. At this point, an outgoing SA exists at node A and a corresponding incoming SA exists at node B. The Security Policy database (SPDB), as described in [1], is used to determine the outgoing SA to be used for a packet generated at Node A. Typical fields used to determine an outgoing SA are the source IP address and the destination IP address of the packet. Once the outgoing SA is established, entries are made in the SPDB that identify the field values to be used to select the outgoing SA. At Node B, the incoming SA to be used is determined by the

4

Security Parameter Index (SPI), the Security Protocol (ESP/AH) and the destination IP address of the incoming packet. The source and destination addresses used to point to a particular outgoing SA in the SPDB are determined by the inputs to IKE negotiation process. The destination address used to point to a particular incoming SA is also determined by inputs to IKE.

The input parameters to IKE in our implementation were the PIP addresses of the source and destination nodes, rather than their TIP addresses. SAs based on PIPs are valid for their lifetime and do not get invalidated by a change in TIP addresses. Once a PIP based IPSec SA was established, we added an entry in the SPDB that pointed to the same SA, for the TIP address of the same destination node. This allowed mangled packets to be processed by the SA established by IKE. In addition, we also added an entry in the SPDB that pointed to the same SA, for the TIP address of the source node. This ensures protection of packets generated with TIP source and destination addresses, such as routing and auto-configuration protocols. The usage of the same SA by multiple data flows is not disallowed by the IPSec standard.

On the receiver side, we disabled destination address check for received packets. This allowed incoming SA lookups to be performed solely based on the SPI and Security Protocol. Thus packets with TIP destination addresses can be processed by SA that was negotiated using the PIP. Since the SPI is always chosen by the receiver, there is no danger of incoming IPSec packets being processed by the incorrect SA. This approach has also been adopted in draft- ietf-ipsec-rfc2402bis-04.txt and draft-ietf-ipsec- esp-v3-06.txt. In addition, the implementation was successfully tested for interoperability with a node that was configured with only the vanilla FreeSwan IPSec implementation (no Mangler code).

A Key Management

The keys used by IPSec can be generated and

distributed using either a certificate-based approach [6], or a hybrid identity-based scheme [8]. Details of these approaches are not described here due to space constraints. We chose the certificate-based approach for the following reasons.

The certificate-based approach is more suited

for dynamic key generation and distribution than the hybrid approach. This is because the computational overhead (in terms of key generation times) for the hybrid approach is orders of magnitude greater (days/key) than the certificate approach (seconds/key). This is due to the more complex cryptographic algorithms (Maurer-Yacobi, Boneh- Franklin, or Fiat-Shamir) used in the hybrid approach, as compared to the algorithms (Rivest Shamir Adlemen, Digital Signature Standard, or Elliptic Curve Cryptography) used in the certificate-based approach. Since the certificate approach is based on standards (IKE, X.509), it can easily

interoperate

with

COTS

and/or

existing

legacy

systems.

Furthermore,

existing

software

(e.g.

FreeSWAN,

 

other

implementations of IKE, etc.) that have been

tested

and

hardened

in

a

wire-line

environment can be re-used and

tailored/customized

to

the

ad

hoc

environment relatively easily. The certificate approach uses slightly more bandwidth than the hybrid approach. More specifically, the certificate approach uses up to 2Kbits additionally for each node in a traffic flow. This overhead is bearable for most ad hoc networks, except in cases where the link bandwidth is on the order of a few kbps. Figure 4 illustrates the sender-based key distribution approach that we adopted for the ad hoc environment. We reduce revocation bandwidth overhead by choosing a reactive approach for certificate validation by requiring the sender to obtain a non-revocation certificate from the Revocation Authority (RA) and pushing it to the receiver, rather than periodically having the RA proactively push the revocation list to all nodes in the network.

Steps 1 & 2 in the Figure illustrate the certificate distribution process. Host 1 generates and then transmits its public key (for use during IKE negotiation) to the Certificate Authority (CA). In an ad-hoc environment this public key transmission needs to be source authenticated to safeguard against spoofing attacks. This is accomplished by deploying host specific authentication keys at the CA. The CA entity, which typically resides in the backbone segment of our ad-hoc architecture, sends back an X.509

5

certificate for the public key received from Host1. Steps A & B depict the process of obtaining non-revocation (NR) certificates from the Revocation Authority (RA) which also resides in the network backbone. Host1 contacts the RA to receive an NR Certificate indicating that its current public key certificate has not been revoked. (The revocation process itself is outside the scope of our architecture but could conceivably be implemented via intrusion detection mechanisms which detect compromised public keys or compromised nodes). The NR Certificate is used in the IKE negotiation process as shown in Step C. Here, the public key certificate is accompanied by its associated NR Certificate when transmitted to Host2. Host2 verifies the NR status of the received certificate by checking the validity of the NR Certificate using the RA’s public key (which also needs to be pre-deployed at each host). An NR Certificate has an associated validity period, requiring the sender to periodically obtain a fresh certificate prior to participation in an IKE negotiation. Once the NR status has been asserted, the public key from Host1 is authenticated using the CA’s public key deployed at each host.

CA RA Cert(PubKey(Host1)) PubKey(Host1) B Cert(PubKey(Host1)) 1 2 Authenticated NRCertificate Clear A Host1 (Cert(PubKey(Host1), NRCertificate) Host2
CA
RA
Cert(PubKey(Host1))
PubKey(Host1)
B
Cert(PubKey(Host1))
1
2
Authenticated
NRCertificate
Clear
A
Host1
(Cert(PubKey(Host1), NRCertificate)
Host2
C

Figure 4:Key Distribution in Ad Hoc Network The X509 based IKE negotiation process discussed above presents a simple extension to the X509 certificate payload involving the addition of a Non-revocation Certificate obtained from an RA to the certificate payload. The bandwidth overhead of this is minimal because it essentially contains a time stamp and a certificate identifier along with authentication information generated by the RA.

B Processing Latency

While our approach permits the handling of IP address change in ad hoc networks, it is

important to understand the impact of the Mangler mechanism, which permits this dynamism, on the IPSec data flow. We compare the processing delays for packets at a sender node, from generation by an application (mgen) to the point they leave the node’s network interface, in the presence and absence of the Mangling process. This includes processing by the pre-existing IPSec SAs. Figure 5 illustrates the average and median latency in micro- seconds for various packet sizes. The median latency shows tighter bounds than the average in the Mangler case, since our Mangler implementation is at the user-level. A user-level implementation is typically impacted more significantly by interrupts and activity of other applications, than a kernel-level implementation. Hence comparison of the median values in the two cases can be considered more appropriate. As is expected, the latency for the Mangler case is always greater than the non-Mangler case. The median Mangler latency is about 2.2 to 3.7 times the non-Mangler latency, depending on the packet size. A similar latency can be expected at the receiver end. While the Mangler latency is significant relative to the non-Mangler case, it is not much in absolute terms, especially considering that the latency can be expected to further improve with faster machines and a

kernel-level Mangler implementation.

SUMMARY

An IPSec-based security architecture for mobile

ad-hoc networks was presented. Simple

extensions to the IPSec SA lookup process and

Security Policy Database configuration were

used to enable the operation of IPSec in this

environment. Extensions were also proposed to

the X.509 Certificate revocation process to allow operation in a mobile ad-hoc environment. These extensions do not violate existing/proposed standards, which permits easy deployment of our mechanisms in an IP network environment and enables backward compatibility with existing deployments. Initial experimental evaluation reveals that the per- packet latency overhead at the end-host for using our proposed mechanisms is tolerable.

REFERENCES

[1] S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol,” RFC 2401, Nov 1998.

[2] D. Harkins and D. Carrel, “The Internet Key Exchange (IKE),” RFC 2409, Nov 1998.

6

[3] S. Kent and R. Atkinson, “IP Encapsulating Security Payload (ESP),” RFC 2406, Nov 1998. [6]
[3] S. Kent and R. Atkinson, “IP Encapsulating
Security Payload (ESP),” RFC 2406, Nov 1998.
[6] C. Adams and S. Farrell “Internet X.509 Public
Key Infrastructure Certificate Management
Protocols”, RFC 2510, Mar 1999
[4] S. Kent and R. Atkinson, “IP Authentication
Header (AH),” RFC 2402, Nov 1998.
[7] K. Young et. al. “Ad Hoc Mobility Protocol Suite
for the MOSAIC ATD”, Milcom 2003.
[5] ITU, “Information technology - Open Systems
Interconnection - The Directory: Public-key and
attribute certificate frameworks ”, Recommendation
X.509, Mar 2000
[8]
D.
Boneh
and
M.
Franklin
“Identity
based
encryption from the Weil pairing”, SIAM
Computing, Vol. 32, No. 3, pp. 586-615, 2003.
J.
of
Mangler Case
Mangler Case
4000
4000
4000
1200
1200
1200
3500
3500
3500
1000
1000
1000
3000
3000
3000
800
800
800
2500
2500
2500
2000
2000
2000
600
600
600
1500
1500
1500
400
400
400
1000
1000
1000
200
200
200
500
500
500
0 0 0
0 0 0
64
64
64
128
128
128
256
256
256
512
512
512
1024
1024
1024
64
64
64
128
128
128
256
256
256
512
512
512
1024
1024
1024
Packet Size (Bytes)
Packet Size (Bytes)
Packet Size (Bytes)
Packet Size (Bytes)
Packet Size (Bytes)
Packet Size (Bytes)
Non-Mangler Case
Non-Mangler Case
Average Latency (usec)
Average Latency (usec)
Average Latency (usec)
Median Latency (usec)
Median Latency (usec)
Median Latency (usec)

Figure 5:Packet Latency for Mangler and non-Mangler case