18.11.2014 Views

Anais - Engenharia de Redes de Comunicação - UnB

Anais - Engenharia de Redes de Comunicação - UnB

Anais - Engenharia de Redes de Comunicação - UnB

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

observations, the adversary may conclu<strong>de</strong> that the session initiator is one of the Mesh<br />

no<strong>de</strong>s that are in both rings.” [Wu and Li 2006]<br />

3. The new Proposal<br />

Our protocol employs a principle similar to that one presented by WuLi in their private<br />

onion ring protocol. That is, it avoids that a no<strong>de</strong> directly sends data (e.g., an access request<br />

or uplink data) to the gateway router. Instead, no<strong>de</strong>s should wait for specific tokens<br />

in or<strong>de</strong>r to anonymously communicate. However, other than using WuLi’s ring routing<br />

approach, we propose a probabilistic routing protocol to make routes more flexible. As<br />

such, our method overcomes the drawbacks of the former proposal of having a fixed ring<br />

route topology.<br />

3.1. Overview<br />

Our proposal consists of three phases: the access phase, the downlink phase, and the uplink<br />

phase. The access phase is inten<strong>de</strong>d to grant to mesh no<strong>de</strong>s anonymous access to<br />

gateway services. The downlink phase follows the access phase and it aims at anonymously<br />

<strong>de</strong>livering data to the requester. And finally, the uplink phase takes place when a<br />

no<strong>de</strong> wants to anonymously send uplink data to the gateway.<br />

In the access phase, the gateway periodically generates access tokens and <strong>de</strong>livers<br />

them to mesh no<strong>de</strong>s. The gateway <strong>de</strong>livers a token to one the no<strong>de</strong>s next to itself. After<br />

receiving it, the no<strong>de</strong> either forwards it to another hop or uses it to make an access request<br />

to the gateway. In the former case, the no<strong>de</strong> performs cryptographic operations on the<br />

token before forwarding it. In the latter case, the mesh no<strong>de</strong> modifies the token to obtain<br />

a new one containing the no<strong>de</strong>’s request. In either case, the no<strong>de</strong>s are free for choosing<br />

the next hop. After the token visits a <strong>de</strong>fined number of hops, the last hop sends it back to<br />

the gateway.<br />

The downlink phase works similar as proposed by WuLi. In this phase, the gateway<br />

provi<strong>de</strong>s data from an Internet address requested by a specific mesh no<strong>de</strong>. These<br />

data are <strong>de</strong>livered as an onion packet through a given route, chosen by the gateway. Each<br />

no<strong>de</strong> in this route <strong>de</strong>crypts one layer of the onion to discover the next hop and then forwards<br />

the packet to it. If the no<strong>de</strong> is the requester, it will obtain the plain downlink data<br />

after <strong>de</strong>crypting the onion’s layer. Finally, the uplink phase occurs when no<strong>de</strong>s want to<br />

asynchronously send uplink data up to the gateway. This phase is based on the same i<strong>de</strong>a<br />

used in the access phase. In or<strong>de</strong>r to send uplink data, active no<strong>de</strong>s should wait until a<br />

so-called uplink carrier arrives. As in the access phase, this carrier, or token, is cast in the<br />

network by the gateway. The next procedures also follow as before, except that the active<br />

no<strong>de</strong> inserts uplink data into the token, instead of an access request.<br />

3.2. Assumptions and Attack Mo<strong>de</strong>l<br />

The assumptions and the attack mo<strong>de</strong>l of our scheme are similar to that ones employed<br />

by Wu and Li in their scheme. An adversary can learn which Internet address is being<br />

accessed, but it cannot confirm which mesh no<strong>de</strong> performed a request to this address. This<br />

means that the no<strong>de</strong> that performed the request (i.e. the active no<strong>de</strong>) is hid<strong>de</strong>n within a<br />

group of mesh no<strong>de</strong>s. In addition, each mesh no<strong>de</strong> and the gateway are assumed to have<br />

enough computer resources to perform the operations required.<br />

341

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!