Subject: [dtn-interest] New look for DTNRG website
From: Melissa Ho <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: Piero Cornice <[email-masked]>, [email-masked]
Date: Mon, 28 Feb 2005 12:52:13 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Take a look at the new www.dtnrg.org!

It is the same content, with a little bit of documentation thrown in.  
Although most of the DTN2 documentation is currently empty, we'll be 
updating the wiki with more content over time.  In the meantime, I've 
added links to Keshav's mindstream wiki on his students' experiences 
installing DTN2.

To avoid wiki spam, the write permissions on this wiki will be fairly 
controlled. Please email me with any new content you might want to add.

Melissa

Kevin Fall wrote:

>>From:  Piero Cornice <[email-masked]>
>>To:    [email-masked]
>>Subject: [dtn-interest] new web site :)
>>Date:  Mon, 28 Feb 2005 16:36:16 +0100
>>
>>Today i went to www.dtnrg.org and i found a brand-new wiki-line website!
>>It's very good and well-made, so thank you :)
>>
>>piero, Italy
>>
>>PS: i didn't receive any news from mailing-list. Is that b/c there wasn't any
>>news or i have to join mailing-list again?
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>    
>>
>
>Thanks go to Melissa Ho for that!
>
>- K
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>  
>

To: Piero Cornice <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] new web site :) 
Date: Mon, 28 Feb 2005 08:15:59 -0800
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Piero Cornice <[email-masked]>
> To:    [email-masked]
> Subject: [dtn-interest] new web site :)
> Date:  Mon, 28 Feb 2005 16:36:16 +0100
>
> Today i went to www.dtnrg.org and i found a brand-new wiki-line website!
> It's very good and well-made, so thank you :)
> 
> piero, Italy
> 
> PS: i didn't receive any news from mailing-list. Is that b/c there wasn't any
> news or i have to join mailing-list again?
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Thanks go to Melissa Ho for that!

- K

Date: Mon, 28 Feb 2005 16:36:16 +0100
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] new web site :)
Sender: [email-masked]

Today i went to www.dtnrg.org and i found a brand-new wiki-line website!
It's very good and well-made, so thank you :)

piero, Italy

PS: i didn't receive any news from mailing-list. Is that b/c there wasn't any
news or i have to join mailing-list again?

To: [email-masked]
Date: Thu, 24 Feb 2005 15:48:35 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] fyi - draft of the role of the IRTF
Sender: [email-masked]

In case you haven't seen this already, have a looksie:

	http://www.ietf.org/internet-drafts/draft-iab-irtf-00.txt

- K

To: [email-masked]
Date: Fri, 18 Feb 2005 13:03:55 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] fyi - new facilities in emulab
Sender: [email-masked]

------- Forwarded Message

>
> From:  Jay Lepreau <[email-masked]>
> To:    [email-masked]
> Subject: New in Emulab: Mobile motes, high security, Windows, wifi
> Date:  Fri, 18 Feb 2005 12:50:53 MST
>
> We've opened for public use four major new features in Utah's Emulab
> network testbed.  They are documented and ready for anyone's reasonable
> research or educational use, or just take them for a test drive.
> 
> 1. 900MHz Motes and 802.11 Stargates on robots: a truly mobile
> wireless testbed, with experimenter-specified movements, simple path
> planning by Emulab, a vision-based tracking system, live maps, and
> webcams.  Control and monitoring are completely integrated into the
> existing Emulab system, so a mobile experiment is very similar to a
> typical Emulab experiment.  This first installation is small, but it
> all works.
> 
> This is really three features: mote support, Stargate support, and
> mobility.  We have a few fixed motes, and will be adding lots more.
>    http://www.emulab.net/tutorial/mobilewireless.php3
> 
> 
> 2,3. Secure environments for running malicious or risky code:
>       A per-experiment switch-enforced firewall.
>       A per-experiment Emulab, by providing Emulab-in-Emulab.
> Plus, at no extra charge, color-coded security levels that
> automatically set up different defense levels.
>    http://www.emulab.net/tutorial/docwrapper.php3?docname=secure.html
> 
> 
> 4. Windows XP is a supported test node OS, joining Linux and FreeBSD.
> Most Emulab features work, including ssh keys and file service.  It's
> got Remote Desktop if you need Windows look-and-feel; it's got Cygwin
> if you prefer Unix.
>    http://www.emulab.net/doc/docwrapper.php3?docname=windows_in_emulab_user.h
tml
> 
> 
> Finally, let me remind you that we also have a non-mobile 802.11a/b/g
> testbed available: 27 PCs scattered around our building, most with two
> Atheros cards.  You can change the madwifi driver, the OS, everything.
>    http://www.emulab.net/tutorial/docwrapper.php3?docname=wireless.html
> 
> 
> Kudos to the whole Emulab team, but especially to Tim Stack, David
> Johnson, Dan Flickinger, Leigh Stoller (robots); Mike Hibler, Leigh
> Stoller (secure env); and Russ Fish, Kirk Webb (Windows).
> 
> Jay Lepreau
> University of Utah

------- End of Forwarded Message

Content-class: urn:content-classes:message
Date: Wed, 16 Feb 2005 15:45:45 -0600
From: "tk424" <[email-masked]>
To: "dtn-interest" <[email-masked]>
Subject: [dtn-interest] Tutorials by Dr. Kevin Fall
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C51470.DE6F733B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear DTN researchers,

=20

I was wondering whether it's possible to get the tutorial by Dr. Kevin
Fall.

In the www.dtnrg.org <http://www.dtnrg.org/> , the given link doesn't
provide any ppt or pdf file.=20

=20

Tutorials:

*	Fall, Durst, Tutorial at SIGCOMM 2004 on Unusual/Challenged
Networks <http://www.acm.org/sigcomm/sigcomm2004/tutorials.html> , for
Aug 30, 200 4=20

This SIGCOMM 2004 conference website only provides the outline and the
link to Dr. Fall's website, which I've already looked through.

Have a nice day!

=20

Best regards,

Tae-hyung Kim

=20

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!
   Friends are angels who lift us to our feet when =20
   our wing have trouble remembering how to fly.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!

------_=_NextPart_001_01C51470.DE6F733B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Dear DTN researchers,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I was wondering whether it&#8217;s possible to get =
the
tutorial by Dr. Kevin Fall.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the <a =
href=3D"http://www.dtnrg.org/">www.dtnrg.org</a>, the
given link doesn&#8217;t provide any ppt or pdf file. </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Tutorials:</span></font></p>

<ul type=3Ddisc>
 <li class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span
     style=3D'font-size:12.0pt'>Fall, Durst, <a
     =
href=3D"http://www.acm.org/sigcomm/sigcomm2004/tutorials.html">Tutorial =
at
     SIGCOMM 2004 on Unusual/Challenged Networks</a>, for =
</span></font>Aug 30, 200      4 </li>
</ul>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This SIGCOMM 2004 conference website only provides =
the
outline and the link to Dr. Fall&#8217;s website, which I&#8217;ve =
already
looked through.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Have a nice day!</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Best regards,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Tae-hyung Kim</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!<br>
&nbsp;&nbsp; Friends are angels who lift us to our feet when&nbsp; <br>
&nbsp; &nbsp;our wing have trouble remembering how to fly.<br>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C51470.DE6F733B--

Date: Wed, 16 Feb 2005 12:47:43 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [dtn-interest] DTN science project
Sender: [email-masked]

Anna Chan wrote:
> Hi,
> 
> Attached is a copy of the rough draft of our DTN science paper.  We're
> planning on doing a few more trials throughout this month and maybe
> modify some parts of the experiment, but we'll keep you all posted. 
> As always, any comments or suggestions are greatly appreciated!

Sorry, Anna, I skimmed your paper briefly when it first arrived but have only now had time to read through it in detail.  I think it is really good work, and the results are most heartening.  A couple of thoughts:

-	It would be helpful to have a couple of illustrative diagrams (though maybe those were included in your original OpenOffice package, which I unfortunately couldn't open).  In particular, a diagram of the end-to-end test apparatus would be nice.

-	The analysis of your findings is good, but I would like to see all of your raw experimental results, maybe in tabular form: configuration, file size, interruption interval size, overall latency, data rate (or something like that).

-	And then, too, it would be nice to see your analytical results in graphical form, so that we can more easily get some intuitive understanding of what the numbers mean.

One useful way to extend the experiment might be to make the end-to-end DTN path longer by inserting one or two additional machines.  This would enable you to explore more complex interruption scenarios, e.g., the links from A to B and from C to D are interrupted but the link from B to C is still intact, etc.  We think we know what happens in that sort of scenario, but experimental confirmation would still be nice to have.

Scott

Date: Tue, 15 Feb 2005 10:35:06 -0600
From: Jeff Allen <[email-masked]>
Reply-To: [email-masked]
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] India Untouched
Sender: [email-masked]

I'm looking forward to reading this book:

  http://www.indiauntouched.com/

Is TIER in touch with the George Foundation, founded by the author of
India Untouched?

  -jeff

Date: Mon, 14 Feb 2005 10:45:21 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] comments on draft-irtf-dtnrg-ltp-motivation-00
Sender: [email-masked]

Hans Kruse wrote:
> see inline
> 
> On Feb 9, 2005, at 14:46, Wesley Eddy wrote:
> 
>> On Tue, Feb 08, 2005 at 01:59:43PM -0800, Scott Burleigh wrote:
>>
>>>
>>>>> In the next 2 paragraphs, I think that the point is that the round 
>>>>> trip
>>>>> time
>>>>> history is potentially very noisy, and so rather than filter it 
>>>>> through an
>>>>> averaging function, it's prefferred to just use the "instantaneous 
>>>>> RTT".
>>>>> This
>>>>> doesn't come out super-clearly from the present draft's exact wording
>>>>> though.
>>>>> I (somewhat) disagree with this approach anyways, but we'll talk about
>>>>> that later.
>>>>
>>>>
>>>>  Yeah the language here in both the places you point out could use some
>>>> clarification. Shall fix.
>>>
>>>
>>> Actually I disagree; I think the language here is crystal clear. :-)  
>>> It's
>>> the concepts that are difficult.  One might indeed say that the round 
>>> trip
>>> time history is potentially very noisy, but that suggests that it's 
>>> still
>>> reasonable to compute timeout intervals by applying some sort of noise
>>> filter to that history; I'm pretty sure it is not.  But as you say, 
>>> let's
>>> talk about that later.
>>
>>
>> I can fully agree that an RTT estimation scheme similar to TCP's is 
>> probably
>> not of much use to LTP.  It looks like there might be room for looking at
>> other simplistic schemes here though, as alternatives to the "most recent
>> measurement" strategy.
>>
>> For instance, storing a histogram of binned individual RTT measurments,
>> and taking the mode should work well.  The challenge is in defining the
>> bin width, although since there's no head of line blocking, etc in LTP,
>> it seems like performance would be rather robust to the choice of bin
>> width, given a large number of sub-flows.
>>
>> Also, since for many space applications, the propagation delay can be 
>> fairly
>> accurately estimated, might that information not be of huge use in noise
>> filtering?
> 
> 
> I think that is an important point for many deep-space links; the noise 
> will be a second-order effect.  However, the variations will play into 
> the timer tolerances, so we need to figure out how to process them.  The 
> good news is that we can be conservative; on deep-space links the 
> physical path delay will be much longer than the order of magnitude of 
> the variations, so the suggested bins or  xxth percentile approach might 
> work.

I think it's interesting to consider alternative mechanisms for computing these timeout intervals, but it's not yet obvious to me that it is really necessary.  What is wrong with the approach presented in the specification?  And how would taking a mode over a histogram of binned measurements be more cost effective -- i.e., either more accurate or computationally less expensive?

Scott

Date: Thu, 10 Feb 2005 23:31:09 -0800
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] Fwd: SMART Scholarship Program Opportunity
Sender: [email-masked]

---------- Forwarded message ----------
From: [email-masked] <[email-masked]>
Date: Tue, 8 Feb 2005 10:45:55 -0500 (EST)
Subject: SMART Scholarship Program Opportunity
To: [email-masked]

Dear Melissa Ho:

ASEE is now administering the Science, Mathematics and Research for
Transformation (SMART) Scholarship Program.  SMART Scholarships are
intended for students near the end of their undergraduate/graduate
studies in science, mathematics, or engineering.

Please forward this opportunity to students you know who can benefit
from this scholarship program. Full tuition, required fees, book
allowance, room and board and other normal educational expenses are
covered for students awarded this scholarship. The application opens
on January 24, 2005 and closes on March 4, 2005. Do not let a
qualified student miss this deadline!

About SMART
Science, mathematics, and engineering (SME), are vital disciplines to
our national defense, therefore a formal Department of Defense (DoD)
Science, Mathematics and Research for Transformation (SMART)
Scholarship has been established by the Ronald W. Reagan National
Defense Authorization Act for Fiscal Year 2005. The purpose is to
promote the education, recruitment and retention of rising junior and
senior undergraduate and graduate students in SME studies. SMART
Scholarships are awarded to applicants who are pursuing a degree in,
or closely related to, one of the following SME disciplines:
â€¢       Aeronautical and Astronautical Engineering
â€¢       Biosciences
â€¢       Chemical Engineering
â€¢       Chemistry
â€¢       Civil Engineering
â€¢       Cognitive, Neural, and Behavioral Sciences
â€¢       Computer and Computational Sciences
â€¢       Electrical Engineering
â€¢       Geosciences
â€¢       Materials Science and Engineering
â€¢       Mathematics
â€¢       Mechanical Engineering
â€¢       Naval Architecture and Ocean Engineering
â€¢       Oceanography
â€¢       Physics

Eligibility
The SMART Scholarship Program is open only to citizens of the United
States.  Persons who hold permanent resident status are not eligible. 
Proof of citizenship will be required.  Students must be at least 18
years of age to be eligible.

SMART Scholarships are intended for students near the end of their
undergraduate/graduate studies in science, mathematics, or
engineering.  Applicants must have received or be on track to receive
their degree by Fall 2007.  Students must have a minimum of a 3.0
average on a 4.0 scale in his or her course of study.

There is an employment obligation to DoD with this scholarship
program. To learn more about the specific obligations, you can visit
the Web site listed below.

Recipients selected in Spring 2005 must begin their scholarship tenure
no later than Fall 2005.   The tenure of a SMART Scholarship is up to
24 months cumulatively starting Fall 2005. Students must be enrolled
in full-time accredited programs leading to a degree in a field
specified above.

Application and Award Dates
Application opens January 24, 2005. All materials must be received by
11:59 p.m. Eastern Standard Time on March 4, 2005.  Subject to the
availability of funds, award notifications will be mailed in April
2005.  Application materials will not be returned to applicants.

For more information and to apply online, visit the Web site at
http://www.asee.org/smart. Email [email-masked] if you have any
questions regarding this scholarship program.

Date: Thu, 10 Feb 2005 11:58:10 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [Fwd: [secdir][New-work] WG Review: IPv6 over IEEE 802.15.4 (lowpan)]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060506070500010703090907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Folks,

The attached might be of interest to people who're considering
going to the IETF (assuming the lowpan group meet there). If
anyone on this list is already involved with this work, I'd
be interested how they think DTN might be revelant, if at all.

Stephen.

--------------060506070500010703090907
Content-Type: message/rfc822;
 name="[secdir][New-work] WG Review: IPv6 over IEEE 802.15.4 (lowpan)"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="[secdir][New-work] WG Review: IPv6 over IEEE 802.15.4 (lowpan)"

From: The IESG <[email-masked]>
To: [email-masked]
Date: Wed, 09 Feb 2005 13:11:04 -0500
Subject: [secdir][New-work] WG Review: IPv6 over IEEE 802.15.4 (lowpan)
Reply-To: [email-masked]
Sender: [email-masked]

A new IETF working group has been proposed in the Internet Area. The IESG has 
not made any determination as yet. The following description was submitted, 
and is provided for informational purposes only. Please send your comments 
to the IESG mailing list ([email-masked]) by February 16th.

+++

IPv6 over IEEE 802.15.4 (lowpan)
=================================

Current Status: Proposed Working Group

Description of Working Group:

Note: Given that there is not much precedent for this type of activity at the
IETF, the text that follows is of an introductory nature. Hence, its objective
is to give a general idea of the application area and motivations for the work.
In particular, this section is not to be construed as detailing work items for
the working group. That is done in the following section on the "Scope of the
Working Group."

Well-established fields such as control networks, and burgeoning ones
such as "sensor" (or transducer) networks, are increasingly being based
on wireless technologies.  Most (but certainly not all) of these nodes
are amongst the most constrained that have ever been networked
wirelessly. Extreme low power (such that they will run potentially for
years on batteries) and extreme low cost (total device cost in single
digit dollars, and riding Moore's law to continuously reduce that price
point) are seen as essential enablers towards their deployment in
networks with the following characteristics:

     * Significantly more devices than current networks
     * Severly limited code and ram space (e.g., highly desirable to fit
       the required code--MAC, IP and anything else needed to execute the
       embedded application-- in, for example,  32K of flash memory, using 8-bit
       microprocessors)
     * Unobtrusive but very different user interface for configuration
       (e.g., using gestures or interactions involving the physical world)
     * Robustness and simplicity in routing or network fabric

A chief component of these devices is wireless communication technology.  In
particular, the IEEE 802.15.4 standard is very promising for the lower
(physical and link) layers.  As for higher layer functions,  there is
considerable interest in using IP technology.  Even though it is not currently
IP-based, the ZigBee Alliance has related ongoing work.  Accordingly, it is
expected that the working group will coordinate and interact with it.

The required work includes items in the following (incomplete) list:

     * IP adaptation/Packet Formats and interoperability
     * Addressing schemes and address management
     * Network management
     * Routing in dynamically adaptive topologies
     * Security, including set-up and maintenance
     * Application programming interface
     * Discovery (of devices, of services, etc)
     * Implementation considerations

Whereas at least some of the above items are within the purview of the
IETF, at this point it is not clear that all of them are. Accordingly,
the LoWPAN working group will address a reduced, more focused set of
objectives.

Scope of lowpan:

Produce "Problems Statement, Assumptions and Goals for Ipv6 for LoWPANs"
(draft-ietf-lowpan-goals-assumptions-xx.txt) to define the problem
statement and goals of the working group.

Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN Networks"
(draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the basic packet
formats and sub-IP adaptation  layer for transmission of IPv6 packets
over IEEE 802.15.4. This includes framing, adaptation, header
compression, address generation and a simple but sufficient mechanism
for ad hoc routing based on AODV.

The working group will reuse existing specifications whenever
reasonable and possible.

The working group will also serve as a venue for ongoing discussions on
other topics related to the more complete list outlined above.
Additional related milestones may be added in the future with AD approval.

_______________________________________________
New-work mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

--------------060506070500010703090907--

Cc: [email-masked], [email-masked], Scott Burleigh <[email-masked]>
From: Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] Re: [ltp] comments on draft-irtf-dtnrg-ltp-motivation-00
Date: Wed, 9 Feb 2005 15:05:05 -0500
To: [email-masked]
Sender: [email-masked]

see inline

On Feb 9, 2005, at 14:46, Wesley Eddy wrote:

> On Tue, Feb 08, 2005 at 01:59:43PM -0800, Scott Burleigh wrote:
>>
>>>> In the next 2 paragraphs, I think that the point is that the round 
>>>> trip
>>>> time
>>>> history is potentially very noisy, and so rather than filter it 
>>>> through an
>>>> averaging function, it's prefferred to just use the "instantaneous 
>>>> RTT".
>>>> This
>>>> doesn't come out super-clearly from the present draft's exact 
>>>> wording
>>>> though.
>>>> I (somewhat) disagree with this approach anyways, but we'll talk 
>>>> about
>>>> that later.
>>>
>>>  Yeah the language here in both the places you point out could use 
>>> some
>>> clarification. Shall fix.
>>
>> Actually I disagree; I think the language here is crystal clear. :-)  
>> It's
>> the concepts that are difficult.  One might indeed say that the round 
>> trip
>> time history is potentially very noisy, but that suggests that it's 
>> still
>> reasonable to compute timeout intervals by applying some sort of noise
>> filter to that history; I'm pretty sure it is not.  But as you say, 
>> let's
>> talk about that later.
>>
>
>
> I can fully agree that an RTT estimation scheme similar to TCP's is 
> probably
> not of much use to LTP.  It looks like there might be room for looking 
> at
> other simplistic schemes here though, as alternatives to the "most 
> recent
> measurement" strategy.
>
> For instance, storing a histogram of binned individual RTT measurments,
> and taking the mode should work well.  The challenge is in defining the
> bin width, although since there's no head of line blocking, etc in LTP,
> it seems like performance would be rather robust to the choice of bin
> width, given a large number of sub-flows.
>
> Also, since for many space applications, the propagation delay can be 
> fairly
> accurately estimated, might that information not be of huge use in 
> noise
> filtering?

I think that is an important point for many deep-space links; the noise 
will be a second-order effect.  However, the variations will play into 
the timer tolerances, so we need to figure out how to process them.  
The good news is that we can be conservative; on deep-space links the 
physical path delay will be much longer than the order of magnitude of 
the variations, so the suggested bins or  xxth percentile approach 
might work.
>
> -Wes
>
> -- 
> Wesley M. Eddy
> NASA GRC / Verizon FNS
> http://roland.grc.nasa.gov/~weddy
>
Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer
Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

Date: Wed, 9 Feb 2005 14:46:18 -0500
From: Wesley Eddy <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] Re: [ltp] comments on draft-irtf-dtnrg-ltp-motivation-00
Sender: [email-masked]

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

On Tue, Feb 08, 2005 at 01:59:43PM -0800, Scott Burleigh wrote:
>
> >>In the next 2 paragraphs, I think that the point is that the round trip=
=20
> >>time
> >>history is potentially very noisy, and so rather than filter it through=
 an
> >>averaging function, it's prefferred to just use the "instantaneous RTT"=
=2E =20
> >>This
> >>doesn't come out super-clearly from the present draft's exact wording=
=20
> >>though.
> >>I (somewhat) disagree with this approach anyways, but we'll talk about
> >>that later.
> >
> >  Yeah the language here in both the places you point out could use some
> >clarification. Shall fix.
>=20
> Actually I disagree; I think the language here is crystal clear. :-)  It'=
s=20
> the concepts that are difficult.  One might indeed say that the round tri=
p=20
> time history is potentially very noisy, but that suggests that it's still=
=20
> reasonable to compute timeout intervals by applying some sort of noise=20
> filter to that history; I'm pretty sure it is not.  But as you say, let's=
=20
> talk about that later.
>

I can fully agree that an RTT estimation scheme similar to TCP's is probably
not of much use to LTP.  It looks like there might be room for looking at
other simplistic schemes here though, as alternatives to the "most recent
measurement" strategy.

For instance, storing a histogram of binned individual RTT measurments,
and taking the mode should work well.  The challenge is in defining the
bin width, although since there's no head of line blocking, etc in LTP,
it seems like performance would be rather robust to the choice of bin
width, given a large number of sub-flows.

Also, since for many space applications, the propagation delay can be fairly
accurately estimated, might that information not be of huge use in noise
filtering?

-Wes

--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--zjcmjzIkjQU2rmur--

Date: Tue, 08 Feb 2005 13:59:43 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: [dtn-interest] Re: [ltp] comments on draft-irtf-dtnrg-ltp-motivation-00
Sender: [email-masked]

Manikantan Ramadas wrote:
> Hi Wes,
> 
> On Fri, Feb 04, 2005 at 11:46:27AM -0500, Wesley Eddy wrote:
> 
>>I just made a run through the LTP motivations document.  It's quite
>>good overall, and I'm pleased with the majority of it.  I do have some
>>comments and suggestions:
>>
>>on page 4: "line of sight of each other" -> "line of sight with each other"

I think both idioms are okay, but I find the former used more often (e.g., search Google for "in line of sight").  I think the text is okay as is.

>>on page 6, during discussion of why standard protocols won't work well,
>>it might be good to also cite:
>>
>>O. B. Akan, J. Fang, I. F. Akyildiz,
>>"Performance of TCP Protocols in Deep Space Communication Networks,"i
>>IEEE Communications Letters, vol. 6, no. 11, pp. 478-480, November 2002.

Sure.

>>on page 7, it might also be worth noting that mechanisms like HTTP pipelining,
>>for mitigating high RTTs, do not exist in many applications.
>>
>>Also here, note that SCTP uses the same slow start algorithm that TCP
>>does, so is similarly unsuitable.  Perhaps note that slow start is
>>designed to probe the unknown capacity of a network path; whereas LTP
>>will be mostly used on single-link paths where there is generally not
>>contention with other hosts, and thus not much need for slow start (or
>>even congestion control).

Excellent suggestion, Wes; thanks.

>   All of the above valuable comments seem reasonable to me. Shall add them to
> the to-do list for the next release of the draft. Thanks! 
> 
> 
>>3.1.2 Session IDs - this is not all that novel, SCTP and BEEP have identical
>>notions.
> 
>   You are right. But given the discussion on the Multiplicity of
> Protocol State Machines in Sec 3.1.1, it seems reasonable to have that
> Sec 3.1.2 on Session IDs in there. It is still a "Feature" of LTP, though
> not necessarily novel.

I agree.  We might well want to note that SCTP and BEEP use the same idea, but it's still important to mention it here in order to help the reader make sense of the design of the protocol.
 
>>page 12: use of "LLC" out of the blue?
> 
>   Yeah, good catch. Shall expand it out and say what it is.

Yes.

>>section 3.6 - it's not clear what you mean by "intolerably optimistic" in
>>reference to timeout intervals.  I think instead of talking about the
>>timeout interval itself, what you're really trying to get at here is
>>that there is no head-of-line blocking in LTP.  This is pretty well
>>described in the SCTP documents, so saying it quickly and refing SCTP
>>should suffice.

Certainly the fact that there is no head-of-line blocking in LTP -- that there may be an essentially unlimited number of concurrent threads of transmission activity -- is what makes it reasonable to be relatively relaxed about timeout intervals.  But we really are talking about the computation of the intervals themselves here: the point is not that there is no head-of-line blocking but instead that the applicable algorithms for computing timeout intervals in LTP are different from those used by TCP, and for good reason.  A reference to SCTP would just mislead the reader, I think.

>>In the next 2 paragraphs, I think that the point is that the round trip time
>>history is potentially very noisy, and so rather than filter it through an
>>averaging function, it's prefferred to just use the "instantaneous RTT".  This
>>doesn't come out super-clearly from the present draft's exact wording though.
>>I (somewhat) disagree with this approach anyways, but we'll talk about
>>that later.
> 
>   Yeah the language here in both the places you point out could use some
> clarification. Shall fix.

Actually I disagree; I think the language here is crystal clear. :-)  It's the concepts that are difficult.  One might indeed say that the round trip time history is potentially very noisy, but that suggests that it's still reasonable to compute timeout intervals by applying some sort of noise filter to that history; I'm pretty sure it is not.  But as you say, let's talk about that later.

>>page 14 - probably should explicitly state that EORP == "end of red part", as
>>this has not been done previously.
> 
>   Good catch again. It is an artifact of our splitting the documents into
> three. The original monolith had the Terminology section defined before, that
> defined EORP. Shall fix.

Yes, good catch.

>>4.2 - in the case where the report-ack gets lost and the RSR retransmits the
>>report, we need clarification on how the report-ack in response to this is
>>generated, since the SSR has gone away long ago.  For instance, tell us that
>>the report itself contains sufficient information to generate the report-ack
>>without referencing the (non-existent) SSR state.
> 
>   This is handled in the main spec. draft with the Sender State Transition
> Diagram.

And more specifically in sections 3.2.3 and 5.13, which are normative.

  I guess we have been slack a little bit here, because it is mostly
> for overview/general idea purposes that this draft is for. But then adding a
> line handling the case that you mention would not be such a big deal. Shall
> do.

Sure.

>>4.2 - shouldn't the upper-layer interface be verbose enough to indicate
>>successful/unsuccessful green part transmissin as well?
> 
>   Well there is this Transmission Completion Notice (Sec 6.4 in the LTP
> Spec. draft) that gets sent to the local client service when all the data
> (red & green) of the session is transmitted and the red-part had been
> reported to have been received fine. I am not really sure if a notice that
> indicates original transmission completion 
> (transmitting once of all red & green data segments, without necessarily
> meaning acknowledgment of all the red segments by the receiver) would be
> useful to the client service instance. But I guess it can be trivially added
> if there is community consensus on that one.

One problem, though, is that there may never be any event that can trigger delivery of an unsuccessful green part transmission, because the dropped segments may include the EOB.

Given that the receiving application is notified of complete reception of the entire red part and of each green-part segment individually, it's not clear to me that an additional notice would add much value.  But as Mani says, if there's consensus that it's needed then it wouldn't be difficult to add.

>>One general thing I really dislike about the protocol's design is the
>>inclusion of "prompted" and "asynchronous" ack modes.  How to use these
>>properly is simply left as an exercise to the implementor, which I feel
>>is potentially dangerous.  If we _need_ them, then we should provide
>>some guidance for how to use them, otherwise remove them from the spec,
>>or they will be either not used or improperly used.
> 
>   I see your point. I would like to hear my co-author Scott's views on this
> one.

It's true that over-zealous accelerated retransmission could consume a lot of bandwidth, but aside from that possibility it's not clear to me how these features are dangerous (if implemented in a conformant manner, like all the other features of the protocol).

If that's the issue, then it seems to me that guidance in how to use accelerated retransmission is the sort of thing that will emerge from experience in the user community and will be documented in later literature; I don't think it's something that we as protocol designers really have any business dictating to users.  Worth discussing some more, though.

Scott

Date: Tue, 08 Feb 2005 13:03:31 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

Wesley Eddy wrote:
> On Mon, Feb 07, 2005 at 11:52:55AM +0000, Stephen Farrell wrote:
> 
>>>>>Virtually all of LTP assumes that a link strictly
>>>>>connects 2 hosts, and that a path is simply one hop across that link.
>>>>
>>>>I'm not sure where that "strictly" comes from, but I guess
>>>>its a matter of emphasis more than anything else.
>>>>
>>>
>>>Take a look at the motivations document:
>>>"""
>>>  In contrast, LTP is a protocol for "point to point" reliability on a
>>>  single link: traffic between two LTP engines is expected not to
>>>  traverse any intermediate relays.
>>>"""
>>
>>So where's it say "strictly"? Must get better glasses:-)
>>
>>How you'd "expect" a protocol to work in nominal mode and what
>>you ought to protect against when there's a potential adversary
>>are not the same.
> 
> To me, the motivations draft seems to pretty explicitly state that any
> environment but a single point-to-point link is out of the potential
> deployment space for LTP.  The protocol includes several design
> assumptions that are based on this property, and would cause it to behave
> rather poorly if this condition is not met.  A single point-to-point link
> is not only the nominal operating environment, but the *required* one.
> Since we seem to have different interpretations here though, perhaps
> others can help obtain consensus on this.

Wes, you are perfectly correct in saying that LTP is designed to be run on point-to-point links and that a number of its design principles assume that this is how it is deployed.  After all, it is principally intended to be run over extremely long R/F links among interplanetary spacecraft and ground stations.

Saying that this is the *required* operating environment is a bit of an overstatement, though.  I don't think there's anything in the text of the spec that prohibits use of the protocol under conditions in which it might not (or might, depending) behave efficiently, and we wouldn't have any way of enforcing that kind of prohibition anyway.

People are going to do what they want to do, and often for perfectly good reasons that we didn't happen to think of in advance.  If LTP proves useful in some environments, I can imagine some experimentation with it in others.  Some of those experiments will not be successful, but perhaps others will.

One example: from LTP's point of view, an underlying TCP connection over the Internet looks a lot like a single, very clean point-to-point link.  Data arrive in transmission order, so the behavioral assumptions that LTP relies on are met.  It could well be argued that there's no good reason to run LTP on top of TCP, but it seems possible to me that someone could eventually construct a plausible ops concept along these lines; in that event, you might have security considerations to address and yet might not want to run a VPN.

> To me, it seems that the need, or lack of need, for authentication
> mechanisms is wholly dependant on how we clarify this design goal.  If
> your interpretation is favored (multiple hops and shared-links allowed),
> it seems like there would be several other issues to contend with, eg:
> dealing with segment reordering, developing some CC mechanisms (BCP re
> RFC 2914), etc.

Sure, a host of other issues come up, though I think some of them are relatively tractable: TCP/IP in the Internet already does congestion control, for example.

I personally am not putting a lot of effort into LTP security, partly because I'm inclined to think that DTN bundling security above it will be sufficient, but largely because I am very far from being an authority on security issues and am in any case not very good at predicting the future.  Although I wouldn't want the security measures Stephen is proposing to be mandatory elements of the core LTP protocol, as optional extensions I think they can't do any harm and in some cases they might well do a lot of good.

Scott

Date: Tue, 8 Feb 2005 12:10:42 -0800
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: Melissa Ho <[email-masked]>, tk424 <[email-masked]>, dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] DTN2 manual or tutorials?
Mail-Followup-To: [email-masked], Melissa Ho <[email-masked]>, tk424 <[email-masked]>, dtn-interest <[email-masked]>
Sender: [email-masked]

> > After you first compile DTN2, you will need to initialize the database:
> > ./daemon/dtnd --init-db
> > 
> > Then to clear the database and run dtn you can use the tidy option:
> > ./daemon/dtnd -t
> 
> There is a bug that _requires_ you to use -t right now. I just figured
> it out a few days ago, and am planning on checking in the change
> today, hopefully. The bug shows up if you try to init the DB using
> --init-db, then run dtnd without -t. You get an ASSERT about
> next_regid still being 0xffffffff. The fix involves ensuring that
> load() gets called before update() in GlobalStore.cc.

Ugh. Well let me know if you have a fix, I'll update that.

> Melissa, on your website, you mention that the code to read in old
> bundles is missing, and that -t is required right now. I don't think
> that's true anymore, right?

It's not. Bundle re-reading works now.

> I am working on a Cygwin port right now, so that I don't have to
> reboot into Linux whenever I want to work on DTN2. I'm very close to
> having that done, and will likely take up some documentation and
> tutorial jobs after that. I haven't talked with Michael about this
> yet, but it seems like the next obvious place where DTN2 needs some
> work contributed to it.

That would be immensely useful and very much appreciated.

-m

Date: Tue, 8 Feb 2005 13:24:26 -0600
From: Jeff Allen <[email-masked]>
Reply-To: [email-masked]
To: Melissa Ho <[email-masked]>
Subject: Re: [dtn-interest] DTN2 manual or tutorials?
Cc: tk424 <[email-masked]>, dtn-interest <[email-masked]>
Sender: [email-masked]

> After you first compile DTN2, you will need to initialize the database:
> ./daemon/dtnd --init-db
> 
> Then to clear the database and run dtn you can use the tidy option:
> ./daemon/dtnd -t

There is a bug that _requires_ you to use -t right now. I just figured
it out a few days ago, and am planning on checking in the change
today, hopefully. The bug shows up if you try to init the DB using
--init-db, then run dtnd without -t. You get an ASSERT about
next_regid still being 0xffffffff. The fix involves ensuring that
load() gets called before update() in GlobalStore.cc.

Melissa, on your website, you mention that the code to read in old
bundles is missing, and that -t is required right now. I don't think
that's true anymore, right?

I am working on a Cygwin port right now, so that I don't have to
reboot into Linux whenever I want to work on DTN2. I'm very close to
having that done, and will likely take up some documentation and
tutorial jobs after that. I haven't talked with Michael about this
yet, but it seems like the next obvious place where DTN2 needs some
work contributed to it.

  -jeff

Date: Tue, 08 Feb 2005 11:56:36 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

Wes,

Yes, I think we've fairly well flogged the arguments. But, being
Irish, its hard to let anyone else get the last word:-)

Wesley Eddy wrote:

> I will not publicly respond further in this thread.  I think this and
> previous messages make my point abundantly clear.  I will continue
> discussion offlist, if you'd wish.  Here are some final responses:
> 
> On Mon, Feb 07, 2005 at 06:06:32PM +0000, Stephen Farrell wrote:
> 
>>>>I can't understand why you continue to ignore the following:
>>>>
>>>> Running LTP over a radio link leaves open potential DoS and
>>>> other directed attacks which are worse than jamming and
>>>> many, in fact, almost all, of the practical options for such
>>>> links (802.11b/WEP,BT,GSM) suffer from known security problems.
>>
>>I take it you accept this then?
>>

> No I don't.  I haven't seen any threat model that presents why LTP
> should attempt to operate over clearly compromised links.  

Fair enough. I've yet to convince you!

 > A sane LTP
> implementation can't be effectively DoSed, in any case.

That's wildly optimistic, according to my, perhaps jaundiced,
view of IT security.

>>I guess my experience tells me that authentication support is a
>>requirement for pretty much all protocols. Isn't that also a very
>>reasonable guideline?
> 
> No.  Authentication is not a requirement (or even a desirable feature)
> for a large (and important) set of network uses, eg casual web browsing.

Eh...HTTP digest auth, HTTP proxy auth, HTTP/TLS with forms based
login, HTTP/TLS with TLS-client-auth, various of the many SAML
possibilities. Those are all things that according to you SHOULD NOT
have been *defined*, just because sometimes the same is provided at
another layer, or is not in use. I just can't see that argument
holding water.

>>>Applying
>>>this to authentication mechanisms in LTP ... the mere presence of an
>>>attacker on a link indicates that it is no longer point-to-point.
>>
>>Hang on. Your initial argument against LTP authentication was that
>>it could be done by a link layer, and you mentioned GSM/GPRS & BT.
>>Now, you seem to be saying that such cases are out of scope.
>>So which is it?
> 
  > I don't follow your question.  I've always said that authentication does
> not belong in LTP and that lower (and upper) layers can do this just
> fine.  

I agree that other layers can do it fine. I disagree that auth. does
not belong.

 > Several rather useful transport protocols (TCP, UDP, DCCP, etc)
> exist without any cryptographic authentication mechanisms.  When these
> have been needed, they've been provided at other layers.

That is true. However, I could believe that that's largely for
historical reasons and that a TLS-like thing would have been
nice to have integrated with TCP (etc.). However, you do make a
fair point and if you could characterise *why* e.g. TCP is ok
without security primitives, then I'd be interested. I suspect
that the answer would turn out to be largely historical, but
others on this list certainly know better than I would.

>>>Authentication mechanisms in LTP would attempt to maintain a semblance
>>>of the designed-for precondition of point-to-pointedness over a
>>>compromised link.  
>>
>>Not at all. Authentication mechanisms allow an LTP peer to detect
>>segment modification/insertion which is possible in the cases
>>mentioned.
> 
> In which case an attacker would just fully utilize the link with noise.
> With or without authentication, LTP can get no useful work done once the
> link is compromised.

Ok. You still don't recognise the difference between jamming and a
directed attack. That's ok, but I still maintain there is a difference.

>>>Except for being futile, this is not a bad goal, only
>>>somewhat out of scope, given the current lack of a lucid description of
>>>even a single use case where an attacker would wish to forge LTP
>>>segments.
>>
>>Hyperbole again. Honestly, it doesn't help me understand you.
>
> Disagree.

Can't accuse you of hyberbole there:-)

>>DoS is a killer for basically any unattended host, regardless of
>>the layer at which it occurs. Turns out that all our experience
>>shows that almost all complex systems have DoS opportunities
>>all over the place.
> 
> LTP itself cannot be DoSed.  

Ahem. That's plain untrue. Say a session has successfully
gotten XXMB across a deep space link and I then manage to
cancel or corrupt the session via segment insertion from
some (off-path) compromised host (using a relay/repeater
or whatever) inside the Earth station. Wouldn't that be a
DoS? It is in my language.

 > There are no resources there, aside from the
> segment buffers.  Forcing segment buffers to be maintained indefinitely
> is possible with or without an LTP-based authentication scheme.
> Resistance is futile.

I think you misunderstand how, at least I, approach DoS - the idea
is to build in mechanisms (e.g. picking sequence numbers at random)
so that its harder to mount an attack (in that case from an off
path attack point).

Stephen.

Date: Tue, 08 Feb 2005 01:05:11 -0800
From: Melissa Ho <[email-masked]>
To: tk424 <[email-masked]>
CC: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] DTN2 manual or tutorials?
Sender: [email-masked]

Alas, the only official documentation and tutorials are those included 
with the source, and the dtn-interest archives.

There is a slightly out-of-date installation guide on my website here:
http://www.melissaho.com/research/dtn/demo

The caveats/tricks you should know are:
1. Download the BerkeleyDB source and compile it with --enable-cxx:
cd build_unix
../dist/configure --enable-cxx
make
make install (as root)
2. Download tclreadline source and install it. This will give you access 
to the dtnd command line help, and in general make it easier to use/test 
dtn. One of the hooks for processing bundles is to specify a tcl command 
to run on bundles that are received. http://tclreadline.sourceforge.net
3. By default, dtnd is initialized with the conf file ./daemon/dtn.conf. 
This is a tcl file - where you can load the appropriate test functions, 
and do any node/route initializations necessary.
4. You may need to specify your LD_LIBRARY _PATH in order to run dtnd 
successfully:
export LD_LIBRARY_PATH=/usr/local/BerkeleyDB4.2/lib

For the dtnd options run it with the --help option:
./daemon/dtnd --help

After you first compile DTN2, you will need to initialize the database:
./daemon/dtnd --init-db

Then to clear the database and run dtn you can use the tidy option:
./daemon/dtnd -t

Read the error messages if it doesn't run successfully - in general, 
Mike has done a pretty good job of putting in informative enough error 
messages for you to be able to fix whatever configuration issues come up.

As another side note, I just did a fresh checkout and build on a fedora 
core 3 machine - and realized that I was missing tcl.h since I didn't 
have tcl-devel installed.

Also - we haven't tested DTN2 on solaris - your best bet (while we're 
still in the early stages) is to do development on Fedora.

Melissa

tk424 wrote:

> Dear DTN2 users,
>
> My team in University of Missouri, Rolla recently installed DTN2 
> software on Solaris9 and is trying to learn this software.
>
> As far as I searched so far, it seems that there is no manual or 
> tutorials on the DTN2 simulator, that is a material that 
> systematically guides a newbie into this DTN2 world. Is this true? If 
> not, where can I get the material? If so, how I can learn how to use 
> this simulator?
>
> I was wondering whether I can ask some specific questions to bug DTN2 
> users. :>
>
> As some of them,
>
> (1) How to use the test files in directory “DTN2/test” such as main.tcl?
>
> (2) What does each tcl and shell files (*.tcl and *.sh) in directory 
> “DTN2/test” do? Does main.tcl use other tcl and shell files?
>
> (3) Can you give me some example commands of “dtnd” so that I can 
> learn the usage of “dtnd”
>
> There are tons of other questions, but I will stop here. J
>
> Thank you in advance!
>
> Best regards,
>
> Tae-hyung Kim
>
> p.s. Just for your information, I have some background on Tcl, C++, 
> awk, and a little bit of shell scripting.
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Friends are angels who lift us to our feet when
> our wing have trouble remembering how to fly.
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2/7/2005
>  
>

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2/7/2005

Date: Tue, 8 Feb 2005 00:56:09 -0500
From: Manikantan Ramadas <[email-masked]>
To: [email-masked], Stephen Farrell <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re: draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

--H+4ONPRPur6+Ovig
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Wes,

Alright, now that I re-read this thread in peace, I seem to understand=20
your positions slightly better. I think quite a bit of the disagreement
is because of misinterpretation of terminology, for example, the word
"relay".=20

> Running LTP over a radio link leaves open potential DoS and
> other directed attacks which are worse than jamming and
> many, in fact, almost all, of the practical options for such
> links (802.11b/WEP,BT,GSM) suffer from known security problems.

I think there is quite a bit of truth in the above statement. Time and again
we find that link-layer security if at all available, is flimsy, and not
robust enough, etc.=20
My personal gut feeling is that security in such technologies get to
be designed by teams of computer engineers/electrical engineers and that
their design team needs people with solid computer security background. [But
then again is a personal "gut" feeling. So ignore it if you disagree with
it. :-) ]

But more often than not you are stuck with hardware or device drivers as the
case may be, that offer flimsy computer security, if at all. But such
devices typically do provide a way of turning off their security mechanisms;
Thus we could turn it off and use a better more robust security mechanism at
a layer above of our choice. This problem, for example, is fairly realistic,
given that it exists atleast with something as prevalent
as 802.11b, bluetooth, etc. For such devices, it is certainly nice to have =
the
layer above offer robust security primitives. But continuing with (what I
understand as) your line of thought, you seem to suggest that if I were
having a bunch of blue-tooth devices (that seem to offer as good as no
security mechanism) communicating with one another and were worried about
the authentication needs of segments, I should just tunnel all my data over
an ssh connection (utilizing an RSA public/private key infrastructure).=20
Sure this can be made to work, but this would probably be an overkill and
might need rewrite of all my applications to do this. In this case, it would
seem ideal to have the layer sitting right above the blue-tooth layer,
over which I have software control, offer robust security. If I was perfect=
ly
happy with the blue-tooth security primitives of course, I shouldn't be
forced to use this security; I agree.

We can still argue on which layer above the raw datalink layer is ideal
for security, where ofcourse individual mileage varies. But such argument is
still not good enough to *not* have robust, optional usage, security
primitives in LTP.

LTP is certainly point-to-point, and of course I agree that quite a lot of
design assumptions of LTP are based on the fact that :=20

Segments sent from the sender are received at the receiver in the same order
as sent (if at all received, that is). The only cause of segment loss is
data corruption. - [A]=20

Certainly. But I guess you have to remember that LTP is point-to-point in
the way an 802.11b sender and receiver are point-to-point. This is a
reasonable analogy, valid for most LTP deployment scenarios. Everybody gets
to listen to whats going on in an LTP session, and any-one within the
environment may make-up a spoofed up segment purporting to come from the
sender, to the receiver. Sure, any such adversary in the environment may jam
the channel environment. It is an easy low-tech solution, that just needs a
lot of power (in the 802.11b case, for example). But a high-tech and clever
solution is ofcourse to make up an LTP cancel segment and close the session.

Similarly, I think what Stephen really means when he used the term "relay"
is a repeater. Atleast a relay that is operating as a pure repeater. Note
that from a layering perspective, it is a datalink layer relay, and given
that LTP sits right above the datalink, this would and should be transparent
for LTP purposes since condition [A] is guarenteed.=20

As another LTP deployment example, consider a network of sensors, basically
802.11b nodes scattered in a lake as with Stephen's research deployment. It
would seem perfectly reasonable to have a mobile 802.11b base-station on a
boat that visits this lake occasionally, to have a protocol stack as below:

   --------
   Bundling
   --------
     LTP  =20
   -------
     UDP
   -------
     IP
   -------
   802.11b
   -------

Also assume the presence of similar stacks on the lake-bed nodes.=20

In this setup ofcourse the entire layer below LTP serves as a datalink that
guarentees condition [A], and LTP is basically being used for its efficient
retransmission properties. Here ofcourse, I am assuming that IP is basically
being used just for its addressing capabilities, and no real routing is
being done when the base-station on the boat talks to each of the nodes.

All that being said, I certainly agree with you in that we need a decent
threat model for our extensions draft. For the first cut, we should atleast
clearly define what kinds of things we are protoecting ourselves against
with the mechanisms we propose. This is a 00 draft after all. More work
needs to be done here, obviously.

I would certainly like to hear what other people in the list think on this
topic; especially the folks researching on DTN security at MITRE.

Thanks guys,
Mani.

On Mon, Feb 07, 2005 at 06:06:32PM +0000, Stephen Farrell wrote:
>=20
> Wes,
>=20
> Wesley Eddy wrote:
>=20
> >On Mon, Feb 07, 2005 at 03:00:55PM +0000, Stephen Farrell wrote:
> >
> >>Wes,
> >>
> >>I can't understand why you continue to ignore the following:
> >>
> >>  Running LTP over a radio link leaves open potential DoS and
> >>  other directed attacks which are worse than jamming and
> >>  many, in fact, almost all, of the practical options for such
> >>  links (802.11b/WEP,BT,GSM) suffer from known security problems.
>=20
> I take it you accept this then?
>=20
> >>Can you provide an argument why a protocol to be used in such
> >>a context MUST NOT define authentication primitives? (Which is
> >>the case you're making).
>=20
> Ok, you make an argument below. I don't buy it myself.
>=20
> >No, that's not at all an accurate interpretation of my position.  I
> >would say that:
> >
> >  A protocol with design considerations as narrow and well-defined as
> >  LTP, SHOULD contain only those mechanisms absolutely necessary for the
> >  functionality of the protocol under the designed-for use cases.  The
> >  protocol SHOULD NOT contain premature optimizations or extensions to
> >  (possibly) satisfy tenuous use cases outside the protocol's
> >  well-articulated design goals.
> >
> >I hope we can all agree that this is a reasonable guideline. =20
>=20
> I think the language is a bit overblown (e.g. "premature", "tenuous"
> as used above aren't really technical terms are they?), which is not
> what I'd want in a "reasonable" guideline, but I think I agree with
> the sentiment (hard to tell given how its phrased).
>=20
> I guess my experience tells me that authentication support is a
> requirement for pretty much all protocols. Isn't that also a very
> reasonable guideline?
>=20
> > Applying
> >this to authentication mechanisms in LTP ... the mere presence of an
> >attacker on a link indicates that it is no longer point-to-point.
>=20
> Hang on. Your initial argument against LTP authentication was that
> it could be done by a link layer, and you mentioned GSM/GPRS & BT.
> Now, you seem to be saying that such cases are out of scope.
> So which is it?
>=20
> Anyway, your statement is not true of any wireless link, e.g.
> microwave is intended to be point to point, but can be eavesdropped
> upon and so of course segments could be inserted too. With a bit of
> effort I'd say optical links would be similarly vulnerable. For
> wired links, an attacker with physical access can generally insert
> segments. I guess its hard to see what kind of like is truely
> point-to-point and invulnerable to segment insertion (maybe
> something protected using wire-speed quantum crypto, but otherwise,
> I'm stuck!). Can you give some examples?
>=20
> >Authentication mechanisms in LTP would attempt to maintain a semblance
> >of the designed-for precondition of point-to-pointedness over a
> >compromised link. =20
>=20
> Not at all. Authentication mechanisms allow an LTP peer to detect
> segment modification/insertion which is possible in the cases
> mentioned.
>=20
> > Except for being futile, this is not a bad goal, only
> >somewhat out of scope, given the current lack of a lucid description of
> >even a single use case where an attacker would wish to forge LTP
> >segments.
>=20
> Hyperbole again. Honestly, it doesn't help me understand you.
>=20
> >If particular applications are worried about being attacked by bogus
> >data, then they'll surely have their own end-to-end methods of
> >authenitcating data. =20
>=20
> I already responded a couple of time wrt the multiple layers
> where security is appropriate I guess.
>=20
> > LTP need not protect them.  The worst thing, it
> >seems, that an attacker could really do is waste capacity at additional
> >links by spoofing segments that an upper layer would decide to route
> >onwards. =20
>=20
> DoS is a killer for basically any unattended host, regardless of
> the layer at which it occurs. Turns out that all our experience
> shows that almost all complex systems have DoS opportunities
> all over the place. Even more so, for power limited hosts.
> Separately, it also turns out to be fairly easy to take over
> many hosts when you can easily talk to them from the Internet -
> hence the firewall market. Much as I'd like this not to be the
> case, wishful thinking is not the correct reaction. Omitting
> basic security mechanisms from network protocols is a good
> example of such wishful thinking IMO.
>=20
> Stephen.
> _______________________________________________
> ltp mailing list
> [email-masked]
> http://irg.cs.ohiou.edu/mailman/listinfo/ltp

--=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 *
____________________________________________________________________

--H+4ONPRPur6+Ovig
Content-Type: application/pgp-signature
Content-Disposition: inline

--H+4ONPRPur6+Ovig--

Date: Mon, 7 Feb 2005 15:17:50 -0500
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Reply-To: [email-masked]
Sender: [email-masked]

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

I will not publicly respond further in this thread.  I think this and
previous messages make my point abundantly clear.  I will continue
discussion offlist, if you'd wish.  Here are some final responses:

On Mon, Feb 07, 2005 at 06:06:32PM +0000, Stephen Farrell wrote:
>=20
> >>I can't understand why you continue to ignore the following:
> >>
> >>  Running LTP over a radio link leaves open potential DoS and
> >>  other directed attacks which are worse than jamming and
> >>  many, in fact, almost all, of the practical options for such
> >>  links (802.11b/WEP,BT,GSM) suffer from known security problems.
>=20
> I take it you accept this then?
>

No I don't.  I haven't seen any threat model that presents why LTP
should attempt to operate over clearly compromised links.  A sane LTP
implementation can't be effectively DoSed, in any case.

=20
=20
> I guess my experience tells me that authentication support is a
> requirement for pretty much all protocols. Isn't that also a very
> reasonable guideline?

No.  Authentication is not a requirement (or even a desirable feature)
for a large (and important) set of network uses, eg casual web browsing.

> > Applying
> >this to authentication mechanisms in LTP ... the mere presence of an
> >attacker on a link indicates that it is no longer point-to-point.
>=20
> Hang on. Your initial argument against LTP authentication was that
> it could be done by a link layer, and you mentioned GSM/GPRS & BT.
> Now, you seem to be saying that such cases are out of scope.
> So which is it?

I don't follow your question.  I've always said that authentication does
not belong in LTP and that lower (and upper) layers can do this just
fine.  Several rather useful transport protocols (TCP, UDP, DCCP, etc)
exist without any cryptographic authentication mechanisms.  When these
have been needed, they've been provided at other layers.

=20
> >Authentication mechanisms in LTP would attempt to maintain a semblance
> >of the designed-for precondition of point-to-pointedness over a
> >compromised link. =20
>=20
> Not at all. Authentication mechanisms allow an LTP peer to detect
> segment modification/insertion which is possible in the cases
> mentioned.

In which case an attacker would just fully utilize the link with noise.
With or without authentication, LTP can get no useful work done once the
link is compromised.

> > Except for being futile, this is not a bad goal, only
> >somewhat out of scope, given the current lack of a lucid description of
> >even a single use case where an attacker would wish to forge LTP
> >segments.
>=20
> Hyperbole again. Honestly, it doesn't help me understand you.

Disagree.

=20
> >If particular applications are worried about being attacked by bogus
> >data, then they'll surely have their own end-to-end methods of
> >authenitcating data. =20
>=20
> I already responded a couple of time wrt the multiple layers
> where security is appropriate I guess.

No one is arguing about the virtues of a multi-layered approach.  We've
all read Saltzer, Reed, & Clark.  What we're talking about here is what
layers a specific feature has merits at.

=20
> > LTP need not protect them.  The worst thing, it
> >seems, that an attacker could really do is waste capacity at additional
> >links by spoofing segments that an upper layer would decide to route
> >onwards. =20
>=20
> DoS is a killer for basically any unattended host, regardless of
> the layer at which it occurs. Turns out that all our experience
> shows that almost all complex systems have DoS opportunities
> all over the place.

LTP itself cannot be DoSed.  There are no resources there, aside from the
segment buffers.  Forcing segment buffers to be maintained indefinitely
is possible with or without an LTP-based authentication scheme.
Resistance is futile.

-Wes

--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--9ADF8FXzFeE7X4jE--

Content-class: urn:content-classes:message
Date: Mon, 7 Feb 2005 14:08:07 -0600
From: "tk424" <[email-masked]>
To: "dtn-interest" <[email-masked]>
Subject: [dtn-interest] DTN2 manual or tutorials?
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C50D50.BD2124C5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear DTN2 users,

=20

My team in University of Missouri, Rolla recently installed DTN2
software on Solaris9 and is trying to learn this software.

As far as I searched so far, it seems that there is no manual or
tutorials on the DTN2 simulator, that is a material that systematically
guides a newbie into this DTN2 world. Is this true? If not, where can I
get the material? If so, how I can learn how to use this simulator?=20

=20

I was wondering whether I can ask some specific questions to bug DTN2
users. :>

As some of them,

(1)     How to use the test files in directory "DTN2/test" such as
main.tcl?

(2)     What does each tcl and shell files (*.tcl and *.sh) in directory
"DTN2/test" do? Does main.tcl use other tcl and shell files?=20

(3)     Can you give me some example commands of "dtnd" so that I can
learn the usage of "dtnd"

=20

There are tons of other questions, but I will stop here. :-)

Thank you in advance!

=20

Best regards,

Tae-hyung Kim

=20

p.s. Just for your information, I have some background on Tcl, C++, awk,
and a little bit of shell scripting.

=20

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!
   Friends are angels who lift us to our feet when =20
   our wing have trouble remembering how to fly.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!

=20

=20

------_=_NextPart_001_01C50D50.BD2124C5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Dear DTN2 users,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>My team in </span></font><font size=3D2 =
face=3DArial><span
  =
style=3D'font-size:10.0pt;font-family:Arial'>University</span></font><fon=
t
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> of </span></font><font
  size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Missouri</span></font><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>, Rolla recently
installed DTN2 software on Solaris9 and is trying to learn this =
software.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As far as I searched so far, it seems that there is =
no
manual or tutorials on the DTN2 simulator, that is a material that =
systematically
guides a newbie into this DTN2 world. Is this true? If not, where can I =
get the
material? If so, how I can learn how to use this simulator? =
</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I was wondering whether I can ask some specific =
questions to
bug DTN2 users. :&gt;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As some of them,</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>(1)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>How to use the test files in directory =
&#8220;DTN2/test&#8221;
such as main.tcl?</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>(2)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>What does each tcl and shell files (*.tcl and =
*.sh) in
directory &#8220;DTN2/test&#8221; do? Does main.tcl use other tcl and =
shell
files? </span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>(3)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>Can you give me some example commands of =
&#8220;dtnd&#8221;
so that I can learn the usage of &#8220;dtnd&#8221;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>There are tons of other questions, but I will stop =
here. </span></font><font
size=3D2 face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:Wingdings'>J</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thank you in advance!</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Best regards,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Tae-hyung Kim</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>p.s. Just for your information, I have some =
background on Tcl,
C++, awk, and a little bit of shell scripting.</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!<br>
&nbsp;&nbsp; Friends are angels who lift us to our feet when&nbsp; <br>
&nbsp; &nbsp;our wing have trouble remembering how to fly.<br>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!</span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C50D50.BD2124C5--

Date: Mon, 7 Feb 2005 14:53:23 -0500
From: Manikantan Ramadas <[email-masked]>
To: Wesley Eddy <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re: [ltp] comments on draft-irtf-dtnrg-ltp-motivation-00
Sender: [email-masked]

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

Hi Wes,

On Fri, Feb 04, 2005 at 11:46:27AM -0500, Wesley Eddy wrote:
> I just made a run through the LTP motivations document.  It's quite
> good overall, and I'm pleased with the majority of it.  I do have some
> comments and suggestions:
>=20
> on page 4: "line of sight of each other" -> "line of sight with each othe=
r"
>=20
> on page 6, during discussion of why standard protocols won't work well,
> it might be good to also cite:
>=20
> O. B. Akan, J. Fang, I. F. Akyildiz,
> "Performance of TCP Protocols in Deep Space Communication Networks,"i
> IEEE Communications Letters, vol. 6, no. 11, pp. 478-480, November 2002.
>=20
> on page 7, it might also be worth noting that mechanisms like HTTP pipeli=
ning,
> for mitigating high RTTs, do not exist in many applications.
>=20
> Also here, note that SCTP uses the same slow start algorithm that TCP
> does, so is similarly unsuitable.  Perhaps note that slow start is
> designed to probe the unknown capacity of a network path; whereas LTP
> will be mostly used on single-link paths where there is generally not
> contention with other hosts, and thus not much need for slow start (or
> even congestion control).
>=20

  All of the above valuable comments seem reasonable to me. Shall add them =
to
the to-do list for the next release of the draft. Thanks!=20

> 3.1.2 Session IDs - this is not all that novel, SCTP and BEEP have identi=
cal
> notions.
>=20

  You are right. But given the discussion on the Multiplicity of
Protocol State Machines in Sec 3.1.1, it seems reasonable to have that
Sec 3.1.2 on Session IDs in there. It is still a "Feature" of LTP, though
not necessarily novel.

> page 12: use of "LLC" out of the blue?
>

  Yeah, good catch. Shall expand it out and say what it is.
 =20
> section 3.6 - it's not clear what you mean by "intolerably optimistic" in
> reference to timeout intervals.  I think instead of talking about the
> timeout interval itself, what you're really trying to get at here is
> that there is no head-of-line blocking in LTP.  This is pretty well
> described in the SCTP documents, so saying it quickly and refing SCTP
> should suffice.
>=20
 =20
> In the next 2 paragraphs, I think that the point is that the round trip t=
ime
> history is potentially very noisy, and so rather than filter it through an
> averaging function, it's prefferred to just use the "instantaneous RTT". =
 This
> doesn't come out super-clearly from the present draft's exact wording tho=
ugh.
> I (somewhat) disagree with this approach anyways, but we'll talk about
> that later.
>=20

  Yeah the language here in both the places you point out could use some
clarification. Shall fix.

> page 14 - probably should explicitly state that EORP =3D=3D "end of red p=
art", as
> this has not been done previously.
>=20

  Good catch again. It is an artifact of our splitting the documents into
three. The original monolith had the Terminology section defined before, th=
at
defined EORP. Shall fix.

> 4.2 - in the case where the report-ack gets lost and the RSR retransmits =
the
> report, we need clarification on how the report-ack in response to this is
> generated, since the SSR has gone away long ago.  For instance, tell us t=
hat
> the report itself contains sufficient information to generate the report-=
ack
> without referencing the (non-existent) SSR state.
>=20

  This is handled in the main spec. draft with the Sender State Transition
Diagram. I guess we have been slack a little bit here, because it is mostly
for overview/general idea purposes that this draft is for. But then adding a
line handling the case that you mention would not be such a big deal. Shall
do.

> 4.2 - shouldn't the upper-layer interface be verbose enough to indicate
> successful/unsuccessful green part transmissin as well?
>=20

  Well there is this Transmission Completion Notice (Sec 6.4 in the LTP
Spec. draft) that gets sent to the local client service when all the data
(red & green) of the session is transmitted and the red-part had been
reported to have been received fine. I am not really sure if a notice that
indicates original transmission completion=20
(transmitting once of all red & green data segments, without necessarily
meaning acknowledgment of all the red segments by the receiver) would be
useful to the client service instance. But I guess it can be trivially added
if there is community consensus on that one.

> One general thing I really dislike about the protocol's design is the
> inclusion of "prompted" and "asynchronous" ack modes.  How to use these
> properly is simply left as an exercise to the implementor, which I feel
> is potentially dangerous.  If we _need_ them, then we should provide
> some guidance for how to use them, otherwise remove them from the spec,
> or they will be either not used or improperly used.
>=20
  I see your point. I would like to hear my co-author Scott's views on this
one.

- 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 *
____________________________________________________________________

--/9DWx/yDrRhgMJTb
Content-Type: application/pgp-signature
Content-Disposition: inline

--/9DWx/yDrRhgMJTb--

Date: Mon, 07 Feb 2005 18:06:32 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

Wes,

Wesley Eddy wrote:

> On Mon, Feb 07, 2005 at 03:00:55PM +0000, Stephen Farrell wrote:
> 
>>Wes,
>>
>>I can't understand why you continue to ignore the following:
>>
>>   Running LTP over a radio link leaves open potential DoS and
>>   other directed attacks which are worse than jamming and
>>   many, in fact, almost all, of the practical options for such
>>   links (802.11b/WEP,BT,GSM) suffer from known security problems.

I take it you accept this then?

>>Can you provide an argument why a protocol to be used in such
>>a context MUST NOT define authentication primitives? (Which is
>>the case you're making).

Ok, you make an argument below. I don't buy it myself.

> No, that's not at all an accurate interpretation of my position.  I
> would say that:
> 
>   A protocol with design considerations as narrow and well-defined as
>   LTP, SHOULD contain only those mechanisms absolutely necessary for the
>   functionality of the protocol under the designed-for use cases.  The
>   protocol SHOULD NOT contain premature optimizations or extensions to
>   (possibly) satisfy tenuous use cases outside the protocol's
>   well-articulated design goals.
> 
> I hope we can all agree that this is a reasonable guideline.  

I think the language is a bit overblown (e.g. "premature", "tenuous"
as used above aren't really technical terms are they?), which is not
what I'd want in a "reasonable" guideline, but I think I agree with
the sentiment (hard to tell given how its phrased).

I guess my experience tells me that authentication support is a
requirement for pretty much all protocols. Isn't that also a very
reasonable guideline?

 > Applying
> this to authentication mechanisms in LTP ... the mere presence of an
> attacker on a link indicates that it is no longer point-to-point.

Hang on. Your initial argument against LTP authentication was that
it could be done by a link layer, and you mentioned GSM/GPRS & BT.
Now, you seem to be saying that such cases are out of scope.
So which is it?

Anyway, your statement is not true of any wireless link, e.g.
microwave is intended to be point to point, but can be eavesdropped
upon and so of course segments could be inserted too. With a bit of
effort I'd say optical links would be similarly vulnerable. For
wired links, an attacker with physical access can generally insert
segments. I guess its hard to see what kind of like is truely
point-to-point and invulnerable to segment insertion (maybe
something protected using wire-speed quantum crypto, but otherwise,
I'm stuck!). Can you give some examples?

> Authentication mechanisms in LTP would attempt to maintain a semblance
> of the designed-for precondition of point-to-pointedness over a
> compromised link.  

Not at all. Authentication mechanisms allow an LTP peer to detect
segment modification/insertion which is possible in the cases
mentioned.

 > Except for being futile, this is not a bad goal, only
> somewhat out of scope, given the current lack of a lucid description of
> even a single use case where an attacker would wish to forge LTP
> segments.

Hyperbole again. Honestly, it doesn't help me understand you.

> If particular applications are worried about being attacked by bogus
> data, then they'll surely have their own end-to-end methods of
> authenitcating data.  

I already responded a couple of time wrt the multiple layers
where security is appropriate I guess.

 > LTP need not protect them.  The worst thing, it
> seems, that an attacker could really do is waste capacity at additional
> links by spoofing segments that an upper layer would decide to route
> onwards.  

DoS is a killer for basically any unattended host, regardless of
the layer at which it occurs. Turns out that all our experience
shows that almost all complex systems have DoS opportunities
all over the place. Even more so, for power limited hosts.
Separately, it also turns out to be fairly easy to take over
many hosts when you can easily talk to them from the Internet -
hence the firewall market. Much as I'd like this not to be the
case, wishful thinking is not the correct reaction. Omitting
basic security mechanisms from network protocols is a good
example of such wishful thinking IMO.

Stephen.

Date: Mon, 7 Feb 2005 09:54:51 -0800
From: Michael Demmer <[email-masked]>
To: Piero Cornice <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] thanks and something about debian
Mail-Followup-To: Piero Cornice <[email-masked]>, [email-masked]
Sender: [email-masked]

> I'd like to inform all the people who wants to compile dtn on a debian machine
> that i had an error while "making" the source of dtn 2.0.2
> The error was about the ASSERT function and i solved it by adding
> the instruction:
> 
> #include <assert.h>
> 
> in line 50 of DTN2/servlib/storage/SQLStore.cc

This should not be necessary, so I'm a little bit confused as to why
you would need this. SQLStore.cc should have at line 43
#include <oasys/debug/Debug.h> which defines the ASSERT macro.

One theory is that on your system, the preprocessor symbol _DEBUG_H_
is defined by some system file, so you never get the definitions from
Debug.h.

If you could do me a favor and first remove the #include <assert.h>
that you added, then cd into DTN2/servlib and run 
'make storage/SQLStore.E'. That will expand out all the preprocessor
symbols. If you could mail me the generated file, I could then take a
look and have a better idea as to what is going on.

thanks,
-mike

Date: Mon,  7 Feb 2005 18:42:21 +0100
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] thanks and something about debian
Sender: [email-masked]

Hi, i'm Piero (italian student)
Thanks to Melissa Ho and Larry Pyeatt for answering me: now everything works :)

I'd like to inform all the people who wants to compile dtn on a debian machine
that i had an error while "making" the source of dtn 2.0.2
The error was about the ASSERT function and i solved it by adding the instruction:

#include <assert.h>

in line 50 of DTN2/servlib/storage/SQLStore.cc

If anyone had the same problem, could try this way...

Thanks again and greetings from italy!
piero

Date: Mon, 7 Feb 2005 12:12:01 -0500
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Reply-To: [email-masked]
Sender: [email-masked]

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

On Mon, Feb 07, 2005 at 03:00:55PM +0000, Stephen Farrell wrote:
>=20
> Wes,
>=20
> I can't understand why you continue to ignore the following:
>=20
>    Running LTP over a radio link leaves open potential DoS and
>    other directed attacks which are worse than jamming and
>    many, in fact, almost all, of the practical options for such
>    links (802.11b/WEP,BT,GSM) suffer from known security problems.
>=20
> Can you provide an argument why a protocol to be used in such
> a context MUST NOT define authentication primitives? (Which is
> the case you're making).
>
> I believe that the situation described above fits exactly with
> your interpretation of the "deployment space for LTP". If not,
> can you explain what I'm missing?
>

No, that's not at all an accurate interpretation of my position.  I
would say that:

  A protocol with design considerations as narrow and well-defined as
  LTP, SHOULD contain only those mechanisms absolutely necessary for the
  functionality of the protocol under the designed-for use cases.  The
  protocol SHOULD NOT contain premature optimizations or extensions to
  (possibly) satisfy tenuous use cases outside the protocol's
  well-articulated design goals.

I hope we can all agree that this is a reasonable guideline.  Applying
this to authentication mechanisms in LTP ... the mere presence of an
attacker on a link indicates that it is no longer point-to-point.
Authentication mechanisms in LTP would attempt to maintain a semblance
of the designed-for precondition of point-to-pointedness over a
compromised link.  Except for being futile, this is not a bad goal, only
somewhat out of scope, given the current lack of a lucid description of
even a single use case where an attacker would wish to forge LTP
segments.

If particular applications are worried about being attacked by bogus
data, then they'll surely have their own end-to-end methods of
authenitcating data.  LTP need not protect them.  The worst thing, it
seems, that an attacker could really do is waste capacity at additional
links by spoofing segments that an upper layer would decide to route
onwards.  This problem is more logically solved at the routing layer,
assuming it is vulnerable.

Still waiting to here anyone elses opinions ... :)

-Wes
=20
--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--KdquIMZPjGJQvRdI--

Date: Mon, 07 Feb 2005 15:00:55 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

Wes,

I can't understand why you continue to ignore the following:

    Running LTP over a radio link leaves open potential DoS and
    other directed attacks which are worse than jamming and
    many, in fact, almost all, of the practical options for such
    links (802.11b/WEP,BT,GSM) suffer from known security problems.

Can you provide an argument why a protocol to be used in such
a context MUST NOT define authentication primitives? (Which is
the case you're making).

I believe that the situation described above fits exactly with
your interpretation of the "deployment space for LTP". If not,
can you explain what I'm missing?

Puzzled,
Stephen.

Wesley Eddy wrote:

> On Mon, Feb 07, 2005 at 11:52:55AM +0000, Stephen Farrell wrote:
> 
>>>>>Virtually all of LTP assumes that a link strictly
>>>>>connects 2 hosts, and that a path is simply one hop across that link.
>>>>
>>>>I'm not sure where that "strictly" comes from, but I guess
>>>>its a matter of emphasis more than anything else.
>>>>
>>>
>>>Take a look at the motivations document:
>>>"""
>>>  In contrast, LTP is a protocol for "point to point" reliability on a
>>>  single link: traffic between two LTP engines is expected not to
>>>  traverse any intermediate relays.
>>>"""
>>
>>So where's it say "strictly"? Must get better glasses:-)
>>
>>How you'd "expect" a protocol to work in nominal mode and what
>>you ought to protect against when there's a potential adversary
>>are not the same.
>>
> 
> 
> 
> To me, the motivations draft seems to pretty explicitly state that any
> environment but a single point-to-point link is out of the potential
> deployment space for LTP.  The protocol includes several design
> assumptions that are based on this property, and would cause it to behave
> rather poorly if this condition is not met.  A single point-to-point link
> is not only the nominal operating environment, but the *required* one.
> Since we seem to have different interpretations here though, perhaps
> others can help obtain consensus on this.
> 
> To me, it seems that the need, or lack of need, for authentication
> mechanisms is wholly dependant on how we clarify this design goal.  If
> your interpretation is favored (multiple hops and shared-links allowed),
> it seems like there would be several other issues to contend with, eg:
> dealing with segment reordering, developing some CC mechanisms (BCP re
> RFC 2914), etc.
> 
> -Wes
>  

Date: Mon, 7 Feb 2005 09:44:09 -0500
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Reply-To: [email-masked]
Sender: [email-masked]

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

On Mon, Feb 07, 2005 at 11:52:55AM +0000, Stephen Farrell wrote:
>=20
> >>>Virtually all of LTP assumes that a link strictly
> >>>connects 2 hosts, and that a path is simply one hop across that link.
> >>
> >>I'm not sure where that "strictly" comes from, but I guess
> >>its a matter of emphasis more than anything else.
> >>
> >
> >Take a look at the motivations document:
> >"""
> >   In contrast, LTP is a protocol for "point to point" reliability on a
> >   single link: traffic between two LTP engines is expected not to
> >   traverse any intermediate relays.
> >"""
>=20
> So where's it say "strictly"? Must get better glasses:-)
>=20
> How you'd "expect" a protocol to work in nominal mode and what
> you ought to protect against when there's a potential adversary
> are not the same.
>

To me, the motivations draft seems to pretty explicitly state that any
environment but a single point-to-point link is out of the potential
deployment space for LTP.  The protocol includes several design
assumptions that are based on this property, and would cause it to behave
rather poorly if this condition is not met.  A single point-to-point link
is not only the nominal operating environment, but the *required* one.
Since we seem to have different interpretations here though, perhaps
others can help obtain consensus on this.

To me, it seems that the need, or lack of need, for authentication
mechanisms is wholly dependant on how we clarify this design goal.  If
your interpretation is favored (multiple hops and shared-links allowed),
it seems like there would be several other issues to contend with, eg:
dealing with segment reordering, developing some CC mechanisms (BCP re
RFC 2914), etc.

-Wes
=20
--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--9amGYk9869ThD9tj--

Date: Mon, 07 Feb 2005 11:52:55 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

Good morning,

Wesley Eddy wrote:
> Providing keys to these link link layers is no more difficult than
> providing the keying material that the proposed LTP authentication
> requires (and does not give one a glimmer of how to obtain).

I disagree. The layer at which its easiest/best to manage security
is something where your mileage definitely varies. Generally it
depends on who's implemented what and who controls what. Personally,
I like having basic, but potentially strong, security options
available at as many layers as possible. Code-signing isn't bad
because we have SOAP-signing, HTTP/TLS, IPsec and WEP, even
though the signed code could easily traverse all those various
crypto'd layers (I've even seen almost that exact thing done!).

> Assuming such a thing is done, for some reason, why is IPsec not
> sufficient? 

Transport mode IPsec would be fine. However as with all other
layer security mechanisms, you sometimes cannot turn it on.
(Actually, I'm not sure how many IPsec implementations support
transport mode well - I've only really played with tunnel mode
stuff myself, e.g. I'd guess you could have trouble with firewalls
not passing IKE.) You'd also have to define a policy for
handling non-IPsec'd LTP traffic which is not something I'm sure
I'd know how to do right now.

Compliance-wise, IPsec is also still optional for IPv4 although
I'd agree that that's a pretty weak argument nowadays except maybe
for some embedded systems whose stacks are very cut-down.

 > If LTP _really needs_ its own security mechanisms, then
 > (similar to IPsec) these mechanisms need to exist within a complete
 > architecture that can cover such things as key distribution, etc.
 > Even if manual keying is to be assumed here, that much has not been
 > stated in the drafts.

Formally, IKE (even IKEv2) is not in the same RFC as ESP, nor
ought it be. So feel free to go right ahead and write up the
LTP key management I-D (actually, I'd be interested in working
an abstract DTN key management document myself, if anyone else
wanted to play around with that).

However, you do make a fair criticism. The current extensions
only allow you to plug in your favorite key management mechanism,
but don't give you a hint as to what's a good/bad way to do
that. I guess we should minimally write the small bit of text
that says the this MUST/SHOULD/MAY work with manual keying. I'd
probably go for a SHOULD there, but would think more first.

OTOH, I'm also aware of the mess that finally resulted in IKE,
so arguably its better in some cases to punt on some of the
harder key management issues. IMO that's defensible here, since
we're dealing with a putative experimental RFC for a new protocol,
which is radically different from the situation when IPsec was
held up for the lack of key management. When LTP is aimed at the
standards track, then your argument will be much more telling.
So, hold that thought for a year or so.

Lastly, there's a good argument that IPsec's current key management
is OTT, depending as it does on an Internet scale PKI, which we
don't have. There's a lot of demand out there for things like
opportunistic crypto. which is basically stymied by everyone doing
IKE correctly! I think, partly as a result of this, the security
community have learnt not to insist on very-strong security being
used everywhere. Which leads me to the approach embodied in the
LTP stuff where we're providing a fairly minimalistic set of
security tools, but ones which can used in a strong-security
environment. I'd certainly defend this approach for longer than
people are willing to read this thread!

>>>Virtually all of LTP assumes that a link strictly
>>>connects 2 hosts, and that a path is simply one hop across that link.
>>
>>I'm not sure where that "strictly" comes from, but I guess
>>its a matter of emphasis more than anything else.
>>
> 
> Take a look at the motivations document:
> """
>    In contrast, LTP is a protocol for "point to point" reliability on a
>    single link: traffic between two LTP engines is expected not to
>    traverse any intermediate relays.
> """

So where's it say "strictly"? Must get better glasses:-)

How you'd "expect" a protocol to work in nominal mode and what
you ought to protect against when there's a potential adversary
are not the same.

> This would seem to negate almost all of the perceived security
> considerations.  

Except maybe for the ones I mentioned in my last mail that didn't
get quoted here:-)

Seriously though, there is a real difference between being robust
against a directed attack versus accidental error conditions. I'd
argue that this alone justifies at least defining how to do
strong-ish authentication in almost any protocol!

 > I would be interested in hearing thoughts from
> others on this matter.

Good idea.

Stephen.

Date: Fri, 4 Feb 2005 17:01:33 -0800
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] web site updated
Sender: [email-masked]

Hi!

I've made a couple of updates to the DTNRG web site (http://www.dtnrg.org).

1. New related project:
   World Wide Web Offline Explorer (WWWOFFLE)
   http://www.gedanken.demon.co.uk/wwwoffle/

2. Link to Matt Bradbury's java implementation of DTN;
   http://sourceforge.net/projects/dtn/

3. The next public meeting will be in Minneapolis, sometime during the
IETF meeting March 6-11.

Melissa

Date: Fri, 4 Feb 2005 15:12:39 -0500
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Reply-To: [email-masked]
Sender: [email-masked]

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

On Fri, Feb 04, 2005 at 07:53:21PM +0000, Stephen Farrell wrote:
>=20
> >There *is* text in the security considerations portion of the main spec.
> >It is still rather confusing in its explanation of how an LTP session
> >can be attacked.  Somewhere the definition of point-to-point link seems
> >to be getting abused. =20
>=20
> RF? Say if you run LTP over bluetooth, 802.11b or some
> other radio, which either hasn't got, or isn't using, its own
> security. Bluetooth would be a good example - its lack of
> key distribution means that you're not very likely
> to find two endpoints sharing a key (or a PKI root, whatever).
>=20
> Same goes for various types of 802.11 networks, particularly
> ad-hoc ones.
>

Providing keys to these link link layers is no more difficult than
providing the keying material that the proposed LTP authentication
requires (and does not give one a glimmer of how to obtain).

=20
> Also, if one were to run LTP over IP, then segments could be inserted
> at any intermediate router. You may say that that's not what LTP is
> for, but in fact, it can be used at that layer, and I've even got
> a use-case (a sensor network for lake water quality with mules)
> for which I'm hoping to get funded to run a pilot.

Running LTP over a shared IP routing structure would be an odd decision,
as there are no congestion control mechanisms.  This does not seem to
be advisable.

Assuming such a thing is done, for some reason, why is IPsec not
sufficient?  If LTP _really needs_ its own security mechanisms, then
(similar to IPsec) these mechanisms need to exist within a complete
architecture that can cover such things as key distribution, etc.  Even
if manual keying is to be assumed here, that much has not been stated
in the drafts.

> > Virtually all of LTP assumes that a link strictly
> >connects 2 hosts, and that a path is simply one hop across that link.
>=20
> I'm not sure where that "strictly" comes from, but I guess
> its a matter of emphasis more than anything else.
>

Take a look at the motivations document:
"""
   In contrast, LTP is a protocol for "point to point" reliability on a
   single link: traffic between two LTP engines is expected not to
   traverse any intermediate relays.
"""

This would seem to negate almost all of the perceived security
considerations.  I would be interested in hearing thoughts from
others on this matter.

-Wes
=20
--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--U/5EjKfnYgGK6hcj--

Date: Fri, 04 Feb 2005 19:53:21 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

Hi Again,

> There *is* text in the security considerations portion of the main spec.
> It is still rather confusing in its explanation of how an LTP session
> can be attacked.  Somewhere the definition of point-to-point link seems
> to be getting abused.  

RF? Say if you run LTP over bluetooth, 802.11b or some
other radio, which either hasn't got, or isn't using, its own
security. Bluetooth would be a good example - its lack of
key distribution means that you're not very likely
to find two endpoints sharing a key (or a PKI root, whatever).

Same goes for various types of 802.11 networks, particularly
ad-hoc ones.

Also, if one were to run LTP over IP, then segments could be inserted
at any intermediate router. You may say that that's not what LTP is
for, but in fact, it can be used at that layer, and I've even got
a use-case (a sensor network for lake water quality with mules)
for which I'm hoping to get funded to run a pilot.

Also, if there is some data relay or switch or de-muxer or whatever
between an LTP endpoint and say an Earth station antenna, there's
another potential point for segment insertion.

 > Virtually all of LTP assumes that a link strictly
> connects 2 hosts, and that a path is simply one hop across that link.

I'm not sure where that "strictly" comes from, but I guess
its a matter of emphasis more than anything else.

> To me, it is clearly impossible to witness any attacks on such a link
> that do not indicate that the link itself has been severely compromised
> in a way that makes it utterly useless for continued communication.

Disagree. See above. Nice hyperbole though:-)

> I would be interested in hearing about scenarious where a point-to-point
> link can carry malicious segments, that do not involve the link being
> rendered totally useless.  If a third party can inject traffic, then
> it seems that they can simply jam the link.

Probably. Be much easier to spot jamming, but in any case the
main concern is that a directed attack can be worse than
jamming, since it may be directed at specific implementation
deficiencies. Say if somehow cancelling a session at a certain
point would leave an endpoint in a "bad" state. Though that
oughtn't happen, its exactly what does happen.

Also, if at some point someone defined some extensions to
LTP which supported the kind of clock resetting, etc. that
proximity-1 allows, then this kind of attack can get much
worse (or much easier, whatever).

Cheers,
Stephen.

Date: Fri, 4 Feb 2005 14:08:53 -0500
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

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

On Fri, Feb 04, 2005 at 06:00:54PM +0000, Stephen Farrell wrote:
>=20
> >This document doesn't yet cite or describe any threat model that these
> >extensions would be effective in defending against.  I would be fairly
> >strongly opposed to publication of this document until such things are
> >clear.
>=20
> Too late - the document has been published:-)
>

=2E. only until June :).  I, of course, meant as an RFC.

=20
>=20
> Having said that, we do have a threat model of sorts:
> (on-or-off-path) DoS attacks which attempt to do things
> like cancel sessions etc. and which mainly require
> segment insertion(s).
>=20
> You're right though that we should be clearer about this - maybe
> we've lost something when we split the document into 3. There
> may also be some mailist archive material that ought to be
> incorporated. I'd appreciate any text or references that
> we could use, and in any case, I'll do more on this for the
> -01 version of the extensions document.
>

There *is* text in the security considerations portion of the main spec.
It is still rather confusing in its explanation of how an LTP session
can be attacked.  Somewhere the definition of point-to-point link seems
to be getting abused.  Virtually all of LTP assumes that a link strictly
connects 2 hosts, and that a path is simply one hop across that link.
To me, it is clearly impossible to witness any attacks on such a link
that do not indicate that the link itself has been severely compromised
in a way that makes it utterly useless for continued communication.

I would be interested in hearing about scenarious where a point-to-point
link can carry malicious segments, that do not involve the link being
rendered totally useless.  If a third party can inject traffic, then
it seems that they can simply jam the link.
=20
--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--sMZCuqyhuhd4ycTi--

Date: Fri, 04 Feb 2005 18:42:23 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

Hi Wes,

Wesley Eddy wrote:

> On Fri, Feb 04, 2005 at 06:00:54PM +0000, Stephen Farrell wrote:
> 
>>>technical opinion: authentication is NOT critical, and does not belong in 
>>>the
>>>base spec.  
>>
>>Huh? This isn't the base spec. Its the extensions document.
>>
> This was in reference to a note in the extensions draft that says:
> """
>    <<Note : The LTP-Auth security mechanism defined here may in future
>    revisions be moved back to the main protocol specification [LTP] if
>    there is community consensus in having it as a critical feature that
>    ought to be included in all implementations of the protocol.>>
> """
> 

Ah. Fair enough. So its +1 for not putting it back then.

>>>For instance, links may handle this much better, and many
>>>currently do.
>>
>>Not sure what you mean there.
> 
> Since LTP runs strictly on point to point links, many link layer
> authentication mechanisms seem to be sufficient for preventing spoofing.

Yes, I agree that this is fairly common. OTOH, link layers that
don't do authentication (well) are also common.

> GSM/GPRS links, for instance, authenticate devices using the secret
> keys stored on the devices' tamper-resistant SIMs and at the AuC.
> The system uses these keys for authentication.  Bluetooth radios
> also have facilities for authenticating each other.

Not exactly the best examples of good use of crypto!

> Personally, I prefer to let similar radio-based schemes do
> authentication (in the subset of deployment scenarios where desired),
> rather than muck up LTP with it.

I agree. Where a lower layer can do the job properly, its
probably better to do that. I totally disagree that defining
how to do segment authentication in LTP is "mucking up"
anything.

> These systems can also do encryption, although I think for LTP,
> encryption is really a non-goal.  That's clearly something that can be
> more effectively done at either higher or lower layers as desired.

That is the current position we've taken. My preference would be
to define a confidentiality primitive though so that its available
if needed. Take the example of WEP, where they had ostensibly good
arguments for why they didn't need much security at that layer.
Arguments which just turned out to be wrong!

Cheers,
Stephen.

Date: Fri, 4 Feb 2005 13:23:47 -0500
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

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

On Fri, Feb 04, 2005 at 06:00:54PM +0000, Stephen Farrell wrote:
>=20
> >technical opinion: authentication is NOT critical, and does not belong i=
n=20
> >the
> >base spec. =20
>=20
> Huh? This isn't the base spec. Its the extensions document.
>

This was in reference to a note in the extensions draft that says:
"""
   <<Note : The LTP-Auth security mechanism defined here may in future
   revisions be moved back to the main protocol specification [LTP] if
   there is community consensus in having it as a critical feature that
   ought to be included in all implementations of the protocol.>>
"""

=20
> > For instance, links may handle this much better, and many
> > currently do.
>=20
> Not sure what you mean there.
>

Since LTP runs strictly on point to point links, many link layer
authentication mechanisms seem to be sufficient for preventing spoofing.

GSM/GPRS links, for instance, authenticate devices using the secret
keys stored on the devices' tamper-resistant SIMs and at the AuC.
The system uses these keys for authentication.  Bluetooth radios
also have facilities for authenticating each other.

Personally, I prefer to let similar radio-based schemes do
authentication (in the subset of deployment scenarios where desired),
rather than muck up LTP with it.

These systems can also do encryption, although I think for LTP,
encryption is really a non-goal.  That's clearly something that can be
more effectively done at either higher or lower layers as desired.

-Wes

--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--/rDaUNvWv5XYRSKj--

Date: Fri, 04 Feb 2005 18:00:54 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

Hi Wes,

Wesley Eddy wrote:

> I have some thoughts on the LTP extensions draft:
> 
> shorten abstract to:
> """
>    In an Interplanetary Internet setting deploying the Bundling protocol
>    being developed by the Delay Tolerant Networking Research Group, the
>    Licklider Transmission Protocol (LTP), is intended to serve as a
>    reliable convergence layer over single hop deep-space RF links.
>    This document describes various optional extensions to the base LTP 
>    specification and is part of a series of related documents describing LTP.
> """

That's fine.

> 
> technical opinion: authentication is NOT critical, and does not belong in the
> base spec.  

Huh? This isn't the base spec. Its the extensions document.

 > For instance, links may handle this much better, and many
 > currently do.

Not sure what you mean there.

> 
> Reference SHA-80 in addition to HMAC.  Personally, I would consider UMAC.

SHA-80? Do you mean SHA-1, SHA-256 or what?

I'd defend HMAC, since its in widespread use in many Internet
protocols. In any case, this is the kind of detail where I'd
get some sanity checking done by e.g. members of the IRTF's
CFRG. Normally, that's better done later on in the process
when other protocol details that might affect good/bad use
of crypto have been sorted.

> I'm not sure why we're calling the codepoints in the auth header
> "ciphersuites".  I would simply prefer the term "algorithm".

The terminology is from TLS. I think it better captures what's
being specified.

> I wouldn't pick RSA for the Signature Ciphersuite either.  ECC seems to be
> a much more solid choice.

Disagree. ECDSA has much less deployment and toolkits are much less
widely available (partly for IPR reasons). RSA is basically the
de-facto standard asymmetric algorithm for Internet protocols at
the moment.

You can I agree make a good case for defining an ECDSA option,
since the signatures are smaller. But before I'd want to do that
I'd like to better understand whether the recent Certicom/NSA
arrangement would cover uses of LTP!

Again, this'd be a detail to run past the CFRG at some point.

> In general, I'm not totally certain what the point of these extensions is.
> This document doesn't yet cite or describe any threat model that these
> extensions would be effective in defending against.  I would be fairly
> strongly opposed to publication of this document until such things are
> clear.

Too late - the document has been published:-)

> I think it's a bit premature to be defining security extensions to LTP
> before we have outlined a threat model.

Ok, now the serious answer:

More work on threat models can always be done and is almost
always useful. However, I would argue that even without an
exhaustively defined threat model, defining how to use
simple authentication and some anti-DoS measures (like the
cookie proposal) is a good thing (TM). There have been many
examples of protocols which suffered from not having any
security mechanisms (too much complexity is also bad, but
I think we've avoided that). Personally, I'd also argue
that we should be defining a confidentiality mechanism,
but I'd understand the push-back against that.

Having said that, we do have a threat model of sorts:
(on-or-off-path) DoS attacks which attempt to do things
like cancel sessions etc. and which mainly require
segment insertion(s).

You're right though that we should be clearer about this - maybe
we've lost something when we split the document into 3. There
may also be some mailist archive material that ought to be
incorporated. I'd appreciate any text or references that
we could use, and in any case, I'll do more on this for the
-01 version of the extensions document.

Thanks,
Stephen.

> 
> -Wes
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ltp mailing list
> [email-masked]
> http://irg.cs.ohiou.edu/mailman/listinfo/ltp

Date: Fri, 4 Feb 2005 12:26:46 -0500
From: Wesley Eddy <[email-masked]>
To: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] draft-irtf-dtnrg-ltp-extensions-00
Sender: [email-masked]

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

I have some thoughts on the LTP extensions draft:

shorten abstract to:
"""
   In an Interplanetary Internet setting deploying the Bundling protocol
   being developed by the Delay Tolerant Networking Research Group, the
   Licklider Transmission Protocol (LTP), is intended to serve as a
   reliable convergence layer over single hop deep-space RF links.
   This document describes various optional extensions to the base LTP=20
   specification and is part of a series of related documents describing LT=
P.
"""

technical opinion: authentication is NOT critical, and does not belong in t=
he
base spec.  For instance, links may handle this much better, and many curre=
ntly do.

Reference SHA-80 in addition to HMAC.  Personally, I would consider UMAC.

I'm not sure why we're calling the codepoints in the auth header
"ciphersuites".  I would simply prefer the term "algorithm".

I wouldn't pick RSA for the Signature Ciphersuite either.  ECC seems to be
a much more solid choice.

In general, I'm not totally certain what the point of these extensions is.
This document doesn't yet cite or describe any threat model that these
extensions would be effective in defending against.  I would be fairly
strongly opposed to publication of this document until such things are
clear.

I think it's a bit premature to be defining security extensions to LTP
before we have outlined a threat model.

-Wes

--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--16qp2B0xu0fRvRD7--

Date: Fri, 04 Feb 2005 09:06:12 -0800
From: Melissa Ho <[email-masked]>
To: Piero Cornice <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] troubles while compiling...
Sender: [email-masked]

You need to recompile BerkeleyDB with cc enabled:
./configure --enable-cc

See:
http://www.melissaho.com/research/dtn/demo/dtn2.php

Melissa

Piero Cornice wrote:

>Hi, i'm Piero from Italy.
>First of all thanks to all the people who answered me for my problem about using
>dtnrecv.
>Now i have another trouble :-P which seems to be stupid, but i don't understand
>it: i installed Fedora 3 on a new pc (that i'll use for my final discussion) and
>then installed BerkeleyDB (with new patches) and compiled dtn 2.0.2. While
>"making" i received this message:
>
>In file included from storage/BerkeleyDBStore.h:41,
>                 from DTNServer.cc:72:
>/usr/local/BerkeleyDB.4.3/include/db_cxx.h:61:23: exception.h: No such file or
>directory
>In file included from storage/BerkeleyDBStore.h:41,
>                 from DTNServer.cc:72:
>/usr/local/BerkeleyDB.4.3/include/db_cxx.h:987: error: expected class-name
>before '{' token
>
>...it seems that i need some exception.h but i don't know where to get it!
>
>Thank you for your attention,
>piero
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>
>  
>

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.3 - Release Date: 1/31/2005

Date: Fri, 4 Feb 2005 11:46:27 -0500
From: Wesley Eddy <[email-masked]>
To: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] comments on draft-irtf-dtnrg-ltp-motivation-00
Sender: [email-masked]

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

I just made a run through the LTP motivations document.  It's quite
good overall, and I'm pleased with the majority of it.  I do have some
comments and suggestions:

on page 4: "line of sight of each other" -> "line of sight with each other"

on page 6, during discussion of why standard protocols won't work well,
it might be good to also cite:

O. B. Akan, J. Fang, I. F. Akyildiz,
"Performance of TCP Protocols in Deep Space Communication Networks,"i
IEEE Communications Letters, vol. 6, no. 11, pp. 478-480, November 2002.

on page 7, it might also be worth noting that mechanisms like HTTP pipelini=
ng,
for mitigating high RTTs, do not exist in many applications.

Also here, note that SCTP uses the same slow start algorithm that TCP
does, so is similarly unsuitable.  Perhaps note that slow start is
designed to probe the unknown capacity of a network path; whereas LTP
will be mostly used on single-link paths where there is generally not
contention with other hosts, and thus not much need for slow start (or
even congestion control).

3.1.2 Session IDs - this is not all that novel, SCTP and BEEP have identical
notions.

page 12: use of "LLC" out of the blue?

section 3.6 - it's not clear what you mean by "intolerably optimistic" in
reference to timeout intervals.  I think instead of talking about the
timeout interval itself, what you're really trying to get at here is
that there is no head-of-line blocking in LTP.  This is pretty well
described in the SCTP documents, so saying it quickly and refing SCTP
should suffice.

In the next 2 paragraphs, I think that the point is that the round trip time
history is potentially very noisy, and so rather than filter it through an
averaging function, it's prefferred to just use the "instantaneous RTT".  T=
his
doesn't come out super-clearly from the present draft's exact wording thoug=
h.
I (somewhat) disagree with this approach anyways, but we'll talk about
that later.

page 14 - probably should explicitly state that EORP =3D=3D "end of red par=
t", as
this has not been done previously.

4.2 - in the case where the report-ack gets lost and the RSR retransmits the
report, we need clarification on how the report-ack in response to this is
generated, since the SSR has gone away long ago.  For instance, tell us that
the report itself contains sufficient information to generate the report-ack
without referencing the (non-existent) SSR state.

4.2 - shouldn't the upper-layer interface be verbose enough to indicate
successful/unsuccessful green part transmissin as well?

One general thing I really dislike about the protocol's design is the
inclusion of "prompted" and "asynchronous" ack modes.  How to use these
properly is simply left as an exercise to the implementor, which I feel
is potentially dangerous.  If we _need_ them, then we should provide
some guidance for how to use them, otherwise remove them from the spec,
or they will be either not used or improperly used.

-Wes

--=20
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy

--JkW1gnuWHDypiMFO--

Date: Fri, 4 Feb 2005 11:36:02 -0500
From: Anna Chan <[email-masked]>
Reply-To: Anna Chan <[email-masked]>
To: Scott Burleigh <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] DTN science project
Sender: [email-masked]

------=_Part_313_17977367.1107534962137
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

Attached is a copy of the rough draft of our DTN science paper.  We're
planning on doing a few more trials throughout this month and maybe
modify some parts of the experiment, but we'll keep you all posted. 
As always, any comments or suggestions are greatly appreciated! 
Thanks again for all your help.

Sincerely,

Anna Chan

------=_Part_313_17977367.1107534962137
Content-Type: application/x-zip-compressed; name=dtn4.sxw
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="dtn4.sxw"

------=_Part_313_17977367.1107534962137
Content-Type: application/msword; name=gizmo_schematic.doc
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gizmo_schematic.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAAhAAAAcBAAAAAAAAAA
EAAAAgAAAAEAAAD+////AAAAAAAAAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgA
AACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAA
AJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAP//////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
------=_Part_313_17977367.1107534962137--

Date: Fri,  4 Feb 2005 13:48:05 +0100
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] troubles while compiling...
Sender: [email-masked]

Hi, i'm Piero from Italy.
First of all thanks to all the people who answered me for my problem about using
dtnrecv.
Now i have another trouble :-P which seems to be stupid, but i don't understand
it: i installed Fedora 3 on a new pc (that i'll use for my final discussion) and
then installed BerkeleyDB (with new patches) and compiled dtn 2.0.2. While
"making" i received this message:

In file included from storage/BerkeleyDBStore.h:41,
                 from DTNServer.cc:72:
/usr/local/BerkeleyDB.4.3/include/db_cxx.h:61:23: exception.h: No such file or
directory
In file included from storage/BerkeleyDBStore.h:41,
                 from DTNServer.cc:72:
/usr/local/BerkeleyDB.4.3/include/db_cxx.h:987: error: expected class-name
before '{' token

...it seems that i need some exception.h but i don't know where to get it!

Thank you for your attention,
piero