Subject: Re: [dtn-interest] BSP and key management
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: dtn interest <[email-masked]>
Date: Tue, 30 Oct 2007 18:17:46 +0000
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Good that we're starting on this (and well done with the
BSP code!).

Something that might be attractive here is TESLA. [1] I
reckon it, or some variant, might be an interesting way
of versioning keys based on symmetric crypto.

Whatcha think?
S.

[1] http://www.ietf.org/rfc/rfc4082.txt

Peter Lovell wrote:
> The first open issue relates to how we handle key management.
> 
> Various of us have different ideas of exactly what it means -- what's in
> and what's not. And each of these has a number of component parts.
> 
> One obvious component is some kind of information-store or database
> where keys or key-material are saved. There are also the processes for
> interacting with local users of the key storage, forming what might be
> called a "key service". Another is the interaction mechanism for a key-
> service at one location and a remote key-service at another.
> 
> My goal is for this thread to decide which things should go into BSP
> specification and which should more properly be in the new KM spec
> initiated by Stephen 
> <http://www.ietf.org/internet-drafts/draft-farrell-dtnrg-km-00.txt> 
> and then reach closure on at least the BSP portions.
> 
>>From the BSP standpoint, I see two main items:-
> 1. what minimum capability is required in support of the mandatory
> ciphersuites
> 2. what does key material look like in a bundle
> 
> The term "key material" used for a bundle is expansive and encompasses
> all the keys and related "stuff" such as certificates, IVs, signatures,
> key references or identifiers, etc etc.
> 
> The other requirements and characteristics seem to be better placed in
> the KM spec, things like:-
> 1. key-wrap using symmetric and assymetric keys
>     (algorithms, procedures etc)
> 2. rules for storage (protection) and usage of key material
> 3. key exchange and/or negotiation protocol between nodes
>     (BSP itself never negotiates keys)
> 
> 
> Thanks.....Peter
> 
> p.s. we only look at KEKs here, not traffic keys
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>, "Peter Lovell" <[email-masked]>, "dtn security" <[email-masked]>
Date: Tue, 30 Oct 2007 14:01:54 -0400
Subject: [dtn-interest] issues in Bundle Security Protocol

Hi all,

BSP is available in the latest dtn tarball (thanks Mike!) 
<http://www.dtnrg.org/docs/code/dtn_2.5.0.tgz>
including all three mandatory ciphersuites. Now that this is generally
available, the dtnrg cvs tree is where updates and changes will appear
first. There are several places where the code needs to improve checking
to guard against bad blocks and this will be happening in the near future.

With this first cycle done, it's time to look at several items we'd
sidelined in order to get this first release completed.

In order to keep the discussions focussed, I'm creating a different
starter for each.

Cheers.....Peter

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>, "dtn security" <[email-masked]>
Date: Tue, 30 Oct 2007 14:02:02 -0400
Subject: [dtn-interest] BSP and key management

The first open issue relates to how we handle key management.

Various of us have different ideas of exactly what it means -- what's in
and what's not. And each of these has a number of component parts.

One obvious component is some kind of information-store or database
where keys or key-material are saved. There are also the processes for
interacting with local users of the key storage, forming what might be
called a "key service". Another is the interaction mechanism for a key-
service at one location and a remote key-service at another.

My goal is for this thread to decide which things should go into BSP
specification and which should more properly be in the new KM spec
initiated by Stephen 
<http://www.ietf.org/internet-drafts/draft-farrell-dtnrg-km-00.txt> 
and then reach closure on at least the BSP portions.

>From the BSP standpoint, I see two main items:-
1. what minimum capability is required in support of the mandatory
ciphersuites
2. what does key material look like in a bundle

The term "key material" used for a bundle is expansive and encompasses
all the keys and related "stuff" such as certificates, IVs, signatures,
key references or identifiers, etc etc.

The other requirements and characteristics seem to be better placed in
the KM spec, things like:-
1. key-wrap using symmetric and assymetric keys
    (algorithms, procedures etc)
2. rules for storage (protection) and usage of key material
3. key exchange and/or negotiation protocol between nodes
    (BSP itself never negotiates keys)

Thanks.....Peter

p.s. we only look at KEKs here, not traffic keys

From: Michael Demmer <[email-masked]>
Date: Fri, 19 Oct 2007 16:37:28 -0700
To: dtn-interest <[email-masked]>, dtn-users <[email-masked]>
Subject: [dtn-interest] DTN reference implementation release 2.5.0

Hi all,

I'm pleased to announce the 2.5.0 release of the DTN2 reference  
implementation. The most recent excerpt from the RELEASE-NOTES is  
included below.

As always, this release is available at http://www.dtnrg.org/wiki/Code.

Happy bundling!
-mike

---

2.5.0 (October 2007)
-------------------
- Integrated support for the Bundle Security Protocol blocks,
   contributed by SPARTA.

- Using SWIG, added bindings to export a version of the application
   interface to different scripting languages, currently supporting
   Tcl, Python, and Perl.

- Implemented a polling feature in the API so applications can use
   select() to wait for bundle arrivals on the IPC handle.

- Added a dtnhttpproxy application to route http requests over a DTN
   network.

- Add a feature to the routing table to allow routes to point to
   alternate endpoint id instead of only a next hop link.

- Fixed the compilation errors in the 2.4.0 release when trying to
   build external components. Changed the default configuration for
   these components to be enabled by default to avoid this oversight in
   the future.

- Fixed the rpm specification file so the rpm builds work again.

- Minor miscelleneous other bug fixes and features.

Date: Fri, 19 Oct 2007 13:49:16 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] New LTP I-Ds

Hi all,

We just updated the LTP I-Ds [1] with a few text changes
in response to the IRSG review. There're no protocol
changes.

Main thing was to clarify the limited applicability
of the protocol in terrestrial environments (basically
saying don't do it if you're in an environment that
needs congestion control:-)

Scott also restructured the motivation draft quite a
bit.

Comments welcome as always, but hopefully soon if
you've got any, since we want to push these back into
the RFC production process.

Cheers,
S.

[1] http://tools.ietf.org/internet-drafts/draft-irtf-dtnrg-lt

From: Hans Kruse <[email-masked]>
Date: Wed, 17 Oct 2007 16:53:40 -0400
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] JPL ION reference implementation release

--Apple-Mail-17--401144319
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Will,
first, you are of course correct.  This software is on the very edge  
of what needs to even be looked at, much less a threat to national  
security.  The fact that we need to go through the review, and  
implement a somewhat onerous protection system, has of course more to  
do with risk-averse institutions (and universities are in that  
category) than with the actual need for protection.

On the upside, the review process at JPL did get ION out from under  
ITAR (the mistake on our website notwithstanding) and out from under  
most other export restrictions.  Compared to DTN2, we fell short by  
one step (removing the Department of Commerce classification  
altogether).

I think it will take action by NASA HQ to get us past that last  
hurdle.   It would certainly save us a bunch of time and resources if  
we could remove the safeguards we did have to put in place, whatever  
their true value may be.

On Oct 17, 2007, at 12:24, Scott Burleigh wrote:

> Ivancic, William D. (GRC-RCN0) wrote:
>> It is a mess and a joke.  I discussed this with the NASA HQ IT  
>> Program and Policy heads as the protection really won't keep  
>> anyone who wants ION from getting it.  This is a "protect your  
>> rear-end" necessity.
>>
>> The answer depends on the lawyer you talk to.  So, to be safe and  
>> make sure one doesn't go to jail, you comply with the policy.
>>
>> One interpretation is:  If I can command and control a satellite  
>> with the technology it is ITAR.  Or course I can send TCP packets  
>> to perform command and control.  Thus, one can conclude that TCP  
>> or IPv4 or IPv6 or just about anything is ITAR.
>>
>> The quesiton I raised is why is DTN-2 openly availabe and ION not  
>> - particularly when a lot of DTN-2 is a result of DARPA funding?   
>> Well, ION is written specifically for space-based devices.  If it  
>> is space, it is ITAR.
>>
>> The security measures put in place cost money and provide no real  
>> security - just a "cover-the-rear-end" necessity.
>>
> The export approval process for software aimed at supporting space
> flight is still kind of painful, but we've been working on  
> streamlining
> it at JPL and I think Hans has got it covered pretty well on the  
> Export
> Rules page.  EAR-99 isn't too hard to live with, and that's where all
> the ION code has ended up so far.
>
> Scott
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of
>>> Peter Lovell
>>> Sent: Wednesday, October 17, 2007 10:44 AM
>>> To: [email-masked]
>>> Subject: Re: [dtn-interest] JPL ION reference implementation release
>>>
>>> On Tue, Oct 16, 2007, Hans Kruse <[email-masked]> wrote:
>>>
>>>> NASA JPL and Ohio University are please to announce the official
>>>> release of ION, JPL's DTN reference implementation.  Supported by a
>>>> grant from the NASA Glenn Research Center, Ohio University provides
>>>> testing, documentation, distribution, and support for the ION code
>>>> which continues to be developed at JPL.
>>>>
>>>> Information, support mailing lists, and the download system can be
>>>> found at "https://www.ocp.ohiou.edu/".
>>>>
>>> Puzzling. The download page says ...
>>> "Unfortunately, as ION is covered by ITAR, we are only  
>>> permitted ..."
>>>
>>> yet the Export Rules page at <https://www.ocp.ohiou.edu/export.html>
>>> second bullet says ...
>>> "ION is not controlled under ITAR rules."  With emphasis on "not".
>>>
>>> Does anyone know what rules actually apply??
>>>
>>> Thanks.....Peter
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-17--401144319
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Will,<DIV>first, you are of =
course correct.=A0 This software is on the very edge of what needs to =
even be looked at, much less a threat to national security.=A0 The fact =
that we need to go through the review, and implement a somewhat onerous =
protection system, has of course more to do with risk-averse =
institutions (and universities are in that category) than with the =
actual need for protection.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>On the upside, the review =
process at JPL did get ION out from under ITAR (the mistake on our =
website notwithstanding) and out from under most other export =
restrictions.=A0 Compared to DTN2, we=A0fell short by one step (removing =
the Department of Commerce classification altogether).</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I think it will take action =
by NASA HQ to get us past that last hurdle.=A0 =A0It would certainly =
save us a bunch of time and resources if we could remove the safeguards =
we did have to put in place, whatever their true value may =
be.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><DIV><DIV>On Oct 17, 2007, =
at 12:24, Scott Burleigh wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Ivancic, William D. (GRC-RCN0) wrote:</DIV> =
<BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">It is a mess and a =
joke.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>I discussed this =
with the NASA HQ IT Program and Policy heads as the protection really =
won't keep anyone who wants ION from getting it.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>This is a "protect your =
rear-end" necessity.</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The answer depends on the lawyer =
you talk to.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>So, to be =
safe and make sure one doesn't go to jail, you comply with the =
policy.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">One interpretation is:<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>If I can command and control =
a satellite with the technology it is ITAR.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Or course I can send TCP =
packets to perform command and control.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Thus, one can conclude that =
TCP or IPv4 or IPv6 or just about anything is ITAR.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
quesiton I raised is why is DTN-2 openly availabe and ION not - =
particularly when a lot of DTN-2 is a result of DARPA funding?<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Well, ION is written =
specifically for space-based devices.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>If it is space, it is =
ITAR.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The security measures put in place cost money and =
provide no real security - just a "cover-the-rear-end" =
necessity.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
</BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The export approval process for =
software aimed at supporting space<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">flight =
is still kind of painful, but we've been working on streamlining<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">it at =
JPL and I think Hans has got it covered pretty well on the Export<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Rules =
page.<SPAN class=3D"Apple-converted-space">=A0 </SPAN>EAR-99 isn't too =
hard to live with, and that's where all<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the ION =
code has ended up so far.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Scott</DIV> <BLOCKQUOTE =
type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">-----Original =
Message-----</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">From: <A =
href=3D"mailto:[email-masked]">dtn-interest-bounce=
[email-masked]</A><SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">[<A =
href=3D"mailto:[email-masked]">mailto:dtn-interest=
[email-masked]</A>] On Behalf Of<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Peter =
Lovell</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Sent: Wednesday, October 17, =
2007 10:44 AM</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">To: <A =
href=3D"mailto:[email-masked]">[email-masked].=
org</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Subject: Re: [dtn-interest] JPL =
ION reference implementation release</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">On Tue, Oct 16, 2007, Hans Kruse =
&lt;<A href=3D"mailto:[email-masked]">[email-masked]</A>&gt; =
wrote:</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> =
<BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">NASA JPL and Ohio =
University are please to announce the official<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">release =
of ION, JPL's DTN reference implementation.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Supported by a<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">grant =
from the NASA Glenn Research Center, Ohio University provides<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">testing, =
documentation, distribution, and support for the ION code<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">which =
continues to be developed at JPL.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Information, support mailing =
lists, and the download system can be<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">found at =
"<A =
href=3D"https://www.ocp.ohiou.edu">https://www.ocp.ohiou.edu</A>/".</DIV><=
DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Puzzling. The download page says ...</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">"Unfortunately, as ION is covered by ITAR, we are =
only permitted ..."</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">yet the Export Rules page at =
&lt;<A =
href=3D"https://www.ocp.ohiou.edu/export.html">https://www.ocp.ohiou.edu/e=
xport.html</A>&gt;</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">second bullet says =
...</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">"ION is not controlled under =
ITAR rules."<SPAN class=3D"Apple-converted-space">=A0 </SPAN>With =
emphasis on "not".</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Does anyone know what rules =
actually apply??</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Thanks.....Peter</DIV> =
</BLOCKQUOTE></BLOCKQUOTE><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">dtn-interest mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked].=
org</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A></DI=
V> </BLOCKQUOTE></DIV><BR><DIV> <SPAN class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Hans Kruse, Professor</FONT></P><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren McClure School of =
Information and Telecommunication Systems</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Adjunct Associate Professor of =
Electrical Engineering and Computer Science</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">292 Lindley Hall, Ohio University, =
Athens, OH, 45701</FONT></P><P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</FONT></P><BR =
class=3D"Apple-interchange-newline"></SPAN> =
</DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-17--401144319--

Date: Wed, 17 Oct 2007 09:24:09 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] JPL ION reference implementation release

Ivancic, William D. (GRC-RCN0) wrote:
> It is a mess and a joke.  I discussed this with the NASA HQ IT Program and Policy heads as the protection really won't keep anyone who wants ION from getting it.  This is a "protect your rear-end" necessity.
>
> The answer depends on the lawyer you talk to.  So, to be safe and make sure one doesn't go to jail, you comply with the policy.
>
> One interpretation is:  If I can command and control a satellite with the technology it is ITAR.  Or course I can send TCP packets to perform command and control.  Thus, one can conclude that TCP or IPv4 or IPv6 or just about anything is ITAR.
>
> The quesiton I raised is why is DTN-2 openly availabe and ION not - particularly when a lot of DTN-2 is a result of DARPA funding?  Well, ION is written specifically for space-based devices.  If it is space, it is ITAR.
>
> The security measures put in place cost money and provide no real security - just a "cover-the-rear-end" necessity.
>   
The export approval process for software aimed at supporting space 
flight is still kind of painful, but we've been working on streamlining 
it at JPL and I think Hans has got it covered pretty well on the Export 
Rules page.  EAR-99 isn't too hard to live with, and that's where all 
the ION code has ended up so far.

Scott
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of 
>> Peter Lovell
>> Sent: Wednesday, October 17, 2007 10:44 AM
>> To: [email-masked]
>> Subject: Re: [dtn-interest] JPL ION reference implementation release
>>
>> On Tue, Oct 16, 2007, Hans Kruse <[email-masked]> wrote:
>>     
>>> NASA JPL and Ohio University are please to announce the official 
>>> release of ION, JPL's DTN reference implementation.  Supported by a 
>>> grant from the NASA Glenn Research Center, Ohio University provides 
>>> testing, documentation, distribution, and support for the ION code 
>>> which continues to be developed at JPL.
>>>
>>> Information, support mailing lists, and the download system can be 
>>> found at "https://www.ocp.ohiou.edu/".
>>>       
>> Puzzling. The download page says ...
>> "Unfortunately, as ION is covered by ITAR, we are only permitted ..."
>>
>> yet the Export Rules page at <https://www.ocp.ohiou.edu/export.html>
>> second bullet says ...
>> "ION is not controlled under ITAR rules."  With emphasis on "not".
>>
>> Does anyone know what rules actually apply??
>>
>> Thanks.....Peter

From: Hans Kruse <[email-masked]>
Date: Wed, 17 Oct 2007 11:49:18 -0400
To: "Peter Lovell" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] JPL ION reference implementation release

--Apple-Mail-8--419406543
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

The Export Rules page is correct.  I missed the other page during  
editing; we'll get that fix post-haste.  ION is controlled under the  
Dept of Commerce with an EAR-99 (the least restrictive) designation.   
Again, the Export Rules page reflects my best understanding of the  
process.

Sorry for the confusion!

On Oct 17, 2007, at 10:44, Peter Lovell wrote:

> On Tue, Oct 16, 2007, Hans Kruse <[email-masked]> wrote:
>
>> NASA JPL and Ohio University are please to announce the official  
>> release
>> of ION,  JPL's DTN reference implementation.  Supported by a grant  
>> from
>> the NASA Glenn Research Center, Ohio University provides testing,
>> documentation, distribution, and support for the ION code which
>> continues to be developed at JPL.
>>
>> Information, support mailing lists, and the download system can be  
>> found
>> at "https://www.ocp.ohiou.edu/".
>>
>> Hans Kruse, Professor
>> J. Warren McClure School of Information and Telecommunication Systems
>> Adjunct Associate Professor of Electrical Engineering and Computer  
>> Science
>> 292 Lindley Hall, Ohio University, Athens, OH, 45701
>> 740-593-4891 voice, 740-593-4889 fax
>>
>
>
> Puzzling. The download page says ...
> "Unfortunately, as ION is covered by ITAR, we are only permitted ..."
>
> yet the Export Rules page at <https://www.ocp.ohiou.edu/export.html>
> second bullet says ...
> "ION is not controlled under ITAR rules."  With emphasis on "not".
>
> Does anyone know what rules actually apply??
>
> Thanks.....Peter
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-8--419406543
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">The Export Rules page is =
correct.=A0 I missed the other page during editing; we'll get that fix =
post-haste.=A0 ION is controlled under the Dept of Commerce with an =
EAR-99 (the least restrictive) designation.=A0 Again, the Export Rules =
page reflects my best understanding of the process.<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Sorry for the =
confusion!</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR><DIV><DIV>On Oct 17, =
2007, at 10:44, Peter Lovell wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">On Tue, Oct 16, 2007, Hans Kruse &lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt; wrote:</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">NASA JPL and Ohio University are =
please to announce the official release</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">of ION,=A0=
 JPL's DTN reference implementation.=A0 Supported by a grant =
from</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">the NASA Glenn Research Center, =
Ohio University provides testing,</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">documentation, distribution, and support for the ION code =
which</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">continues to be developed at =
JPL.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Information, support mailing lists, and the download =
system can be found</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">at "<A =
href=3D"https://www.ocp.ohiou.edu">https://www.ocp.ohiou.edu</A>/".</DIV><=
DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Hans =
Kruse, Professor</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">J. Warren McClure School of =
Information and Telecommunication Systems</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Adjunct =
Associate Professor of Electrical Engineering and Computer =
Science</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">292 Lindley Hall, Ohio =
University, Athens, OH, 45701</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">740-593-4891 =
voice, 740-593-4889 fax</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV> </BLOCKQUOTE><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Puzzling. The download page says ...</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">"Unfortunately, as ION is covered by ITAR, we are =
only permitted ..."</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">yet the Export Rules page at =
&lt;<A =
href=3D"https://www.ocp.ohiou.edu/export.html">https://www.ocp.ohiou.edu/e=
xport.html</A>&gt;</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">second bullet says =
...</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">"ION is not controlled under =
ITAR rules."<SPAN class=3D"Apple-converted-space">=A0 </SPAN>With =
emphasis on "not".</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Does anyone know what rules =
actually apply??</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Thanks.....Peter</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">dtn-interest mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked].=
org</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A></DI=
V> </BLOCKQUOTE></DIV><BR><DIV> <SPAN class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Hans Kruse, Professor</FONT></P><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren McClure School of =
Information and Telecommunication Systems</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Adjunct Associate Professor of =
Electrical Engineering and Computer Science</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">292 Lindley Hall, Ohio University, =
Athens, OH, 45701</FONT></P><P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</FONT></P><BR =
class=3D"Apple-interchange-newline"></SPAN> =
</DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-8--419406543--

Content-class: urn:content-classes:message
Date: Wed, 17 Oct 2007 10:47:51 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Peter Lovell" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] JPL ION reference implementation release

It is a mess and a joke.  I discussed this with the NASA HQ IT Program and Policy heads as the protection really won't keep anyone who wants ION from getting it.  This is a "protect your rear-end" necessity.

The answer depends on the lawyer you talk to.  So, to be safe and make sure one doesn't go to jail, you comply with the policy.

One interpretation is:  If I can command and control a satellite with the technology it is ITAR.  Or course I can send TCP packets to perform command and control.  Thus, one can conclude that TCP or IPv4 or IPv6 or just about anything is ITAR.

The quesiton I raised is why is DTN-2 openly availabe and ION not - particularly when a lot of DTN-2 is a result of DARPA funding?  Well, ION is written specifically for space-based devices.  If it is space, it is ITAR.

The security measures put in place cost money and provide no real security - just a "cover-the-rear-end" necessity.

Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Peter Lovell
> Sent: Wednesday, October 17, 2007 10:44 AM
> To: [email-masked]
> Subject: Re: [dtn-interest] JPL ION reference implementation release
> 
> On Tue, Oct 16, 2007, Hans Kruse <[email-masked]> wrote:
> 
> >NASA JPL and Ohio University are please to announce the official 
> >release of ION,  JPL's DTN reference implementation.  Supported by a 
> >grant from the NASA Glenn Research Center, Ohio University provides 
> >testing, documentation, distribution, and support for the ION code 
> >which continues to be developed at JPL.
> >
> >Information, support mailing lists, and the download system can be 
> >found at "https://www.ocp.ohiou.edu/".
> >
> >Hans Kruse, Professor
> >J. Warren McClure School of Information and 
> Telecommunication Systems 
> >Adjunct Associate Professor of Electrical Engineering and Computer 
> >Science
> >292 Lindley Hall, Ohio University, Athens, OH, 45701
> >740-593-4891 voice, 740-593-4889 fax
> >
> 
> 
> Puzzling. The download page says ...
> "Unfortunately, as ION is covered by ITAR, we are only permitted ..."
> 
> yet the Export Rules page at <https://www.ocp.ohiou.edu/export.html>
> second bullet says ...
> "ION is not controlled under ITAR rules."  With emphasis on "not".
> 
> Does anyone know what rules actually apply??
> 
> Thanks.....Peter
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>
Date: Wed, 17 Oct 2007 10:44:08 -0400
Subject: Re: [dtn-interest] JPL ION reference implementation release

On Tue, Oct 16, 2007, Hans Kruse <[email-masked]> wrote:

>NASA JPL and Ohio University are please to announce the official release
>of ION,  JPL's DTN reference implementation.  Supported by a grant from
>the NASA Glenn Research Center, Ohio University provides testing,
>documentation, distribution, and support for the ION code which
>continues to be developed at JPL.
>
>Information, support mailing lists, and the download system can be found
>at "https://www.ocp.ohiou.edu/".
>
>Hans Kruse, Professor
>J. Warren McClure School of Information and Telecommunication Systems
>Adjunct Associate Professor of Electrical Engineering and Computer Science
>292 Lindley Hall, Ohio University, Athens, OH, 45701
>740-593-4891 voice, 740-593-4889 fax
>

Puzzling. The download page says ...
"Unfortunately, as ION is covered by ITAR, we are only permitted ..."

yet the Export Rules page at <https://www.ocp.ohiou.edu/export.html>
second bullet says ...
"ION is not controlled under ITAR rules."  With emphasis on "not".

Does anyone know what rules actually apply??

Thanks.....Peter

To: [email-masked]
From: Hans Kruse <[email-masked]>
Date: Tue, 16 Oct 2007 18:37:30 -0400
Subject: [dtn-interest] JPL ION reference implementation release

--Apple-Mail-3--481314269
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

NASA JPL and Ohio University are please to announce the official  
release of ION,  JPL's DTN reference implementation.  Supported by a  
grant from the NASA Glenn Research Center, Ohio University provides  
testing, documentation, distribution, and support for the ION code  
which continues to be developed at JPL.

Information, support mailing lists, and the download system can be  
found at "https://www.ocp.ohiou.edu/".

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-3--481314269
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>NASA JPL and Ohio =
University are please to announce the official release of ION,=A0 JPL's =
DTN reference implementation.=A0 Supported by a grant from the NASA =
Glenn Research Center, Ohio University provides testing, documentation, =
distribution, and support for the ION code which continues to be =
developed at JPL.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Information, support =
mailing lists, and the download system can be found at "<A =
href=3D"https://www.ocp.ohiou.edu">https://www.ocp.ohiou.edu</A>/".</DIV><=
BR><DIV> <SPAN class=3D"Apple-style-span" style=3D"border-collapse: =
separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: =
0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Hans Kruse, Professor</FONT></P><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren McClure School of =
Information and Telecommunication Systems</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Adjunct Associate Professor of =
Electrical Engineering and Computer Science</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">292 Lindley Hall, Ohio University, =
Athens, OH, 45701</FONT></P><P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</FONT></P><BR =
class=3D"Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>=

--Apple-Mail-3--481314269--

To: [email-masked]
From: Kevin Fall <[email-masked]>
Date: Tue, 16 Oct 2007 09:08:42 -0700
Subject: [dtn-interest] Fwd: [Ns-developers] ns-3.0.7 development release available

--Apple-Mail-7--504642342
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

fyi.. -K

Begin forwarded message:

> From: Tom Henderson <[email-masked]>
> Date: October 15, 2007 11:39:24 PM PDT
> To: ns-developers <[email-masked]>
> Subject: [Ns-developers] ns-3.0.7 development release available
>
> The most recent of our monthly ns-3 development releases is  
> available at the below location:
> http://www.nsnam.org/releases/ns-3.0.7.tar.bz2
>
> Please see this "getting started" page:
> http://www.nsnam.org/getting_started.html
>
> From the release notes:
>
> Release 3.0.7 (2007/10/15)
> ========================
>   - OLSR routing protocol
>   - A timer class
>   - Additional mobility models (random waypoint, random 2D walk)
>   - A mobility visualization tool
>
> These were all discussed on the list over the past month.  We also  
> adopted logging code changes that have been discussed on the list  
> in the past week, and fixed a number of bugs.
>
> The next regularly scheduled release is in mid-November.  We'll  
> update the roadmap again in about a week and update the list.  This  
> wiki page is also being used to keep track of proposals under  
> review: http://www.nsnam.org/wiki/index.php/ 
> Roadmap#Code_proposals_under_review Please also consider reviewing  
> the tutorial if you are new to ns-3.
>
> - Tom
>
>
>
>

--Apple-Mail-7--504642342
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">
fyi.. -K<br><div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Tom Henderson &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><b>Date: =
</b></font><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">October 15, 2007 11:39:24 PM PDT</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" color=3D"#000000" =
style=3D"font: 12.0px Helvetica; color: #000000"><b>To: </b></font><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">ns-developers &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</font>=
</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><font face=3D"Helvetica" size=3D"3" =
color=3D"#000000" style=3D"font: 12.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica"><b>[Ns-developers] ns-3.0.7 development =
release available</b></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div> <div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The most recent of our monthly =
ns-3 development releases is available at the below location:</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"http://www.nsnam.org/releases/ns-3.0.7.tar.bz2">http://www.nsnam.o=
rg/releases/ns-3.0.7.tar.bz2</a></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Please see this "getting =
started" page:</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"http://www.nsnam.org/getting_started.html">http://www.nsnam.org/ge=
tting_started.html</a></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">=46rom the release =
notes:</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Release 3.0.7 (2007/10/15)</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><span =
class=3D"Apple-converted-space">=A0 </span>- OLSR routing =
protocol</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><span =
class=3D"Apple-converted-space">=A0 </span>- A timer class</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><span class=3D"Apple-converted-space">=A0 </span>- =
Additional mobility models (random waypoint, random 2D walk)</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><span class=3D"Apple-converted-space">=A0 </span>- A =
mobility visualization tool</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">These were all discussed on the =
list over the past month.<span class=3D"Apple-converted-space">=A0 =
</span>We also adopted logging code changes that have been discussed on =
the list in the past week, and fixed a number of bugs.</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The next =
regularly scheduled release is in mid-November.<span =
class=3D"Apple-converted-space">=A0 </span>We'll update the roadmap =
again in about a week and update the list.<span =
class=3D"Apple-converted-space">=A0 </span>This wiki page is also being =
used to keep track of proposals under review: <a =
href=3D"http://www.nsnam.org/wiki/index.php/Roadmap#Code_proposals_under_r=
eview">http://www.nsnam.org/wiki/index.php/Roadmap#Code_proposals_under_re=
view</a> Please also consider reviewing the tutorial if you are new to =
ns-3.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">- Tom</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div> </blockquote></div><br></body></html>=

--Apple-Mail-7--504642342--

From: Michael Demmer <[email-masked]>
Date: Mon, 15 Oct 2007 15:54:46 -0700
To: dtn-interest <[email-masked]>, dtn-dev <[email-masked]>, dtn-users <[email-masked]>, dtn-security <[email-masked]>
Subject: [dtn-interest] dtnrg.org transition complete

We've moved the wiki site and mailing lists over to a new server, and  
things appear to be working fine now.

We've preserved all list subscriptions, though as you may have  
noticed from the mailman messages, everyone has a newly allocated  
mailman password. Also, options relating to message formats and  
digests need to be re-applied on the new mailing list server.

Please contact me if you run into any problems with the new  
configuration.

-mike

Content-class: urn:content-classes:message
Date: Mon, 15 Oct 2007 10:38:21 -0700
From: "Jattan, RamsayX R" <[email-masked]>
To: <[email-masked]>
Subject: [Dtn-interest] test

This is a multi-part message in MIME format.

------_=_NextPart_001_01C80F52.34067B37
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

testing

Ramsay Jattan

CompuCom Systems, Inc.=20
System Administrator for Berkeley
Intel Research IT=20
Phone: 510-495-3034 Pager 877-462-7449
Email: [email-masked]=20

IRIT info:  http://irit.research.intel-research.net
<blocked::http://irit.research.intel-research.net/>=20
For IRIT support, send email to [email-masked]=20

=20

------_=_NextPart_001_01C80F52.34067B37
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Book Antiqua";
	panose-1:2 4 6 2 5 3 5 3 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
	{mso-style-type:personal-compose;
	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;}
-->
</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'><o:p>&nbsp;</o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><em><b><i><f=
ont
size=3D2 color=3Dnavy face=3D"Book Antiqua"><span =
style=3D'font-size:10.0pt;font-family:
"Book Antiqua";color:navy;font-weight:bold'>Ramsay =
Jattan</span></font></i></b></em><b><font
color=3Dmaroon><span =
style=3D'color:maroon;font-weight:bold'><o:p></o:p></span></font></b></p>=

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><em><b><i><f=
ont
size=3D2 color=3Dnavy face=3D"Book Antiqua"><span =
style=3D'font-size:10.0pt;font-family:
"Book Antiqua";color:navy;font-weight:bold'>CompuCom Systems, Inc. =
</span></font></i></b></em><b><i><font
size=3D2 color=3Dnavy face=3D"Book Antiqua"><span =
style=3D'font-size:10.0pt;font-family:
"Book Antiqua";color:navy;font-weight:bold;font-style:italic'><br>
<em><i><font face=3D"Book Antiqua"><span style=3D'font-family:"Book =
Antiqua"'>System
Administrator for</span></font></i></em></span></font><em><i><font =
color=3Dnavy
face=3D"Times New Roman"><span style=3D'color:navy'> =
</span></font></i></em></i></b><st1:City
w:st=3D"on"><st1:place w:st=3D"on"><em><b><i><font size=3D2 color=3Dnavy
  face=3D"Book Antiqua"><span =
style=3D'font-size:10.0pt;font-family:"Book Antiqua";
  color:navy;font-weight:bold'><u1:place u2:st=3D"on"><u1:City =
u2:st=3D"on">Berkeley</span></font></i></b></em></st1:place></st1:City></=
u1:City></u1:place><b><font
color=3Dnavy><span style=3D'color:navy;font-weight:bold'><br>
</span></font></b><em><b><i><font size=3D2 color=3Dnavy face=3D"Book =
Antiqua"><span
style=3D'font-size:10.0pt;font-family:"Book =
Antiqua";color:navy;font-weight:bold'>Intel
Research IT</span></font><font color=3Dnavy><span style=3D'color:navy'> =
</span></font></i></b></em><b><i><font
color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'><br>
</span></font></i></b><em><b><i><font size=3D2 color=3Dnavy =
face=3D"Times New Roman"><span
style=3D'font-size:10.0pt;color:navy;font-weight:bold'>Phone: =
510-495-3034 Pager
877-462-7449</span></font></i></b></em><b><font color=3Dnavy><span
style=3D'color:navy;font-weight:bold'><br>
</span></font></b><em><b><i><font size=3D2 color=3Dnavy face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:navy;font-weight:bold'>Email:</span></fon=
t><font
color=3Dnavy><span style=3D'color:navy'> <a =
href=3D"mailto:[email-masked]"
title=3D"mailto:[email-masked]&#10;mailto:michaelx.ham@intel.=
com&#10;mailto:[email-masked]">[email-masked]</a>
</span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></em></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><em><b><i><f=
ont
size=3D2 color=3Dnavy face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:navy;font-weight:bold'>IRIT =
info</span></font></i></b></em><em><b><i><font
size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;font-weight:bold'>:&nbsp;
</span></font></i></b></em><b><font color=3Dnavy><span =
style=3D'color:navy;
font-weight:bold'><a =
href=3D"blocked::http://irit.research.intel-research.net/"
title=3D"blocked::http://irit.research.intel-research.net/&#10;http://iri=
t.research.intel-research.net/"><em><i><font
color=3Dblack face=3D"Times New Roman"
title=3D"blocked::http://irit.research.intel-research.net/"><span
title=3D"blocked::http://irit.research.intel-research.net/"><span
style=3D'color:windowtext;text-decoration:none'>http://irit.research.inte=
l-research.net</span></span></font></i></em></a><br>
</span></font></b><em><b><i><font size=3D2 color=3Dnavy face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:navy;font-weight:bold'>For IRIT support, =
send
email to </span></font><font color=3Dnavy><span style=3D'color:navy'><a
href=3D"mailto:[email-masked]" =
title=3D"mailto:[email-masked]">[email-masked]</a>
</span></font><font color=3Dmaroon><span =
style=3D'color:maroon'><o:p></o:p></span></font></i></b></em></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C80F52.34067B37--

Date: Mon, 15 Oct 2007 09:01:49 +0530
From: "vishwas Rudramurthy" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Interested to Join
Sender: [email-masked]

------=_Part_14450_10004581.1192419109194
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi ,

I am interested to join this community

- Vishwas R

------=_Part_14450_10004581.1192419109194
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Hi ,</div>
<div>&nbsp;</div>
<div>I am interested to join this community</div>
<div>&nbsp;</div>
<div>- Vishwas R</div>

------=_Part_14450_10004581.1192419109194--

Date: Sun, 14 Oct 2007 19:14:10 +0100
To: "Peter Lovell" <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re(7): [dtn-interest] "security destination"
Cc: "dtn interest" <[email-masked]>
Sender: [email-masked]

At Saturday 13/10/2007 10:24 -0400, Peter Lovell wrote:
>Hi lloyd,

hi Peter - inline below.

>On Fri, Oct 12, 2007, Lloyd Wood <[email-masked]> wrote:
>
>>At Friday 12/10/2007 15:42 -0400, Peter Lovell wrote:
>>>This discussion is indeed helpful.
>>>
>>>Parts are turning, though, on semantics and definitions so I'll add a
>>>few thoughts.
>>>
>>>Stephen views the suggestion as "routing" and I think that's too narrow.
>>>It can be viewed that way but is not quite the same. 
>>>
>>>It's worthwhile to note, as Susan mentioned, that the push/pop
>>>suggestion does not *add* a new pathing requirement. That has already
>>>been done by the use of security-destination fields in security blocks.
>>>The suggestion is not adding the path requirement but is just an
>>>implementation mechanism to help make the requirement work, and get
>>>bundles properly to their destinations. If we don't want to have such a
>>>pathing requirement then the solution is to disallow security-
>>>destination. If there are security-destinations then there's a path
>>>requirement. It's that simple. Choose one.
>>
>>What if the specified security destination is the same as the final endpoint?
>>Using the security destination in that way with multiple nested popping at
>>the same destination avoids imposing any pathing requirement, imo; you
>>can use a security destination without a path requirement.
>>
>>This could allow security 'tunnelled' in a separate reliability wrapper, as is
>>commonly done by reliable protocols - with both the error detection 'tunnel'
>>and the inner encryption being removed at the final endpoint.
>>Previously suggested on in [1].
>>
>>(Looping could be addressed with a TTL/hopcount mechanism.)
>>
>>L.
>>
>>[1] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-September/002917.html 
>
>
>If the security destination is the same as the final bundle destination
>then it could work that way.
>
>However you and others have described scenarios where various nodes have
>limited ability, such as 
>>My understanding is that most intended uses of DTN nodes 
>>are for embedded nodes -- that is, nodes not capable of 
>>running Windows.
>Nodes such as these might not have the necessary capabilities.

My take here is that such embedded nodes will want reliable delivery of data.
The only current way to get that reliability and resistance to introduced errors
with DTN protocols (bundle and LTP) is to implement the security frameworks
and reuse security for reliability (outlined in the LTP optional extensions draft
and in the irtf-dtnrg-bundle-checksum draft.)

As you say, such nodes likely won't have the necessary horsepower/resources to
implement the security frameworks. Yet, they do need reliable delivery, so likely
won't look to DTN protocols for their needs. I think this is a missed opportunity
for DTN, which is aimed more at the 'high end' of processing power.

>In addition, network configurations using an insecure dtnet to connect
>two secure subnetworks may wish to super-protect the traffic between the
>gateways just to make it look uniform, in addition to any end-to-end
>protection there might be. The keys and ciphersuites used might exist
>only at the bastion gateways, and perhaps the storage and processing
>power too.

Yes, that problem had given me pause for thought earlier.
Let's examine that scenario in more detail.

A - G1 - C1 - C2 - C3 ... Cn - G2 - B

A needs to communicate with B via security bastion gateways G1
and G2. The private DTN networks that A and B reside in are
connected by a carrier network C, with multiple hops between
G1 and G2. A and B are communicating via the bundle protocol.
It's a DTN network, so connectivity is intermittent at best.

Now, A and B don't implement security per se, but do want to
ensure reliable communication between them, so they have to
have an end-to-end checksum. In the bundle protocol, such a
checksum can only get implemented via the bundle security
protocol, via either a private key or via an known public-keyed
or insecure method outlined in irtf-dtnrg-bundle-checksum-00.

G1 and G2 implement more security, so they add a(nother)
security layer.

Now, when G1 hands a bundle to C1, the first node in the
third-party carrier network, C1 has to know that the bundle it has
just been handed is actually not corrupted and worth expending the
effort on forwarding across the carrier network C to G2.

But C1 doesn't have G1's private keys, so it doesn't know about the
worth of the bundle content that it has just been handed, which
contains opaque sections of bits. Errors in these sections can't be
detected. Another bundle checksum is needed - one that G1 has
computed and C1 can use to validate the bundle.

Each node has this problem - 'is the bundle I've just been handed
even worth forwarding on'? Thus, a reliability checksum needs to be
added by G1 outside the encryption, to allow verification by each node
of C that Ck has received the bundle correctly from Ck-1, and is actually
going to forward something that won't just be discarded at G2, and, if
discarded there, should have been discarded much earlier to conserve
network resources.

Conserving network resources is pretty important for bundle networks -
unlike the terrestrial Internet, you can't just send on the corrupted frame
to the endnode to finally detect the problem, discard the frame, and
expect resends to take care of it. (There's a weak analogy with ATM
early/partial packet discard here, as far as conserving resources goes.)

Unlike the Internet, the cost of delivery is higher; there may be no chance
of a resend at a late point of error detection as nodes are no longer
connected, though the chance of a resend earlier when e.g. C1 and C2
are still talking may be possible. But for that local resend to work, C2 needs
to be able to check the validity of the bundle it receives and detect errors.
As the bundle content is encrypted with G1's key which C doesn't have,
another checksum is needed around that.

This reliability check for third-party carriage of encrypted content is quite
important, given sparse resources in bundle networks. C needs a reason to
know that this bundle is worth carrying, rather than just drop it as encrypted
noise it can't check in favour of its own bundles that it can decode, check or
parse for errors, and G2 wants to receive a bundle known to be error-free.

(We have talked about this in the security considerations of
draft-irtf-dtnrg-bundle-checksum-00, which outlines the drawbacks to
implementing the approach in draft-irtf-dtnrg-bundle-checksum-00.)

So, the final picture looks like this:

A - G1 - C1 - C2 - C3 ... Cn - G2 - B
A ------- e2e reliability  -------- B
    G1 ---- added security --- G2
    G1 -- subnet reliability - G2

There's three layers there. Pathing is used because the (outer G) security
destination is different. The security destination G needs to implement
push-pop to support the outer reliability checksum that is needed so that
C can recognise that all of G's content, including the encrypted content,
is transferred correctly, and do resends internal to C nodes if necessary.

Does the BSP as-is cover this scenario?

(An alternative would be mandate that the convergence layers implement
some sort of checksum over bundle payloads, which covers each hop. But
that is weaker than the subnet checksum, as it doesn't cover programming
errors or single event upsets in the nodes, and recomputing a checksum 
at each node actually takes more resources overall. A single subnet
checksum is far preferable. Reliability is best implemented top-down, not
bottom-up, in accordance with the end-to-end principle.)

>So although the scheme you describe will work, BSP has already included
>extended capability allowing intermediate security destinations. My
>intent is to make that work reliably, rather than making more extensive
>changes to BSP.

'reliably' has its own semantic connotations, of course. Here, I'm using it to mean
'without errors introduced in transmission or within a bundle node'.

cheers,

L.

>Regards.....Peter

From: "Peter Lovell" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, Susan <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Wesley Eddy" <[email-masked]>, "Howard Weiss" <[email-masked]>, "Kevin Fall" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(7): [dtn-interest] "security destination"
Date: Sat, 13 Oct 2007 10:24:18 -0400
Sender: [email-masked]

Hi lloyd,

On Fri, Oct 12, 2007, Lloyd Wood <[email-masked]> wrote:

>At Friday 12/10/2007 15:42 -0400, Peter Lovell wrote:
>>This discussion is indeed helpful.
>>
>>Parts are turning, though, on semantics and definitions so I'll add a
>>few thoughts.
>>
>>Stephen views the suggestion as "routing" and I think that's too narrow.
>>It can be viewed that way but is not quite the same. 
>>
>>It's worthwhile to note, as Susan mentioned, that the push/pop
>>suggestion does not *add* a new pathing requirement. That has already
>>been done by the use of security-destination fields in security blocks.
>>The suggestion is not adding the path requirement but is just an
>>implementation mechanism to help make the requirement work, and get
>>bundles properly to their destinations. If we don't want to have such a
>>pathing requirement then the solution is to disallow security-
>>destination. If there are security-destinations then there's a path
>>requirement. It's that simple. Choose one.
>
>What if the specified security destination is the same as the final endpoint?
>Using the security destination in that way with multiple nested popping at
>the same destination avoids imposing any pathing requirement, imo; you
>can use a security destination without a path requirement.
>
>This could allow security 'tunnelled' in a separate reliability
wrapper, as is
>commonly done by reliable protocols - with both the error detection 'tunnel'
>and the inner encryption being removed at the final endpoint.
>Previously suggested on in [1].
>
>(Looping could be addressed with a TTL/hopcount mechanism.)
>
>L.
>
>[1] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-September/
002917.html

If the security destination is the same as the final bundle destination
then it could work that way.

However you and others have described scenarios where various nodes have
limited ability, such as 
>My understanding is that most intended uses of DTN nodes 
>are for embedded nodes -- that is, nodes not capable of 
>running Windows.
Nodes such as these might not have the necessary capabilities.

In addition, network configurations using an insecure dtnet to connect
two secure subnetworks may wish to super-protect the traffic between the
gateways just to make it look uniform, in addition to any end-to-end
protection there might be. The keys and ciphersuites used might exist
only at the bastion gateways, and perhaps the storage and processing
power too.

So although the scheme you describe will work, BSP has already included
extended capability allowing intermediate security destinations. My
intent is to make that work reliably, rather than making more extensive
changes to BSP.

Regards.....Peter

Date: Fri, 12 Oct 2007 21:21:12 +0100
To: "Peter Lovell" <[email-masked]>, Susan <[email-masked]>, "Stephen Farrell" <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re(6): [dtn-interest] "security destination"
Cc: "Wesley Eddy" <[email-masked]>, "Howard Weiss" <[email-masked]>, "Kevin Fall" <[email-masked]>, "dtn interest" <[email-masked]>
Sender: [email-masked]

At Friday 12/10/2007 15:42 -0400, Peter Lovell wrote:
>This discussion is indeed helpful.
>
>Parts are turning, though, on semantics and definitions so I'll add a
>few thoughts.
>
>Stephen views the suggestion as "routing" and I think that's too narrow.
>It can be viewed that way but is not quite the same. 
>
>It's worthwhile to note, as Susan mentioned, that the push/pop
>suggestion does not *add* a new pathing requirement. That has already
>been done by the use of security-destination fields in security blocks.
>The suggestion is not adding the path requirement but is just an
>implementation mechanism to help make the requirement work, and get
>bundles properly to their destinations. If we don't want to have such a
>pathing requirement then the solution is to disallow security-
>destination. If there are security-destinations then there's a path
>requirement. It's that simple. Choose one.

What if the specified security destination is the same as the final endpoint?
Using the security destination in that way with multiple nested popping at
the same destination avoids imposing any pathing requirement, imo; you
can use a security destination without a path requirement.

This could allow security 'tunnelled' in a separate reliability wrapper, as is
commonly done by reliable protocols - with both the error detection 'tunnel'
and the inner encryption being removed at the final endpoint.
Previously suggested on in [1].

(Looping could be addressed with a TTL/hopcount mechanism.)

L.

[1] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-September/002917.html

>The suggestion doesn't determine what exact path a bundle must take. It
>only ensures that the security destinations are visited in the required
>order - nothing more. My own view of the suggestion is not as a routing
>mechanism but as a very lightweight tunnel. Think of it as an
>encapsulation with a gossamer envelope. So the suggestion doesn't
>determine the routing for a bundle -- it can wander all over the dtnet
>as much as the routers determine -- but only a list of nodes which must
>be visited at some time, in order.
>
>It's certainly possible for looping ( loopy ?? :) paths to cause a
>bundle to visit a node more than once. In this case the push/pop
>suggestion is definitely an advantage as it will visit its ultimate
>resting place quite unaware of that fact, enroute to the intermediate
>destination. It's being tunneled and, although it may pass through the
>ultimate destination, the immediate task is to get it to the "next
>processing" node. When it gets there, it will be sent back and that's OK
>and quite normal. 
>
>[As an aside, I hate to think of the implementation details for the non-
>push/pop scheme when a bundle arrives at the bundle-destination and is
>then sent elsewhere for the intermediate processing which had been
>skipped. Forwarding a bundle away from the bundle-destination ... hhmmm.
>I think I'll stand well back from that scenario, maybe with a helmet and
>blast protection.]
>
>Regards.....Peter
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: "Peter Lovell" <[email-masked]>
To: Susan <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Wesley Eddy" <[email-masked]>, "Howard Weiss" <[email-masked]>, "Kevin Fall" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(6): [dtn-interest] "security destination"
Date: Fri, 12 Oct 2007 15:42:24 -0400
Sender: [email-masked]

This discussion is indeed helpful.

Parts are turning, though, on semantics and definitions so I'll add a
few thoughts.

Stephen views the suggestion as "routing" and I think that's too narrow.
It can be viewed that way but is not quite the same. 

It's worthwhile to note, as Susan mentioned, that the push/pop
suggestion does not *add* a new pathing requirement. That has already
been done by the use of security-destination fields in security blocks.
The suggestion is not adding the path requirement but is just an
implementation mechanism to help make the requirement work, and get
bundles properly to their destinations. If we don't want to have such a
pathing requirement then the solution is to disallow security-
destination. If there are security-destinations then there's a path
requirement. It's that simple. Choose one.

The suggestion doesn't determine what exact path a bundle must take. It
only ensures that the security destinations are visited in the required
order - nothing more. My own view of the suggestion is not as a routing
mechanism but as a very lightweight tunnel. Think of it as an
encapsulation with a gossamer envelope. So the suggestion doesn't
determine the routing for a bundle -- it can wander all over the dtnet
as much as the routers determine -- but only a list of nodes which must
be visited at some time, in order.

It's certainly possible for looping ( loopy ?? :) paths to cause a
bundle to visit a node more than once. In this case the push/pop
suggestion is definitely an advantage as it will visit its ultimate
resting place quite unaware of that fact, enroute to the intermediate
destination. It's being tunneled and, although it may pass through the
ultimate destination, the immediate task is to get it to the "next
processing" node. When it gets there, it will be sent back and that's OK
and quite normal. 

[As an aside, I hate to think of the implementation details for the non-
push/pop scheme when a bundle arrives at the bundle-destination and is
then sent elsewhere for the intermediate processing which had been
skipped. Forwarding a bundle away from the bundle-destination ... hhmmm.
I think I'll stand well back from that scenario, maybe with a helmet and
blast protection.]

Regards.....Peter

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] "security destination"
Date: Fri, 12 Oct 2007 13:19:06 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Peter Lovell" <[email-masked]>, "Wesley Eddy" <[email-masked]>, "Howard Weiss" <[email-masked]>, "Kevin Fall" <[email-masked]>, "dtn interest" <[email-masked]>
Sender: [email-masked]

Stephen,

Part of me sees your point, but there is also a part of me that still
disagrees, so I'd like to explore this further.  Please see my comments
below.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: Stephen Farrell [mailto:[email-masked]] 
>Sent: Friday, October 12, 2007 12:21 PM
>To: Symington, Susan F.
>Cc: Peter Lovell; Wesley Eddy; Howard Weiss; Kevin Fall; dtn interest
>Subject: Re: [dtn-interest] "security destination"
>
>
>
>Symington, Susan F. wrote:
>> I just received Stephen's email saying that he doesn't believe this
>> push/pop security proposal should be in the security spec 
>because it is
>> a routing scheme. I'm not sure I agree with this. I wouldn't 
>call it a
>> routing scheme. It seems to me that the proposal merely 
>makes  explicit
>> a routing requirement that had previously been implicitly imposed by
>> the addition of a security block whose security-destination is not
>> equal to the bundle destination. 
>
>No, the proposal specifies how one MUST do that and hence is
>a routing scheme, not a requirement. (And in any case, there's
>no generic need for that requirement, if we include the possibility
>of looping routes, the bundle might get to the final destination
>first and then be forwarded to the security-destination and
>back.)

Yes, there might be looping routes, causing the bundle to go to the
final destination first before being forwarded to the
security-destination and then back to the final destination. That is a
good point and I don't dispute it. But such a looping route can just as
easily occur if the push/pop security proposal is being used. The
push/pop security proposal doesn't preclude there being looping routes.
In my initial email I said that the push/pop security "proposal isn't
saying how the bundle has to get to the intermediate (security
destination) node, only that it has to get to that node before it gets
to the final destination." This wasn't exactly accurate. The proposal
allows the bundle to be routed to the final destination before reaching
the security destination. But, in order to be useful, the bundle has to
(eventually) be routed to the security destination before being routed
to the final destination. There is no getting around this. Even if
there is a looping route and the bundle gets to its security
destination without having first visited its CB security destination,
it would have to be forwarded to the security destination in the CB
before it could be returned to the destination for delivery. 

[...]

>
>Its more than that - it says that you do the security destinations
>in a certain, fixed order. (yet again declaring itself as a routing
>scheme:-)

Before a bundle can be delivered at its destination, it must pass
through the security-destination of (for example) the CB in the bundle.
There is no getting around this. Yes, an ordering is being imposed, but
this ordering is imposed by the fact that the security block with the
security-destination field was inserted into the bundle, not by the
fact that the the push/pop security proposal is being used. 

>
> > The
>> push/pop security proposal only makes it a lot more likely that the
>> bundle will actually get to that intermediate (security destination)
>> node before getting to the final node if the routing scheme 
>being used
>> is not security-aware.
>
>The push/pop scheme is a security-destination-aware routing
>scheme.

Sorry, but I don't see it that way yet.
>

As an additional thought, let's think about what would happen if we
don't adopt the push/pop security proposal and a bundle that includes a
CB with a security destination reaches its final destination without
having first been forwarded through its security destination. Looking
at the BSP, it seems disquietingly silent in the face of this scenario
(unless I missed something). What the destination node does in this
case would of course depend on its security policy. If it delivers the
bundle, that would be pretty silly because the bundle will be encrypted
and therefore useless. It could throw away the bundle; which is not
very useful. Its other option would be to encapsulate the bundle and
send it to the security destination (though it's not clear to me that
this is currently allowd by the BP). If the bundle is going to be sent
to the security destination anyway (which is the only course of action
that enables the bundle to be useful), then I don't see the problem
with using the push/pop proposal.

I guess what I need for you to convince me that the push/pop proposal
is unnecessarily constraining is an example of how a bundle would move
differently through the network if the proposal isn't used versus if it
is used. Isn't the bundle's movement (insofar as it must pass through
the security-destination before being delivered at the final
destination) going to end up being the same either way?

Awaiting enlightenment,
susan

Date: Fri, 12 Oct 2007 17:21:21 +0100
From: Stephen Farrell <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
CC: Peter Lovell <[email-masked]>, Wesley Eddy <[email-masked]>, Howard Weiss <[email-masked]>, Kevin Fall <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: [dtn-interest] "security destination"
Sender: [email-masked]

Symington, Susan F. wrote:
> I just received Stephen's email saying that he doesn't believe this
> push/pop security proposal should be in the security spec because it is
> a routing scheme. I'm not sure I agree with this. I wouldn't call it a
> routing scheme. It seems to me that the proposal merely makes  explicit
> a routing requirement that had previously been implicitly imposed by
> the addition of a security block whose security-destination is not
> equal to the bundle destination. 

No, the proposal specifies how one MUST do that and hence is
a routing scheme, not a requirement. (And in any case, there's
no generic need for that requirement, if we include the possibility
of looping routes, the bundle might get to the final destination
first and then be forwarded to the security-destination and
back.)

> The proposal isn't saying how the bundle has to get to the intermediate
> (security destination) node, only that it has to get to that node
> before it gets to the final destination, which is true as a routing
> requirement whether or not we use the push/pop security proposal. 

Its more than that - it says that you do the security destinations
in a certain, fixed order. (yet again declaring itself as a routing
scheme:-)

 > The
> push/pop security proposal only makes it a lot more likely that the
> bundle will actually get to that intermediate (security destination)
> node before getting to the final node if the routing scheme being used
> is not security-aware.

The push/pop scheme is a security-destination-aware routing
scheme.

Cheers,
S.

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] "security destination"
Date: Fri, 12 Oct 2007 11:26:13 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Wesley Eddy" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "Howard  Weiss" <[email-masked]>, "Kevin Fall" <[email-masked]>, "dtn interest" <[email-masked]>
Sender: [email-masked]

Peter,

Thanks for this clear writeup. I will be thinking about this push/pop
security destination proposal to see if I can find holes, but right now
it seems reasonable. 

I don't envy you having to implement it though.

I just received Stephen's email saying that he doesn't believe this
push/pop security proposal should be in the security spec because it is
a routing scheme. I'm not sure I agree with this. I wouldn't call it a
routing scheme. It seems to me that the proposal merely makes  explicit
a routing requirement that had previously been implicitly imposed by
the addition of a security block whose security-destination is not
equal to the bundle destination. 

The proposal isn't saying how the bundle has to get to the intermediate
(security destination) node, only that it has to get to that node
before it gets to the final destination, which is true as a routing
requirement whether or not we use the push/pop security proposal. The
push/pop security proposal only makes it a lot more likely that the
bundle will actually get to that intermediate (security destination)
node before getting to the final node if the routing scheme being used
is not security-aware.

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Peter
Lovell
>Sent: Thursday, October 11, 2007 8:07 PM
>To: Peter Lovell; Wesley Eddy; Stephen Farrell; Howard Weiss; 
>Kevin Fall; dtn interest
>Subject: [dtn-interest] "security destination"
>
>On Wed, Sep 19, 2007, Peter Lovell <[email-masked]> wrote:
>
>
>> On Wed, Sep 19, 2007 at 03:19:26PM +0100, Stephen Farrell wrote:
>> 
>> Actually, I thought there were a few big questions remaining 
>on the BSP
>> itself.  The freshest one in my mind is how bundles are 
>actually routed
>> to the security-destination. 
>
>
>>On Wed, Sep 19, 2007, Wesley Eddy <[email-masked]> wrote:
>>
>>>     [snip]  The
>>>IPsec protocols either construct proper tunnels by encapsulation or
>>>operate end-to-end.  The BSP adds addresses (security-source and
>>>security-destination) in addition to the primary bundle block's
>>>addresses, without encapsulating.  This is quite different.
>>
>>
>>Chatting just now with Howie about this, I realize that the push/pop
>>scheme for security-destination would also eliminate another 
>nasty problem.
>>
>>The recent discussion-draft included a section pointing out an issue
>>with "overlapping security zones" and the kind of trouble 
>that results.
>>The push/pop scheme makes that impossible.
>>
>>That's not for this cycle though. But let's take it up in a few
weeks.
>>
>
>
>Well, the vacation has come and gone (and was great) so it's about
time
>to consider this again in more detail.
>
>For those on the list new to this topic, it will help to read new
>sections 3.2 and 3.3 in the latest security draft
<http://www.ietf.org/
>internet-drafts/draft-irtf-dtnrg-bundle-security-04.txt>
>
>In a nutshell, BSP's use of "security destination" creates several
>difficulties. 
>
>The creator of the block with the security destination clearly expects
>the bundle to be routed through that intermediate node on the 
>way to the
>final destination, but there's no way for this to be expressed to the
>routers and make it happen. By their very nature, dtn networks are
>expected to have variable pathing and, in the absence of directions to
>the contrary, routers will forward bundles as they see fit. So it is
>quite possible that a bundle will arrive at the bundle destination
>having bypassed the security destination, and be useless. 
>
>A second problem is that of overlapping security zones, as described
in
>section 3.3. We don't presently have a solution for this within BSP.
>
>So, having thought about this for a while, I'm proposing a 
>change to the
>way security block processing works when the block is added to the
>bundle, only in the case where the security destination is not the
>bundle destination. This is for PSBs and CBs only, as the case 
>with BABs
>is simple and not of interest because they're single-hop only.
>
>The change is that the security block uses a conceptual 
>push/pop process
>with respect to the bundle destination. The implementation details
need
>not concern us here (*I* have to write the code anyhow :) and let's
>focus on the behavior. When a security block is added (with security
>dest != bundle dest) then the security destination is pushed onto the
>bundle-destination stack. All processes and all forwarding nodes after
>this see the security destination as the ultimate destination, so the
>bundle is obviously sent there. When it arrives and the security block
>is processed [remember that this is the final destination for this
>security block], the address is pop'ed and the original bundle
>destination is restored, and the bundle forwarded there. So what we've
>done is to create a tunnel from security-source to 
>security-destination.
>These can be nested if conditions require.
>
>This scheme will solve the two issues described above. The first is
>trivial -- if the security destination is pushed on the bundle
>destination, the bundle obviously will be routed there. The
overlapping
>zones are solved also. Taking the example in section 3.3, the addition
>of PSa at BN1 causes the bundle destination to change from BN4 to BN3,
>so BN2's PSb won't be able to span to BN4, but only to BN3. Since the
>destination is "pulled in" the overlapping zone can't be created.
>
>I've looked at various scenarios, including canonicalization for PS
>blocks, and haven't found anything which would cause a 
>problem. But more
>consideration is good because I'm sure others have scheme I haven't
>thought of.
>
>Please let me know if you find holes in this solution.
>
>Thanks.....Peter
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Fri, 12 Oct 2007 16:12:50 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
CC: Wesley Eddy <[email-masked]>, Howard Weiss <[email-masked]>, Kevin Fall <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: [dtn-interest] "security destination"
Sender: [email-masked]

Peter Lovell wrote:
> In a nutshell, BSP's use of "security destination" creates several
> difficulties. 

s/creates/can create/ but so can encrypting with the wrong
key.

> The change is that the security block uses a conceptual push/pop process
> with respect to the bundle destination. The implementation details need
> not concern us here (*I* have to write the code anyhow :) and let's
> focus on the behavior. When a security block is added (with security
> dest != bundle dest) then the security destination is pushed onto the
> bundle-destination stack. All processes and all forwarding nodes after
> this see the security destination as the ultimate destination, so the
> bundle is obviously sent there. When it arrives and the security block
> is processed [remember that this is the final destination for this
> security block], the address is pop'ed and the original bundle
> destination is restored, and the bundle forwarded there. So what we've
> done is to create a tunnel from security-source to security-destination.
> These can be nested if conditions require.

I don't think that should be in the security spec. Its a routing
scheme. While its perfectly fine for there to be a routing scheme
that is security-destination aware, I don't believe we want to
determine the one-and-only such scheme here and now. (Documenting
the above as an example of what might be done would be fine.)

Stephen.

From: "Peter Lovell" <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Wesley Eddy" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "Howard Weiss" <[email-masked]>, "Kevin Fall" <[email-masked]>, "dtn interest" <[email-masked]>
Date: Thu, 11 Oct 2007 20:06:53 -0400
Subject: [dtn-interest] "security destination"
Sender: [email-masked]

On Wed, Sep 19, 2007, Peter Lovell <[email-masked]> wrote:

> On Wed, Sep 19, 2007 at 03:19:26PM +0100, Stephen Farrell wrote:
> 
> Actually, I thought there were a few big questions remaining on the BSP
> itself.  The freshest one in my mind is how bundles are actually routed
> to the security-destination. 

>On Wed, Sep 19, 2007, Wesley Eddy <[email-masked]> wrote:
>
>>     [snip]  The
>>IPsec protocols either construct proper tunnels by encapsulation or
>>operate end-to-end.  The BSP adds addresses (security-source and
>>security-destination) in addition to the primary bundle block's
>>addresses, without encapsulating.  This is quite different.
>
>
>Chatting just now with Howie about this, I realize that the push/pop
>scheme for security-destination would also eliminate another nasty problem.
>
>The recent discussion-draft included a section pointing out an issue
>with "overlapping security zones" and the kind of trouble that results.
>The push/pop scheme makes that impossible.
>
>That's not for this cycle though. But let's take it up in a few weeks.
>

Well, the vacation has come and gone (and was great) so it's about time
to consider this again in more detail.

For those on the list new to this topic, it will help to read new
sections 3.2 and 3.3 in the latest security draft <http://www.ietf.org/
internet-drafts/draft-irtf-dtnrg-bundle-security-04.txt>

In a nutshell, BSP's use of "security destination" creates several
difficulties. 

The creator of the block with the security destination clearly expects
the bundle to be routed through that intermediate node on the way to the
final destination, but there's no way for this to be expressed to the
routers and make it happen. By their very nature, dtn networks are
expected to have variable pathing and, in the absence of directions to
the contrary, routers will forward bundles as they see fit. So it is
quite possible that a bundle will arrive at the bundle destination
having bypassed the security destination, and be useless. 

A second problem is that of overlapping security zones, as described in
section 3.3. We don't presently have a solution for this within BSP.

So, having thought about this for a while, I'm proposing a change to the
way security block processing works when the block is added to the
bundle, only in the case where the security destination is not the
bundle destination. This is for PSBs and CBs only, as the case with BABs
is simple and not of interest because they're single-hop only.

The change is that the security block uses a conceptual push/pop process
with respect to the bundle destination. The implementation details need
not concern us here (*I* have to write the code anyhow :) and let's
focus on the behavior. When a security block is added (with security
dest != bundle dest) then the security destination is pushed onto the
bundle-destination stack. All processes and all forwarding nodes after
this see the security destination as the ultimate destination, so the
bundle is obviously sent there. When it arrives and the security block
is processed [remember that this is the final destination for this
security block], the address is pop'ed and the original bundle
destination is restored, and the bundle forwarded there. So what we've
done is to create a tunnel from security-source to security-destination.
These can be nested if conditions require.

This scheme will solve the two issues described above. The first is
trivial -- if the security destination is pushed on the bundle
destination, the bundle obviously will be routed there. The overlapping
zones are solved also. Taking the example in section 3.3, the addition
of PSa at BN1 causes the bundle destination to change from BN4 to BN3,
so BN2's PSb won't be able to span to BN4, but only to BN3. Since the
destination is "pulled in" the overlapping zone can't be created.

I've looked at various scenarios, including canonicalization for PS
blocks, and haven't found anything which would cause a problem. But more
consideration is good because I'm sure others have scheme I haven't
thought of.

Please let me know if you find holes in this solution.

Thanks.....Peter

Date: Mon, 08 Oct 2007 17:25:55 -0400
From: Christopher Small <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] OLPC/XO and DTN?
Sender: [email-masked]

Is anyone working on a port of DTN to the one-laptop-per-child XO machine?

- Chris
-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research                           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138