Professional Documents
Culture Documents
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
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
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:
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
Intermediate
Node
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.
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
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
4000
3500
3000
2500
2000
1500
1000
500
0
Mangler Case
64
128
256
512
1200
1000
800
600
400
200
0
1024
64
128
256
512
Non-Mangler Case
Figure 5:Packet Latency for Mangler and non-Mangler case
1024