Subject: Re: [dtn-interest] CVS server
From: Michael Demmer <[email-masked]>
To: Magnus Lindholm <[email-masked]>
Cc: [email-masked]
Date: Wed, 24 Nov 2004 16:41:14 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

The problem was due to a misconfigured firewall. It has been fixed and
you should have access once again.

Sorry for the inconvenience,
-mike

> Hi,
> 
> I've been able to check out both DNT1 and DTN2 sources up until early
> november but I've noticed that the CVS repository is no longer available
> via code.dtnrg.org, the machine seems to be up and running though. Is
> there any news on it's availablilty?
> 
> Regards
> 
> Magnus Lindholm
> Developer Engineer
> SNC project
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Tue, 23 Nov 2004 18:57:33 +0000
From: Stephen Farrell <[email-masked]>
To: "Susan F. Symington" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN security
Sender: [email-masked]

Susan,

Susan F. Symington wrote:

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

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

> I looked at the latest spec and have the following comments about PSH (and BAH
> too in most cases).
>  
> - PSH only support signatures up to 2048 bits long which is IMO far too close
>   to the wire - 2048 bit RSA signatures are entirely likely to be used, so some
>   mechanism for longer signatures should be provided. Also, its says
>   "optionally" running the hash through a signature alg. What would be the
>   purpose of omitting this step?
> 
> Susan: How do you come to the conclusion that PSH only supports signatures 
 > up to 2048 bits long? It is my understanding that the Security
 > Information field of the PSH, which is where the signed hash
 > would reside, is a variable length field,and thus not limited in size.
 > Where are we misunderstanding each other?

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

> - What's wrong with MACing btw?

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

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

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

> Susan: I don't think there is any loop detection mechanism. In order to be 
 > able to detect replays, we have to be able to distinguish between
 > replays and legitimate retransmissions. THis is tricky and would 
probably
 > require adding a field to the bundle header. But also every DTN node
 > would have to maintain a local list of allbundles received and this list
 > could quickly become very large.

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

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

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

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

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

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

Stephen.

From: "Susan F. Symington" <[email-masked]>
To: "'Stephen Farrell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [dtn-interest] DTN security
Date: Tue, 23 Nov 2004 13:22:17 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C4D15F.748184C0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Stephen,

Thank you for your comments on my previous DTN security posting. My
responses are interspersed with your comments in the attached file. I have
preceeded my responses with "Susan:".

-susan 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, November 18, 2004 8:32 AM
To: Susan F. Symington
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN security

Hi Susan,

 > A few of us got together last week to talk about DTN security.
 > Attached is a summary of that discussion.
 >
 > -Susan Symington

Good to see that this bit of the spec is getting looked at.
We should make sure this and LTP aren't out of whack sometime,
but meanwhile, there're a couple of comments attached.

Stephen.

------=_NextPart_000_000C_01C4D15F.748184C0
Content-Type: text/plain;
	name="secd-Susan-response-to-Stephen_Farrell.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="secd-Susan-response-to-Stephen_Farrell.txt"

Stephen,

Thank you for your comments on my previous DTN security posting. My =
responses are below. I have preceeded my responses with "Susan:".

-susan

> 1. The Bundle Protocol should be made explicit regarding the =
distinction
> between a source and a sender as well as the distinction between a =
destination
> and a receiver. Each bundle has one source and one destination, but =
will have
> as many senders and receivers as there are DTN hops from the source to =
the
> destination. The source signs the hash in the Payload Security Header =
(PSH),
> which provides the bundle with end-to-end data integrity and source
> authentication, and the destination decrypts this signed hash in the =
PSH. The
> sender signs the hash in the Bundle Authentication Header (BAH), which =
provides
> the bundle with data integrity and sender authentication along the =
single hop
> from the sender to the receiver. The receiver decrypts this signed =
hash in the
> BAH.

Would it be worthwhile being more efficient if sender=3Dsource? You =
could
define a scheme whereby both hashes are input to a single private key=20
operation and a single signature authenticates both. Probably not =
worthwhile=20
though.

Susan: I don't see how this could work. If you think it's worth =
pursuing, then please explain in a little more detail how it would work. =
(Its only possible for sender=3Dsource on the first hop of a bundle's =
journy from source to destination. I didn't think that the PSH hash =
would typically be checked by this first hop anyway.)=20

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

Susan: How do you come to the conclusion that PSH only supports =
signatures up to 2048 bits long? It is my understanding that the =
Security Information field of the PSH, which is where the signed hash =
would reside, is a variable length field,and thus not limited in size. =
Where are we misunderstanding each other?

- 3.3, p17: using a single bit in the payload security byte to=20
  indicate encryption is broken - all sensible protocols require at=20
  least an algId and keyID (you note the algId later, but keyId is
  also needed)

Susan: Good point. Adding an optional KeyID field is a good idea. (Right =
now, the source endpoint ID is the "key lookup information" needed to =
look up the appropriate key to use to decrypt the signed hash in the =
PSH. I suppose that it could also be used as the key lookup information =
to look up the appropriate key to use to decrypt the payload if we =
really want to save bits. But it is better to have the flexibility that =
an optional "KeyID field for confidentiality" would provide. Thanks.

- when I sign, where do I include the public-key,cert-id or whatever? If
  its derived from other identity info, then you have to say (at least =
as
  an example) how that'd work - basically, there needs to be at least =
one
  way to do key management
- What's wrong with MACing btw?

> 3. DTN security mechanisms will explicitly not have as a goal =
protection of the
> DTN infrastructure against Denial of Service as executed by replay =
attacks.

That's at least badly stated IMO. The goal should be protection against
DoS generally. Depending on a lower layer to prevent replays is not a
good idea - both accidental and deliberate replays will happen and the
a DTN had better not fall over as a result!

Susan: The DTN won't fall over if there are deliberate or accidental =
replays. It's just that nothing will be builT into the protocol to =
enable replayed bundles to be detected and discarded at arbitrary DTN =
nodes. Replays are one form of Denial of Service attack that we are =
consciously not trying to protect the DTN infrastructure against, =
because the cost of providing this protection is not worth the benefit.=20

> 4. Even though protection of the infrastructure against replay attacks =
is not a
> goal of DTN security, DTN shall optionally support protecting =
applications from
> receiving replayed bundles. The bundle agent at the destination host =
should
> have the ability to 2 keep a local list of already-received bundles, =
check all
> received bundles against this list, and reject duplicate bundles. This =
behavior
> should be optional, and the destination application, as a new =
parameter of the
> Register.Request primitive, should be able to indicate to the =
destination
> bundle agent whether it does or does not want the destination bundle =
agent to
> enforce the at most once semantics and discard all duplicate bundles. =
It would
> be up to the application to decide what to do with a bundle in the =
case that
> the application had registered for receipt of that bundle requesting
> at-most-one semantics, but the bundle was received without a payload =
security
> header (as indicated by absence of the authentication option in the
> Data.Indication primitive).

Now I'm confused:-) But if checking for replays is well defined but =
optional=20
that's not nearly as bad!

Susan: We are making a distinction between detecting a replay at an =
arbitrary DTN node in the infrastructure, and detecting a replay at a =
destination host. The infrastructure may have replayed packets that will =
not be detected and discarded at arbitrary nodes, but if an application =
so chooses, it can have its bundle agent protect it from receiving =
replayed bundles.=20

I guess there'll also need to be some loop detection stuff, just like =
with
email. Why not use a digest over (content/bundle/whatever) for that and
then you can get replay protection too?

Susan: I don't think there is any loop detection mechanism. In order to =
be able to detect replays, we have to be able to distinguish between =
replays and legitimate retransmissions. THis is tricky and would =
probably require adding a field to the bundle header. But also every DTN =
node would have to maintain a local list of allbundles received and this =
list could quickly become very large.=20

> 5. The use of the three security-related options (confidentiality, =
integrity,
[...]

Again, what's the point of a bare-digest there? It only allows detection =
of
accidental changes, deliberate changes only require re-calculation so it =
may
as well be missing.

Susan: Using an unsigned hash is in there as an option. An unsigned hash =
really just provides error detection, like one BIG checksum value. If =
protection against malicious modification is needed, the hash must be =
signed.

> 6. The Send.Request should have additional optional parameters to =
enable the
[...]

Good. Still missing keyId for confid. though.

> 7. We may want to define a new optional parameter of the Send.Request =
primitive
> that would be used to indicate to the bundle agent that the =
application does
> not want to trust the underlying network and therefore that the bundle =
should
> be protected with a BAH.

Is that like the "security flag"? [RFC3514] Not clear that this is =
worthwhile.

Susan: The point is that the workings of the bundle layer are normally =
transparent to the application, but this parameter gives a sending =
application a little more control. Each bundle agent must authenticate =
bundles received, but it can do so in one of two ways: either by using =
the BAH or by asserting the authenticity of the bundle (presumably based =
on the fact that an underlying network that is known  to be secure is =
used). Sending and receiving applications don't now have any way of =
knowing how a sent/received bundle has been protected while in transit. =
The idea is that this new parameter can be used by a DTN application to =
signal to the bundle layer that it wants its data protected using a BAH =
at every hop along the way from source to destination, and it doesn't =
want to trust the security of any of the underlying networks to provide =
this bundle authentication on any hop.=20

> 10. In order to enable the Bundle Protocol to simultaneously support =
reactive
> fragmentation and provide authentication using the BAH, we want to =
change the
> definition of the bundle authentication header so that the hash in the =
BAH
> authentication field is computed over the following information: the =
entire
> bundle, except for the payload field of the Bundle Payload Header (the
> authentication field of the BAH should be zeroed out before the hash =
is
> calculated), and the endpoint ID of the sender (although the endpoint =
ID of the
> sender will not necessarily be included in the bundle header, its =
value should
> be included in the information over which the BAH hash is calculated). =
=20
[...]

Sounds ok. But you need to make sure (I didn't check) that all the =
inputs
to this hashing are at the front of the bundle so that the BAH can be=20
calculated for v. large bundles without having to buffer up loads of
stuff or wait for the entire bundle to have passed. If you don't do
that then the BAH has to be a trailer, sent after everything else has =
been
transmitted. (Mind you, given that BAH is hop-by-hop I'm confused
about this a bit.)

Susan: The payload is always at the end of the bundle and the payload is =
not included in  the information over which the hash is calculated, so =
there will not be any such buffering up of loads of stuff.

> 11. The security information field in the PSH should be calculated =
over the
> entire bundle (not just the payload, as is currently specified). =
Specifically,
> the hash in the PSH should be calculated over the entire bundle, with: =
the
> authentication information field of the BAH zeroed out (because it is =
mutable),
> the security information field of the PSH zeroed out, and the =
custodian field
> of the Primary Bundle Header zeroed out (because it is mutable).

So long as they don't change en-route that's ok.

Susan: Yes, I have actually rethought this recently and realized that =
the entire BAH must be omitted from the PSH hash calculation, because =
there is no way to guarantee that a bundle that is sent from the source =
with a BAH will be received at the sender with a BAH, nor is there any =
way to guarantee that a bundle that is sent from the source without a =
BAH won't have a BAH when it is received at the sender. Before =
calculating the PSH hash at both sender and receiver, if the bundle has =
a BAH, the BAH must be removed and the next header field of the field =
preceding the BAh in the chained bundle header must be given a new value =
so as to omit the BAH and point to the header beyond the BAH. At the =
source the PSH is calculated before the BAH, and at the recipient, the =
BAH is verified (and then omitted) before the PSH.

> 14. The question arose as to what has a private key. Do applications =
have keys?
> Do port numbers have keys? Do people have keys? Right now, the way the =
protocol
> is structured, the value in the source endpoint ID is used as the =
mechanism to
> determine what public key to use to decrypt the hash value in the =
Payload
> Security Header. This implies that source endpoint IDs have keys. =
There is no
> reason that keys need to be associated with only source endpoint IDs, =
however.
> It was suggested that there should be an optional field in the Payload =
Security
> Header that has as value the information needed to look up the =
appropriate key
> needed to decrypt the bundles hash and thereby authenticate the =
bundle. Having
> this field would decouple the source endpoint ID from the public key
> information and provide more flexibility and greater granularity =
regarding what
> is able to be authenticated. The appeal of this is that it would =
enable keys to
> be flexibly associated with whatever entity makes sense for a =
particular
> application. On the other hand, enabling the source endpoint ID field =
to both
> denote the source of the bundle and be the information needed in order =
to look
> up the public key needed to authenticate the bundle as is currently =
defined
> saves bits in the header, because a single field is able to serve two =
purposes.
> Adding the optional key lookup field would provide added flexibility =
and
> granularity of authentication at the cost of the additional bits that =
would be
> required to include this field in the header.

You need this (or equivalent) for key rollover and other purposes.

Susan: Good point. Thanks.

> 15. Applications should not be burdened with having to sign hashes. =
Ideally,
> the hash value in the security information field of the PSH should be =
signed
> without the application having to do anything special to make this =
happen. On
> the other hand, in order for the bundle agent to sign the hash, the =
bundle
> agent would have to be privy to the applications private key. The =
private keys
> of sources should not be divulged to bundle agents because making =
bundle agents
> privy to source private keys would make it impossible to distinguish =
between
> authenticating the source versus authenticating the source bundle =
agent as the
> originator of the bundle. Private keys must at a minimum be stored in =
the
> client side of the application/bundle agent API to keep them separate =
from the
> source bundle agent. Perhaps these private keys can be kept in a =
library or
> server that is responsible for performing the key signing =
functionality,
> thereby freeing the application from direct involvement in the process =
of
> signing each PSH hash.

That contradicts #11 about PSH covering more than payload doesn't it?

Susan: I wouldn't say "contradict", but it does complicate matters. The =
application is the entity that knows the private key, but the bundle =
agent is the entity that knows the values of the headers in the bundle =
over which the PSH hash is calculated. The bundle agent has to calculate =
the hash and then pass it elsewhere (to the application or to a special =
key-signing library or server entity) that will sign the hash and return =
the signed hash to the bundle agent for insertion into the PSH.

------=_NextPart_000_000C_01C4D15F.748184C0--

Date: Tue, 23 Nov 2004 11:36:10 +0100
To: [email-masked]
From: "Magnus Lindholm" <[email-masked]>
Subject: [dtn-interest] CVS server
Sender: [email-masked]

Hi,

I've been able to check out both DNT1 and DTN2 sources up until early
november but I've noticed that the CVS repository is no longer available
via code.dtnrg.org, the machine seems to be up and running though. Is
there any news on it's availablilty?

Regards

Magnus Lindholm
Developer Engineer
SNC project

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Sat, 20 Nov 2004 00:16:58 -0800 (PST)
From: Praveen Choudary <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Research
Sender: [email-masked]

Hi,
 My research interests are in Delay Tolerant Networks,
Sensor Networks and Mobile Ad-hoc Networks. Presently
I am doing research on my own. I want to demonstrate
my research capability by working on a research
project. I can read, understand and analyse the
publications. I have got a good understanding of the
research work done in my areas of interest.
 
 Kindly let me know if it possible for researchers in
this group to help me. If anybody can specify the
research problem and give me some suggestions to
proceed,  I will work on the problem and try my best
to develop some potential solutions.

Looking forward for an opportunity,
Sincerely,
Praveen. 

		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 

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

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

Hi Susan,

 > A few of us got together last week to talk about DTN security.
 > Attached is a summary of that discussion.
 >
 > -Susan Symington

Good to see that this bit of the spec is getting looked at.
We should make sure this and LTP aren't out of whack sometime,
but meanwhile, there're a couple of comments attached.

Stephen.

--------------070507060305060405010901
Content-Type: text/plain;
 name="secd.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="secd.txt"

> 1. The Bundle Protocol should be made explicit regarding the distinction
> between a source and a sender as well as the distinction between a destination
> and a receiver. Each bundle has one source and one destination, but will have
> as many senders and receivers as there are DTN hops from the source to the
> destination. The source signs the hash in the Payload Security Header (PSH),
> which provides the bundle with end-to-end data integrity and source
> authentication, and the destination decrypts this signed hash in the PSH. The
> sender signs the hash in the Bundle Authentication Header (BAH), which provides
> the bundle with data integrity and sender authentication along the single hop
> from the sender to the receiver. The receiver decrypts this signed hash in the
> BAH.

Would it be worthwhile being more efficient if sender=source? You could
define a scheme whereby both hashes are input to a single private key 
operation and a single signature authenticates both. Probably not worthwhile 
though.

I looked at the latest spec and have the following comments about PSH (and BAH
too in most cases).
 
- PSH only support signatures up to 2048 bits long which is IMO far too close
  to the wire - 2048 bit RSA signatures are entirely likely to be used, so some
  mechanism for longer signatures should be provided. Also, its says
  "optionally" running the hash through a signature alg. What would be the
  purpose of omitting this step?
- 3.3, p17: using a single bit in the payload security byte to 
  indicate encryption is broken - all sensible protocols require at 
  least an algId and keyID (you note the algId later, but keyId is
  also needed)
- when I sign, where do I include the public-key,cert-id or whatever? If
  its derived from other identity info, then you have to say (at least as
  an example) how that'd work - basically, there needs to be at least one
  way to do key management
- What's wrong with MACing btw?

> 3. DTN security mechanisms will explicitly not have as a goal protection of the
> DTN infrastructure against Denial of Service as executed by replay attacks.

That's at least badly stated IMO. The goal should be protection against
DoS generally. Depending on a lower layer to prevent replays is not a
good idea - both accidental and deliberate replays will happen and the
a DTN had better not fall over as a result!

> 4. Even though protection of the infrastructure against replay attacks is not a
> goal of DTN security, DTN shall optionally support protecting applications from
> receiving replayed bundles. The bundle agent at the destination host should
> have the ability to 2 keep a local list of already-received bundles, check all
> received bundles against this list, and reject duplicate bundles. This behavior
> should be optional, and the destination application, as a new parameter of the
> Register.Request primitive, should be able to indicate to the destination
> bundle agent whether it does or does not want the destination bundle agent to
> enforce the at most once semantics and discard all duplicate bundles. It would
> be up to the application to decide what to do with a bundle in the case that
> the application had registered for receipt of that bundle requesting
> at-most-one semantics, but the bundle was received without a payload security
> header (as indicated by absence of the authentication option in the
> Data.Indication primitive).

Now I'm confused:-) But if checking for replays is well defined but optional 
that's not nearly as bad!

I guess there'll also need to be some loop detection stuff, just like with
email. Why not use a digest over (content/bundle/whatever) for that and
then you can get replay protection too?

> 5. The use of the three security-related options (confidentiality, integrity,
[...]

Again, what's the point of a bare-digest there? It only allows detection of
accidental changes, deliberate changes only require re-calculation so it may
as well be missing.

> 6. The Send.Request should have additional optional parameters to enable the
[...]

Good. Still missing keyId for confid. though.

> 7. We may want to define a new optional parameter of the Send.Request primitive
> that would be used to indicate to the bundle agent that the application does
> not want to trust the underlying network and therefore that the bundle should
> be protected with a BAH.

Is that like the "security flag"? [RFC3514] Not clear that this is worthwhile.

> 10. In order to enable the Bundle Protocol to simultaneously support reactive
> fragmentation and provide authentication using the BAH, we want to change the
> definition of the bundle authentication header so that the hash in the BAH
> authentication field is computed over the following information: the entire
> bundle, except for the payload field of the Bundle Payload Header (the
> authentication field of the BAH should be zeroed out before the hash is
> calculated), and the endpoint ID of the sender (although the endpoint ID of the
> sender will not necessarily be included in the bundle header, its value should
> be included in the information over which the BAH hash is calculated).  
[...]

Sounds ok. But you need to make sure (I didn't check) that all the inputs
to this hashing are at the front of the bundle so that the BAH can be 
calculated for v. large bundles without having to buffer up loads of
stuff or wait for the entire bundle to have passed. If you don't do
that then the BAH has to be a trailer, sent after everything else has been
transmitted. (Mind you, given that BAH is hop-by-hop I'm confused
about this a bit.)

> 11. The security information field in the PSH should be calculated over the
> entire bundle (not just the payload, as is currently specified). Specifically,
> the hash in the PSH should be calculated over the entire bundle, with: the
> authentication information field of the BAH zeroed out (because it is mutable),
> the security information field of the PSH zeroed out, and the custodian field
> of the Primary Bundle Header zeroed out (because it is mutable).

So long as they don't change en-route that's ok.

> 14. The question arose as to what has a private key. Do applications have keys?
> Do port numbers have keys? Do people have keys? Right now, the way the protocol
> is structured, the value in the source endpoint ID is used as the mechanism to
> determine what public key to use to decrypt the hash value in the Payload
> Security Header. This implies that source endpoint IDs have keys. There is no
> reason that keys need to be associated with only source endpoint IDs, however.
> It was suggested that there should be an optional field in the Payload Security
> Header that has as value the information needed to look up the appropriate key
> needed to decrypt the bundles hash and thereby authenticate the bundle. Having
> this field would decouple the source endpoint ID from the public key
> information and provide more flexibility and greater granularity regarding what
> is able to be authenticated. The appeal of this is that it would enable keys to
> be flexibly associated with whatever entity makes sense for a particular
> application. On the other hand, enabling the source endpoint ID field to both
> denote the source of the bundle and be the information needed in order to look
> up the public key needed to authenticate the bundle as is currently defined
> saves bits in the header, because a single field is able to serve two purposes.
> Adding the optional key lookup field would provide added flexibility and
> granularity of authentication at the cost of the additional bits that would be
> required to include this field in the header.

You need this (or equivalent) for key rollover and other purposes.

> 15. Applications should not be burdened with having to sign hashes. Ideally,
> the hash value in the security information field of the PSH should be signed
> without the application having to do anything special to make this happen. On
> the other hand, in order for the bundle agent to sign the hash, the bundle
> agent would have to be privy to the applications private key. The private keys
> of sources should not be divulged to bundle agents because making bundle agents
> privy to source private keys would make it impossible to distinguish between
> authenticating the source versus authenticating the source bundle agent as the
> originator of the bundle. Private keys must at a minimum be stored in the
> client side of the application/bundle agent API to keep them separate from the
> source bundle agent. Perhaps these private keys can be kept in a library or
> server that is responsible for performing the key signing functionality,
> thereby freeing the application from direct involvement in the process of
> signing each PSH hash.

That contradicts #11 about PSH covering more than payload doesn't it?

--------------070507060305060405010901--

Date: Thu, 18 Nov 2004 00:35:34 -0500
From: "Li, Jiang (Leo)" <[email-masked]>
Organization: Dept of Sys & Comp Sci, Howard University
To: chenbin <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] what are the differences between the DTN protocol and the implemented protocol in JPL's Mars project
Sender: [email-masked]

IMHO, IPN can be thought as a sub-category of DTN. You may want to read
Kevin Fall's paper

"A Delay-Tolerant Network Architecture for Challenged Internets"
http://www.dtnrg.org/papers/IRB-TR-03-003.pdf

Also check other papers on http://www.dtnrg.org/

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

chenbin wrote:
> Hi,
>  
> I am just beginning to concern DTN. But I know JPL has suceeded in 
> communicating with its Mars rover Spirit by IPN.What are the differences 
> between the DTN protocol and the implemented protocol in JPL's Mars project?
>  

From: "Susan F. Symington" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] DTN security
Date: Tue, 16 Nov 2004 10:15:00 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C4CBC5.23DD5480
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0001_01C4CBC5.23E061C0"

------=_NextPart_001_0001_01C4CBC5.23E061C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

All,
 
A few of us got together last week to talk about DTN security. Attached is a
summary of that discussion.
 
-Susan Symington

------=_NextPart_001_0001_01C4CBC5.23E061C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D849331115-16112004>All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D849331115-16112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D849331115-16112004>A few =
of us got=20
together last week to talk about DTN security. Attached is a summary of =
that=20
discussion.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D849331115-16112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D849331115-16112004>-Susan =

Symington</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_001_0001_01C4CBC5.23E061C0--

------=_NextPart_000_0000_01C4CBC5.23DD5480
Content-Type: application/pdf;
	name="security discussion 11-11-2004-summary.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="security discussion 11-11-2004-summary.pdf"

------=_NextPart_000_0000_01C4CBC5.23DD5480--

Date: Wed, 10 Nov 2004 13:47:13 -0500
From: Matthew MacLeod <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Graduate Studies in DTN
Sender: [email-masked]

Hello-

I've just started by M.A.Sc. in Distributed Systems and Computer 
Communication Networks, but for various reasons am looking to transfer 
to a program (preferably Ph.D. level) at another school. I've been 
following the IPN list for some time, but only recently discovered that 
the DTN has subsumed a lot of that work. Are there opportunities for 
graduate research in this field? What Universities are involved in the 
project? From my browsing of the list it seems that Berkeley is doing a 
lot of interesting work, but I'm open to other options.

To give you a quick idea of my background, I have a B. Eng. with High 
Distinction in Communication Engineering, and I completed 5 student work 
terms at Defence R&D Canada, in the Mobile Communications Electronic 
Warfare group. I mentioned my interest in DTN to my former manager, and 
he seemed interested in helping to fund any research I do in that area 
as well. I'm especially interested in protocol development, as well as 
writing real-time/embedded network software to implement those protocols.

Thanks for any advice you can give,

--
Matt MacLeod
Systems and Computer Engineering
Carleton University

Date: Mon, 08 Nov 2004 17:40:34 -0800
From: Melissa Ho <[email-masked]>
To: Esther H Jennings <[email-masked]>
CC: Magnus Lindholm <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] DTN1 vs DTN2
Sender: [email-masked]

DTN1 is currently available on the web site.  DTN2 has no schedule for 
availability.

We will let people know when we have a beta release of DTN2, but if you 
want to start looking at the code now, you are welcome to check it out 
via CVS. Instructions are here:
http://melissa.myensim.net/research/dtn/demo/dtn2.php

DTN2 is a reference implementation - so it implements exactly what is 
described in the architecture and protocol specifications.  In later 
stages, we will add more delay tolerant applications, and have examples 
of support for various convergence layers, but at the moment we do not 
have any functionality specific to space applications. Eventually, 
provided that DTN2 meets requirements in terms of size and space 
limitations, we would hope that people working on space projects would 
develop extensions to DTN2 and make them available to dtn-interest.

Melissa

Esther H Jennings wrote:

>Hello,
>
>Does anyone know (or have any guess) about when DTN1 might be available?
>I understand that DTN2 is under development now.  Is there a "beta" version that I can download and start looking at/trying out the code to get a better understanding of the DTN architecture?  As I understand, there are specialization of DTN for space applications vs. for terrestrial applications.  Does DTN2 contain implementations to support both space and terrestrial applications?
>
>Esther Jennings
>JPL
>
>----- Original Message -----
>From: Melissa Ho <[email-masked]>
>Date: Wednesday, November 3, 2004 4:08 pm
>Subject: Re: [dtn-interest] DTN1 vs DTN2
>
>  
>
>>DTN2 is a new, from-scratch (mostly) reference implementation. 
>>It's not 
>>a branch of  DTN1 - it has a different architecture, is 
>>implemented in a 
>>different language, uses different data structures, and has a 
>>different 
>>application API.
>>
>>DTN1 can be considered to be the "old" reference implementation, 
>>which 
>>is optimized for efficiency of bundle processing and to 
>>demonstrate DTN 
>>in action. However, as such, the learning curve for understanding 
>>the 
>>implementation and extending it was a bit high, since it was 
>>designed 
>>for neither.  DTN2 is meant to address this issue, and make it 
>>easier 
>>for people to adopt DTN as a part of their systems.
>>
>>In Mike Demmer's words, for DTN2 "we attempt to clearly embody the 
>>components of the DTN architecture, provide a platform for 
>>experimentation and extension, and also provide a robust and 
>>flexible 
>>software framework to enable real-world deployment in a range of 
>>application domains." In a nutshell, we want this to be useful for 
>>understanding how DTN works, and we want it to be usable by anyone 
>>that 
>>wants to run DTN.  It will also serve as a base point for 
>>interoperability testing.
>>
>>As a fine point, DTN2 will support the newest bundle protocol and 
>>architecture specs, where DTN1 reflects the architecture and 
>>protocol as 
>>it stood a while ago.
>>
>>The other main difference between DTN1 and DTN2 is that DTN1 is in 
>>a 
>>working state, where DTN2 is still under development, and will 
>>continue 
>>to be for a while.  We will not be able to help you or provide 
>>support 
>>if you choose to use DTN2 before it is released. (Sorry!)
>>
>>Melissa
>>Intel Research Berkeley
>>
>>Magnus Lindholm wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I understand there are two reference implementation of DTN, DTN1 
>>>      
>>>
>>and DTN2. 
>>    
>>
>>>Is DTN2 simply a successor to DTN1 or are they two branches being
>>>developed in parallel?
>>>If so, what are the differences between the two branches, except 
>>>      
>>>
>>that DTN1
>>    
>>
>>>is written in C
>>>and DTN2 in C++?
>>>
>>>Regards
>>>
>>>Magnus Lindholm
>>>
>>>_______________________________________________
>>>dtn-interest mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>    
>>
>
>
>  
>

Date: Mon, 08 Nov 2004 07:37:47 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] What are the differences between the DTN protocol and the implemented protocol in JPL's Mars project?
Sender: [email-masked]

At 12:43 AM 11/8/2004, Chen Bin wrote:

>Hi,
>
>I am just beginning to concern DTN. But I know JPL has suceeded in 
>communicating with its Mars rover Spirit by IPN.
>
>What are the differences between the DTN protocol and the implemented 
>protocol in JPL's Mars project?

Maybe the best way to think of the Mars Exploration Rover communication 
system is as a prototype or proof of concept for delay-tolerant 
networking.  The MER system isn't a fully automated protocol and it's not 
standardized -- I've never seen a formal specification for it -- so it 
really has nothing in common with DTN except some operational 
concepts.  But those concepts are important and the success of MER has 
amply demonstrated their value: store-and-forward relay communications 
through orbiting satellites enabled vastly more data to be returned from 
the rovers to Earth than would have been possible with standard 
direct-to-Earth radio transmission.

Scott

From: =?gb2312?B?s8Kx8w==?= <[email-masked]>
To: [email-masked]
Date: Mon, 8 Nov 2004 16:43:53 +0800
Subject: [dtn-interest] What are the differences between the DTN protocol and the implemented protocol in JPL's Mars project?
Sender: [email-masked]

PGh0bWw+PHByZT48UFJFPkhpLDxCUj48QlI+SSBhbSBqdXN0IGJlZ2lubmluZyB0byBjb25j
ZXJuIERUTi4gQnV0IEkga25vdyBKUEwgaGFzIHN1Y2VlZGVkIGluIGNvbW11bmljYXRpbmcg
d2l0aCBpdHMgTWFycyByb3ZlciBTcGlyaXQgYnkgSVBOLjwvUFJFPjxQUkU+V2hhdCBhcmUg
dGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIERUTiBwcm90b2NvbCBhbmQgdGhlIGltcGxl
bWVudGVkIHByb3RvY29sIGluIEpQTCdzIE1hcnMgcHJvamVjdD88L1BSRT48UFJFPjxCUj48
QlI+QmVzdCByZWdhcmRzLDxCUj48QlI+Q2hlbiBCaW48QlI+PC9QUkU+PC9wcmU+PC9odG1s
Pjxicj48YnI+PGJyPjxicj48YnI+PGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09PGJy
PjI2M7Xn19PTyrz+o63QxcC108rX1Neo0rU=

Date: Mon, 08 Nov 2004 09:52:31 +0800
From: chenbin <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] What are the differences between the DTN protocol and the implemented protocol in JPL's Mars project?
Sender: [email-masked]

Hi,

I am just beginning to concern DTN. But I know JPL has suceeded in communicating with its Mars rover Spirit by IPN.What are the differences between the DTN protocol and the implemented protocol in JPL's Mars project?

Best regards,

Chen Bin

Date: Mon, 08 Nov 2004 09:50:32 +0800
From: chenbin <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] what are the differences between the DTN protocol and the implemented protocol in JPL's Mars project
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_Wb+giJu05Mn7OoRqSlJIig)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi,

I am just beginning to concern DTN. But I know JPL has suceeded in communicating with its Mars rover Spirit by IPN.What are the differences between the DTN protocol and the implemented protocol in JPL's Mars project?

--Boundary_(ID_Wb+giJu05Mn7OoRqSlJIig)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2600.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Hi,</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>I am&nbsp;just beginning&nbsp;to concern DTN. But I know JPL 
has suceeded in communicating with its Mars rover Spirit by IPN.What are the 
differences between the DTN protocol and the implemented protocol in JPL's Mars 
project?</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_Wb+giJu05Mn7OoRqSlJIig)--

Date: Thu, 04 Nov 2004 10:04:14 -0800
From: Esther H Jennings <[email-masked]>
Subject: Re: [dtn-interest] DTN1 vs DTN2
To: Melissa Ho <[email-masked]>
Cc: Magnus Lindholm <[email-masked]>, [email-masked]
Priority: normal
Sender: [email-masked]

Hello,

Does anyone know (or have any guess) about when DTN1 might be available?
I understand that DTN2 is under development now.  Is there a "beta" version that I can download and start looking at/trying out the code to get a better understanding of the DTN architecture?  As I understand, there are specialization of DTN for space applications vs. for terrestrial applications.  Does DTN2 contain implementations to support both space and terrestrial applications?

Esther Jennings
JPL

----- Original Message -----
From: Melissa Ho <[email-masked]>
Date: Wednesday, November 3, 2004 4:08 pm
Subject: Re: [dtn-interest] DTN1 vs DTN2

> DTN2 is a new, from-scratch (mostly) reference implementation. 
> It's not 
> a branch of  DTN1 - it has a different architecture, is 
> implemented in a 
> different language, uses different data structures, and has a 
> different 
> application API.
> 
> DTN1 can be considered to be the "old" reference implementation, 
> which 
> is optimized for efficiency of bundle processing and to 
> demonstrate DTN 
> in action. However, as such, the learning curve for understanding 
> the 
> implementation and extending it was a bit high, since it was 
> designed 
> for neither.  DTN2 is meant to address this issue, and make it 
> easier 
> for people to adopt DTN as a part of their systems.
> 
> In Mike Demmer's words, for DTN2 "we attempt to clearly embody the 
> components of the DTN architecture, provide a platform for 
> experimentation and extension, and also provide a robust and 
> flexible 
> software framework to enable real-world deployment in a range of 
> application domains." In a nutshell, we want this to be useful for 
> understanding how DTN works, and we want it to be usable by anyone 
> that 
> wants to run DTN.  It will also serve as a base point for 
> interoperability testing.
> 
> As a fine point, DTN2 will support the newest bundle protocol and 
> architecture specs, where DTN1 reflects the architecture and 
> protocol as 
> it stood a while ago.
> 
> The other main difference between DTN1 and DTN2 is that DTN1 is in 
> a 
> working state, where DTN2 is still under development, and will 
> continue 
> to be for a while.  We will not be able to help you or provide 
> support 
> if you choose to use DTN2 before it is released. (Sorry!)
> 
> Melissa
> Intel Research Berkeley
> 
> Magnus Lindholm wrote:
> 
> >Hi,
> >
> >I understand there are two reference implementation of DTN, DTN1 
> and DTN2. 
> >Is DTN2 simply a successor to DTN1 or are they two branches being
> >developed in parallel?
> >If so, what are the differences between the two branches, except 
> that DTN1
> >is written in C
> >and DTN2 in C++?
> >
> >Regards
> >
> >Magnus Lindholm
> >
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >
> >  
> >
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Wed, 03 Nov 2004 16:08:32 -0800
From: Melissa Ho <[email-masked]>
To: Magnus Lindholm <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] DTN1 vs DTN2
Sender: [email-masked]

DTN2 is a new, from-scratch (mostly) reference implementation. It's not 
a branch of  DTN1 - it has a different architecture, is implemented in a 
different language, uses different data structures, and has a different 
application API.

DTN1 can be considered to be the "old" reference implementation, which 
is optimized for efficiency of bundle processing and to demonstrate DTN 
in action. However, as such, the learning curve for understanding the 
implementation and extending it was a bit high, since it was designed 
for neither.  DTN2 is meant to address this issue, and make it easier 
for people to adopt DTN as a part of their systems.

In Mike Demmer's words, for DTN2 "we attempt to clearly embody the 
components of the DTN architecture, provide a platform for 
experimentation and extension, and also provide a robust and flexible 
software framework to enable real-world deployment in a range of 
application domains." In a nutshell, we want this to be useful for 
understanding how DTN works, and we want it to be usable by anyone that 
wants to run DTN.  It will also serve as a base point for 
interoperability testing.

As a fine point, DTN2 will support the newest bundle protocol and 
architecture specs, where DTN1 reflects the architecture and protocol as 
it stood a while ago.

The other main difference between DTN1 and DTN2 is that DTN1 is in a 
working state, where DTN2 is still under development, and will continue 
to be for a while.  We will not be able to help you or provide support 
if you choose to use DTN2 before it is released. (Sorry!)

Melissa
Intel Research Berkeley

Magnus Lindholm wrote:

>Hi,
>
>I understand there are two reference implementation of DTN, DTN1 and DTN2. 
>Is DTN2 simply a successor to DTN1 or are they two branches being
>developed in parallel?
>If so, what are the differences between the two branches, except that DTN1
>is written in C
>and DTN2 in C++?
>
>Regards
>
>Magnus Lindholm
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>  
>

Date: Wed, 03 Nov 2004 17:03:14 +0100
To: [email-masked]
From: "Magnus Lindholm" <[email-masked]>
Subject: [dtn-interest] DTN1 vs DTN2
Sender: [email-masked]

Hi,

I understand there are two reference implementation of DTN, DTN1 and DTN2. 
Is DTN2 simply a successor to DTN1 or are they two branches being
developed in parallel?
If so, what are the differences between the two branches, except that DTN1
is written in C
and DTN2 in C++?

Regards

Magnus Lindholm