vulnerable to packet type analysis attacks thus do not provide complete ... requiring operations, this goal effectively
Secure Anonymous routing in Ad Hoc networks T.Rajendran
K.V.Sreenaath
Security Technology Group, Motorola India Private Limited, Bangalore, India.
Research Scholar
[email protected]
[email protected] ABSTRACT Communication in Ad Hoc networks relies on the routing functionality of the intermediate nodes. Secure routing and preventing traffic analysis are important criterion for secure anonymous communication in Ad Hoc networks. By analyzing the traffic in ad hoc networks, the location and identity of the nodes can be found thereby losing anonymity. A number of techniques are available for anonymous routing. Existing techniques are vulnerable to packet type analysis attacks thus do not provide complete anonymity and security. Also they involve more cryptographic overhead. We propose a secure anonymous communication system for Ad Hoc networks involving less cryptographic operations and also addressing various drawbacks in existing techniques providing complete anonymity.
2.2 Shared secret key between Source and Destination We assume the availability of a shared secret key K shared between any two communicating entities.
2.3 IP datagram In this system, the route request, route reply, data and other communication packets (See section 8) will form part of the IP datagram section of the IP packet. The packet model is shown in Fig.1.
Keywords anonymous routing; ad-hoc network.
1. INTRODUCTION Communication in Ad Hoc networks relies on the routing functionality of the intermediate nodes. Secure routing and preventing traffic analysis are important criterion for secure anonymous communication in Ad Hoc networks. By analyzing the traffic in ad hoc networks, the location and identity of the nodes can be found thereby losing anonymity. A number of techniques are available for anonymous routing [1], [2], [3], [4], [5]. Existing techniques either involve more cryptographic overhead or do not provide complete anonymity and security. We propose a secure anonymous communication system for Ad Hoc networks involving less cryptographic operations and also addressing various drawbacks in existing techniques providing complete anonymity.
3. Adversary model
2. ASSUMPTIONS 2.1 One-way hash function H k (m) is a fast, one-way, collision-resistant hash function that
3.2 Active adversary
takes a key(k) and message(m) as input and maps it to a fixed length bit string known as digest or checksum of the message.
Figure 1. Packet Model of Secure Anonymous Routing in AD Hoc networks
We assume the existence of two different adversaries.
3.1 Passive adversary External global passive adversary who could eavesdrop all possible communications in the Ad Hoc network trying to learn the identity of the source or destination or routing path of a packet.
Active cooperating nodes within the network that participate in tandem trying to learn about the nodes, their identity, etc., through the route or data messages that pass through the network.
4. GOALS Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference’04, Month 1–2, 2004, City, State, Country. Copyright 2004 ACM 1-58113-000-0/00/0004…$5.00.
The major issues that are addressed through this secure anonymous Ad Hoc routing model are
4.1 Anonymity of sender & receiver In this model the intermediate nodes en route have no information about the sender and receiver identity, their location within the network and distance between the communicating nodes.
Similarly, the source and destination nodes will not be able to infer any information about the intermediate nodes en route.
network, every node in the network needs to generate a fresh key pair for every RREQ that is released in the network. The private key is stored in the node’s routing table. Note that the cost of generating public/private key pairs is non-negligible.
4.2 Security Various protocol functionalities such as route discovery, route maintenance and data transmission are secured from attacks such as packet type analysis.
•
RREP messages carry no identifier that can be linked to the RREQ messages. This means that for a node to decide whether it has to forward a RREP or not, it has to try to decrypt it with every private key it has stored in its routing table.
•
The destination is identified using a trapdoor identifier of the following form: kSD[dest] where dest is a public binary string that indicates that “you are the destination if you see this” and kSD is a shared key between the source and destination. When a node receives a RREQ it will have to decrypt the trapdoor identifier with every key it shares with other nodes.
4.3 Efficiency The proposed model has low processing overhead. As nodes in an ad-hoc network are devices not capable of complex, time requiring operations, this goal effectively means that the protocol should make minimize the use of public key cryptography. As public key encryption/decryption requires considerable time & processor compared to symmetric encryption/decryption techniques, the proposed protocol should make use of symmetric cryptography effectively.
5. DRAWBACKS OF EXISTING TECHNIQUES Currently existing models/techniques for secure anonymous communication suffer from one or more of the following drawbacks.
5.4 Drawbacks of SDAR •
It is vulnerable to attacks based on packet type recognition that are explained in section 5.2.
•
Route discovery is very inefficient as it requires every forwarding node to perform a public key decryption, a public key encryption and a signature generation for every RREQ message it forwards. Again this is a substantial cost as RREQ messages are flooded over the entire network.
•
The destination learns the identity of all the forwarding nodes on the path.
•
In SDAR it is assumed that every broadcast contains the identity of the broadcasting node in plaintext.
5.1 Efficiency Existing techniques are not efficient. More cryptographic overhead are involved in it. For example in ASR and ANODR, every forwarding node has to generate a fresh public/private key pair while forwarding RREQ packets. Similarly while receiving a RREP it has to decrypt with the list of private keys it is having as the RREP packet doesn’t have any information to point to the appropriate key.
5.2 Attacks based on packet types In the existing anonymous communication techniques, it is easy for the global passive adversary to find the type of each transmitted packet such as route request (RREQ), route reply (RREP), data (DATA) and Jitter (JITTER) packets. RREP packets can be easily traced along its path revealing the identity of the sender, receiver & nodes en route. Though there may be other RREP packets injected to deceive the tracing, most existing techniques pass a route identifier in the RREP packet. This facilitates identifying the route reply messages that correspond to route requests, thereby revealing the identity of the nodes. Though finding the identity of the intermediate nodes are slightly difficult, finding the identity of the source and destination is quite an easy task. The solution to this attack is to hide the packet type from adversaries. But at the same time the intended nodes should be able to identify the packet based on its type with much ease.
5.3 Drawbacks of ASR and ANODR •
It is vulnerable to attacks based on packet type recognition that are explained in section 5.2.
•
Every forwarding node has to generate a fresh public/secret key pair for every RREQ message it forwards. As these RREQs are flooded over the entire
5.5 Drawbacks of MASK •
It is vulnerable to attacks based on packet type recognition that are explained in section 5.2. It is somewhat protected from this type of attack by making use of different LinkIDs (A LinkID is an identifier for a link connecting two nodes.) when transmitting across different hops. However, packets belonging to a single route always use the same LinkID, which again makes tracing the packets specific to that route possible thereby revealing identities of nodes.
•
In addition to this in [1], the RREQ packets and the destination identifier in RREQ packets are exposed to passive adversaries.
•
The final destination is contained within every RREQ message in plaintext.
•
MASK relies on a tight synchronization of keys and pseudonyms between neighboring nodes.
5.6 Drawbacks of ARM •
It is vulnerable to attacks based on packet type attacks that are explained in section 5.2.
•
The source has to generate fresh public/private key pair when it generates an RREQ. Every other node receiving & forwarding the RREQ should perform a public key encryption operation to send a key that will aid in the destination to generate reply onion.
6. PROPOSED MODEL The proposed model (Example of which is shown in Fig. 2) for secure anonymous Ad Hoc communication addresses the issues discussed in the previous section.
i th element from the hash chain LH i (0 ≤ i ≤ N ) . The receiver will keep track of the element in the hash chain that should be available in the next packet. By keeping track of the hash in the packet, receiver, ‘R’ will be able to identify that the packet was indeed sent by node ‘S’. All the packet data including packet type will be encrypted by the shared key LK SR . Using this technique ‘S’ can send packets to ‘R’ without any neighbour nodes having any idea of the identity of the source/ destination or type of the packet. Thus global adversaries will not be able decipher the sender/ receiver identity, route path and packet type by analysing the traffic.
6.3 Anonymous broadcasting During bootstrapping, the broadcasting node(S) creates a hash chain BH 0 to BH N and sends BH N to the receiving nodes(R) together with the shared key BK . The would
have
( N − i)
the
th
i th
element
broadcasted packet from
the
hash
chain BH N −i . The receiving nodes will not be able to Figure 2. Example of the network in the proposed model
generate BH j , given BH j +1 , but would be able to ascertain that
the
packet
was
that BH j +1
Hash chains are used extensively in various cryptography applications such as one-time passwords, server-supported signatures, micropayments, etc. Hash chain is formed by repeatedly applying the one-way hash function h(k , m) to a
6.4 Configuration
h1 = h(k , h0 ) , h2 = h(k , h1 ) , …, hN = h(k , hN −1 ) . The proposed model uses hash chains to effectively hide the sender, receiver identity and packet-type in the packets being sent. This is explained in Section 6.2. This chain is one-way, in that knowledge of of hi − j
hi + j (j ≥ 1)
hi
cannot be calculated with the
and without the knowledge
(j ≤ 1) . This is due to the fact that the hash chain is built
on a one-way hash function. This one-way property can be used for authentication of the nodes during Anonymous broadcasting. This is explained in Section 6.3.
6.2 Hiding the packet identity During bootstrapping, Sender(S) and receiver(R) will adhere to a hash sequence LH 0 to LH N and a shared key ( LK SR ) is established between them. Each packet sent by the sender will include an element from the hash chain. The
i
th
transmitted packet
Pi (0 ≤ i ≤ N ) will have the
by
S
by
verifying
= H ( BK , BH j ) .
6.1 One way hash chain
random seed h0 . The hash chain will be as follows
broadcasted
Whenever a node in the communication network wishes to update its configuration parameters such as broadcast key/hash or Link key/hash then it uses the configuration packet (explained in section 7.5) to update neighboring nodes. This prevents the passive adversary from analyzing repeated patterns in packets thereby deducing the keys shared between the nodes.
6.5 Jitter To confuse the passive adversary, a node can send Jitter packets (explained in section 7.6 and 7.7) to any node. In addition, a node can also request some other node to send some jitter packets. This can fool the passive adversary by disguising that there are some active messages between those nodes between which there exists no active communication.
7. SECURE ANONYMOUS ROUTING PROCEDURE The various procedure/ protocol followed for secure anonymous routing in Ad Hoc networks are explained below in detail.
7.1 Boot Strapping 1) ' A' broadcasts its Public initialize packet..
Key, PU K A in a Bootstrap
2)
LK BA , BBK , 3)
B − A,
receives PK A and generates Link Key
' B'
Link Hash
B − A , LH BA1 ,
Broadcast Hash,
BBH ,
5)
Broadcast Key,
{RREQ + RREQ − DATA}N BK ).
Broadcast Authentication
Hash,
BBAH .
' B'
then encrypts LK BA , LH BA1 , BBK , BBH , BBAH
using
PU K A and sends the encrypted message to ' A'
6)
in a
' N ' appends one bytes ‘type’ value of ‘1’( type value for RREQ is defined as ‘1’) before RREQ-DATA and encrypts the resultant data with N ' s broadcast key. (That isIt appends its broadcast hash and its broadcast authentication hash
with
{RREQ + RREQ − DATA}N BK .
resultant data is the route request data. 7)
' N'
generates the broadcast hash
Bootstrap Request packet. 4)
' A'
receives and decrypts it using his Private Key
and stores
authentication hash
PR K A
LK BA , LH BA1 , BBK , BBH , BBAH . LK AB , LH AB1 , ABK , ABH , ABAH
8)
5)
' A'
6)
encrypts them using LK BA and sends it to ' B ' in a BootStrap Response packet. ' B ' receives the encrypted message from ' A' and stores
generates
and
LK AB , LH AB1 , ABK , ABH , ABAH . BOOTSTRAP-PKT
BID (Broadcast ID)
Bootstrap data
16 bytes
4 bytes
variable
N BH i
appends
Broadcast Broadcast HashAuth Hash- The below fields encrypted by key
N BH i
N BAH n
and
the
N BK
Type route Hashed Unique Encrypted fieldid IdentifierSession RREQKey‘1’ K shared sess K shared
H
16 bytes
1 byte
2 byte
(U )
16 bytes
{K
}
32 bytes
Figure 4. Route Request packet format
A - PU K A (128 bytes). For bootStrap request packet the will
be
{LK BA , LH BA , BBK , BBH , BBAH }PUKA (112
7.3 Route Request handling by Intermediate nodes Any intermediate node including the destination handles the route request as follows. 1)
{LK AB , LH AB , ABK , ABH , ABAH }LK BA (112
' A'
receives the broadcast message by identifying the
broadcast hash,
bytes). For bootStrap response packet the bootstrap data will be
Broadcast
neighboring nodes.
16 bytes
The BID field is used to relate the bootstrap request or response packets with the appropriate bootstrap initialize packet. For bootstrap initialize packet the bootstrap data will be Public Key of data
N BAH n and
N BH i and
N BAH n with {RREQ + RREQ − DATA}N BK . ' N ' then broadcasts the route request data to
Figure 3. Bootstrap packet format
bootstrap
The
2)
It verifies
N BH i
N's
from the lookup table.
identity by generating
N BAH n +1 from
bytes).
N BAH n .
7.2 Route Request generation by Source
same as the broadcast authentication hash present in the lookup up table corresponding to ' N ' then it means that the verification is successful and the packet has originated from ' N ' .
The source node generates the route request as follows. 1)
The source node, ' N ' , generates Session Key,
and
between the source
3)
and the destination. (Destination- The node for which route is requested. Source- The node which requests the route for the destination). ' N ' hashes the unique identifier U with the shared
4)
encrypts it with Shared key,
2)
K sess
K shared ,
key K shared . 3)
It generates a 2 byte value called ‘route id’ to keep track of the route request.
4)
' N'
appends the encrypted session key,
with hashed unique identifier, form RREQ-DATA.
hK shared (U )
' A'
then generates
N BH i +1
from
N BH i
and stores the
same in the lookup table corresponding to node It then hashes the known shared key,
K shared
' A' . 'U '
with
and
checks if it matches with the Hashed Unique Identifier in the Route Request message. If it matches then it means that the node ' B ' is the destination for the route request and hence a)
' A'
decrypts Encrypted Session Key-
{K sess }K shared
in the RREQ message and stores the session key,
{K sess }K shared and ‘route id’ to
If the generated broadcast authentication hash is
K sess . b)
Follows the procedure to send Route Reply message.
5)
If the hashed Unique identifier did not match with what was present in the request, then it means node ' A' is not the destination for the route request and hence should broadcast
N BH n
the request further. It replaces
N BAH n
and
' A' , ABH i and ABAH n . ' A' encrypts the RREQ + RREQ − DATA present in
Hash of
7)
It
ABH i
appends
through which the route reply came, 2)
{RREQ + RREQ − DATA} ABK and
with
broadcasts
the
It verifies the hashed value of the universal identifier 'U ' present in the Route reply packet with the hash computed with the universal identifier along with its session key, has originated form the destination. It copies the route key and the route hash present in the Route Reply message in to the Active Route Table corresponding to the route id in the forward entry columns. That is in
same.
7.4 Route Reply handling by Source The source node 'N' handles the route reply as follows. 1)
2)
Node
' N'
hash,
RH routeidi
generates the route key,
RK routeid
and route
for the corresponding route-id.
It adds an entry in its Active Route Table for the corresponding route id. It will add the route-id and then add Route
RK routeid _ rev
Key
and
route
5)
LH BAii to LH BAi +1i
5)
' N ' then deletes the entry corresponding to the route-id in the RREQ Table.
7.6 Route Reply handling by Source Any node neither source nor destination 'N' handles the route reply as follows. 1)
It
decrypts
{RREP + route − id + RK routeid + RH routeid i }LK DN using the Link Key associated with the neighboring node
id, hK
Reply are stored as
sess
'U '
using 2)
(U ) , RK routeid
and
RH routeid _ revi .
' N ' checks for corresponding route id entry in the RREQ table and if the timestamp is greater than zero, then it gets the
' NE '
LK DN and
Link Hash
LH DNi
for the neighbor node, ' N E ' to which the route response has to be sent. ' N ' encrypts the appended data, RREP-type, route-id,
LK DN
then
RK routeid _ revi .
4)
It stores
5)
‘forward’ column of the Active Route Table corresponding to the route id and replace them in place of existing Route Hash and Route Key in the route reply message. ' N ' encrypts the combined data, RREP-type, route-id,
RK routeid _ fwd
and
and Route Hash,
RK routeid _ fwd i
Route Key, Route Hash with the Link Key
to form
LK NM
in the
shared
the neighbor node 'M ' to form {RREP − type + route − id + RK routeid + RH routeidi }LK NM
with
appends
{RREP − type + route − id + RK routeid + RH routeidi }LK DN6) to the Link Hash,
and
' N ' then generates a new Route Key RK routeid _ fwd and RK routeid _ fwd i .
{RREP − type + route − id + RK routeid + RH routeidi }LK DN It
RK routeid _ rev
3)
from the table and
Route Key, Route Hash with the Link Key
8)
columns.
It appends the type, RREP- value of ‘2’ with 2 byte route-
hence gets the Link Key
7)
RH routeid _ fwd i
It updates the Link Hash
hash
K sess , hK sess (U ) .
next hop id, i.e. the neighbor node,
6)
and
through which the route reply came, LK BA . It then stores the Route Key and the Route Hash in the Route Reply message in to the Active Route Table in the ‘reverse’ columns. That is Route Key and Route Hash from the Route
It generates a 16 byte hash of Unique identifier the session key,
4)
RK routeid _ fwd
4)
RH routeid _ revi for that corresponding route id. 3)
LK BA .
K sess . If they are same then it means that the Route Reply 3)
ABAH n
and
decrypts
using the Link Key associated with the neighboring node
the received Route Request message with its broadcast key,
ABK .
It
{RREP − type + route − id + RK routeid + RH routeidi }LK DN
with
corresponding Broadcast Hash and Broadcast Authentication
6)
1)
LH DNi to form the Route reply message
and sends the same to the next hop neighboring node. ' N ' deletes the entry corresponding to the route id in the RREQ Table.
7.5 Route Reply handling by Destination The destination node 'N' handles the route reply as follows.
It
appends
LH NM i to form the Route reply message and sends the same to the next hop neighboring node, ' M ' . ' N ' deletes the entry corresponding to the route id in the
to the Link Hash,
7)
then
{RREP − type + route − id + RK routeid + RH routeidi }LK NM
RREQ Table.
7.7 Data forwarding by Source 1) Source node ' N ' looks for the route-id in the Active Routes table and fetches hash RH routeid _ fwd n , key RK routeid _ fwd . 2)
of the data with
K sess
and/or
the session key
hK sess (data ) . If the hash is computed it is appended with 3)
data. Hash for the corresponding routeid and one byte ‘type’ field, DATA- value of ‘3’ is appended with the data packet (data packet (plain text or encrypted text) + computed hash (optional)). And the resultant is encrypted using the Route Key
RK routeid _ fwd
for the corresponding route-id.
7.8 Data forwarding by Destination 1) The Route Key RK routeid _ rev corresponding to the routeid found using the Route Hash 2)
RH routeid _ revi in the received
message is fetched from the Active Route Table. It
decrypts
{DATA + {data}K sess + hK sess (data )(opt )}RK routeid in the received message using 3) 4)
RK routeid _ rev .
If the data is encrypted it is decrypted and if hash is computed then it is verified. If data is verified (If hash is computed on the data in the received packet then it is recomputed on data using
RH routeid _ revi )
then
Node
'N'
updates
RH routeid _ revi with RH routeid _ revi +1 .
7.9 Data forwarding by Intermediate nodes 1) Intermediate node ' N ' checks for a matching forward entry hash id in the Active Route Table. If there is one then it fetches the corresponding forward/ reverse Route Hash
2)
RH routeid _ fwd i ,
RH routeid _ rev j and
Keys RK routeid _ fwd and
RK routeid _ rev .
Route
' N' decrypts {DATA + {data}Ksess + hK sess (data )(opt )}RK routeid RK routeid _ rev . ' N' encrypts DATA + data/{data}Ksess + hK sess (data )(opt )
using 3)
using
RH routeid _ fwd i
which
results
in
{DATA + {data}Ksess + hK sess (data)(opt )}RK routeid _ fwd
It
appends
{DATA + {data}Ksess + hK sess (data)(opt )}RK routeid _ fwd with 5)
It then encrypts the data with the session key, computes hash
4)
It
RH routeid _ fwd i
updates
and sends the packet.
RH routeid _ fwd i to
RH routeid _ revi
to
RH routeid _ fwd i +1
RH routeid _ revi +1
and
in the Active Routing
Table.
8. ANALYSIS In this section we will analyze both the anonymity and security aspect of the proposed mechanism.
8.1 Anonymity Analysis None of the packets bear the identity of a node. Our protocol uses the techniques from existing anonymous routing protocols to hide the packet identity in the packets. Additionally, the protocol is safe from packet type analysis attacks which make it impossible to decipher information about packet types. Thus anonymity is preserved in the proposed protocol.
8.1.1 Packet type analysis attack In the conventional anonymous routing mechanisms, the packet type, such as Route Request, Route Reply, Data and Jitter will go unencrypted. This aids in analyzing the packet based on its type. For example, by matching route request packet flow from one node to the other and by corresponding mapping of route reply messages, it can be found that a route is established between two nodes. The node at which the route request ends and the route reply originates is the destination node while the node at which the route reply ends is the source node with respect to route establishment. This type of attack is overcome in the proposed mechanism by encrypting the type of the packet along with other information (see section 7.2). Therefore, only the node with which the link key LK is shared can decrypt the packet and hence see the packet type.
8.1.2 Flow Analysis Attacks By careful analysis of constant flow of packets between nodes, it can be inferred that the communicating nodes are busy nodes and constant traffic is exchanged between. By further analysis of frequency of exchange of packets along a particular route, the end point of communication can be found. To prevent this, existing anonymous routing mechanisms propose a packet type called Jitter (see section 7.6 and 7.7). Jitter packets are packets that are used to keep the idle routes busy with flow of packets. However, they do not mean or communicate anything between the communicating end points. This has serious drawbacks in existing mechanisms in which simple analysis of the packet type reveals that the packet is Jitter packet. This is overcome in the proposed mechanism by encrypting the Jitter Packet type, which finally gives real meaning in disguising the traffic analyzer.
8.1.3 Identity Privacy In the proposed mechanism the communication between two end points happen through the key,
K shared
shared between them.
Both in the route request and during the data transfer phase, the
messages are transferred between the end points through the shared key which identifies the end point of communication without revealing the nodes’ identity.
route request from its neighbor, if the hash does not match then it is considered to be a fake packet and is neither processed further nor sent to other nodes.
8.1.4 Location Privacy
8.2.3 Route Maintenance Attack
In conventional mechanisms, attacks on location privacy are achieved as follows. An intermediary node that forwards the route request and route response appends fixed length information. On careful analysis of the length of the packet, the distance between the source and the intermediate node can be found. In the proposed mechanism, intermediate nodes do not append anything. Rather, the hash gets replaced and decryption and encryption of the message takes place. This does not result in appending any fixed length information thereby not revealing location of the nodes.
Route maintenance attacks are carried by malicious nodes by sending route error packet to re initiate the route discovery process. However, in the proposed mechanism this cannot be carried because, there is shared key for every specific route between the routing nodes. Only upon using those keys the route error packets can be exchanged between the routing nodes to change the route or to re initiate the route discovery mechanism. This makes it difficult for the malicious node to generate the route key and fake a route error packet. However, if the routing node becomes a malicious node then prevention of such an attack becomes difficult to handle in the proposed mechanism.
8.2 Security Analysis 8.2.1 Passive Attacks The most common attack on routing is malicious nodes silently refusing to perform the preferred functions such as forwarding route request, route response, etc. The proposed mechanism does not have a model such as watch dog [ref- see the paper and add the reference] as the packet are modified node by node basis.
8.2.2 Distributed Denial of Service (DDoS) Attack In anonymous routing mechanism, Distributed Denial of Service (DDoS) attack can be carried in two ways.
8.2.2.1 Many-to-one attack In this type of attack many nodes try to identify a target and exhaust its resources. However, this is prevented in the proposed mechanism as Identity Privacy is ensured.
8.2.2.2 One-to-many attack In this type of attack one node intends to attack multiple nodes by sending fake route request or route response. In the proposed mechanism sending fake route response is not possible since the node that receives the route response from its neighbor will match it with the route id of the route request that was sent from it. The fake route request packet scenario is also prevented in the proposed mechanism as follows. Every node that sends a route request will use the key and hash chain shared with its neighbor to send the route request. In the receiving node, on reception of the
9. REFERENCES [1] Yanchao Zhang, Wei Liu, Wenjing Lou. “Anonymous communications in mobile ad hoc networks”, INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies, March 2005, pp. 19401951, vol.3, 2005. [2] Bo Zhu, Zhiguo Wan, Kankanhalli, M.S, Feng Bao, Deng, R.H, "Anonymous secure routing in mobile ad-hoc networks.", 29th Annual IEEE International Conference on Local Computer Networks (LCN'04), pp. 102-108, 2004. [3] Stefaan Seys, Bart Preneel, K.U. Leuven, “ARM: Anonymous Routing Protocol for Mobile Ad Hoc Networks.”, AINA 2006, 20th International Conference on Advanced Information Networking and Aplications. [4] J. Kong and X. Hong. “ANODR: Anonymous on demand routing with untraceable routes for mobile ad-hoc networks” MobiHoc 2003, In Proceedings of the 4th ACM International Symposium on Mobile Ad hoc Networking and Computing, pp. 291–302, 2003. [5] A. Boukerche, K. El-Khatib, L. Xu, and L. Korba. “A novel solution for achieving anonymity in wireless ad hoc networks”, In Proceedings of the 1st ACM international workshop on Performance evaluation of wireless ad hoc, sensor, and ubiquitous networks, pp. 30–38, 2004. [6] C. Perkins, E. Belding-Royer, S. Das. "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
