SECURING AD-HOC NETWORKS USING IPSEC

Abhrajit Ghosh
Telcordia Technologies
Applied Research
Piscataway, NJ

Rajesh Talpade
Telcordia Technologies
Applied Research
Piscataway, 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 perpacket latency overhead at the end-host for
using our proposed mechanisms is tolerable.
Keyword:
Security

Mobility,

Ad-hoc

networks,

IPSec,

INTRODUCTION
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. IETFs
IPSec protocol suite [1] has traditionally been
useful in protecting wire-line networks from

Moncef Elaoud
Telcordia Technologies
Applied Research
Piscataway, NJ

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

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, replayprotection and non-repudiation of IP traffic.
These services are provided by establishing
Security Associations (SAs) between IPSecenabled 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.

Border Router

IP BACKBONE

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 intradomain 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 nodes 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 Bs PIP address to identify it
as a traffic destination. On the other hand, the
routing and address configuration protocols
make use of Node Bs 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 adhoc 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 endto-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.

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

A:

Node B
Application

Application
S(PIP-A)+D(PIP-B)+Data

Mangler

Mangler
S(PIP-A)+D(TIP-B)+Data

IPSec

IPSec

B:

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

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

IPSec

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

Intermediate
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 draftietf-ipsec-rfc2402bis-04.txt and draft-ietf-ipsecesp-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,
BonehFranklin, 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 RAs 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 CAs public key
deployed at each host.
CA

RA
Cert(PubKey(Host1))

PubKey(Host1)

Cert(PubKey(Host1))

1
2

Authenticated

NRCertificate

Clear

A
Host1

(Cert(PubKey(Host1), NRCertificate)

Host2

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 nodes 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 microseconds 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 perpacket 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.
[4] S. Kent and R. Atkinson, IP Authentication
Header (AH), RFC 2402, Nov 1998.
[5] ITU, Information technology - Open Systems
Interconnection - The Directory: Public-key and
attribute certificate frameworks , Recommendation
X.509, Mar 2000

[6] C. Adams and S. Farrell Internet X.509 Public

Key
Infrastructure
Certificate
Management
Protocols, RFC 2510, Mar 1999
[7] K. Young et. al. Ad Hoc Mobility Protocol Suite
for the MOSAIC ATD, Milcom 2003.
[8] D. Boneh and M. Franklin Identity based
encryption from the Weil pairing, SIAM J. of
Computing, Vol. 32, No. 3, pp. 586-615, 2003.

4000
3500
3000
2500
2000
1500
1000
500
0

Median Latency (usec)

Average Latency (usec)

Mangler Case

64

128

256

512

1200
1000
800
600
400
200
0

1024

64

128

256

512

Packet Size (Bytes)

Packet Size (Bytes)

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

1024