Subject: [dtn-interest] new papers available on dtnrg.org
From: Melissa Ho <[email-masked]>
To: [email-masked]
Date: Wed, 29 Dec 2004 18:03:45 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

There are two new tech reports and a paper/poster available on the
DTNRG web site:
http://www.dtnrg.org

K. Fall "Messaging in Difficult Environments," IRB-TR-04-019, Dec. 27, 2004

M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra, "Implementing
Delay Tolerant Networking,"  IRB-TR-04-020, Dec. 28, 2004

Melissa Ho and Kevin Fall.  "Poster: Delay Tolerant Networking for
Sensor Networks." In the First IEEE Conference on Sensor and Ad Hoc
Communications and Networks (SECON 2004). October 2004

Melissa

From: "Daniel Caughran" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 29 Dec 2004 13:50:12 -0500
Importance: Normal
Subject: [dtn-interest] dtn.conf
Sender: [email-masked]

I am one of the students working on the science project involving the DTN
software. We are currently using DTN version 2.0.2 and having some problems
with the configuration.  We are attempting to use three computers to send
bundles from one to another using the third as a bundle relay. Could anybody
send us an example dtn.conf file or explain the  parameters.

Daniel Caughran
[email-masked]

Date: Tue, 28 Dec 2004 10:21:20 -0800
To: Jeffrey Elkner <[email-masked]>
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Decisions, decisions...
Cc: DTN <[email-masked]>, Colin Applegate <[email-masked]>, Daniel Caughran <[email-masked]>, Paul Flint <[email-masked]>, Eric Howard <[email-masked]>
Sender: [email-masked]

At 11:08 AM 12/28/2004 -0500, Jeffrey Elkner wrote:
>Hello again, Scott,
>
>I'm sorry to be pestering you again, but we need to figure out what to
>do to move this project forward.  Here is the situation:
>
>- they are supposed to hand in data on the day we return from winter
>break (January 3rd).
>
>- Colin is able to get version 1 of the DTN software running (see
>http://linus.yhspatriot.net/cs/at/students/Applegate_Colin/DTNSetup),
>but version 2 does not work (see Colin's email below).
>
>I had suggested to them that doing the experiment with the current
>version of the software would be more useful to the project (though I
>would be grateful for your thoughts on that), but they can't get it to
>work.
>
>Do you think we should push ahead trying to get the version 2 software
>working, or would it make more sense to run the experiment with the
>older version?

Hi, Jeffrey.  I just passed on to Colin a tip on the version 2 software 
that may enable you to work with that version (per Bob Durst: "the first 
time you run the daemon, you must run it with the "tidy" (-t) flag to 
ensure that the persistent state is clean and tidy").  If this does the 
trick, great!

If not, and given your very tight deadline, I would say to go ahead with 
DTN1.  The same architectural principles are being explored either way, and 
I think that's really what matters for this project.

Scott

From: Jeffrey Elkner <[email-masked]>
To: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Cc: Colin Applegate <[email-masked]>, Daniel Caughran <[email-masked]>, Paul Flint <[email-masked]>, Eric Howard <[email-masked]>
Date: Tue, 28 Dec 2004 11:08:40 -0500
Subject: [dtn-interest] Decisions, decisions...
Sender: [email-masked]

Hello again, Scott,

I'm sorry to be pestering you again, but we need to figure out what to
do to move this project forward.  Here is the situation:

- they are supposed to hand in data on the day we return from winter
break (January 3rd).

- Colin is able to get version 1 of the DTN software running (see
http://linus.yhspatriot.net/cs/at/students/Applegate_Colin/DTNSetup),
but version 2 does not work (see Colin's email below).

I had suggested to them that doing the experiment with the current
version of the software would be more useful to the project (though I
would be grateful for your thoughts on that), but they can't get it to
work.

Do you think we should push ahead trying to get the version 2 software
working, or would it make more sense to run the experiment with the
older version?

Thanks again for all your help!

> From: Colin Applegate <[email-masked]>
> Date: Tue, 28 Dec 2004 10:40:46 -0500
> Subject: DTN2 Assertion Error
> To: [email-masked]
> 
> 
> Hello Scott,
> 
> I am working on the DTN2 science project with Daniel and Anna in
> conjunction with Jeff Elkner. I got DTN2 to compile and almost work...
> here is my dtnd output after running ./dtnping
> bundles://loopback/tcp://localhost:5000/
> 
> dtn% [1104248182.862866 /assert critical] ASSERTION FAILED
> (globals.next_regid_!= 0xffffffff) at storage/GlobalStore.cc:97
> Aborted
> 
> I receive a similar error when I try to use dtnsend to send dtnd a
> string, line 78 as opposed to line 97, similar function call.
> 
> I have checked permissions of the /var/dtn -- owned by user dtn
> I'm using Fedora Core 3, TCL 8.4, and Berkeley DB 4.2 with both patches applied
> 
> Thank you so much for any ideas/help Scott!
> 
> --
> -Colin Applegate
> President, Applegate Consulting
> Yorktown HS LTSP Lab [Student] Administrator

-- 
Jeffrey Elkner <[email-masked]>
Open Book Project <http://ibiblio.org/obp>

Date: Tue, 21 Dec 2004 15:54:43 -0800
To: DTNRG <[email-masked]>
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Comments on the bundling draft
Sender: [email-masked]

At 02:06 PM 12/19/2004, Manikantan Ramadas wrote:

>Some thoughts/comments/suggestions on
>draft-irtf-dtnrg-bundle-spec-02.txt :
>
>* Sec 2.3.2 We might need a RegistrationError.indication primitive to
>serve the case (for example) if the default failure action requested
>of deferring bundle delivery until a period of passive or active
>reception by the application was unacceptable to the bundle agent (for
>storage or other administrative considerations). A bundle-agent may
>also choose to reject a request by the application to run a procedure
>provided by the application while deferring bundles for security
>reasons, say. Besides the Register.request, a
>Change_registration.request requesting changes as in the above
>examples, may also deserve a RegistrationError.indication.

A good point, Mani, but it's a fine line: my preference is to limit 
prescriptions for error handling in a spec like this to those that pertain 
to the protocol itself, to indicate intent to the developer.  Certainly 
there are wide range of other anomalies that a sound implementation is 
going to have to handle somehow, but I don't think it's our job as protocol 
designers to make all those rules, since none of this Service Description 
stuff affects interoperability anyway.  We run the risk of over-specifying 
and unreasonably constraining the developer.

>* Sec 2.5.2 II para, II line, may be you want to call this one
>CancelBundle.request to be in Sync. with the title as we have with all
>other request primitives? Just caught my eye, thats all.

You mean in the "Semantics" paragraph, right?  Absolutely, good catch.

>* Sec 2.5.10 SendError.indication : Since the bundling application
>uniquely refers to each Send request with a SendTokenBinding, isn't it
>enough if we just return the SendTokenBinding parameter instead of all
>those parameters we are returning?

Good point; certainly simpler and more elegant.  It forces the application 
to remember all the transmission parameters that were associated with that 
Send.request, though.  I dunno, I could go either way on this question, but 
I'm leaning toward agreeing with you.

>* Closing out Section 2,  May be we need a table(s) of reason-codes to
>be sent back as a parameter along with SendError.indication and
>RegistrationError.indication primitives? Reason-codes for
>SendError.indication could include reasons like :
>
>  o No route to host (ever)
>  o Can't meet lifespan (if the bundle agent was aware of the link
>schedules)

Yes, a good idea.

>While RegistrationError.indication could include reason-codes for
>stuff like :
>  o Can't defer delivery
>  o Can't run user-specified procedure

Again, though, I disagree on this one.

>* This is just a curiosity question: Why have we left Reserved spaces
>for bundle header type values interspersed like 0x03, 0x04, 0x06
>instead of having all the Reserved values towards the end?

Well, the spec has gone through a lot of changes, and implementations have 
tracked those changes to some extent.  Since the header type numbers are 
arbitrary anyway, I think it just seemed as if we'd be somewhat less likely 
to break something somewhere if, whenever we deleted a header type, we 
simply retired the number and left it Reserved rather than reassigning that 
number and all subsequent type numbers.

>* Sec 3.3, ASCII diagrams illustrating bit allotment for Class of
>Service Flags and Payload Security would be nice!

You're right, a worthwhile picture to include.

>* Sec 3.7. This has been raised in a recent thread on DTN Security.
>But just for the sake of completeness : we need to clearly say what
>happens under reactive fragmentation when bundles authentication
>breaks at the receiver. Although reactive fragmentation is likely to
>be a rather corner case (at least for links with relatively long
>uptimes), we go thru' all this pain just to make sure NOT to lose bits
>that made all this way but were corrupted just because the link went
>down right in the middle of transmission, right? But this is all
>useless if the receiving bundle agent is going to throw such a
>fragmented bundle anyways since it was inauthentic.

Right, that issue surfaced after this version of the spec was 
submitted.  We clearly have to address this.

>* Sec 4.2 Step 1, last-but-1 line : you mean the "sending bundle
>agent" here right? Or, I don't understand whats going on here.

Yes, it would be the sending bundle agent that was enforcing these rules.

>* Sec 4.4 Bundle Fowarding : Before beginning with Step 2, how do we
>handle cases such as
>
>  o This bundle must have taken the wrong path to reach us because we
>have no route to the destination region (ever)
>
>  o We have a route to the destination region, but the link is down
>now, and  based on link schedules we know that we can't meet the
>TTL when the link would become available next. In such a case, it
>seems good not to bother saving the bundle, but rather send back an
>error message.

Yes, this is a place where we might want to beef up the anomaly handling 
procedures.  In the first case, I think we discard the bundle and, if it 
was custodial, we send back a "Failed" custodial signal as described in 
Step 3 of 4.2 (using reason codes as defined in Table 7).  In the second 
case, I would be inclined to simply hang on the bundle and see what 
happens, as sometimes we don't know all that we think we know.  But this 
could be a management decision supported by an implementation-specific 
hook, and a rejection decision could again result in one of those "Failed" 
custodial signals.

>* Sec 4.5.1 Bundle Fragmentation, towards the end when we discuss
>reactive fragmentation. All of this discussion seems to assume that
>reactive fragmentation happened while transmitting the final payload
>section of the bundle. May be a few lines on what to do when the link
>went down while transmitting say like the Dictionary Header could be
>useful?

We need to make it clear that this case does NOT result in reactive 
fragmentation: the receiver can't construct a fragmentary bundle unless it 
receives the entire bundle header and at least one byte of the payload.  I 
think this is implied by the first bullet in the first paragraph of 4.5.1 
but obviously it is possible to miss that.

>* Sec 5.1 Table 5. This one is rather a matter of style. The table
>only lists the value of status flag while the discussion below the
>table uses clauses like "if the bundle fragment bit is set..", "if the
>bundle-forwarded bit is set.." etc instead of saying "if the value was
>0x80.." etc.  While it is clear to me that the
>bundle fragment bit is the MSB and the bundle-forwarded bit is the
>third LSB, may be adding a "Bit" column by the side of the "Value"
>column or having a simple ASCII diagram instead of the table
>illustrating the flag assignment, would make me happy. But this is
>certainly a low priority objection/comment.

Sure, this is reasonable.

>* Sec 5.2 Table 7 The values 0x03 - 0x06 clearly don't go with a
>Status flag 0x01 (Custody Transfer Succeeded) (Table 6). May be we
>need a Status flag assignment in Table 6 that stands for Custody
>Transfer Failed (may be 0x00)?

I think calling the bit identified by mask 0x01 the "custody transfer 
succeeded" bit, with implicitly Boolean semantics, is actually a pretty 
efficient way to convey this information.  (Maybe that column heading 
should be "mask" instead of "value".)  But I do think we need to add value 
0x00 "No error" to Table 7.

Scott 

Date: Tue, 21 Dec 2004 16:17:44 -0500 (EST)
From: Donghua Xu <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTN simulation
Sender: [email-masked]

Hi all,

Just FYI, we are currently working on a ns2-based DTN
simulation tool.  We will release the tool for public
download soon. Hope it'll help researchers here. :)

Donghua Xu                 Email: [email-masked]
College of Computing       Homepage: http://www.cc.gatech.edu/~xu
Georgia Tech               Phone: (404)894-6736(office)

Date: Mon, 20 Dec 2004 17:28:32 -0800
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] update to DTN 2.0 release
Sender: [email-masked]

Hi!

DTN-2.0.2 is now available at http://www.dtnrg.org/#code

This release supersedes 2.0.1, and works with BerkeleyDB 4.3 as well as 4.2.

Melissa

Date: Mon, 20 Dec 2004 10:29:00 -0800 (PST)
From: Sushant Jain <[email-masked]>
To: Stephen Farrell <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] DTN simulation
Sender: [email-masked]

Hi,

I am working on routing issues in DTN and I wrote a simulator
in Java. Its available at 
http://www.cs.washington.edu/homes/sushjain/dtn.html

cheers,
Sushant

On Mon, 20 Dec 2004, Stephen Farrell wrote:

> 
> Hi Agam,
> 
> I've done a bit of work like this, which I started by rejecting
> ns-2! Instead I worked with OMNET++ [1] which suited me better.
> I integrated ephemeris handling into an OMNET module to get
> the delays required on messages. My code's way out of date now,
> since it was based on v2.3 and I'm waiting for the
> soon-to-be-released v3.0 to start again. However, if its
> of interest get in touch and I can let you know more.
> 
> I think some others may have done work based on STK [2] which
> is another option if you've the time to learn how to use it
> (and the licenses required).
> 
> Regards,
> Stephen.
> 
> PS: I'd be interested in hearing back from you when you've picked
> a simulator.
> 
> [1] http://www.omnetpp.org/
> [2] http://www.stk.com/
> 
> Agam Brahma wrote:
> 
> > hi
> > 
> > I'm doing a project involving DTN --- and it will require ns-2
> > simulation (or similar) to prove results/get data etc. Has anyone got
> > this (an ns-2 simulation of DTN) working before ?
> > 
> > thanks in advance,
> > agam
> > 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Mon, 20 Dec 2004 14:08:14 +0000
From: Stephen Farrell <[email-masked]>
To: Agam Brahma <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN simulation
Sender: [email-masked]

Hi Agam,

I've done a bit of work like this, which I started by rejecting
ns-2! Instead I worked with OMNET++ [1] which suited me better.
I integrated ephemeris handling into an OMNET module to get
the delays required on messages. My code's way out of date now,
since it was based on v2.3 and I'm waiting for the
soon-to-be-released v3.0 to start again. However, if its
of interest get in touch and I can let you know more.

I think some others may have done work based on STK [2] which
is another option if you've the time to learn how to use it
(and the licenses required).

Regards,
Stephen.

PS: I'd be interested in hearing back from you when you've picked
a simulator.

[1] http://www.omnetpp.org/
[2] http://www.stk.com/

Agam Brahma wrote:

> hi
> 
> I'm doing a project involving DTN --- and it will require ns-2
> simulation (or similar) to prove results/get data etc. Has anyone got
> this (an ns-2 simulation of DTN) working before ?
> 
> thanks in advance,
> agam
> 

Date: Mon, 20 Dec 2004 10:43:49 +0530
From: Agam Brahma <[email-masked]>
Reply-To: Agam Brahma <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN simulation
Sender: [email-masked]

hi

I'm doing a project involving DTN --- and it will require ns-2
simulation (or similar) to prove results/get data etc. Has anyone got
this (an ns-2 simulation of DTN) working before ?

thanks in advance,
agam

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Date: Sun, 19 Dec 2004 17:06:54 -0500
From: Manikantan Ramadas <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] Comments on the bundling draft
Sender: [email-masked]

--lMM8JwqTlfDpEaS6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Some thoughts/comments/suggestions on
draft-irtf-dtnrg-bundle-spec-02.txt :

* Sec 2.3.2 We might need a RegistrationError.indication primitive to
serve the case (for example) if the default failure action requested
of deferring bundle delivery until a period of passive or active
reception by the application was unacceptable to the bundle agent (for
storage or other administrative considerations). A bundle-agent may
also choose to reject a request by the application to run a procedure
provided by the application while deferring bundles for security
reasons, say. Besides the Register.request, a
Change_registration.request requesting changes as in the above
examples, may also deserve a RegistrationError.indication.

* Sec 2.5.2 II para, II line, may be you want to call this one
CancelBundle.request to be in Sync. with the title as we have with all
other request primitives? Just caught my eye, thats all.

* Sec 2.5.10 SendError.indication : Since the bundling application
uniquely refers to each Send request with a SendTokenBinding, isn't it
enough if we just return the SendTokenBinding parameter instead of all
those parameters we are returning?

* Closing out Section 2,  May be we need a table(s) of reason-codes to
be sent back as a parameter along with SendError.indication and
RegistrationError.indication primitives? Reason-codes for
SendError.indication could include reasons like :

 o No route to host (ever)
 o Can't meet lifespan (if the bundle agent was aware of the link
schedules)

While RegistrationError.indication could include reason-codes for
stuff like :
 o Can't defer delivery
 o Can't run user-specified procedure

* This is just a curiosity question: Why have we left Reserved spaces
for bundle header type values interspersed like 0x03, 0x04, 0x06
instead of having all the Reserved values towards the end?

* Sec 3.3, ASCII diagrams illustrating bit allotment for Class of
Service Flags and Payload Security would be nice!

* Sec 3.7. This has been raised in a recent thread on DTN Security.
But just for the sake of completeness : we need to clearly say what
happens under reactive fragmentation when bundles authentication
breaks at the receiver. Although reactive fragmentation is likely to
be a rather corner case (at least for links with relatively long
uptimes), we go thru' all this pain just to make sure NOT to lose bits
that made all this way but were corrupted just because the link went
down right in the middle of transmission, right? But this is all
useless if the receiving bundle agent is going to throw such a
fragmented bundle anyways since it was inauthentic.

* Sec 4.2 Step 1, last-but-1 line : you mean the "sending bundle
agent" here right? Or, I don't understand whats going on here.

* Sec 4.4 Bundle Fowarding : Before beginning with Step 2, how do we
handle cases such as=20

 o This bundle must have taken the wrong path to reach us because we
have no route to the destination region (ever)

 o We have a route to the destination region, but the link is down
now, and  based on link schedules we know that we can't meet the
TTL when the link would become available next. In such a case, it
seems good not to bother saving the bundle, but rather send back an
error message.

* Sec 4.5.1 Bundle Fragmentation, towards the end when we discuss
reactive fragmentation. All of this discussion seems to assume that
reactive fragmentation happened while transmitting the final payload
section of the bundle. May be a few lines on what to do when the link
went down while transmitting say like the Dictionary Header could be
useful?

* Sec 5.1 Table 5. This one is rather a matter of style. The table
only lists the value of status flag while the discussion below the
table uses clauses like "if the bundle fragment bit is set..", "if the
bundle-forwarded bit is set.." etc instead of saying "if the value was
0x80.." etc.  While it is clear to me that the
bundle fragment bit is the MSB and the bundle-forwarded bit is the
third LSB, may be adding a "Bit" column by the side of the "Value"
column or having a simple ASCII diagram instead of the table
illustrating the flag assignment, would make me happy. But this is
certainly a low priority objection/comment.

* Sec 5.2 Table 7 The values 0x03 - 0x06 clearly don't go with a
Status flag 0x01 (Custody Transfer Succeeded) (Table 6). May be we
need a Status flag assignment in Table 6 that stands for Custody
Transfer Failed (may be 0x00)?

- Mani.

--=20
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
 =20
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--lMM8JwqTlfDpEaS6
Content-Type: application/pgp-signature
Content-Disposition: inline

--lMM8JwqTlfDpEaS6--

From: Jeffrey Elkner <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked], Anna Chan <[email-masked]>, Daniel Caughran <[email-masked]>, Colin Applegate <[email-masked]>
Organization: Open Book Project <http://ibiblio.org/obp>
Date: Sun, 19 Dec 2004 13:21:30 -0500
Subject: [dtn-interest] Getting the DTN software to run...
Sender: [email-masked]

Hi Scott,

I am Anna's teacher and adviser for this project.  I can't thank you
enough for the suggestions you have given her.  She now has a well
designed experimental model and the opportunity to make a real
contribution to a real project!

The deadline for the science fair is rapidly approaching, and Daniel
Caughran (Anna's partner in this project) has been working for weeks
without success to get the DTN software running.  He has encountered the
following problems:

1. The code wouldn't compile because he didn't have the necessary
libraries installed.

2. The code would compile (after he setup a Fedora Core 3 box with
"Install Everything" selected), but the program would seg-falt when the
sotware was run.

Daniel is feeling a bit frustrated, so I decided I would give him a
hand.  I began by going to the DTN site (http://www.dtnrg.org/) and
looking for the software.  I found the "Can I get any code?" section,
and clicked on the link to: http://www.dtnrg.org/code/DTN-2.0.1.tgz .
Alas, it was a broken link.  (looking at http://www.dtnrg.org/code/
confirms that it is not there).

Questions:

1. For the experiment, which version of the software would you suggest?
Where can we get that software?

2. Do you have a suggested GNU/Linux distribution?

3. What libraries are needed to compile the DTN software?

If I could get answers to these questions, I will setup the DTN boxes
for them so they can proceed with the experiment.

Thanks!

On Thu, 2004-12-16 at 16:07 -0800, Scott Burleigh wrote:
> At 08:54 AM 12/15/2004, magical monkey wrote:
> >Hi,
> >
> >I'm a senior at Yorktown High School doing a science project related
> >to the efficiency of a delay-tolerant-network.  I was wondering if I
> >could get some feedback on whether the project seems reasonable or
> >useful - I'm planning to study the delay in transfer by varying delay
> >times from 1000-60000 seconds, in intervals of 1000 to study the
> >transfer success ratio and overall transfer time as delay is increased
> >(and do statistical analysis on the data).  Any comments or
> >suggestions would be greatly appreciated!  Thanks a lot.
> >
> >Sincerely,
> >Anna
> 
> Hi, Anna.
> 
> I believe this will be pretty challenging in the near term, as we don't yet 
> have an implementation of a "convergence layer" adapter to a protocol that 
> can efficiently accomplish reliable data transfer between two points 
> separated by the kind of delay you're talking about.
> 
> If you're looking at a 1000-second delay end-to-end but brief delays 
> point-to-point (for example: A sends to B via TCP convergence layer over an 
> Ethernet at a time when B has no connectivity to C; you wait 1000 seconds, 
> then break the A-B connectivity and establish B-C connectivity, and B then 
> sends to C via the TCP convergence layer over an Ethernet; you've got a 
> 1000-second end-to-end delay between A and C), then it's doable with the 
> code we've currently got.  But in that case I'd be concerned that you 
> wouldn't get very interesting transfer success and overall transfer time 
> statistics.
> 
> I suspect that the sort of study you want to perform will require 
> implementation of a convergence layer adapter to something like the 
> Licklider Transmission Protocol (LTP), which does reliable point-to-point 
> transmission over very long delays.  Stephen Farrell at Trinity College 
> Dublin has been working on an implementation of LTP itself, but for the CL 
> adapter I'm afraid you'd be on your own.  Not a trivial project.
> 
> Scott

-- 
Jeffrey Elkner <[email-masked]>
Open Book Project <http://ibiblio.org/obp>

Date: Sun, 19 Dec 2004 09:16:23 -0800 (PST)
From: vivek verma <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Application for  Paper on Delay Tolerant Network
Sender: [email-masked]

--0-1459077913-1103476583=:2561
Content-Type: multipart/alternative; boundary="0-1554340019-1103476583=:2561"

--0-1554340019-1103476583=:2561
Content-Type: text/plain; charset=us-ascii

Dear Sir/Madam,
             we are students of Indian School of Mines currently doing B.Tech from I.S.M Dhanbad.we have done our 3rd year summer training based on Delat Tolerant Network.
             we have attached our paper.please download the attachment and if u find it interesting please reply me.
 
Paper done by:
i) Vivek Kumar
Final Sem,B.Tech
I.S.M Dhanbad
 
ii)Ashutosh Singh Chauhan
Final Sem,B.Tech
I.S.M Dhanbad
 
iii) Sudhanshu Kumar
Final Sem,B.Tech
I.S.M Dhanbad

		
---------------------------------
Do you Yahoo!?
 Dress up your holiday email, Hollywood style. Learn more.
--0-1554340019-1103476583=:2561
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>Dear Sir/Madam,</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we are students of Indian School of Mines currently doing B.Tech from I.S.M Dhanbad.we have done our 3rd year summer training based&nbsp;on Delat Tolerant Network.</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we have attached our paper.please download the attachment and if u find it interesting please reply me.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Paper done by:</DIV>
<DIV>i)&nbsp;Vivek Kumar</DIV>
<DIV>Final Sem,B.Tech</DIV>
<DIV>I.S.M Dhanbad</DIV>
<DIV>&nbsp;</DIV>
<DIV>ii)Ashutosh Singh Chauhan</DIV>
<DIV>Final Sem,B.Tech</DIV>
<DIV>I.S.M Dhanbad</DIV>
<DIV>&nbsp;</DIV>
<DIV>iii) Sudhanshu Kumar</DIV>
<DIV>Final Sem,B.Tech</DIV>
<DIV>I.S.M Dhanbad</DIV></DIV><p>
		<hr size=1>Do you Yahoo!?<br> 
Dress up your holiday email, Hollywood style. <a href="http://us.rd.yahoo.com/evt=29909/*http://celebrity.mail.yahoo.com">Learn more.</a>
--0-1554340019-1103476583=:2561--
--0-1459077913-1103476583=:2561
Content-Type: application/msword; name="report.doc"
Content-Transfer-Encoding: base64
Content-Description: report.doc
Content-Disposition: attachment; filename="report.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAC
AAAAZgAAAAAAAAAAEAAAaAAAAAIAAAD+////AAAAAGUAAABqAAAA////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////

--0-1459077913-1103476583=:2561--

Date: Fri, 17 Dec 2004 08:26:01 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Bundling spec query
Sender: [email-masked]

At 08:03 AM 12/17/2004, Manikantan Ramadas wrote:
>On Thu, Dec 16, 2004 at 04:23:12PM -0800, Scott Burleigh wrote:
> > At 04:05 PM 12/16/2004, Manikantan Ramadas wrote:
> > >On Thu, Dec 16, 2004 at 03:39:57PM -0800, Scott Burleigh wrote:
> > >> At 04:06 AM 12/14/2004, Darren Long wrote:
> > >> >Hi,
> > >> >
> > >> >In "bundling-spec-v3e.pdf", para 2.5.6, Change-Registration.Request,
> > >> >should the semantics show another parameter of type "delivery failure
> > >> >action", to allow the agent to determine what the new preferences are?
> > >>
> > >> Do you mean a second "delivery failure action" parameter?  The one 
> that's
> > >> noted in that paragraph is the one that tells the agent what the new
> > >> preference is, not a reiteration of the current (old) preference.
> > >>
> > >
> > >  I think what he saying here, Scott, is that the
> > >Change-registration.request line should also list the new delivery
> > >failure action as a parameter and read as in :
> > >
> > >Change-registration.request(registration token, default failure action)
> >
>
>   Looks like we are not looking at the same document then. You are
>probably looking at a draft that is updated from the one on the dtnrg
>website. The bundling-spec-v3e.pdf available from the website reads
>just :
>
>Change-registration.request(registration token)
>
>in Sec 2.5.6.

The website needs to be updated, I think.  This is okay in the current 
published version of the spec: 
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-02.txt.

Scott

Date: Fri, 17 Dec 2004 11:03:32 -0500
From: Manikantan Ramadas <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Bundling spec query
Sender: [email-masked]

On Thu, Dec 16, 2004 at 04:23:12PM -0800, Scott Burleigh wrote:
> At 04:05 PM 12/16/2004, Manikantan Ramadas wrote:
> >On Thu, Dec 16, 2004 at 03:39:57PM -0800, Scott Burleigh wrote:
> >> At 04:06 AM 12/14/2004, Darren Long wrote:
> >> >Hi,
> >> >
> >> >In "bundling-spec-v3e.pdf", para 2.5.6, Change-Registration.Request,
> >> >should the semantics show another parameter of type "delivery failure
> >> >action", to allow the agent to determine what the new preferences are?
> >>
> >> Do you mean a second "delivery failure action" parameter?  The one that's
> >> noted in that paragraph is the one that tells the agent what the new
> >> preference is, not a reiteration of the current (old) preference.
> >>
> >
> >  I think what he saying here, Scott, is that the
> >Change-registration.request line should also list the new delivery
> >failure action as a parameter and read as in :
> >
> >Change-registration.request(registration token, default failure action)
> 

  Looks like we are not looking at the same document then. You are
probably looking at a draft that is updated from the one on the dtnrg
website. The bundling-spec-v3e.pdf available from the website reads
just : 

Change-registration.request(registration token) 

in Sec 2.5.6.

- Mani.

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

Date: Thu, 16 Dec 2004 16:23:12 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Bundling spec query
Sender: [email-masked]

At 04:05 PM 12/16/2004, Manikantan Ramadas wrote:
>On Thu, Dec 16, 2004 at 03:39:57PM -0800, Scott Burleigh wrote:
> > At 04:06 AM 12/14/2004, Darren Long wrote:
> > >Hi,
> > >
> > >In "bundling-spec-v3e.pdf", para 2.5.6, Change-Registration.Request,
> > >should the semantics show another parameter of type "delivery failure
> > >action", to allow the agent to determine what the new preferences are?
> >
> > Do you mean a second "delivery failure action" parameter?  The one that's
> > noted in that paragraph is the one that tells the agent what the new
> > preference is, not a reiteration of the current (old) preference.
> >
>
>   I think what he saying here, Scott, is that the
>Change-registration.request line should also list the new delivery
>failure action as a parameter and read as in :
>
>Change-registration.request(registration token, default failure action)

Sorry, it's the end of the day and I seem to be getting more confused by 
the moment.

The syntax for Change-Registration.request in the spec (at least in the 
original draft copy I'm looking at) is:

         Change-registration.request( registration token, delivery failure 
action)

The delivery failure action in this primitive is the action to be applied 
-- from now on -- to all arriving bundles destined for registrant 
identified by the registration token.  It's not really a default, in the 
sense that something else will routinely override it; it's the new rule, 
replacing the rule established at the time of original registration.

I have a feeling that I'm missing something very obvious here, but maybe it 
will be clearer to me in the morning.

Scott 

Date: Thu, 16 Dec 2004 16:07:50 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] dtn question
Cc: [email-masked]
Sender: [email-masked]

At 08:54 AM 12/15/2004, magical monkey wrote:
>Hi,
>
>I'm a senior at Yorktown High School doing a science project related
>to the efficiency of a delay-tolerant-network.  I was wondering if I
>could get some feedback on whether the project seems reasonable or
>useful - I'm planning to study the delay in transfer by varying delay
>times from 1000-60000 seconds, in intervals of 1000 to study the
>transfer success ratio and overall transfer time as delay is increased
>(and do statistical analysis on the data).  Any comments or
>suggestions would be greatly appreciated!  Thanks a lot.
>
>Sincerely,
>Anna

Hi, Anna.

I believe this will be pretty challenging in the near term, as we don't yet 
have an implementation of a "convergence layer" adapter to a protocol that 
can efficiently accomplish reliable data transfer between two points 
separated by the kind of delay you're talking about.

If you're looking at a 1000-second delay end-to-end but brief delays 
point-to-point (for example: A sends to B via TCP convergence layer over an 
Ethernet at a time when B has no connectivity to C; you wait 1000 seconds, 
then break the A-B connectivity and establish B-C connectivity, and B then 
sends to C via the TCP convergence layer over an Ethernet; you've got a 
1000-second end-to-end delay between A and C), then it's doable with the 
code we've currently got.  But in that case I'd be concerned that you 
wouldn't get very interesting transfer success and overall transfer time 
statistics.

I suspect that the sort of study you want to perform will require 
implementation of a convergence layer adapter to something like the 
Licklider Transmission Protocol (LTP), which does reliable point-to-point 
transmission over very long delays.  Stephen Farrell at Trinity College 
Dublin has been working on an implementation of LTP itself, but for the CL 
adapter I'm afraid you'd be on your own.  Not a trivial project.

Scott

Date: Thu, 16 Dec 2004 19:05:59 -0500
From: Manikantan Ramadas <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Bundling spec query
Sender: [email-masked]

On Thu, Dec 16, 2004 at 03:39:57PM -0800, Scott Burleigh wrote:
> At 04:06 AM 12/14/2004, Darren Long wrote:
> >Hi,
> >
> >In "bundling-spec-v3e.pdf", para 2.5.6, Change-Registration.Request, 
> >should the semantics show another parameter of type "delivery failure 
> >action", to allow the agent to determine what the new preferences are?
> 
> Do you mean a second "delivery failure action" parameter?  The one that's 
> noted in that paragraph is the one that tells the agent what the new 
> preference is, not a reiteration of the current (old) preference.
> 

  I think what he saying here, Scott, is that the
Change-registration.request line should also list the new delivery
failure action as a parameter and read as in :

Change-registration.request(registration token, default failure action)

- Mani.
-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

Date: Thu, 16 Dec 2004 15:39:57 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Bundling spec query
Sender: [email-masked]

At 04:06 AM 12/14/2004, Darren Long wrote:
>Hi,
>
>In "bundling-spec-v3e.pdf", para 2.5.6, Change-Registration.Request, 
>should the semantics show another parameter of type "delivery failure 
>action", to allow the agent to determine what the new preferences are?

Do you mean a second "delivery failure action" parameter?  The one that's 
noted in that paragraph is the one that tells the agent what the new 
preference is, not a reiteration of the current (old) preference.

Scott 

Date: Wed, 15 Dec 2004 16:10:56 -0800
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] Call For Papers: Workshop on Delay Tolerant Networking (WDTN-05)
Sender: [email-masked]

************************************************************
   PRELIMINARY CALL FOR PAPERS

   Workshop on Delay Tolerant Networking (WDTN-05)
   (to be held with SIGCOMM 2005: Aug 20-26, 2005, Philidelphia, PA, USA)

   http://www.dtnrg.org/

************************************************************

Goals
Today, the most successful network architecture is that of the
Internet. It has scaled well beyond the original plan of its
designers, and the Internet Protocol has been carried on a great
number of underlying protocols, including itself. However, the
Internet's protocol architecture suffers some problems when
implemented on classes of networks for which it was not originally
designed. For example, when disconnection and reconnection is common,
or link performance is highly variable or extreme, one or more of the
traditional Internet protocols do not work well. In this workshop, we
wish to explore physical
networks that operate significantly differently from wired, connected
networks and the protocol architectures used to deal with such
situations, and techniques for making applications tolerant to
disruptions and/or high delays. More specifically, we solicit papers
in the following areas:

(a) Physical characteristics of performance-challenged neworks
(b) Networking systems operating over unusual/challenged networks
(c) Protocol design and evaluation of operations over challenged networks

Submissions ranging from presentations of specific systems or network
system performance to more general, philosophical position papers as
to what to do about them are welcome. Papers that bring out
interesting and novel ideas at an early stage in their development are
favored over highly polished, journalstyle
results. Selected papers will be forward - looking, with impact and
implications for ongoing or future research.

Paper Format and Submission Instructions
Submitted papers must be no more than 8 pages long, with no characters
in smaller than 10 point fonts. Papers will be reviewed single blind.
Submit papers via the WDTN-05 submission site:
http://blizzard.cs.uwaterloo.ca/DTNCRP

Program Committee
Kevin Fall, Intel (organizer)
Ellen Zegura, Georgia Tech
Milica Stojanovic, MIT/Woods Hole
Christophe Diot, Intel
S. Keshav, Waterloo (organizer)
Robert Durst, MITRE
James Sterbenz, Univ. Massachusetts
Jon Crowcroft, Cambridge Univ.
Eric Brewer, UC Berkeley
Amin Vahdat, UC San Diego
Deborah Estrin, UCLA
John Heidemann, USC/ISI
Supratik Bhattacharyya, Sprint/ATL

Provisional Deadlines
Submission deadline: March 30, 2005
Notification deadline: May 10, 2005
Camera ready deadline: June 2, 2005

Date: Wed, 15 Dec 2004 15:39:08 -0800
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] DTN2 initial official code release and web site update
Sender: [email-masked]

The initial code release of DTN2 (DTN-2.0.1) is available on the web site:
http://www.dtnrg.org/#code

The goal of this implementation is to clearly represent the components
of the DTN architecture, while also providing a robust and flexible
software framework for experimentation, extension, and real-world
deployment.

As of yet, this implementation supports basic DTN functionality,
including the application api, return receipts, static routing, and
flood routing.  It also includes some example applications - ping and
dtncp/dtncpd, a file transfer dtn client and server.

I have also updated the web site with the new LTP documents, the ICWN
DTN call for papers,  and a preliminary call for papers for SIGCOMM
WDTN-05.

Melissa

Date: Wed, 15 Dec 2004 11:54:19 -0500
From: magical monkey <[email-masked]>
Reply-To: magical monkey <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-interest] dtn question
Sender: [email-masked]

Hi,

I'm a senior at Yorktown High School doing a science project related
to the efficiency of a delay-tolerant-network.  I was wondering if I
could get some feedback on whether the project seems reasonable or
useful - I'm planning to study the delay in transfer by varying delay
times from 1000-60000 seconds, in intervals of 1000 to study the
transfer success ratio and overall transfer time as delay is increased
(and do statistical analysis on the data).  Any comments or
suggestions would be greatly appreciated!  Thanks a lot.

Sincerely,
Anna

Date: Tue, 14 Dec 2004 18:10:19 -0500 (EST)
From: <[email-masked]>
To: [email-masked]
Cc: Zygmunt Haas <[email-masked]>
Subject: [dtn-interest] A project to list on your DTNRG list
Sender: [email-masked]

Hi,

We have a project - SWIM (Shared Wireless Infostation Model), which
is an example of a Delay Tolerant Networks. You may want to link to a
short description of the project on our web page at:
	http://wnl.ece.cornell.edu/wnlprojects.html#Biosystems
where two of our papers are downloadable as well.

Best,

Zygmunt Haas.
==--==-=======
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas              http://people.ece.cornell.edu/haas 
Wireless Networks Laboratory       http://wnl.ece.cornell.edu
School of Electrical Engineering         
Cornell University                 tel: +1-607-255-3454
323 Frank Rhodes Hall              fax: +1-607-255-9072
Ithaca, NY 14853                   e-mail: haas(at)ece(dot)cornell(dot)edu
U.S.A                             
	       WNL web page: http://wnl.ece.cornell.edu
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

Date: Tue, 14 Dec 2004 12:06:48 +0000
To: [email-masked]
From: Darren Long <[email-masked]>
Subject: [dtn-interest] Bundling spec query
Sender: [email-masked]

--=======2EA536CF=======
Content-Type: text/plain; x-avg-checked=avg-ok-7F884FC2; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

In "bundling-spec-v3e.pdf", para 2.5.6, Change-Registration.Request, should 
the semantics show another parameter of type "delivery failure action", to 
allow the agent to determine what the new preferences are?

Darren

_______________________________________________

         In theory, theory and practice are the same.

                 In practice, they're not!
_______________________________________________ 

--=======2EA536CF=======
Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-7F884FC2
Content-Disposition: inline

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.809 / Virus Database: 551 - Release Date: 09/12/2004

--=======2EA536CF=======--

Date: Wed, 8 Dec 2004 22:25:23 -0500
From: Manikantan Ramadas <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] Updated LTP internet-drafts
Sender: [email-masked]

Hi folks,

  We have an updated specification for LTP (Licklider Transmission
Protocol) just submitted to IETF. It is described in 3 internet-drafts
now :

(a) The motivation document - draft-irtf-dtnrg-ltp-motivation-00.txt
(b) The main spec. document - draft-irtf-dtnrg-ltp-02.txt
(c) The extensions document - draft-irtf-dtnrg-ltp-extensions-00.txt

While ID announce messages for (a) and (c) came out yesterday, we are
still awaiting an ID announce for (b). Thus you may find just (a) and
(c) at the IETF Internet-drafts web-page currently. 

All three of them are however available from our LTP web-page at
http://irg.cs.ohiou.edu/ltp (and you may get a version here with all
the ^L characters in their right place with the page-formatting
correct and as submitted :-) 

We would be eager to hear your thoughts on them. 

The abstract from the main spec. follows :

"Abstract

   This document describes the Licklider Transmission Protocol (LTP)
   designed to provide retransmission-based reliability over links
   characterized by extremely long message round-trip times (RTTs)
   and/or frequent interruptions in connectivity.  Since communication
   across interplanetary space is the most prominent example of this
   sort of environment, LTP is principally aimed at supporting "long-
   haul" reliable transmission in interplanetary space, but has
   applications in other environments as well.
      
   In an Interplanetary Internet setting deploying the Bundling protocol
   being developed by the Delay Tolerant Networking Research Group, LTP
   is intended to serve as a reliable convergence layer over single hop
   deep-space RF links. LTP does ARQ of data transmissions by soliciting
   selective-acknowledgment reception reports.  It is stateful, and has
   no negotiation or handshakes."

Thanks,
Mani.

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

Date: Sat, 4 Dec 2004 14:32:38 -0800 (PST)
From: Sushant Jain <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Interesting scalable emulation environment
Sender: [email-masked]

Hi guys,

There was a talk at ICSI sometime back, about -fast network topology
emulation-.  The system looks pretty neat. One can instantiate 
arbitary ns like topologies (100s of nodes)
(network stacks really) on "one machine" and test real code/applications 
without modifications (like Emulab). 
Its like virtual machine stuff (entrapid) but much more efficient as it 
works on a more aggressive "zero copying" paradigm. 

Later, myself, mike and Kevin talked to that guy and it looks like 
an interesting possibility to build a more robust testing environment.

More information at: 
http://www.tel.fer.hr/imunes/
(Abstract of the talk below)

thanks
Sushant

---------- Forwarded message ----------
Date: Tue, 26 Oct 2004 12:53:49 -0700
From: Lakshmi <[email-masked]>
To: Lakshmi <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked],
     [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked],
     [email-masked], [email-masked],
     [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked], [email-masked],
     Dennis Geels <[email-masked]>, [email-masked],
     [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked]
Subject: Lunch meeting (10/27)

Speaker: Marko Zec, ICSI visitor from University of Zagreb
Title: Using an operating system kernel as a building block for scalable 
and fast network topology emulation
Time: 12:30 PM

Abstract:

While traditional network protocol simulation tools offer great levels 
of flexibility and extensibility, as long as they target simulation of 
networked environments entirely decoupled from any external systems, 
they typically do not need to operate in real time.  However, fast and 
efficient operation becomes increasingly important as soon as any kind 
of real-time interaction between simulated and external environments 
becomes required.  In this talk we show that an operating system kernel 
itself can serve as a highly efficient network topology emulation 
engine, as opposed to the traditional model of running network 
emulators as standalone user-space processes.  The proposed approach of 
shifting the packet forwarding path of an network emulator entirely 
into an OS kernel has several desirable properties, such as very low 
per-packet processing overhead and conservative use of system 
resources, which results in good overall performance and 
scalability.  Furthermore, existing networking applications or 
tools ranging from traffic generators or analyzers to routing protocol 
daemons or web servers can work unmodified on top of the kernel-level 
emulator, making it suitable for a wide range of experimentation 
scenarios.  Time permitting, we will briefly demonstrate how the 
described approach works in our prototype implementation called IMUNES, 
an integrated multiprotocol network emulator / simulator.

Date: Sat, 04 Dec 2004 04:18:09 -0500
From: "Li, Jiang (Leo)" <[email-masked]>
Organization: Dept of Sys & Comp Sci, Howard University
To: [email-masked]
Subject: [dtn-interest] Call for Papers: Special Session on Delay Tolerant Networks and Applications in ICWN'05
Sender: [email-masked]

*Please accept our apology if you accept this CFP in duplicates.*

The following information is also available at
http://pluto.scs.howard.edu/icwn05_dtn/

=================================================================

Special Session on
DISRUPTION TOLERANT NETWORKS AND APPLICATIONS
ICWN '05

CALL FOR PAPERS
	  	
IMCSE '05

In conjunction with the International Conference on Wireless Networks 
(ICWN). ICWN is part of the International Multiconference in Computer 
Science and Computer Engineering to be held June 27-30, 2005 in Las 
Vegas, NV..

Session Overview

Disruption tolerant networks (DTN) are the kind of networks that lack 
continuous connectivity. A DTN is often found when the nodes have very 
limited communication range, are highly mobile, or are under extreme 
environments. Several examples are as follows:

     * A network of PDA’s using Bluetooth where for some reasons (e.g. 
mobility, power limit) one PDA is not always able to communicate with 
any others.
     * An inter-planet satellite communication network where satellites 
may only communicate with each other several times a day.
     * A sensor network where sensors are not powerful enough to submit 
data to a collecting server.
     * A military field communication network where nodes (e.g. tanks, 
soldier communication equipments) are subject to being destroyed.

The characteristics of DTNs are very different from the traditional 
computer networks (e.g. the Internet) in that the latter have some 
well-known assumptions: 1) continuous connectivity, 2) very low packet 
loss rate, and 3) reasonably low propagation delay and queueing delay. 
DTNs do not satisfy all of the assumptions, and sometimes none. Wireless 
ad hoc networks bear some similarities with some types of DTNs since 
some parts of them may actually form an ad hoc network. However, 
wireless ad hoc networks still have those assumptions. In consequence, 
the existing protocols will not be able to handle the data transmission 
in DTNs. New protocols and algorithms need to be developed.

Within the overall category of DTN, there are actually several different 
types of DTN due to their different characteristics. For instance, in 
the example DTNs above, the first example is dramatically different from 
the second one. The satellite trajectories are predictable while the 
movement of a person may be random. Therefore, for different types of 
DTNs, different solutions may need to be proposed.

Under some situations, DTNs may not yield satisfying performance due to 
the limitation of environments. However, a good algorithm should be able 
to decide whether certain conditions can satisfy certain criteria, and 
if they do, form paths to allow “smooth” data transmission.

This session will provide a platform for discussion of various 
algorithms, their performance, and the applications that utilize DTNs. 
The session will serve as a forum for scientists, leading experts, 
technical professionals, and users involved in research and application 
development of DTN. They will gather together to discuss the benefits, 
challenges, risks, and applications of DTN. At the same time this 
session is an attempt to bring together those organizations involved in 
topics of DTN.

Paper Submissions
Authors are invited to submit papers describing in detail the original 
contribution on the various current issues involved with social 
computing. Each submission should be a maximum of 7-pages in the IEEE 
Proceedings format , including a 100 word abstract, and a cover page 
listing the name, affiliation, complete address, telephone, e-mail, and 
facsimile information for the corresponding author. Contributions will 
be reviewed by at least three reviewers from both Program Committee and 
external reviewers for originality, significance, clarity, soundness, 
relevance and technical contents on basis of papers.

Electronic submission of papers is strongly encouraged (pdf, postscript, 
or MS Word). Authors can submit their papers via email to 
[email-masked] or [email-masked]. Deadline for submission is 
Feb. 26, 2005. If electronic submission is not possible, the paper can 
be submitted via regular mail to :

       Dr. Jiang Li, or Dr. L. Burge III
       Department of Systems and Computer Science
       B36-A Mackey Bldg.
       Howard University
       Washington, DC 20059, USA

The Proceedings will be published by CSREA Press (ISBN) in 
hardcopy/book. The proceedings will be available at the conference. In 
addition to the hardcopy, it is also planned to publish the papers on a 
CD. All conference proceedings published by CSREA Press are considered 
for inclusion in major database indexes that are designed to provide 
easy access to the current literature of the sciences (database 
examples: ISI Thomson Scientific, IEE INSPEC, ...). A special issue of 
the International Journal of Wireless and Mobile Computing (IJWMC) is 
being planned consisting of selected papers from ICWN (not just this 
special session).

• Papers due: Feb. 16, 2005
• Notification of Acceptance: March 21, 2005
• Camera-Ready Paper Due: April 20, 2005

For more information, send an email to one of two session organizers,
L. Burge: [email-masked], or Jiang Li: [email-masked]

Topics of Interest include, but not limited to the following:

• Routing Algorithms
• Packet Storage and Forwarding
• Congestion and Flow Control
• Interoperability of Proprietary Networking Protocols
• Security
• Middleware Technology
• Application of DTN
• Performance and Modeling
• Simulation
Call for Reviewers:
The Special Session is in need of reviewers that are knowledgeable in 
the field.We plan to send a list of abstracts to each reviewer to select 
some papers to review. If you are willing to review some number of 
papers, (preferably between two and four, but any number will do!), 
please send a note to [email-masked] or [email-masked]. The 
deadline for reviewers is early January 31, 2005.

-- 
Jiang (Leo) Li, Assistant Professor
Department of Systems and Computer Science
Howard University, Washington, DC
202-865-0056

Date: Thu, 02 Dec 2004 13:10:00 +0000
From: Stephen Farrell <[email-masked]>
To: "Susan F. Symington" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN security
Sender: [email-masked]

Hi Susan,

I won't overburden the ">" mechanism:-)

There are three things we're talking about:

1. Acceptable max. rsa signature length.
2. Whether to support MACing.
3. Supporting detection of replays.

For no good reason at all I'll take 'em in reverse order:

3. I believe that the DTN protocols should not make it hard to
detect replays. That simple really. The exact details of how
best to do this will depend on the rest of the protocol, but
there are well known ways to do it, e.g. the kerberos
approach, or leveraging the shared state from symmetric
mechanisms. IMO the thing to do for now, is to agree that
making replay detection easy is desirable, then to figure
out other protocol details, and then a specific replay
detection scheme , and lastly to check that it doesn't
overburden the protocol for various use cases.

2. The use of symmetric and asysmmetric cryptography in
protocols is almost the same in terms of complexity and
the amount of shared state. In symmetric cases, the shared
state is obvious, in asymmetric cases, it comes down to
handling revocation. If you are saying that the DTN won't
support revocation, *ever*, then using signatures is
easier than MACs. However, if you might ever want to
revoke a public key, (via CRLs, OCSP, SCVP, XKMS or
your own home grown mechanism) then the PKI based
approach is more-or-less just as hard. Symmetric cases are
also easier to setup and debug during development and
interopability testing, as was seen with IPsec VPNs for
example. The approach I'd advocate is for the base DTN
protocol to be algorithm agile allowing support
for RSA, DSA, ECDSA (maybe useful for having shorter
signatures) and MACing, in particular HMAC. I'd probably
argue that RSA-with-sha256 and HMAC (not sure
which variant off the top of my head) would be a good
set of MUST algorithms for now.

3. RSA signatures are the same length as the RSA key's
modulus. 2048 bit RSA keys are in common use today (even
if SHA-1 and MD5 aren't of commensurate strength, SHA-256
and its cousins are well defined and available today).
There is only one direction for RSA key length to take,
which is to get longer over time (at least until someone
finally invents an interesting general purpose
quantum computer:-). Defining a protocol today which
limits signatures to 2040 bits is simply broken.
Now there are a number of ways to get around this - you
can stick with a one byte length, but allocate
a special value (e.g. 255) which isn't a length, but
rather indicates that the next two bytes contain the
real length. Or, you could take something like the
SDNV-8/SDNV-16 appoach we've taken in LTP. I don't
mind which way this is done, but it would be wrong
to not do this in this version of the protocol.

I guess both of the above arguments apply to all uses
of authentication, i.e. both BAH and PSH. I can't
see any reason you'd want to differentiate at that
level.

Finally, you were kind-of asking me to propose detailed
solutions for these issues, (and I haven't done that:-).
I would be very interested in being involved in working
out those details of DTN security (and even more
interested in figuring out how to do key management!),
but I don't think there's enough bandwidth via email to
do that efficiently. Maybe if someone proposed having
a full-day's meeting on just this, say in conjunction
with the spring IETF...?

Regards,
Stephen.

Susan F. Symington wrote:

> Stephen,
> 
> I appreciate your feedback. 
> My responses are interspersed, this time prepended with "SUSAN2":
> 
> -susan
> 
> Susan F. Symington wrote:
> 
> 
>>Stephen,
>>
>>Thank you for your comments on my previous DTN security posting. My
> 
> responses are below. I have preceeded my responses with "Susan:".
> 
>>-susan
>>
>>
>>
>>
>>>1. The Bundle Protocol should be made explicit regarding the distinction
>>>between a source and a sender as well as the distinction between a
> 
> destination
> 
>>>and a receiver. Each bundle has one source and one destination, but will
> 
> have
> 
>>>as many senders and receivers as there are DTN hops from the source to the
>>>destination. The source signs the hash in the Payload Security Header
> 
> (PSH),
> 
>>>which provides the bundle with end-to-end data integrity and source
>>>authentication, and the destination decrypts this signed hash in the PSH.
> 
> The
> 
>>>sender signs the hash in the Bundle Authentication Header (BAH), which
> 
> provides
> 
>>>the bundle with data integrity and sender authentication along the single
> 
> hop
> 
>>>from the sender to the receiver. The receiver decrypts this signed hash in
> 
> the
> 
>>>BAH.
>>
>>
>>Would it be worthwhile being more efficient if sender=source? You could
>>define a scheme whereby both hashes are input to a single private key 
>>operation and a single signature authenticates both. Probably not
> 
> worthwhile 
> 
>>though.
>>
>>Susan: I don't see how this could work. If you think it's worth pursuing, 
> 
>  > then please explain in a little more detail how it would work. (Its
>  > only possible for sender=source on the first hop of a bundle's journy
> 
>>from source to destination. I didn't think that the PSH hash would 
> 
>  > typically be checked by this first hop anyway.)
> 
> Its a trick that was used in SET where you include both hashes as the
> plaintext input to signing (which probably then uses another pkcs#1
> digest or whatever). Benefit is a single use of the private key,
> but two separately verifiable signed things. See the SET specs if
> you want details, but its almost certainly not worth doing here unless
> lots of bundles will have both BAH and PSH and will not be routed
> via an intermediate bundle router.
> 
> SUSAN2: It is interesting, but I agree that it doesn't seem worth doing in
> this application.
> 
> 
>>I looked at the latest spec and have the following comments about PSH (and
> 
> BAH
> 
>>too in most cases).
>> 
>>- PSH only support signatures up to 2048 bits long which is IMO far too
> 
> close
> 
>>  to the wire - 2048 bit RSA signatures are entirely likely to be used, so
> 
> some
> 
>>  mechanism for longer signatures should be provided. Also, its says
>>  "optionally" running the hash through a signature alg. What would be the
>>  purpose of omitting this step?
>>
>>Susan: How do you come to the conclusion that PSH only supports signatures
> 
> 
>  > up to 2048 bits long? It is my understanding that the Security
>  > Information field of the PSH, which is where the signed hash
>  > would reside, is a variable length field,and thus not limited in size.
>  > Where are we misunderstanding each other?
> 
> The length field is a single octet isn't it? (See section 3.6)
> 
> SUSAN2: Yes. I do not feel qualified to make a judgement regarding what a
> large-enough length field is for the signature field, but I have looked into
> it a little and I can lay out some of the considerations that I've read
> about. By the way, you express concern about the length of the PSH
> signatures. Does your concern also extend to the BAH signatures, which have
> the same length limit of 2040 (to be precise) bits?
> 
> Here is a more full description of the issue and a discussion of some of the
> considerations:
> 
> There is a concern that the length fields for the BAH and PSH headers may
> need to be longer than 8 bits so that they will be large enough to
> accomodate the growing size of RSA signatures. The largest number that can
> be represented using 8 bits is 255. 255 times 8 is 2040, so 2040 bits is the
> largest length signature that could be represented. 
> 
> While the Digital Signature Standard (DSS) produces a fixed-length signature
> irrespective of the size of the key used with it, RSA signature length is a
> function of the key length employed. Signatures using an RSA key of 16,384
> bits in length take around 2.5Kb (2550 bits). Such a signature would not fit
> into either the PSH or the BAH. Therefore, if we anticipate that the Bundle
> Protocol will be used with a key this size, then we should increase the size
> of the length fields in the PSH and BAH accordingly. However, we are trying
> to be very conservative as far as not adding to the length of the Bundle
> Protocol header unless absolutely necessary. Every bit costs.
> 
> The real question, therefore, seems to be, do we anticipate that users will
> want to use keys of this size?  If so, what is the largest key we should
> anticipate so we know how many more bits to add to the length field? 
> 
> On the other hand, it seems that there may be a good argument that we will
> not want to use keys this large to form the digital signatures in the BAH
> and PSH. Consider that a conventional 80-bit key has the equivalent strength
> of a 1024-bit public key. A conventional 128-bit key is equivalent to a
> 3000-bit public key. The bigger the key, the more secure. Also, the bigger
> the key, the more time it takes to apply it. Therefore, selecting a key of
> the right size is a matter of finding a length that is large enough to be
> secure, but small enough to be applied quickly. The advantage of a key that
> is larger and therefore more secure is that it will enable whatever you are
> protecting to stay encrypted and therefore private for many years. However,
> using a key to create a digital signature does not involve encrypting any
> data that we care about keeping secret for many years. It is not about
> privacy, but authentication. I think all that we care about when using the
> key to sign the digital signatures in the BAH and PSH is that the key isn't
> broken during the time that it is in use. 
> 
> Furthermore, when we create a digital signature, we are talking about using
> a key to sign the output of a hash function, which is a relatively small
> amount of data. "Interestingly though, making the signature keys longer
> doesn't necessarily make an overall stronger signature scheme. One notes
> that the only "generally accepted" hash functions MD5, SHA-1 & RIPEMD only
> offer security around 160-bits (128-bits for MD5). If one uses a 4096-bit
> RSA / ElGamal signature key with one of these hash functions, are we really
> increasing security significantly? I would suggest not; a birthday attack
> could be undertaken against the hash function in 2 [to the power 80]
> operations (or, worse 2 [to the power 64] for MD5) thus, against some
> attacks, throwing asymmetric key bits at the signature scheme may give the
> naive user a false impression of security in the signature scheme."
> 
> (quoted from PGP DH vs. RSA FAQ, Version 1.5 
> Copyright C 1999 Sam Simpson - All Rights Reserved, 
> http://www.scramdisk.clara.net/pgpfaq.html])
> 
> Another consideration is that even though we may not want to use a large RSA
> key to form the digital signature, if there is a chance that the source may
> want to use the same key to both sign the PSH and encrypt the data, then the
> key might have to be considerably longer, because it would be being used to
> provide privacy. If this is a factor, then it would affect only the length
> of the PSH length field and not the BAH length field.
> 
> The above are some of the things that we need to think about when deciding
> whether or not to increase the size of the length field. Given that every
> bit is precious and we don't want to increase the header size any more than
> we have to, perhaps the length fields are now an appropriate length. If they
> become too short at some time in the future, perhaps we could at that time
> define version X+1 of the bundle protocol that assumes some
> appropriate-valued number should always be added to the value in the length
> field to get the "real" length. This would enable us to reinterpret the
> length field value without having to actually change the size of the length
> fields in the protocol. Is this feasible?
> 
> Do you still feel strongly that we should increase the size of the length
> field? What other thoughts do you have to add to the above considerations?
> 
> 
>>- What's wrong with MACing btw?
> 
> 
> You didn't say! (We do allow MACing in the current proposal for
> LTP authentiction & I'd argue it ought be allowed here too.)
> 
> SUSAN2: If I understand you correctly, you are saying that in addition to
> the option of being able to use a digital signature to ensure the
> authenticity of the data, you would like to have the alternative option of
> using a MAC to ensure the authenticity.
> 
> The advantage of using a MAC instead of a digital signature is that a MAC,
> being based on private key cryptography, can be computed faster than a
> digital signature (which is based on public key cryptography). Are there any
> other benefits or other reasons that you are arguing that use of MACs ought
> to be allowed?
> 
> Also, are you arguing this for both the PSH and BAH or just one?
> 
> I think the reason that MACing isn't in there as an option is that this
> protocol is for DTNs, which are expected to suffer frequent and
> unpredictable losses of connectivity. Using MACs requires the sender and
> recipient (in the case of the BAH), or the source and destination (in the
> case of the PSH) to have a shared private key that they both use, and
> distributing this same key to both communicating parties who may be located
> at some distance across a DTN can't be assumed to be feasible. (It would
> seem to be a lot easier in the case of adjacent entities using the BAH than
> in the case of distant entities using the PSH though.)
> 
> I guess my feeling is that there doesn't seem to be any good reason to
> preclude the use of MACs as an option in addition to digital signatures. I
> don't see any harm in allowing MACing to be an option in the BAH and the PSH
> instead of having a signed hash be the only possible method of
> authentication for these headers. The only cost that I can see is that we
> would have to add one bit to each header to be used to indicate whether we
> are MACing or digitally signing. (Or can you think of a way to do it that
> wouldn't cost us this bit?) The question then becomes: is having the MAC
> option worth the cost of an additional bit? 
> 
> Any thoughts?
> 
> 
>>>3. DTN security mechanisms will explicitly not have as a goal protection
> 
> of the
> 
>>>DTN infrastructure against Denial of Service as executed by replay
> 
> attacks.
> 
>>
>>That's at least badly stated IMO. The goal should be protection against
>>DoS generally. Depending on a lower layer to prevent replays is not a
>>good idea - both accidental and deliberate replays will happen and the
>>a DTN had better not fall over as a result!
>>
>>Susan: The DTN won't fall over if there are deliberate or accidental 
> 
>  > replays. It's just that nothing will be builT into the protocol to
>  > enable replayed bundles to be detected and discarded at arbitrary
>  > DTN nodes. Replays are one form of Denial of Service attack that we
>  > are consciously not trying to protect the DTN infrastructure against,
>  > because the cost of providing this protection is not worth the
>  > benefit.
> 
> I think that this is miguided. Let me try again: if bundles
> can be routed, how to you detect/prevent loops? (Other than
> via TTL.)
> 
> SUSAN2: I guess that you are pointing out that if we take this approach, we
> are placing the burden on our routing protocols that they be inherently
> loop-free. It's good to have that requirement stated explicitly. 
> 
> 
>>Susan: I don't think there is any loop detection mechanism. In order to be
> 
> 
>  > able to detect replays, we have to be able to distinguish between
>  > replays and legitimate retransmissions. THis is tricky and would 
> probably
>  > require adding a field to the bundle header. But also every DTN node
>  > would have to maintain a local list of allbundles received and this list
>  > could quickly become very large.
> 
> Not necessarily. Kerberos does this over UDP by keeping a digest of
> rx'd packets and a window which determines how fresh a packet must
> be (at the expense of synchronised clocks).
> 
> Two peers could also maintain a counter which might be worthwhile
> if they used MACing of bundles between them (or just use a MAC
> in counter-mode!).
> 
> SUSAN2: I would like to better understand what you are proposing. If there
> is an easy way to detect replays that doesn't require each node to maintain
> an excessive amount of state, then it would be great if we could detect
> them; I just don't see it yet. The DTN already has synchronized clocks, so
> that requirement isn't troubling. Would you mind explaining in a little more
> detail how you are proposing we detect replays and distinguish them from
> legitimate retransmissions? I would appreciate that. 
> 
> 
>>>5. The use of the three security-related options (confidentiality,
> 
> integrity,
> 
>>[...]
>>
>>Again, what's the point of a bare-digest there? It only allows detection
> 
> of
> 
>>accidental changes, deliberate changes only require re-calculation so it
> 
> may
> 
>>as well be missing.
>>
>>Susan: Using an unsigned hash is in there as an option. [...]
> 
> 
> Yes. But I asked what the point was. If you do include this (and it
> may be worthwhile) it has to be crystal clear that it doesn't provide
> security. In LTP we're considering doing this by MACing with a fixed
> key (documented in the spec).
> 
> SUSAN2: I agree that it needs to be crystal clear that it doesn't provide
> security. That's one reason I suggested it be called "error detection"
> instead of "authentication". 
> 
> 
>>>7. We may want to define a new optional parameter of the Send.Request
> 
> primitive
> 
>>>that would be used to indicate to the bundle agent that the application
> 
> does
> 
>>>not want to trust the underlying network and therefore that the bundle
> 
> should
> 
>>>be protected with a BAH.
>>
>>Is that like the "security flag"? [RFC3514] Not clear that this is
> 
> worthwhile.
> 
>>Susan: The point is that the workings of the bundle layer are normally 
> 
>  > transparent to the application, but this parameter gives a sending
>  > application a little more control[...] it doesn't
>  > want to trust the security of any of the underlying networks
>  > to provide this bundle authentication on any hop.
> 
> So it is like rfc3514 then:-) It is trusting the underlying
> networks unless it uses some end-to-end mechanism.
> 
> SUSAN2: I guess what you are saying is that I am fooling myself as a user if
> I try to tell myself that I have ensured more security for my bundle if I
> command my bundle layer to tell all other bundle layers not to trust their
> underlying network and use a BAH on all hops instead, because I have to
> trust my bundle layer and all other bundle layers to carry out this request.
> I think I see your point. 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Wed, 1 Dec 2004 22:28:40 +0000
From: Agam Brahma <[email-masked]>
Reply-To: Agam Brahma <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Research
Sender: [email-masked]

in this code, shouldn't the comparison for error code be !=0 instead of != 1??

[servlib/storage/sqlglobalstore.cc]
bool
SQLGlobalStore::update()
{
    log_debug("updating global store");
    
    if (store_->update(this, -1) != 1) {
        log_err("error updating global store");
        return false;
    }
    
    return true;
}

On Sat, 20 Nov 2004 00:16:58 -0800 (PST), Praveen Choudary
<[email-masked]> wrote:
> Hi,
>  My research interests are in Delay Tolerant Networks,
> Sensor Networks and Mobile Ad-hoc Networks. Presently
> I am doing research on my own. I want to demonstrate
> my research capability by working on a research
> project. I can read, understand and analyse the
> publications. I have got a good understanding of the
> research work done in my areas of interest.
> 
>  Kindly let me know if it possible for researchers in
> this group to help me. If anybody can specify the
> research problem and give me some suggestions to
> proceed,  I will work on the problem and try my best
> to develop some potential solutions.
> 
> Looking forward for an opportunity,
> Sincerely,
> Praveen.
> 
> __________________________________
> Do you Yahoo!?
> The all-new My Yahoo! - Get yours free!
> http://my.yahoo.com
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

From: "Susan F. Symington" <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [dtn-interest] DTN security
Date: Wed, 1 Dec 2004 12:35:03 -0500
Sender: [email-masked]

Stephen,

I appreciate your feedback. 
My responses are interspersed, this time prepended with "SUSAN2":

-susan

Susan F. Symington wrote:

> Stephen,
> 
> Thank you for your comments on my previous DTN security posting. My
responses are below. I have preceeded my responses with "Susan:".
> 
> -susan
> 
> 
> 
>>1. The Bundle Protocol should be made explicit regarding the distinction
>>between a source and a sender as well as the distinction between a
destination
>>and a receiver. Each bundle has one source and one destination, but will
have
>>as many senders and receivers as there are DTN hops from the source to the
>>destination. The source signs the hash in the Payload Security Header
(PSH),
>>which provides the bundle with end-to-end data integrity and source
>>authentication, and the destination decrypts this signed hash in the PSH.
The
>>sender signs the hash in the Bundle Authentication Header (BAH), which
provides
>>the bundle with data integrity and sender authentication along the single
hop
>>from the sender to the receiver. The receiver decrypts this signed hash in
the
>>BAH.
> 
> 
> Would it be worthwhile being more efficient if sender=source? You could
> define a scheme whereby both hashes are input to a single private key 
> operation and a single signature authenticates both. Probably not
worthwhile 
> though.
> 
> Susan: I don't see how this could work. If you think it's worth pursuing, 
 > then please explain in a little more detail how it would work. (Its
 > only possible for sender=source on the first hop of a bundle's journy
> from source to destination. I didn't think that the PSH hash would 
 > typically be checked by this first hop anyway.)

Its a trick that was used in SET where you include both hashes as the
plaintext input to signing (which probably then uses another pkcs#1
digest or whatever). Benefit is a single use of the private key,
but two separately verifiable signed things. See the SET specs if
you want details, but its almost certainly not worth doing here unless
lots of bundles will have both BAH and PSH and will not be routed
via an intermediate bundle router.

SUSAN2: It is interesting, but I agree that it doesn't seem worth doing in
this application.

> I looked at the latest spec and have the following comments about PSH (and
BAH
> too in most cases).
>  
> - PSH only support signatures up to 2048 bits long which is IMO far too
close
>   to the wire - 2048 bit RSA signatures are entirely likely to be used, so
some
>   mechanism for longer signatures should be provided. Also, its says
>   "optionally" running the hash through a signature alg. What would be the
>   purpose of omitting this step?
> 
> Susan: How do you come to the conclusion that PSH only supports signatures

 > up to 2048 bits long? It is my understanding that the Security
 > Information field of the PSH, which is where the signed hash
 > would reside, is a variable length field,and thus not limited in size.
 > Where are we misunderstanding each other?

The length field is a single octet isn't it? (See section 3.6)

SUSAN2: Yes. I do not feel qualified to make a judgement regarding what a
large-enough length field is for the signature field, but I have looked into
it a little and I can lay out some of the considerations that I've read
about. By the way, you express concern about the length of the PSH
signatures. Does your concern also extend to the BAH signatures, which have
the same length limit of 2040 (to be precise) bits?

Here is a more full description of the issue and a discussion of some of the
considerations:

There is a concern that the length fields for the BAH and PSH headers may
need to be longer than 8 bits so that they will be large enough to
accomodate the growing size of RSA signatures. The largest number that can
be represented using 8 bits is 255. 255 times 8 is 2040, so 2040 bits is the
largest length signature that could be represented. 

While the Digital Signature Standard (DSS) produces a fixed-length signature
irrespective of the size of the key used with it, RSA signature length is a
function of the key length employed. Signatures using an RSA key of 16,384
bits in length take around 2.5Kb (2550 bits). Such a signature would not fit
into either the PSH or the BAH. Therefore, if we anticipate that the Bundle
Protocol will be used with a key this size, then we should increase the size
of the length fields in the PSH and BAH accordingly. However, we are trying
to be very conservative as far as not adding to the length of the Bundle
Protocol header unless absolutely necessary. Every bit costs.

The real question, therefore, seems to be, do we anticipate that users will
want to use keys of this size?  If so, what is the largest key we should
anticipate so we know how many more bits to add to the length field? 

On the other hand, it seems that there may be a good argument that we will
not want to use keys this large to form the digital signatures in the BAH
and PSH. Consider that a conventional 80-bit key has the equivalent strength
of a 1024-bit public key. A conventional 128-bit key is equivalent to a
3000-bit public key. The bigger the key, the more secure. Also, the bigger
the key, the more time it takes to apply it. Therefore, selecting a key of
the right size is a matter of finding a length that is large enough to be
secure, but small enough to be applied quickly. The advantage of a key that
is larger and therefore more secure is that it will enable whatever you are
protecting to stay encrypted and therefore private for many years. However,
using a key to create a digital signature does not involve encrypting any
data that we care about keeping secret for many years. It is not about
privacy, but authentication. I think all that we care about when using the
key to sign the digital signatures in the BAH and PSH is that the key isn't
broken during the time that it is in use. 

Furthermore, when we create a digital signature, we are talking about using
a key to sign the output of a hash function, which is a relatively small
amount of data. "Interestingly though, making the signature keys longer
doesn't necessarily make an overall stronger signature scheme. One notes
that the only "generally accepted" hash functions MD5, SHA-1 & RIPEMD only
offer security around 160-bits (128-bits for MD5). If one uses a 4096-bit
RSA / ElGamal signature key with one of these hash functions, are we really
increasing security significantly? I would suggest not; a birthday attack
could be undertaken against the hash function in 2 [to the power 80]
operations (or, worse 2 [to the power 64] for MD5) thus, against some
attacks, throwing asymmetric key bits at the signature scheme may give the
naive user a false impression of security in the signature scheme."

(quoted from PGP DH vs. RSA FAQ, Version 1.5 
Copyright C 1999 Sam Simpson - All Rights Reserved, 
http://www.scramdisk.clara.net/pgpfaq.html])

Another consideration is that even though we may not want to use a large RSA
key to form the digital signature, if there is a chance that the source may
want to use the same key to both sign the PSH and encrypt the data, then the
key might have to be considerably longer, because it would be being used to
provide privacy. If this is a factor, then it would affect only the length
of the PSH length field and not the BAH length field.

The above are some of the things that we need to think about when deciding
whether or not to increase the size of the length field. Given that every
bit is precious and we don't want to increase the header size any more than
we have to, perhaps the length fields are now an appropriate length. If they
become too short at some time in the future, perhaps we could at that time
define version X+1 of the bundle protocol that assumes some
appropriate-valued number should always be added to the value in the length
field to get the "real" length. This would enable us to reinterpret the
length field value without having to actually change the size of the length
fields in the protocol. Is this feasible?

Do you still feel strongly that we should increase the size of the length
field? What other thoughts do you have to add to the above considerations?

> - What's wrong with MACing btw?

You didn't say! (We do allow MACing in the current proposal for
LTP authentiction & I'd argue it ought be allowed here too.)

SUSAN2: If I understand you correctly, you are saying that in addition to
the option of being able to use a digital signature to ensure the
authenticity of the data, you would like to have the alternative option of
using a MAC to ensure the authenticity.

The advantage of using a MAC instead of a digital signature is that a MAC,
being based on private key cryptography, can be computed faster than a
digital signature (which is based on public key cryptography). Are there any
other benefits or other reasons that you are arguing that use of MACs ought
to be allowed?

Also, are you arguing this for both the PSH and BAH or just one?

I think the reason that MACing isn't in there as an option is that this
protocol is for DTNs, which are expected to suffer frequent and
unpredictable losses of connectivity. Using MACs requires the sender and
recipient (in the case of the BAH), or the source and destination (in the
case of the PSH) to have a shared private key that they both use, and
distributing this same key to both communicating parties who may be located
at some distance across a DTN can't be assumed to be feasible. (It would
seem to be a lot easier in the case of adjacent entities using the BAH than
in the case of distant entities using the PSH though.)

I guess my feeling is that there doesn't seem to be any good reason to
preclude the use of MACs as an option in addition to digital signatures. I
don't see any harm in allowing MACing to be an option in the BAH and the PSH
instead of having a signed hash be the only possible method of
authentication for these headers. The only cost that I can see is that we
would have to add one bit to each header to be used to indicate whether we
are MACing or digitally signing. (Or can you think of a way to do it that
wouldn't cost us this bit?) The question then becomes: is having the MAC
option worth the cost of an additional bit? 

Any thoughts?

>>3. DTN security mechanisms will explicitly not have as a goal protection
of the
>>DTN infrastructure against Denial of Service as executed by replay
attacks.
> 
> 
> That's at least badly stated IMO. The goal should be protection against
> DoS generally. Depending on a lower layer to prevent replays is not a
> good idea - both accidental and deliberate replays will happen and the
> a DTN had better not fall over as a result!
> 
> Susan: The DTN won't fall over if there are deliberate or accidental 
 > replays. It's just that nothing will be builT into the protocol to
 > enable replayed bundles to be detected and discarded at arbitrary
 > DTN nodes. Replays are one form of Denial of Service attack that we
 > are consciously not trying to protect the DTN infrastructure against,
 > because the cost of providing this protection is not worth the
 > benefit.

I think that this is miguided. Let me try again: if bundles
can be routed, how to you detect/prevent loops? (Other than
via TTL.)

SUSAN2: I guess that you are pointing out that if we take this approach, we
are placing the burden on our routing protocols that they be inherently
loop-free. It's good to have that requirement stated explicitly. 

> Susan: I don't think there is any loop detection mechanism. In order to be

 > able to detect replays, we have to be able to distinguish between
 > replays and legitimate retransmissions. THis is tricky and would 
probably
 > require adding a field to the bundle header. But also every DTN node
 > would have to maintain a local list of allbundles received and this list
 > could quickly become very large.

Not necessarily. Kerberos does this over UDP by keeping a digest of
rx'd packets and a window which determines how fresh a packet must
be (at the expense of synchronised clocks).

Two peers could also maintain a counter which might be worthwhile
if they used MACing of bundles between them (or just use a MAC
in counter-mode!).

SUSAN2: I would like to better understand what you are proposing. If there
is an easy way to detect replays that doesn't require each node to maintain
an excessive amount of state, then it would be great if we could detect
them; I just don't see it yet. The DTN already has synchronized clocks, so
that requirement isn't troubling. Would you mind explaining in a little more
detail how you are proposing we detect replays and distinguish them from
legitimate retransmissions? I would appreciate that. 

>>5. The use of the three security-related options (confidentiality,
integrity,
> 
> [...]
> 
> Again, what's the point of a bare-digest there? It only allows detection
of
> accidental changes, deliberate changes only require re-calculation so it
may
> as well be missing.
> 
> Susan: Using an unsigned hash is in there as an option. [...]

Yes. But I asked what the point was. If you do include this (and it
may be worthwhile) it has to be crystal clear that it doesn't provide
security. In LTP we're considering doing this by MACing with a fixed
key (documented in the spec).

SUSAN2: I agree that it needs to be crystal clear that it doesn't provide
security. That's one reason I suggested it be called "error detection"
instead of "authentication". 

>>7. We may want to define a new optional parameter of the Send.Request
primitive
>>that would be used to indicate to the bundle agent that the application
does
>>not want to trust the underlying network and therefore that the bundle
should
>>be protected with a BAH.
> 
> Is that like the "security flag"? [RFC3514] Not clear that this is
worthwhile.
> 
> Susan: The point is that the workings of the bundle layer are normally 
 > transparent to the application, but this parameter gives a sending
 > application a little more control[...] it doesn't
 > want to trust the security of any of the underlying networks
 > to provide this bundle authentication on any hop.

So it is like rfc3514 then:-) It is trusting the underlying
networks unless it uses some end-to-end mechanism.

SUSAN2: I guess what you are saying is that I am fooling myself as a user if
I try to tell myself that I have ensured more security for my bundle if I
command my bundle layer to tell all other bundle layers not to trust their
underlying network and use a BAH on all hops instead, because I have to
trust my bundle layer and all other bundle layers to carry out this request.
I think I see your point. 

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest