[Dataset] umass/diesel (v. 2008-09-14)

top

The following traces have been added: 
transfer/fall2007, transfer/ap_connectivity, and transfer/vifi.
		

The changed components are as follows:

@MISC{umass-diesel-2008-09-14,
  author = {John Burgess and Brian Neil Levine and Ratul Mahajan and John Zahorjan and Aruna Balasubramanian and Arun Venkataramani and Yun Zhou and Bruce Croft and Nilanjan Banerjee and Mark Corner and Don Towsley},
  title = {{CRAWDAD} data set umass/diesel (v. 2008-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel},
  month = sep,  
  year = 2008
}
					

This dataset includes the real mobility and real transfers of the bus-based 
DTN (Disruption-tolerant-network) testbed, called UMassDieselNet, 
operating from the UMass Amherst campus and the surrounding county.

We have constructed a DTN testbed composed of 30-40 buses 
operated by the UMass Amherst branch of the Pioneer Valley Transport Authority 
(PVTA) that we have fitted with a custom package of off-the-shelf hardware. 
This testbed is called UMassDieselNet. The transit buses service an area 
sparsely covering approximately 150 square miles.  

The route each bus is placed on each day is chosen by the garage dispatcher and 
can change during the day.  Buses can leave the network at any time.
We did not try to automatically determine the routes of buses, though this is 
possible with some significant effort. We decided against this approach 
after finding GPS data often inconsistent or containing gaps where line-of-sight 
to satellites was lost.

The testbed began operating in May 2004 with five buses.
Each bus carries a HaCom Open Brick computer (P6-compatible 577Mhz CPU, 256MB RAM). 
An 802.11b Access Point (AP) is attached to each brick to provide DHCP access
to passengers and passersby. A second USB-based 802.11b interface constantly scans 
the surrounding area for DHCP offers and other buses. Each bus also has a GPS device
attached to the brick. Each brick runs Linux on a 40GB notebook hard drive.

See the metadata of each traceset or trace for details of collection methodology.

[Traceset] umass/diesel/throwbox (v. 2007-12-02)

top

the initial version

@MISC{umass-diesel-throwbox-2007-12-02,
  author = {Nilanjan Banerjee and Mark Corner and Brian Neil Levine},
  title = {{CRAWDAD} trace set umass/diesel/throwbox (v. 2007-12-02)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/throwbox},
  month = dec,  
  year = 2007
}
					

This traceset was collected during the throwbox deployment in Umass DieselNet 
in Summer 2006. The traces contain bus-bus transfer records and bus-throwbox 
transfer records.

One solution for improving DTN performance is to place
additional stationary nodes in the network, which increases the
number and frequency of contact opportunities. We proposed 
the use of throwboxes within a DTN for this purpose. Throwboxes 
are inexpensive, battery-powered, stationary nodes with radios 
and storage. When two nodes pass by the same location at different 
times, the throwbox acts as a router, creating a new contact 
opportunity. 

To support a real-world test of the throwbox, we used our
DTN testbed, the UMassDieselNet. The testbed normally
consists of 40 buses covering an area of more than 150 square
miles. However, when the experiments were performed, during
a reduced summer bus schedule, only 10 buses were running on
three routes. Each bus is a highly mobile DTN node using a
small computer with an attached access point and WiFi interface.
Buses constantly scan for other nodes and transfer DTN
data whenever a connection can be made.

We augmented the equipment on the buses with an XTend radio and 
added scripts to beacon the position, speed, and direction
of motion of the buses once each second. We deployed
three always-on throwbox prototypes in fixed locations for three
weeks on the UMassDieselNet bus routes.

[Traceset] umass/diesel/transfer (v. 2008-09-14)

top

The following traces have been added: 
transfer/spring2006, transfer/spring2007, and transfer/ap_connectivity

The changed components are as follows:

@MISC{umass-diesel-transfer-2008-09-14,
  author = {John Burgess and Brian Neil Levine and Ratul Mahajan and John Zahorjan and Aruna Balasubramanian and Arun Venkataramani and Yun Zhou and Bruce Croft and Nilanjan Banerjee and Mark Corner and Don Towsley},
  title = {{CRAWDAD} trace set umass/diesel/transfer (v. 2008-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/transfer},
  month = sep,  
  year = 2008
}
					

This set of DieselNet logs were compiled from busses running routes serviced 
by UmassTransit, which lists their bus routes on the web at http://www.umass.edu/campus_services/transit/. 
Of UmassTransit's busses, 30-40 busses were equipped with DieselNet equipment and a certain 
portion of those operated daily as dictated by bus failures and maintenance.

To maintain and monitor our network, we use numerous external APs that offer 
free service along the bus routes hosted by third parties. 
We have installed only two APs - one on campus and one at the bus garage. 
Whenever the buses have web access, they retrieve software updates from a central
server. At that time a bus provides its current GPS location and MAC address, and 
it uploads logs of its performance during the day, including the throughput of 
bus-to-bus transfer opportunities, APs contacted, a record of movement, and
application records.

To enable bus-to-bus transfers, the buses beacon on a single channel once every 100ms. 
We programmed the bricks in each bus to transfer the largest amount of data possible 
using TCP at each transfer opportunity. 

To allow us to easily test different routing algorithms in a real DTN environment, 
we set the UMassDieselNet buses to transmit random data to one another whenever 
they are within range and record the time, transmission size, and buses involved.

We excluded holidays and other occasions causing buses to run infrequently.

[Trace] umass/diesel/throwbox/summer2006 (v. 2007-12-02)

top

the initial version

@MISC{umass-diesel-throwbox-summer2006-2007-12-02,
  author = {John Burgess and Brian Neil Levine and Ratul Mahajan and John Zahorjan and Aruna Balasubramanian and Arun Venkataramani and Yun Zhou and Bruce Croft and Nilanjan Banerjee and Mark Corner and Don Towsley},
  title = {{CRAWDAD} trace umass/diesel/throwbox/summer2006 (v. 2007-12-02)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/throwbox/summer2006},
  month = dec,  
  year = 2007
}
					

The traces contains connection event between buses (in DieselNet)
and buses and throwboxes placed in the network.

The traces contains connection event between buses (in DieselNet)
and buses and throwboxes placed in the network.

The name of the bus nodes follow the pattern "PVTA_(bus number)". 
The three throwboxes placed in the network have names "PVTA_TB0", 
"PVTA_TB1", "PVTA_TB2". The connectivity traces have data about 
the duration of contact, time at which the contact took place, 
the amount of data transfered, the position (longitude and latitude) at 
which the connections happened and the speed and direction of the bus 
motion when the connection event took place. The filenames indicate the 
date on which the connection trace was collected. For example, 6-23-2006 
would mean June 23, 2006.

[Trace] umass/diesel/transfer/fall2007 (v. 2008-09-14)

top

the initial version

@MISC{umass-diesel-transfer-fall2007-2008-09-14,
  author = {Nilanjan Banerjee and Mark Corner and Don Towsley and Brian Neil Levine},
  title = {{CRAWDAD} trace umass/diesel/transfer/fall2007 (v. 2008-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/transfer/fall2007},
  month = sep,  
  year = 2008
}
					

Data transfer logs on UmassDieselNet, a disruption-tolerant network (DTN) in the months October-November 2007.

The released traces have five directories

1. gps_logs : This is the directory which has the cumulative
gps_logs for all the buses seen during the period which the 
traces were collected. 

2. mobile-mobile: This is the collection of all the mobile-mobile contact
events. 

3. basestation-mobile: The traces are similar to the mobile-mobile traces
but are for the AP-mobile contact events.

4. mobile-mobile-mesh-relay: these are the traces for the connection events
between a mobile node and the six stationary relay/mesh boxes placed in the
network.
 
5. xtendtrace: This has the connection events between mobile nodes over
the Xtend Maxstream radio.

If you use these traces in a research paper, please reference the traces as 

Relays, Base Stations, and Meshes: Enhancing Mobile Networks with
Infrastructure. Nilanjan Banerjee, Mark D. Corner, Don Towsley, and Brian Neil
Levine. In Proceedings of ACM MobiCom, San Francisco, CA, USA, September 2008.

The released traces have five directories

1. gps_logs : This is the directory which has the cumulative
gps_logs for all the buses seen during the period which the 
traces were collected. There is a directory corresponding to every
bus and within each directory for a bus there are files for every 
day with a set of time stamped gps locations.

2. mobile-mobile: This is the collection of all the mobile-mobile contact
events. Each line includes the time at which a contact occured, the amount
of data that was transfered, the duration of contact and the position 
where the contact took place.

3. basestation-mobile: The traces are similar to the mobile-mobile traces
but are for the AP-mobile contact events.

4. mobile-mobile-mesh-relay: these are the traces for the connection events
between a mobile node and the six stationary relay/mesh boxes placed in the
network.
 
5. xtendtrace: This has the connection events between mobile nodes over
the Xtend Maxstream radio.

[Trace] umass/diesel/transfer/ap_connectivity_fall2007 (v. 2008-09-13)

top

the initial version

@MISC{umass-diesel-transfer-ap_connectivity_fall2007-2008-09-13,
  author = {Aruna Balasubramanian and Brian Neil Levine and Arun Venkataramani},
  title = {{CRAWDAD} trace umass/diesel/transfer/ap_connectivity_fall2007 (v. 2008-09-13)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/transfer/ap_connectivity_fall2007},
  month = sep,  
  year = 2008
}
					

This set of traces were collected from UMass DieselNet 
during the Fall semester of 2007. The traces contain connection times and durations 
between two buses and between a bus and an AP.

This set of DieselNet traces where compiled during Fall 2007 from busses 
running routes serviced by Umass Transit.
Umass Transit's 40 busses were equipped with DieselNet equipment and 
a certain portion of those operated daily as dictated by bus failures 
and maintenance. Each bus scans for connection with other buses or 
access points (APs) on the road, and when found, connects to the bus or the AP.

This trace contains connection events between busses as well as between a bus and an AP.
All connection events occurring during a day are stored in the log file matching 
that date (year-month-date). Time stamps are recorded as absolute minutes and 
seconds after midnight. 

If you use these traces in a research paper, please reference the traces as 

Aruna Balasubramanianm Brian Neil Levine and Arun Venkataramani,
"Enabling Interactive Applications for Hybrid Networks" 
in Proceedings of ACM Mobicom, September 2008

There are two files with the same name under two different directories 
called bus-bus and bus-ap. The bus-bus directory contains trace logs 
of bus connections, while the bus-ap directory contains trace logs of 
a bus-AP connections. 

Bus-AP
----------

We made sure to log only interactions with open APs, by pinging a well known 
server using the open AP connection. We do not send data during the open AP 
connection and use periodic ping messages to estimate the total length of 
the connection. The connection length excludes time taken for association and 
getting a DHCP address.

As example entry in the log is 
3204 00:12:17:c5:71:72 0:0:1 null 5.182 72.5552333333 42.2817516667

The first column is the bus ID, the second column in the MAC address of the AP, 
the third column is the time. The fourth column is always null and is for consistency 
with the bus-bus traces. The fifth column is the total duration of meeting in seconds. 
The last two columns are the longitude and latitude respectively.

Bus-Bus
------------

Each bus are identified by an ID.  In the following entry, bus 3030 sent bus 3203 
at 0:27:22 transferring  2297600 bytes. The connection lasted for 33 seconds and 
the latitude and longitude of meeting is 72.53267 and 42.39381 respectively. 
Entries where the first or second column is "null" should be ignored.

3030 3203 0:27:22 2297600 33 72.53396 42.3946283333

[Trace] umass/diesel/transfer/vifi (v. 2008-06-08)

top

the initial version

@MISC{umass-diesel-transfer-vifi-2008-06-08,
  author = {Aruna Balasubramanian and Ratul Mahajan and Arun Venkataramani and Brian Neil Levine and John Zahorjan},
  title = {{CRAWDAD} trace umass/diesel/transfer/vifi (v. 2008-06-08)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/transfer/vifi},
  month = jun,  
  year = 2008
}
					

This set of DieselNet traces were compiled in December 2007 
and contains the connection quality between one bus and APs on the road. 
The connection quality is measured using AP beacons heard by the bus 
on a per second granularity.

This set of DieselNet traces where compiled from December 4 to 6th on Channel 1 
and December 12th to 14th on Channel 6. The trace logs contain the connection 
quality between one bus and APs on the road. The connection quality is measured 
using AP beacons heard by the bus on a per second granularity. The bus was set 
in promiscuous mode when the traces were logged. The traces only includes APs found 
in the Amherst town center. There are 10 such APs in Channel 1 and 14 in Channel 6.

We present the connection quality between the bus and APs as path loss values (in db). 
Apart from the connection quality between a bus and an AP, the trace also contains 
connection quality between two APs. Since this information is not available 
from the beacons, we first approximate all APs from which the bus receives beacons 
in a single time interval, to be within the transmission range. For two APs 
within transmission range, we assign the path loss values uniformly at random 
between 80db to 110db. 

If you use these traces in a research paper, please reference the traces as

Aruna Balasubramanian, Ratul Mahajan, Arun Venkataramani, Brian Neil Levine and John Zahorjan
"Interactive WiFi Connectivity for Moving Vehicles"
in Proceedings of ACM Sigcomm, August 2008

The trace directory contains 10 trace files each for Channel 1 and Channel 6. 
The 10 trace files are generated with different seeds.

In the traces, the bus is identified by the number 1. All APs are marked from 2 onwards. 
The first column is the time, the second column is the first participant and 
the third column in the second participant. The participant is either the bus or the AP. 
The last column is the path loss value. A sample log from the trace is

3 1 2 92
3 4 10 84

The first line says that, at 3 seconds, the path loss value between the bus (marked 1) 
and AP 2 is 92 db. The second line says that, at time 3 seconds, AP 4 and AP 10 have 
a path loss value of 84db.

[Trace] umass/diesel/transfer/ap_connectivity (v. 2007-12-02)

top

the initial version

@MISC{umass-diesel-transfer-ap_connectivity-2007-12-02,
  author = {Aruna Balasubramanian and Yun Zhou and Brian Neil Levine and Arun Venkataramani and Bruce Croft},
  title = {{CRAWDAD} trace umass/diesel/transfer/ap_connectivity (v. 2007-12-02)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/transfer/ap_connectivity},
  month = dec,  
  year = 2007
}
					

Bus-to-ap transfer record collected from DieselNet during the spring semester of 2007.

UmassTransit's 40 busses were equipped with DieselNet equipment and a
certain portion of those operated daily as dictated by bus failures
and maintenance.

All connection events occurring during a day are stored in the log
file matching that date (month/day/year). The buses are identified by
their MAC address. Time stamps are recorded as absolute minutes and
seconds after midnight. In the following entry, bus 00:09:5B:B3:51:6B 
met an access point at 16 minutes and 44 seconds after midnight 
for a duration of 36 seconds.

Bus 00:09:5B:B3:51:6B with AP at time 00:16:44 for 36.0 seconds

[Trace] umass/diesel/transfer/spring2006 (v. 2007-12-02)

top

the initial version

@MISC{umass-diesel-transfer-spring2006-2007-12-02,
  author = {John Burgess and Brian Neil Levine and Ratul Mahajan and John Zahorjan and Aruna Balasubramanian and Arun Venkataramani and Yun Zhou and Bruce Croft and Nilanjan Banerjee and Mark Corner and Don Towsley},
  title = {{CRAWDAD} trace umass/diesel/transfer/spring2006 (v. 2007-12-02)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/transfer/spring2006},
  month = dec,  
  year = 2007
}
					

Bus-to-bus transfer record collected from DieselNet during the spring semester of 2006.

This trace includes two directories:
	* Bus-Bus subdirectory contains bus-to-bus transfer records
	* DispatchRecord subdirectory contains bus dispatching records.

1. Bus-to-bus transfer records are saved in files named as MDDYYYY, for example, file
2082006 contains transfer records for Feb 08, 2006. Within each file, each line 
describe a bus-to-bus transfer. For example, the following sample lines:

Bus 3112 at 72.532745 42.393852 on route 1 in contact with bus 3114 at 72.532745 42.393852 on route 1 at time 418:27 for 45204688 bytes in 184792.0 ms

means that the bus 3112 was in contact with bus 3114 while it's at location 
(72.532745 N,42.393852 W). The contact started at 418mins and 27 seconds after 
the 00:00:00 (i.e., 6:58:27 A.M.) of Feb 28, 2006, and lasts for 194792.0 
milliseconds. Note that the "on route 1" information should be ignored.

2. Dispathcing records include two files: DA_all.txt and DB_sheet.txt.

* The DA_all.txt contains the dispatching records (inputed by hand from 
the DA sheets, with drivers name ignored). 

For example, the following sample lines in the file:
----------------------------------------------------
DATE 4/3/2006
## AM SHIFTS
TIME_AT_GARAGE  SHIFT   BUS  DRIVER  In_SERVICE   IN_SERVICE_LOC   DRVR_CHNG
6:10            AM21    34   NA      6:55         MHC              10:30
6:10            AM42    32   NA      6:30         GRC              8:32
6:25            AM22    38   NA      6:45         HAGISMALL        11:00
6:30            AM43    42   NA      6:50         STKRD            9:05M 9:23T
6:40            AM45    12   NA      7:00         GRC              8:49
6:40            AM31    16   NA      7:10         HAMPCOLL         10:45B/11:05G
6:42            AM11    33   NA      7:12         OLDBTOWN         10:51
6:45            AMA     21   NA      7:05         STADIUM          10:35
6:50            AM23    35   NA      7:10         HAGISMALL        10:00
6:52            AM1     36   NA      7:19         CLIFFSIDE        10:52
.....

Here, DATE line indicates the following records are for the date specified. Each line
follows give "TIME_AT_GARAGE  SHIFT   BUS  DRIVER  In_SERVICE   IN_SERVICE_LOC   DRVR_CHNG"
for each shift. For example, the line:

6:10            AM21    34   NA      6:55         MHC              10:30

means that bus 34 serve shift AM21 on that day, it starts at garage at 6:10 A.M.,
and starts to enter service at 6:55 A.M. at bus stop MHC. The bus will be changed to
another driver (also to another shift) at 10:30 A.M.

** DB_sheet.txt contains essentially similar information, dumped from a database system. 
Each line in the file specifies the mapping from bus to shift. For example,

03/01/2006,30,15MID,3033 

means that on March 1 2006, bus 3033 was dispatched to run on shift MID15, route 30.

[Trace] umass/diesel/transfer/spring2007 (v. 2007-12-02)

top

the initial version

@MISC{umass-diesel-transfer-spring2007-2007-12-02,
  author = {Aruna Balasubramanian and Brian Neil Levine and Arun Venkataramani},
  title = {{CRAWDAD} trace umass/diesel/transfer/spring2007 (v. 2007-12-02)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/transfer/spring2007},
  month = dec,  
  year = 2007
}
					

This set of DieselNet traces where compiled during Spring 2007 from busses 
running routes serviced by UmassTransit, which lists their bus routes on 
the web at http://www.umass.edu/campus_services/transit/. UmassTransit's 
40 busses were equipped with DieselNet equipment and a certain portion of 
those operated daily as dictated by bus failures and maintenance.

This set of DieselNet traces where compiled during Spring 2007 from busses 
running routes serviced by UmassTransit. UmassTransit's 40 busses were 
equipped with DieselNet equipment and a certain portion of those operated 
daily as dictated by bus failures and maintenance.

All connection events occurring during a day are stored in the log file 
matching that date (month/day/year). 

The buses are identified by their MAC address. Time stamps are recorded 
as absolute minutes and seconds after midnight. 

In the following entry, bus 00:09:5B:B3:E3:4E sent bus 00:09:5B:B5:6E:6E 
at 06:57:18 transferring 94240422 bytes. The latitude and longitude of 
meeting is 72.53267 and 42.39381 respectively. The last column is true 
if the satellite reading is current and false otherwise.  

00:09:5B:B3:E3:4E 00:09:5B:B5:6E:6E 06:57:18 94240422 72.53267 42.39381 true

[Trace] umass/diesel/transfer/infocom2006 (v. 2006-01-17)

top

the initial version

@MISC{umass-diesel-transfer-infocom2006-2006-01-17,
  author = {John Burgess and Brian Neil Levine and Ratul Mahajan and John Zahorjan and Aruna Balasubramanian and Arun Venkataramani and Yun Zhou and Bruce Croft and Nilanjan Banerjee and Mark Corner and Don Towsley},
  title = {{CRAWDAD} trace umass/diesel/transfer/infocom2006 (v. 2006-01-17)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umass/diesel/transfer/infocom2006},
  month = jan,  
  year = 2006
}
					

This set of DieselNet logs were compiled during the Spring semester of 2005 
from busses running routes serviced by UmassTransit, which lists their bus routes on the web 
at http://www.umass.edu/campus_services/transit/. Of UmassTransit's 40 busses, approximately 
30 busses were equipped with DieselNet equipment and a certain portion of those operated daily 
as dictated by bus failures and maintenance.

Our testbed is subject to the real schedule of the UMass campus - many fewer 
buses run on weekends and holidays. To realize some uniformity, we used 
60 traces from weekdays between January 25, 2005 to May 6, 2005; we excluded 
holidays and other occasions causing buses to run infrequently.  

On average, about 28 buses are active each day, and each days lasts from about 7AM to 7PM. 
In all, the traces consist of over 720 hours of recorded data for each of the 30 buses
(about 20,000 bus-hours total). 

Busses are assigned a route semi-arbitrarily each day. Some routes require short busses, 
some routes require long busses, and some vary by their passenger capacity needs:
- Routes 30, 31, and 38 must use long busses
- Routes 34, 35, 37, and 39 must use shot busses
- Routes 32, 33, 36, 45, and 46 may use either
Bus numbers beginning 30xx are long busses, bus numbers beginning 31xx are short busses. 
Though not present in these logs, prefix numbers other than 31xx and 30xx indicate a test unit 
or other non-bus based unit (which often show up on the Umass DieselNet web site).

All connection events occurring during a day are stored in the log file 
matching that date (month/day/year). Log events are entered by the bus receiving the data, 
which is the first bus listed on each line. Though events would ideally be symmetrical, they, 
in reality, are not. Whichever sending connection begins first will reach maximum speed and 
slow the "ramping up" of the TCP connection going in the other direction 
(over time they will equalize). Additionally, a connection in one event may succeed 
while a connection in the opposite direction may not be established due to network 
configuration hiccups (the linux network stack and wifi drivers were not targeted 
toward an environment where interfaces are rapidly reconfigured). 
Time stamps are recorded as absolute minutes and seconds after midnight. 
In the following entry, bus 3123 receives 277512 bytes from bus 3102 at 6:55:11 AM. 
Routes and GPS coordinates should be ignored because GPS information was not accurate 
when these logs were being generated.

"Bus 3123 at 72.53236 42.3933 on route 1 in contact with bus 3102 at 72.53236 42.3933 on route 1 at time 415:11 for 277512 bytes"

[Author] John Burgess

top

[Author] Brian Neil Levine

top

[Author] Ratul Mahajan

top

[Author] John Zahorjan

top

[Author] Aruna Balasubramanian

top

[Author] Arun Venkataramani

top

[Author] Yun Zhou

top

[Author] Bruce Croft

top

[Author] Nilanjan Banerjee

top

[Author] Mark Corner

top

[Author] Don Towsley

top

[Paper] balasubramanian-dtn

top

[Paper] balasubramanian-hybrid

top

[Paper] balasubramanian-interactive

top

[Paper] balasubramanian-search

top

[Paper] banerjee-relays

top

[Paper] banerjee-throwboxes

top

[Paper] burgess-attacks

top

Disruption-Tolerant Networks (DTNs) deliver data in network environments 
composed of intermittently connected nodes. Just as in traditional networks, 
malicious nodes within a DTN may attempt to delay or destroy data in transit to 
its destination. Such attacks include dropping data, flooding the network with 
extra messages, corrupting routing tables, and counterfeiting network 
acknowledgments. Many existing methods for securing routing protocols require 
authentication supported by mechanisms such as a public key infrastructure, 
which is difficult to deploy and operate in a DTN, where connectivity is 
sporadic. Furthermore, the complexity of such mechanisms may dissuade node 
participation so strongly that potential attacker impacts are dwarfed by the 
loss of contributing participants. In this paper, we use connectivity traces 
from our UMass Diesel- Net project and the Haggle project to quantify routing 
attack effectiveness on a DTN that lacks security. We introduce plausible 
attackers and attack modalities and provide complexity results for the 
strongest of attackers. We show that the same routing with packet replication 
used to provide robustness in the face of unpredictable mobility allows the 
network to gracefully survive attacks. In the case of the most effective 
attack, acknowledgment counterfeiting, we show a straightforward defense that 
uses cryptographic hashes but not a central authority. We conclude that 
disruption-tolerant networks are extremely robust to attack; in our 
trace-driven evaluations, an attacker that has compromised 30% of all nodes 
reduces delivery rates from 70% to 55%, and to 20% with knowledge of future 
events. By comparison, contemporaneously connected networks are significantly 
more fragile

[Paper] burgess-maxprop

top

[Paper] zhang-bus-dtn

top