Subject: Re: [dtn-security] Re(2): Header Encryption
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Peter Lovell <[email-masked]>, Sushil Chaudhari <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 17 Jul 2009 14:22:48 -0500
List-Id: DTN Security Discussion <dtn-security.maillists.intel-research.net>

>>2.Does DTN2 can be used with IPSEC? if not do we need additional
>>convergence layer for the support to IPSEC?
>
>I know of no particular reason it would be a problem but I must admit I
>haven't tried it. I'm sure others have and maybe they'll comment on
>successes or failure.
>
>Regards.....Peter
>
In the NASA internal multi-center testbed, the  IP network bubble at each center are connected via IPsec tunnels.  DTN over IP over IPsec tunnels is run all the time.  IPsec is independent of DTN layer security.

/Will

Date: Fri, 17 Jul 2009 19:06:10 +0000
From: "Sushil Chaudhari" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] Header Encryption

Thank you for the replies. 

But please clearify the following questions:

1. Does IPSec require “gateway” nodes, as bundle-in-bundle encapsulation require?

2. Does IPSec provide bundle data integrity and authenticity validation?

Date: Fri, 17 Jul 2009 18:57:20 +0000
From: "Sushil Chaudhari" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] Header Encryption

Hi,

We are using BSP and while observing bundles on Wireshark, the header seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-security-08, "every bundle must contain a primary block that contains the source and destination EID's that can not be encrypted"

My question is, 
1.Do we have some method for header encryption?
2.Does DTN2 can be used with IPSEC? if not do we need additional convergence layer for the support to IPSEC?

Thanks..

From: Peter Lovell <[email-masked]>
To: Sushil Chaudhari <[email-masked]>, [email-masked]
Date: Fri, 17 Jul 2009 12:20:14 -0400
Subject: [dtn-security] Re(2):  Header Encryption

On Fri, Jul 17, 2009, Sushil Chaudhari <[email-masked]> wrote:

>We are using BSP and while observing bundles on Wireshark, the header
>seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-
>security-08, "every bundle must contain a primary block that contains
>the source and destination EID's that can not be encrypted"
>
>My question is, 
>1.Do we have some method for header encryption?

The nodes need to be able to process the bundle, so you need basic
things like addresses. If it's important to encrypt the headers, about
your only choice is bundle-in-bundle encapsulation. You then encrypt the
encapsulated bundle (PCB). But this new bundle *still* needs a primary
block, and addresses, and the like. 

What goal are you trying to achieve?

>2.Does DTN2 can be used with IPSEC? if not do we need additional
>convergence layer for the support to IPSEC?

I know of no particular reason it would be a problem but I must admit I
haven't tried it. I'm sure others have and maybe they'll comment on
successes or failure.

Regards.....Peter

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Sushil Chaudhari <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 17 Jul 2009 12:56:06 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-security] Header Encryption

DTN header compression can be done similar to IPsec tunnel mode via first doing bundle-in-bundle and then encrypting the internal bundle using PCB of the BSP.  Basically you set a DTNsec tunnel mode.  I haven't done it, but that would be how one would do it.

IPsec if independent of DTN security.  If you want IPsec "for linux" use the tools I pointed to a few days ago.

IPsec Tools which get you SETKEY
The "IP" command on newer builds also has static key configuration capability.

There are a about 4 IKEv2 implementations I am aware of.  My personal preference for what I needed was StrongSwan.

Have fun with security.  Remember - Security is the Ultimate Denial of Service and Security Breaks everything.

If you are trying to learn DTN, my recommendation is do it without security first.

/Will
>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Sushil
>Chaudhari
>Sent: Friday, July 17, 2009 12:02 PM
>To: [email-masked]
>Subject: Re: [dtn-security] Header Encryption
>
>Hi,
>
>We are using BSP and while observing bundles on Wireshark, the header
>seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-security-
>08, "every bundle must contain a primary block that contains the source
>and destination EID's that can not be encrypted"
>
>My question is,
>1.Do we have some method for header encryption?
>2.Does DTN2 can be used with IPSEC? if not do we need additional
>convergence layer for the support to IPSEC?
>
>Thanks..
>_______________________________________________
>dtn-security mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-security

Date: Fri, 17 Jul 2009 16:01:40 +0000
From: "Sushil Chaudhari" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] Header Encryption

Hi,

We are using BSP and while observing bundles on Wireshark, the header seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-security-08, "every bundle must contain a primary block that contains the source and destination EID's that can not be encrypted"

My question is, 
1.Do we have some method for header encryption?
2.Does DTN2 can be used with IPSEC? if not do we need additional convergence layer for the support to IPSEC?

Thanks..

Date: Fri, 17 Jul 2009 15:51:25 +0000
From: "Sushil Chaudhari" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] Header Encryption

Hi,

We are using BSP and while observing bundles on Wireshark, the header seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-security-08, "every bundle must contain a primary block that contains the source and destination EID's that can not be encrypted"

My question is, 
1.Do we have some method for header encryption?
2.Does DTN2 can be used with IPSEC? if not do we need additional convergence layer for the support to IPSEC?

Thanks..

From: Peter Lovell <[email-masked]>
To: Sushil Chaudhari <[email-masked]>, [email-masked]
Date: Thu, 16 Jul 2009 15:04:23 -0400
Subject: [dtn-security] Re(4):  Ciphersuite

On Thu, Jul 16, 2009, Sushil Chaudhari <[email-masked]> wrote:

>Hi,
>
>It looks as PC3 ciphersuite actually implemented for AES GCM mode. If I
>read RFC4106 correctly, it does provide confidentiality, data origin and
>data integrity authentication...
>
>Apparently, it does fulfill the purpose of all 3 security blocks.
>
>Am I read something incorrectly?

Your analysis is a bit to simplistic. PC3 does guarantee that the
payload data (and only the payload data) has not been changed in
transit. But there's no "certificate of authenticity". You do not know
who originated the data.

You know it is unmodified but you don't know if it's genuine.

With PIB you get a signature from the sender so you know, within the
constraints of your keying mechanism, who actually sent the data.

Regards....Peter

Date: Thu, 16 Jul 2009 18:07:55 +0000
From: "Sushil Chaudhari" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-security] Re(2):  Ciphersuite

Hi,

It looks as PC3 ciphersuite actually implemented for AES GCM mode. If I read RFC4106 correctly, it does provide confidentiality, data origin and data integrity authentication…

Apparently, it does fulfill the purpose of all 3 security blocks.

Am I read something incorrectly?

Date: Thu, 16 Jul 2009 10:11:56 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Organization: Leonix Solutions Pte Ltd
To: Peter Lovell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-security] Encrypted IP headers

This is a multi-part message in MIME format.
--------------030706070700010003080008
Content-Type: multipart/alternative;
	boundary="------------080800000701040905030407"

--------------080800000701040905030407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> On Wed, Jul 15, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
> <[email-masked]> wrote:
>
>   
>>>  Most systems have some interaction with the outside even
>>> though the community may be a closed one.
>>>   
>>>       
>> Many military, navy, government, financial systems have a hard 
>> requirement that they do not communicate with the internet (or even with 
>> anything that does). In my case, I can live with that.
>>     
>
> I guess I need to enlarge on the point I was trying to make. 
>   
Thanks again for replying , Peter. I think I grokked all that you said 
and we seem to be in understanding here. I do hope that these 
discussions don't take up too much of your time, but you are an 
invaluable sounding-board.

> A fully-isolated system will be easier to secure but this requires full
> isolation. That is, no networking contact at all with the outside. 
Well, no _intended_ contact with the outside world. It's easy enough to 
achieve no contact with wired networks (ignoring USB sticks, CDs, etc, 
introducing something into the system). But I am talking of a wireless 
network, so I can only say that my intention would be to have no contact 
to the outside world - but I can't stop IP packets floating around on 
the frequency to which my nodes are listening. And that introduces the 
potential for security problems. If possible, I would like to deflect 
these problems as early as possible, and IP header encryption seems a 
reasonable solution.

> Once
> you have that, I'm not sure that encrypting the IP headers etc gives you
> a decent return on your effort.
>
>   
I can't say either way. Will probably have to build it and profile it. 
If I can deflect rogue packets "quickly enough" to prevent DOS, then 
it's worth it. If not, then my IP header encryption only exacerbates the 
problem by adding more overhead.  Hmmm, thinking abut it, it does not 
seem to offer anything for DOS deflection...

what about other security advantages? I am thinking here of TCP/IP, not 
DTN. Are there any TCP/IP exploits which I can defend against with IP 
header encryption? Man in the middle, IP spoofing, etc?

> The challenging situations where dtn is attractive will probably have
> interactions with the outside world, even though there might not be
> "communication" in the sense of exchanging information. If you have a
> portable radio, it has to deal with every packet in order to find the
> ones of interest. So your community might be closed but, at the lowest
> level, you have to listen to everything. And that's where the trouble starts. 
>   
Yes, I see that. So, I am adding overhead there and have to ask if a) it 
is tolerable in absolute timing terms (but routers do this all the time, 
with MAC address filtering)  and b) the overhead brings be security 
gains in TCP/IP. And, coming from the GSM/ UMTS / Satellite world, I 
don't know enough about TCP/IP security, but am trying to get up to 
speed fast.

Thanks, as always, for your insight.

> Regards.....Peter
>
>
>   

-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208

--------------080800000701040905030407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">On Wed, Jul 15, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap=""> Most systems have some interaction with the outside even
though the community may be a closed one.
  
      </pre>
    </blockquote>
    <pre wrap="">Many military, navy, government, financial systems have a hard 
requirement that they do not communicate with the internet (or even with 
anything that does). In my case, I can live with that.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I guess I need to enlarge on the point I was trying to make. 
  </pre>
</blockquote>
Thanks again for replying , Peter. I think I grokked all that you said
and we seem to be in understanding here. I do hope that these
discussions don't take up too much of your time, but you are an
invaluable sounding-board. <br>
<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">
A fully-isolated system will be easier to secure but this requires full
isolation. That is, no networking contact at all with the outside. </pre>
</blockquote>
Well, no _intended_ contact with the outside world. It's easy enough to
achieve no contact with wired networks (ignoring USB sticks, CDs, etc,
introducing something into the system). But I am talking of a wireless
network, so I can only say that my intention would be to have no
contact to the outside world - but I can't stop IP packets floating
around on the frequency to which my nodes are listening. And that
introduces the potential for security problems. If possible, I would
like to deflect these problems as early as possible, and IP header
encryption seems a reasonable solution. <br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Once
you have that, I'm not sure that encrypting the IP headers etc gives you
a decent return on your effort.

  </pre>
</blockquote>
I can't say either way. Will probably have to build it and profile it.
If I can deflect rogue packets "quickly enough" to prevent DOS, then
it's worth it. If not, then my IP header encryption only exacerbates
the problem by adding more overhead.&nbsp; Hmmm, thinking abut it, it does
not seem to offer anything for DOS deflection... <br>
<br>
what about other security advantages? I am thinking here of TCP/IP, not
DTN. Are there any TCP/IP exploits which I can defend against with IP
header encryption? Man in the middle, IP spoofing, etc?<br>
<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">The challenging situations where dtn is attractive will probably have
interactions with the outside world, even though there might not be
"communication" in the sense of exchanging information. If you have a
portable radio, it has to deal with every packet in order to find the
ones of interest. So your community might be closed but, at the lowest
level, you have to listen to everything. And that's where the trouble starts. 
  </pre>
</blockquote>
Yes, I see that. So, I am adding overhead there and have to ask if a)
it is tolerable in absolute timing terms (but routers do this all the
time, with MAC address filtering)&nbsp; and b) the overhead brings be
security gains in TCP/IP. And, coming from the GSM/ UMTS / Satellite
world, I don't know enough about TCP/IP security, but am trying to get
up to speed fast. <br>
<br>
Thanks, as always, for your insight.<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">
Regards.....Peter

  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="80">-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208
</pre>
</body>
</html>

--------------080800000701040905030407--

--------------030706070700010003080008
Content-Type: text/x-vcard; charset=utf-8;
 name="Graham.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Graham.vcf"

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet:[email-masked]
title:Technical director
tel;work:+65 6316 9968
tel;fax:+65 6316 9208
tel;cell:+65 9725 7353
x-mozilla-html:FALSE
url:http://leonixsolutions.com/
version:2.1
end:vcard

--------------030706070700010003080008--

From: Peter Lovell <[email-masked]>
To: Sushil Chaudhari <[email-masked]>, [email-masked]
Date: Wed, 15 Jul 2009 18:21:15 -0400
Subject: [dtn-security] Re(2):  Ciphersuite

On Wed, Jul 15, 2009, Sushil Chaudhari <[email-masked]> wrote:

>As mentioned in the draft-irtf-dtnrg-bundle-security-08 :
>The BAB ciphersuite is based on shared secret using HMAC.
>The PIB is based on digital signatures using RSA with SHA 256.
>the PCB and ESB are based on RSA with AES.
>
>My question is, do we have (or can we implement) any common ciphersuite
>for all of the security blocks?

Well, there's no common ciiphersuite because they serve different
purposes. PCB encrypts the data, for example, while PIB allows you to
verify it hasn't been altered but does not make it secret.

What are you trying to achieve?

Regards.....Peter

Date: Wed, 15 Jul 2009 21:49:39 +0000
From: "Sushil Chaudhari" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] Ciphersuite

Hi,

As mentioned in the draft-irtf-dtnrg-bundle-security-08 :
The BAB ciphersuite is based on shared secret using HMAC.
The PIB is based on digital signatures using RSA with SHA 256.
the PCB and ESB are based on RSA with AES.

My question is, do we have (or can we implement) any common ciphersuite for all of the security blocks?

Thanks

From: Peter Lovell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, Sushil Chaudhari <[email-masked]>, [email-masked]
Date: Wed, 15 Jul 2009 11:41:25 -0400
Subject: [dtn-security] Re(2):  Key generation

Hi Will,

in this case, "setkey" is part of a small command set that's included in
DTN2 RI.

It doesn't support ciphersuites other than BA1 though.

Your suggestion to use openssl for key creation is good -- I recommend it too.

Regards.....Peter

On Wed, Jul 15, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>SETKEY is for IPsec and comes from IPsec tools.  So, SETKEY is for IP
>not DTN. But the concepts apply.
>
>Openssl is what you want.  Openssl can create all types of keys and
>certificates.
>
>For a quick tutorial on setting up a test Certificate Authority and
>associated keys, I recommend the Strongswan configuration guide. 
>Someone put a lot of time and money into Strongswan as the documentation
>is very good - better than most commercial system IMHO.  I read this
>first then look at the appropriate Openssl man pages below, then run
>through the sample here.  After that, you should have a decent idea on
>what you may want to do with Openssl and certificates.
>http://www.strongswan.org/docs/readme42.htm#section_3
>
>
>Use Openssl to create keys.  Having used Openssl, I found the books
>rather limiting.  You may want to  go online and use the manuals as
>there are lots of hyperlinks.
>http://www.openssl.org/docs/apps/openssl.html
>
>
>/Will
>
>
>>-----Original Message-----
>>From: [email-masked] [mailto:dtn-
>>[email-masked]] On Behalf Of Sushil
>>Chaudhari
>>Sent: Tuesday, July 14, 2009 5:06 PM
>>To: [email-masked]
>>Subject: Re: [dtn-security] Key generation
>>
>>Hi,
>>
>>There's setkey <host> <siphersuite> <key> command used to set the key
>>for the specified host and ciphersuite.
>>
>>What utility is used to produce the key?
>>
>>If security policy is set to use "confidentiality block" and no external
>>key is provided, how's the key get generated by DTN2?
>>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Sushil Chaudhari <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 15 Jul 2009 07:27:08 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-security] Key generation

SETKEY is for IPsec and comes from IPsec tools.  So, SETKEY is for IP not DTN. But the concepts apply.

Openssl is what you want.  Openssl can create all types of keys and certificates.

For a quick tutorial on setting up a test Certificate Authority and associated keys, I recommend the Strongswan configuration guide.  Someone put a lot of time and money into Strongswan as the documentation is very good - better than most commercial system IMHO.  I read this first then look at the appropriate Openssl man pages below, then run through the sample here.  After that, you should have a decent idea on what you may want to do with Openssl and certificates.
http://www.strongswan.org/docs/readme42.htm#section_3

Use Openssl to create keys.  Having used Openssl, I found the books rather limiting.  You may want to  go online and use the manuals as there are lots of hyperlinks.
http://www.openssl.org/docs/apps/openssl.html

/Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Sushil
>Chaudhari
>Sent: Tuesday, July 14, 2009 5:06 PM
>To: [email-masked]
>Subject: Re: [dtn-security] Key generation
>
>Hi,
>
>There’s setkey <host> <siphersuite> <key> command used to set the key
>for the specified host and ciphersuite.
>
>What utility is used to produce the key?
>
>If security policy is set to use “confidentiality block” and no external
>key is provided, how’s the key get generated by DTN2?
>
>Thnks.
>_______________________________________________
>dtn-security mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-security

From: Peter Lovell <[email-masked]>
To: Sushil Chaudhari <[email-masked]>, [email-masked]
Date: Wed, 15 Jul 2009 08:21:37 -0400
Subject: [dtn-security] Re(2):  Key generation

On Tue, Jul 14, 2009, Sushil Chaudhari <[email-masked]> wrote:

>Hi,
>
>There's setkey <host> <siphersuite> <key> command used to set the key
>for the specified host and ciphersuite.
>
>What utility is used to produce the key?
>
>If security policy is set to use "confidentiality block" and no external
>key is provided, how's the key get generated by DTN2?
>

Hi Sushil,

this is used only by the BA1 ciphersuite. For other ciphersuites you
need to manage the keys (typically RSA public/private key pairs) using
the KeySteward class. There is no command-set to support those at present.

Regards.....Peter

From: Peter Lovell <[email-masked]>
To: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Date: Wed, 15 Jul 2009 07:49:03 -0400
Cc: [email-masked]
Subject: [dtn-security] Re(2):  Encrypted IP headers

On Wed, Jul 15, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<[email-masked]> wrote:

>>  Most systems have some interaction with the outside even
>> though the community may be a closed one.
>>   
>Many military, navy, government, financial systems have a hard 
>requirement that they do not communicate with the internet (or even with 
>anything that does). In my case, I can live with that.

I guess I need to enlarge on the point I was trying to make. 

A fully-isolated system will be easier to secure but this requires full
isolation. That is, no networking contact at all with the outside. Once
you have that, I'm not sure that encrypting the IP headers etc gives you
a decent return on your effort.

The challenging situations where dtn is attractive will probably have
interactions with the outside world, even though there might not be
"communication" in the sense of exchanging information. If you have a
portable radio, it has to deal with every packet in order to find the
ones of interest. So your community might be closed but, at the lowest
level, you have to listen to everything. And that's where the trouble starts. 

Regards.....Peter

Date: Wed, 15 Jul 2009 11:03:31 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Organization: Leonix Solutions Pte Ltd
To: Peter Lovell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-security] Encrypted IP headers

This is a multi-part message in MIME format.
--------------030900030109090604070404
Content-Type: multipart/alternative;
	boundary="------------060202050300050706050304"

--------------060202050300050706050304
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> On Mon, Jul 13, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
> <[email-masked]> wrote:
>
>   
>> What about this then - is it even feasible? If I know that I have a 
>> closed universe of nodes, can I encrypt the IP headers? That might help 
>> prevent  DOS by repeated pinging.   <snip>
>>
>> Am I on a totally wrong track here? Or could encrypted IP headers be one 
>> more layer of armour?
>>
>>     
>
> I guess this could work for an isolated system, but those are of limited
> interest.
of limited interest ... or extremely secure ;-)

>  Most systems have some interaction with the outside even
> though the community may be a closed one.
>   
Many military, navy, government, financial systems have a hard 
requirement that they do not communicate with the internet (or even with 
anything that does). In my case, I can live with that.

What if you effectively have two devices in one? Say you do your IP 
header en/de-cryption at driver level? Encrypt wifi and not BlueTooth? 
In my case, I can also live with that.

> When faced with a DOS attack, the challenge is to get rid of as many
> packets as possible with the absolute least effort. the question is --
> would encrypting the IP headers help or hinder this ??
>   
An excellent point and a very good question (drat!). Let me think it 
through. At first glance, it seems to add more processing, especially at 
a time-critical low-level. You _might_ save time at higher levels by 
doing so, but the bottle-neck is at the interrupt-handlers/drivers, 
trying to triage the IP packets at the earliest opportunity. I have seen 
devices do this - they are effectively routers. To answer that question, 
I guess I would have to "suck it and see" - code it up and profile it.

Unless anyone else has experience, or even a gut feeling?

Thanks, as always, Peter, for the provocation to thought.
> Regards.....Peter
>
>
>   

-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208

--------------060202050300050706050304
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=US-ASCII" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">On Mon, Jul 13, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">What about this then - is it even feasible? If I know that I have a 
closed universe of nodes, can I encrypt the IP headers? That might help 
prevent  DOS by repeated pinging.   &lt;snip&gt;

Am I on a totally wrong track here? Or could encrypted IP headers be one 
more layer of armour?

    </pre>
  </blockquote>
  <pre wrap=""><!---->
I guess this could work for an isolated system, but those are of limited
interest.</pre>
</blockquote>
of limited interest ... or extremely secure ;-) <br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap=""> Most systems have some interaction with the outside even
though the community may be a closed one.
  </pre>
</blockquote>
Many military, navy, government, financial systems have a hard
requirement that they do not communicate with the internet (or even
with anything that does).&nbsp; In my case, I can live with that.<br>
<br>
What if you effectively have two devices in one? Say you do your IP
header en/de-cryption at driver level? Encrypt wifi and not BlueTooth?&nbsp;
In my case, I can also live with that.<br>
<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">
When faced with a DOS attack, the challenge is to get rid of as many
packets as possible with the absolute least effort. the question is --
would encrypting the IP headers help or hinder this ??
  </pre>
</blockquote>
An excellent point and a very good question&nbsp; (drat!). Let me think it
through. At first glance, it seems to add more processing, especially
at a time-critical low-level. You _might_ save time at higher levels by
doing so, but the bottle-neck is at the interrupt-handlers/drivers,
trying to triage the IP packets at the earliest opportunity. I have
seen devices do this - they are effectively routers. To answer that
question, I guess I would have to "suck it and see" - code it up and
profile it. <br>
<br>
Unless anyone else has experience, or even a gut feeling?<br>
<br>
Thanks, as always, Peter, for the provocation to thought.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">
Regards.....Peter

  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="80">-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208
</pre>
</body>
</html>

--------------060202050300050706050304--

--------------030900030109090604070404
Content-Type: text/x-vcard; charset=utf-8;
 name="Graham.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Graham.vcf"

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet:[email-masked]
title:Technical director
tel;work:+65 6316 9968
tel;fax:+65 6316 9208
tel;cell:+65 9725 7353
x-mozilla-html:FALSE
url:http://leonixsolutions.com/
version:2.1
end:vcard

--------------030900030109090604070404--

Date: Tue, 14 Jul 2009 21:05:39 +0000
From: "Sushil Chaudhari" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] Key generation

Hi,

There’s setkey <host> <siphersuite> <key> command used to set the key for the specified host and ciphersuite.

What utility is used to produce the key?

If security policy is set to use “confidentiality block” and no external key is provided, how’s the key get generated by DTN2?

Thnks.

From: Peter Lovell <[email-masked]>
To: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Date: Mon, 13 Jul 2009 09:46:02 -0400
Cc: [email-masked]
Subject: [dtn-security] Re(2): Re(2): How do you feel about Bonjour/Avahi?

On Mon, Jul 13, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<[email-masked]> wrote:

>What about this then - is it even feasible? If I know that I have a 
>closed universe of nodes, can I encrypt the IP headers? That might help 
>prevent  DOS by repeated pinging.   <snip>
>
>Am I on a totally wrong track here? Or could encrypted IP headers be one 
>more layer of armour?
>

I guess this could work for an isolated system, but those are of limited
interest. Most systems have some interaction with the outside even
though the community may be a closed one.

When faced with a DOS attack, the challenge is to get rid of as many
packets as possible with the absolute least effort. the question is --
would encrypting the IP headers help or hinder this ??

Regards.....Peter

Date: Mon, 13 Jul 2009 11:21:32 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Organization: Leonix Solutions Pte Ltd
To: Peter Lovell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-security] Re(2):  How do you feel about Bonjour/Avahi?

This is a multi-part message in MIME format.
--------------030806060009040706060507
Content-Type: multipart/alternative;
	boundary="------------020008060004090908010308"

--------------020008060004090908010308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> [snip]
>
>   
>>> Bonjour is just a service discovery protocol, not a part of a security
>>> system. And it's localized so that only your neighbours know. It
>>> shouldn't make any difference to integrity or confidentiality as those
>>> should be handled by the defenses you have deployed. At a stretch, it
>>> might make adversaries aware of your system but if they see Bonjour
>>> advertisements then they're close to you already and can see your
>>> network traffic.
>>>   
>>>       
>> An excellent point, and one which worries me. How does "standard" 
>> security which is not int he DTN part of the system affect the overall 
>> system of which DTN is only a part?
>>     
>
> I'm not sure I understand your point here. DTN sits on top of various
> transport mechanisms (referred to as "convergence layers" in the specs)
> and these may have their own security mechanisms. These are in addition
> to the dtn ones that only are invoked after coming through the lower
> layers. As an example, if you are using TCP convergence layer, I would
> expect that to defend against common TCP DOS attacks, such as syn-flood.
> DTN doesn't have to deal with those.
>
>   
A point well made. It's not (currently) part of my remit to be concerned 
about TCP/IP, WEP/WPA, et al. But it surely needs to be considered in my 
system and I don't see who else will do it. Oh, well, that's why ssytems 
have v2.0 :-)

>   
>>> Bonjour and static IP addresses are solutions to different problems. An
>>> IP address allows a system to send something to you. Bonjour allows a
>>> nearby system to find you if it doesn't know your address.
>>>   
>>>       
>> In my idea of a "closed, secure" system, if someone does not know my IP 
>> address, then I don't even want him to know that I exist (al least, I 
>> think so ... )
>>     
>
> You might indeed want him not to know, and it might be good to keep as
> low a profile as possible. But in most cases (not all) I wouldn't
> categorize that as real "security". It's like having secret crypto algorithms.
>   
A very good point. Secret crypto is generally snake-oil and certainly 
not widely peer-reviewed.

> Can it be one part of a layered defense? Certainly. Do I place much
> reliance on it? No, with occasional exceptions. 
>
>   
What about this then - is it even feasible? If I know that I have a 
closed universe of nodes, can I encrypt the IP headers? That might help 
prevent  DOS by repeated pinging. Of course, there are only a limited 
number of public IP addresses, which could be quickly and easily tried, 
but it throws up one more roadblock. Or I could use "real" IP addresses 
- maybe IPv6 9after carefully reading 
http://www.seanconvery.com/ipv6.html) ...

Am I on a totally wrong track here? Or could encrypted IP headers be one 
more layer of armour?

>>> If you are sensitive about denial-of-service attacks then I would
>>> suggest strongly that you do not use a hard-coded IP address, but
>>> specify a dns address instead.
>>>
>>>   
>>>       
>> And that gets resolved to an IP address how? If I have an ad-hoc 
>> network, I don't want to have a DNS server.
>>     
>
> The non-Bonjour scenario uses a standard dns server -- nothing strange
> there. Bonjour works in a standard local network (think of a small
> office with DHCP, internet connectivity and with or without a dns server
> for the local machines) or purely ad-hoc. In the ad-hoc case, the
> machines self-assign link-local IP addresses in the range
> 169.254.0.0/16. Discovery is done using multicast-dns. The machines
> respond directly and there is no server involved.
>
>   
Thanks for clarifying. Looks like I need to re-read TCP/IP/DNS for Dummies.

> Cheers.....Peter
>
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-security
>
>   

-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208

--------------020008060004090908010308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">[snip]
  <pre wrap="">

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Bonjour is just a service discovery protocol, not a part of a security
system. And it's localized so that only your neighbours know. It
shouldn't make any difference to integrity or confidentiality as those
should be handled by the defenses you have deployed. At a stretch, it
might make adversaries aware of your system but if they see Bonjour
advertisements then they're close to you already and can see your
network traffic.
  
      </pre>
    </blockquote>
    <pre wrap="">An excellent point, and one which worries me. How does "standard" 
security which is not int he DTN part of the system affect the overall 
system of which DTN is only a part?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I'm not sure I understand your point here. DTN sits on top of various
transport mechanisms (referred to as "convergence layers" in the specs)
and these may have their own security mechanisms. These are in addition
to the dtn ones that only are invoked after coming through the lower
layers. As an example, if you are using TCP convergence layer, I would
expect that to defend against common TCP DOS attacks, such as syn-flood.
DTN doesn't have to deal with those.

  </pre>
</blockquote>
A point well made. It's not (currently) part of my remit to be
concerned about TCP/IP, WEP/WPA, et al. But it surely needs to be
considered in my system and I don't see who else will do it. Oh, well,
that's why ssytems have v2.0 :-)<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Bonjour and static IP addresses are solutions to different problems. An
IP address allows a system to send something to you. Bonjour allows a
nearby system to find you if it doesn't know your address.
  
      </pre>
    </blockquote>
    <pre wrap="">In my idea of a "closed, secure" system, if someone does not know my IP 
address, then I don't even want him to know that I exist (al least, I 
think so ... )
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You might indeed want him not to know, and it might be good to keep as
low a profile as possible. But in most cases (not all) I wouldn't
categorize that as real "security". It's like having secret crypto algorithms.
  </pre>
</blockquote>
A very good point. Secret crypto is generally snake-oil and certainly
not widely peer-reviewed.<br>
<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">
Can it be one part of a layered defense? Certainly. Do I place much
reliance on it? No, with occasional exceptions. 

  </pre>
</blockquote>
What about this then - is it even feasible? If I know that I have a
closed universe of nodes, can I encrypt the IP headers? That might help
prevent&nbsp; DOS by repeated pinging. Of course, there are only a limited
number of public IP addresses, which could be quickly and easily tried,
but it throws up one more roadblock. Or I could use "real" IP addresses
- maybe IPv6 9after carefully reading
<a class="moz-txt-link-freetext" href="http://www.seanconvery.com/ipv6.html">http://www.seanconvery.com/ipv6.html</a>) ... <br>
<br>
Am I on a totally wrong track here? Or could encrypted IP headers be
one more layer of armour?<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">If you are sensitive about denial-of-service attacks then I would
suggest strongly that you do not use a hard-coded IP address, but
specify a dns address instead.

      </pre>
    </blockquote>
    <pre wrap="">And that gets resolved to an IP address how? If I have an ad-hoc 
network, I don't want to have a DNS server.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The non-Bonjour scenario uses a standard dns server -- nothing strange
there. Bonjour works in a standard local network (think of a small
office with DHCP, internet connectivity and with or without a dns server
for the local machines) or purely ad-hoc. In the ad-hoc case, the
machines self-assign link-local IP addresses in the range
169.254.0.0/16. Discovery is done using multicast-dns. The machines
respond directly and there is no server involved.

  </pre>
</blockquote>
Thanks for clarifying. Looks like I need to re-read TCP/IP/DNS for
Dummies.<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Cheers.....Peter

_______________________________________________
dtn-security mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-security">http://maillists.intel-research.net/mailman/listinfo/dtn-security</a>

  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="80">-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208
</pre>
</body>
</html>

--------------020008060004090908010308--

--------------030806060009040706060507
Content-Type: text/x-vcard; charset=utf-8;
 name="Graham.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Graham.vcf"

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet:[email-masked]
title:Technical director
tel;work:+65 6316 9968
tel;fax:+65 6316 9208
tel;cell:+65 9725 7353
x-mozilla-html:FALSE
url:http://leonixsolutions.com/
version:2.1
end:vcard

--------------030806060009040706060507--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Peter Lovell <[email-masked]>, "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Date: Fri, 10 Jul 2009 07:57:37 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-security] Re(2): Re(2): Re(2): Is there a "secure" reference implementation of the DTN stack?

There appear to be so many ways to put security together with bundles that interoperability will be interesting.

Pictures would help greatly, but internet drafts and pictures as complex as those needed to show what parts of bundles are included in the crypto algorithms and what parts might change and are therefore not include are too complex for Ascii art.

If someone had some funding to provide to a student or entry level engineer, perhaps they could create such diagrams and put them on the DTNRG wiki (once blessed).

/Will

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Peter Lovell
>Sent: Friday, July 10, 2009 7:35 AM
>To: Graham Keellings (Leonix Solutions Pte Ltd)
>Cc: [email-masked]
>Subject: [dtn-security] Re(2): Re(2): Re(2): Is there a "secure"
>reference implementation of the DTN stack?
>
>On Fri, Jul 10, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
><[email-masked]> wrote:
>
>>Peter Lovell wrote:
>>> Hi Graham,
>>>
>>> the best document at this time is the Bundle Security Protocol
>>> Specification, available at <http://tools.ietf.org/id/draft-irtf-
>dtnrg-
>>> bundle-security-08.txt>
>>>
>>wow, that did take some reading (and I doubt that I truly understood
>>half of it ;-)
>>
>>Is there no similar document which covers the whole system, describing
>>security measures at each layer, or each stage of the transaction?
>>
>
>
>Hi Graham,
>
>at the moment that is as good as it gets.
>
>Maybe I should write a "BSP for Dummies" book (I assume that you're
>familiar with that series)  :)
>
>Cheers.....Peter
>
>_______________________________________________
>dtn-security mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-security

From: Peter Lovell <[email-masked]>
To: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Date: Fri, 10 Jul 2009 07:35:09 -0400
Cc: [email-masked]
Subject: [dtn-security] Re(2): Re(2): Re(2): Is there a "secure" reference implementation of the DTN stack?

On Fri, Jul 10, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<[email-masked]> wrote:

>Peter Lovell wrote:
>> Hi Graham,
>>
>> the best document at this time is the Bundle Security Protocol
>> Specification, available at <http://tools.ietf.org/id/draft-irtf-dtnrg-
>> bundle-security-08.txt>
>>   
>wow, that did take some reading (and I doubt that I truly understood 
>half of it ;-)
>
>Is there no similar document which covers the whole system, describing 
>security measures at each layer, or each stage of the transaction?
>

Hi Graham,

at the moment that is as good as it gets.

Maybe I should write a "BSP for Dummies" book (I assume that you're
familiar with that series)  :)

Cheers.....Peter

From: Peter Lovell <[email-masked]>
To: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Date: Fri, 10 Jul 2009 08:09:58 -0400
Cc: [email-masked]
Subject: [dtn-security] Re(2):  How do you feel about Bonjour/Avahi?

>> If I'm part of law enforcement, I'll probably value confidentiality most
>> highly (although the courts may emphasize integrity and chain-of-custody
>> for evidence).
>>
>>   
>And military? I would imagine that since lives are at stake that might 
>be the defining peak of the pyramid...

Maybe, but let's not take the discussion in that direction.

>> Bonjour is just a service discovery protocol, not a part of a security
>> system. And it's localized so that only your neighbours know. It
>> shouldn't make any difference to integrity or confidentiality as those
>> should be handled by the defenses you have deployed. At a stretch, it
>> might make adversaries aware of your system but if they see Bonjour
>> advertisements then they're close to you already and can see your
>> network traffic.
>>   
>An excellent point, and one which worries me. How does "standard" 
>security which is not int he DTN part of the system affect the overall 
>system of which DTN is only a part?

I'm not sure I understand your point here. DTN sits on top of various
transport mechanisms (referred to as "convergence layers" in the specs)
and these may have their own security mechanisms. These are in addition
to the dtn ones that only are invoked after coming through the lower
layers. As an example, if you are using TCP convergence layer, I would
expect that to defend against common TCP DOS attacks, such as syn-flood.
DTN doesn't have to deal with those.

>> Bonjour and static IP addresses are solutions to different problems. An
>> IP address allows a system to send something to you. Bonjour allows a
>> nearby system to find you if it doesn't know your address.
>>   
>In my idea of a "closed, secure" system, if someone does not know my IP 
>address, then I don't even want him to know that I exist (al least, I 
>think so ... )

You might indeed want him not to know, and it might be good to keep as
low a profile as possible. But in most cases (not all) I wouldn't
categorize that as real "security". It's like having secret crypto algorithms.

Can it be one part of a layered defense? Certainly. Do I place much
reliance on it? No, with occasional exceptions. 

>> If you are sensitive about denial-of-service attacks then I would
>> suggest strongly that you do not use a hard-coded IP address, but
>> specify a dns address instead.
>>
>>   
>And that gets resolved to an IP address how? If I have an ad-hoc 
>network, I don't want to have a DNS server.

The non-Bonjour scenario uses a standard dns server -- nothing strange
there. Bonjour works in a standard local network (think of a small
office with DHCP, internet connectivity and with or without a dns server
for the local machines) or purely ad-hoc. In the ad-hoc case, the
machines self-assign link-local IP addresses in the range
169.254.0.0/16. Discovery is done using multicast-dns. The machines
respond directly and there is no server involved.

Cheers.....Peter

Date: Fri, 10 Jul 2009 14:47:01 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Organization: Leonix Solutions Pte Ltd
To: Kamal Srinivasan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-security] How do you feel about Bonjour/Avahi?

This is a multi-part message in MIME format.
--------------060402000400060801090208
Content-Type: multipart/alternative;
	boundary="------------050605080803030808050207"

--------------050605080803030808050207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kamal Srinivasan wrote:
> Graham,
> Our research group @ Univ. of Wisconsin have been working on Anonymous
> communication and Key Management in DTN.
>   
There is a whole Venn-digram of terminology overlap here. Althogu I 
mention DTN, ad-hoc is also a defining phrase for me - which means that 
I can't have a dedicated node as a DNS or key server, since talking out 
hat node makes my network useless.

> Short ans: Our perspective is...it boils down as to how paranoid the app.
> developer over DTN is with security.  
As paranoid as possible, in my case - military grade or more - but of 
course there is a trade-off in terms of time & resources needed to add 
this security

> This really drives where the ACL policies reside in the stack.
>
>   
All over, I think ...

> A not so short ans:
>
> In DTNs, if the connectivity is sparse enough you want to exploit as many
> opportunities as you could. 
That seems to imply an open and trusting network, whereas I am thinking 
of a closed and mistrusting one.

> In such scenarios it would benefit from blaring
> out than hard coding and relying on meeting the hard coded IP devices.  This
> becomes a serious concern when you have unplanned mobility scenarios, where
> you know lesser about the network. So it really depends on what class of DTN
> you are looking into.
>   
"Secure" whatever that means - enough to satisfy banking, the military, 
etc - closed and suspicious, if not paranoid.  But I think we are 
missing an overall discussion of this sort f thing - maybe even just a 
table - showing the trade off between how much security you want and 
what it will cost you.

> If you were to blare out and have approp. policies in place at the BP layer,
> that can be controlled by the app. then you could blare out and still be
> secure. Even if you were not to broadcast, many underlying comm. methods
> would in common scenarios (for ex. in 802.11).
But there are many layers of worry - even bog-standard DOS attacks could 
give grief to my network.

>  We tried to develop an
> anonymous communication sub-layer on top of the sensor nodes (motes), but
> the underlying layers were revealing enough entropy of information.
>
> The above two observations, led us to think of designs that would let the
> user control broadcast, but enable such comm. if the developer thinks it
> would benefit for them to use such blaring for their app.
>
> thanks,
> kamal
>   
Thanks _very_ much for taking the time to send such a long and well 
formulated answer.

/graham

>
> On Wed, Jul 8, 2009 at 10:13 PM, Graham Keellings (Leonix Solutions Pte Ltd)
> <[email-masked]> wrote:
>
>   
>> From a security standpoint?
>>
>> How secure is it to have all of my nodes blaring "here I am, bad guys, come
>> and try to connect to me"?
>>
>> Would I be safer just using hard coded IP address?
>>
>> Thanks in advance for any opinions.
>>
>> ~graham();
>>
>> _______________________________________________
>> dtn-security mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-security
>>
>>
>>     
>
>   

-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208

--------------050605080803030808050207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kamal Srinivasan wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Graham,
Our research group @ Univ. of Wisconsin have been working on Anonymous
communication and Key Management in DTN.
  </pre>
</blockquote>
There is a whole Venn-digram of terminology overlap here. Althogu I
mention DTN, ad-hoc is also a defining phrase for me - which means that
I can't have a dedicated node as a DNS or key server, since talking out
hat node makes my network useless. <br>
<br>
<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">
Short ans: Our perspective is...it boils down as to how paranoid the app.
developer over DTN is with security.  </pre>
</blockquote>
As paranoid as possible, in my case - military grade or more - but of
course there is a trade-off in terms of time &amp; resources needed to
add this security <br>
<br>
<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">This really drives where the ACL policies reside in the stack.

  </pre>
</blockquote>
All over, I think ... <br>
<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">A not so short ans:

In DTNs, if the connectivity is sparse enough you want to exploit as many
opportunities as you could. </pre>
</blockquote>
That seems to imply an open and trusting network, whereas I am thinking
of a closed and mistrusting one. <br>
<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">In such scenarios it would benefit from blaring
out than hard coding and relying on meeting the hard coded IP devices.  This
becomes a serious concern when you have unplanned mobility scenarios, where
you know lesser about the network. So it really depends on what class of DTN
you are looking into.
  </pre>
</blockquote>
"Secure" whatever that means - enough to satisfy banking, the military,
etc - closed and suspicious, if not paranoid.&nbsp; But I think we are
missing an overall discussion of this sort f thing - maybe even just a
table - showing the trade off between how much security you want and
what it will cost you. <br>
<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">
If you were to blare out and have approp. policies in place at the BP layer,
that can be controlled by the app. then you could blare out and still be
secure. Even if you were not to broadcast, many underlying comm. methods
would in common scenarios (for ex. in 802.11).</pre>
</blockquote>
But there are many layers of worry - even bog-standard DOS attacks
could give grief to my network. <br>
<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap=""> We tried to develop an
anonymous communication sub-layer on top of the sensor nodes (motes), but
the underlying layers were revealing enough entropy of information.

The above two observations, led us to think of designs that would let the
user control broadcast, but enable such comm. if the developer thinks it
would benefit for them to use such blaring for their app.

thanks,
kamal
  </pre>
</blockquote>
Thanks _very_ much for taking the time to send such a long and well
formulated answer.<br>
<br>
/graham <br>
<br>
<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">

On Wed, Jul 8, 2009 at 10:13 PM, Graham Keellings (Leonix Solutions Pte Ltd)
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">From a security standpoint?

How secure is it to have all of my nodes blaring "here I am, bad guys, come
and try to connect to me"?

Would I be safer just using hard coded IP address?

Thanks in advance for any opinions.

~graham();

_______________________________________________
dtn-security mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-security">http://maillists.intel-research.net/mailman/listinfo/dtn-security</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="80">-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208
</pre>
</body>
</html>

--------------050605080803030808050207--

--------------060402000400060801090208
Content-Type: text/x-vcard; charset=utf-8;
 name="Graham.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Graham.vcf"

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet:[email-masked]
title:Technical director
tel;work:+65 6316 9968
tel;fax:+65 6316 9208
tel;cell:+65 9725 7353
x-mozilla-html:FALSE
url:http://leonixsolutions.com/
version:2.1
end:vcard

--------------060402000400060801090208--

Date: Fri, 10 Jul 2009 14:38:02 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Organization: Leonix Solutions Pte Ltd
To: Peter Lovell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-security] How do you feel about Bonjour/Avahi?

This is a multi-part message in MIME format.
--------------080700040705050006030208
Content-Type: multipart/alternative;
	boundary="------------000405030703060609050206"

--------------000405030703060609050206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> On Thu, Jul 9, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
> <[email-masked]> wrote:
>
>   
>> From a security standpoint?
>>
>> How secure is it to have all of my nodes blaring "here I am, bad guys,
>> come and try to connect to me"?
>>
>> Would I be safer just using hard coded IP address?
>>
>> Thanks in advance for any opinions.
>>
>> ~graham();
>>     
>
>
> Hi Graham,
>
> it depends.
>
> Mostly it depends upon the definition you have in mind for "security".
>
> In typical discussions, security encompasses integrity, confidentiality
> and availability. Various organizations will prioritize those differently.
>
>   
Thanks very much for the swift reply, Peter. It came within ten minutes 
and I am a day late in replying :-/

I am glad that you mention "availability", because some people with whom 
I discuss the subject seem fixated on cryptography. As you mention 
later, we might  decline to use Bonjour, but are still broadcasting our 
presence. That leaves each node open to conventional DOS attacks, but 
some people seem to see that as not a part of DTN, just some standard 
let someone else take care of it, IP" issue.

> Many commercial transactions will place integrity uppermost, although
> those containing sensitive personally-identifying data may have
> confidentiality above all. Thinking about a personal stock trade account
> as an example - my purchase instruction for a thousand shares of some
> company is not very secret but the brokerage really does want to know
> that it is accurate and came from me.
>
> If I'm the exclusive retailer for a top-selling low-priced widget, I'll
> probably tolerate some fraudulent transactions but I *really* need my
> web site to be up all the time, taking orders.
>
> If I'm part of law enforcement, I'll probably value confidentiality most
> highly (although the courts may emphasize integrity and chain-of-custody
> for evidence).
>
>   
And military? I would imagine that since lives are at stake that might 
be the defining peak of the pyramid...

> Bonjour is just a service discovery protocol, not a part of a security
> system. And it's localized so that only your neighbours know. It
> shouldn't make any difference to integrity or confidentiality as those
> should be handled by the defenses you have deployed. At a stretch, it
> might make adversaries aware of your system but if they see Bonjour
> advertisements then they're close to you already and can see your
> network traffic.
>   
An excellent point, and one which worries me. How does "standard" 
security which is not int he DTN part of the system affect the overall 
system of which DTN is only a part?

> Bonjour and static IP addresses are solutions to different problems. An
> IP address allows a system to send something to you. Bonjour allows a
> nearby system to find you if it doesn't know your address.
>   
In my idea of a "closed, secure" system, if someone does not know my IP 
address, then I don't even want him to know that I exist (al least, I 
think so ... )

> If you are sensitive about denial-of-service attacks then I would
> suggest strongly that you do not use a hard-coded IP address, but
> specify a dns address instead.
>
>   
And that gets resolved to an IP address how? If I have an ad-hoc 
network, I don't want to have a DNS server.

> Regards.....Peter
>
>
>   
Thanks, peter, despite 25+ years of telecoms s/w development, much of 
what we now discuss is strangely new to me. I am learning a lot from you.

/graham

--------------000405030703060609050206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">On Thu, Jul 9, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">From a security standpoint?

How secure is it to have all of my nodes blaring "here I am, bad guys,
come and try to connect to me"?

Would I be safer just using hard coded IP address?

Thanks in advance for any opinions.

~graham();
    </pre>
  </blockquote>
  <pre wrap=""><!---->

Hi Graham,

it depends.

Mostly it depends upon the definition you have in mind for "security".

In typical discussions, security encompasses integrity, confidentiality
and availability. Various organizations will prioritize those differently.

  </pre>
</blockquote>
Thanks very much for the swift reply, Peter. It came within ten minutes
and I am a day late in replying :-/<br>
<br>
<br>
I am glad that you mention "availability", because some people with
whom I discuss the subject seem fixated on cryptography. As you mention
later, we might&nbsp; decline to use Bonjour, but are still broadcasting our
presence. That leaves each node open to conventional DOS attacks, but
some people seem to see that as not a part of DTN, just some standard
let someone else take care of it, IP" issue.<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Many commercial transactions will place integrity uppermost, although
those containing sensitive personally-identifying data may have
confidentiality above all. Thinking about a personal stock trade account
as an example - my purchase instruction for a thousand shares of some
company is not very secret but the brokerage really does want to know
that it is accurate and came from me.

If I'm the exclusive retailer for a top-selling low-priced widget, I'll
probably tolerate some fraudulent transactions but I *really* need my
web site to be up all the time, taking orders.

If I'm part of law enforcement, I'll probably value confidentiality most
highly (although the courts may emphasize integrity and chain-of-custody
for evidence).

  </pre>
</blockquote>
And military? I would imagine that since lives are at stake that might
be the defining peak of the pyramid... <br>
<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Bonjour is just a service discovery protocol, not a part of a security
system. And it's localized so that only your neighbours know. It
shouldn't make any difference to integrity or confidentiality as those
should be handled by the defenses you have deployed. At a stretch, it
might make adversaries aware of your system but if they see Bonjour
advertisements then they're close to you already and can see your
network traffic.
  </pre>
</blockquote>
An excellent point, and one which worries me. How does "standard"
security which is not int he DTN part of the system affect the overall
system of which DTN is only a part? <br>
<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">
Bonjour and static IP addresses are solutions to different problems. An
IP address allows a system to send something to you. Bonjour allows a
nearby system to find you if it doesn't know your address.
  </pre>
</blockquote>
In my idea of a "closed, secure" system, if someone does not know my IP
address, then I don't even want him to know that I exist (al least, I
think so ... )<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">
If you are sensitive about denial-of-service attacks then I would
suggest strongly that you do not use a hard-coded IP address, but
specify a dns address instead.

  </pre>
</blockquote>
And that gets resolved to an IP address how? If I have an ad-hoc
network, I don't want to have a DNS server.<br>
<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Regards.....Peter

  </pre>
</blockquote>
Thanks, peter, despite 25+ years of telecoms s/w development, much of
what we now discuss is strangely new to me. I am learning a lot from
you. <br>
<br>
/graham<br>
<br>
</body>
</html>

--------------000405030703060609050206--

--------------080700040705050006030208
Content-Type: text/x-vcard; charset=utf-8;
 name="Graham.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Graham.vcf"

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet:[email-masked]
title:Technical director
tel;work:+65 6316 9968
tel;fax:+65 6316 9208
tel;cell:+65 9725 7353
x-mozilla-html:FALSE
url:http://leonixsolutions.com/
version:2.1
end:vcard

--------------080700040705050006030208--

Date: Fri, 10 Jul 2009 13:26:32 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Organization: Leonix Solutions Pte Ltd
To: Peter Lovell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-security] Re(2): Re(2): Is there a "secure" reference implementation of the DTN stack?

This is a multi-part message in MIME format.
--------------010804040201090703040103
Content-Type: multipart/alternative;
	boundary="------------070301050606010205030707"

--------------070301050606010205030707
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
> Hi Graham,
>
> the best document at this time is the Bundle Security Protocol
> Specification, available at <http://tools.ietf.org/id/draft-irtf-dtnrg-
> bundle-security-08.txt>
>   
wow, that did take some reading (and I doubt that I truly understood 
half of it ;-)

Is there no similar document which covers the whole system, describing 
security measures at each layer, or each stage of the transaction?

~graham();

> This is quite a long document and describes both the general approach
> with ciphersuites and the specific implementation of suites for Bundle
> Authentication (BA), Payload Integrity (PI), Payload Confidentiality
> (PC) and Extension Security (EA). In your search for A Rosetta Stone,
> you'll find that this is about as stony as it gets. It will take some
> time to discern the humour in that statement :)
>
> Regards.....Peter
>
>
>
> On Mon, Jun 29, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
> <[email-masked]> wrote:
>
>   
>> hi, Peter,
>>
>>   firs dumb question - is here a single document which discusses the
>> security aspects built into the reference stack? 
>>
>> What I have is someone who "wants DTN with security" but only because he
>> has been told from above that that is what he wants. 
>>
>> He wants to take "a slow, phased approach, maybe just starting with
>> adding (H)MAC to the link establish, then working up to more in later
>> phases". It sounds from what you say that HMAC is already there (for
>> data bundles only? Control plane too?)
>>
>> He is not too clear about what he wants, possibly because he himself  is
>> being given instructions which vary. He has a cryptography (but not
>> necessarily a security) expert from the local university who is
>> "analyzing the code to find weak points" - some weeks I am just supposed
>> to fill these weak points with code, and other weeks I am supposed to be
>> providing security analysis and advice
>>
>> I have been looking around, but I suppose that I ought have started by
>> asking if there is a Rosseta Stone for security in the reference stack.
>>
>> Sorry to be such a nuisance.
>>
>> Thanks, as always, for your help.
>>
>> With best wishes,
>>
>> Graham 
>>
>>
>>
>> Peter Lovell wrote:
>> Hi Graham,
>>
>> threats such as the ones you describe are handled by the Bundle Security
>> Protocol (BSP) code in the RI. Your application does not have to do
>> encryption etc - that is part of BSP RI code.
>>
>> You *do* have to handle management of keys and that means that you have
>> to write some code that the RI code will call. The thumbnail sketch is
>> that the RI code needs protection applied to something (small, such as
>> an ephemeral key) and your code needs to select an appropriate key and
>> do it. There will be some sample code for this but it's not there yet.
>>
>> Each bundle can have HMAC to protect against changes and also against
>> DOS injection attacks. This is standard already.
>>
>> In short, you'll find that the fundamental capabilities you need are
>> already present but you have to supply the key-management code as
>> appropriate for your key mechanism.
>>
>> Regards.....Peter
>>
>>
>> On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
>> <[email-masked]> wrote:
>>
>>  
>> That;'s the problem - I am not a security expert?
>>
>> I guess encryption would be provided by the application which uses DTN?
>>
>> What about add a MAC (or HMAC) for the link established stuff (or even
>> every bundle)?
>>
>> How to denying man in the middle attacks or spoofed bundles, DOS at the
>> network layer by injecting many fake packets? That sort of thing ...
>>
>> Thanks again for your help, Peter.
>>
>>
>>
>> Peter Lovell wrote:
>>    
>> Hi Graham,
>>
>>
>>      
>> there is an agreed upon standard "reference implementation" of DTN 2.6
>> and Oasys 1.3, but  it lacks security features.
>>
>>        
>> what security features do you find missing? The RI is not a turnkey
>> solution but more of a "reference framework".
>>
>> I'm trying to help but am unsure of what's lacking.
>>
>> Regards.....Peter
>>
>>
>>
>> On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
>> <[email-masked]> wrote:
>>
>>
>>      
>> hi, Peter,
>>
>> there is an agreed upon standard "reference implementation" of DTN 2.6
>> and Oasys 1.3, but  it lacks security features.
>>
>> Now, let us say that someone wants a "secure" implementation - but
>> doesn't care about the details of "secure", just that it is generally
>> agreed to be "secure" (or (much) more so than the standard
>> implementation. Is there a reference build for that which can be
>>        
>> downloaded?
>>    
>> My guess is that everyone's perception of "secure" differs and that even
>> for one person it is a matter of trade-offs, but I just though that I
>> would  ask if there is some consensus on what it means for DTN to be
>> "secure".
>>
>> Thanks very much for taking the time to reply.
>>
>> With best wishes,
>>
>> Graham
>>
>>
>> Peter Lovell wrote:
>>
>>        
>> On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
>> <[email-masked]> wrote:
>>
>>
>>
>>          
>> Is there a "secure" reference implementation of the DTN stack available
>> for download? Is there even agreement of what a "secure" implementation
>> should be, or is it all a question of trade-offs?
>>
>> Thanks in advance for any help.
>>
>> Graham
>>
>>
>>            
>> Hi Graham,
>>
>> I'm not sure what you're expecting when you refer to a "secure"
>> reference implementation. Do you mean one with the security protocols,
>> or one that had been hardened, or one that has been certified by some
>> organization or other?
>>
>> If you can give a little more context we can help fill in what you need.
>>
>> Cheers.....Peter
>>
>>
>>
>>
>>          
>> --
>> Technical Director
>> Leonix Solutions (Pte) Ltd
>> 18 Boon Lay Way
>> #09-95 TradeHub 21
>> Singapore 609966
>> Telephone:+65 6316 9968
>> Fax: +65 6316 9208
>>
>>
>>        
>>
>>
>>      
>> --
>> Technical Director
>> Leonix Solutions (Pte) Ltd
>> 18 Boon Lay Way
>> #09-95 TradeHub 21
>> Singapore 609966
>> Telephone:+65 6316 9968
>> Fax: +65 6316 9208
>>
>>    
>>
>>
>> _______________________________________________
>> dtn-security mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-security
>>
>>  
>>
>>
>> -- 
>> Technical Director
>> Leonix Solutions (Pte) Ltd
>> 18 Boon Lay Way
>> #09-95 TradeHub 21
>> Singapore 609966
>> Telephone:+65 6316 9968
>> Fax: +65 6316 9208
>>     
>
>
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-security
>
>   

-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208

--------------070301050606010205030707
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=iso-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Hi Graham,

the best document at this time is the Bundle Security Protocol
Specification, available at <a class="moz-txt-link-rfc2396E" href="http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-security-08.txt">&lt;http://tools.ietf.org/id/draft-irtf-dtnrg-
bundle-security-08.txt&gt;</a>
  </pre>
</blockquote>
wow, that did take some reading (and I doubt that I truly understood
half of it ;-)<br>
<br>
Is there no similar document which covers the whole system, describing
security measures at each layer, or each stage of the transaction? <br>
<br>
~graham();<br>
<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">
This is quite a long document and describes both the general approach
with ciphersuites and the specific implementation of suites for Bundle
Authentication (BA), Payload Integrity (PI), Payload Confidentiality
(PC) and Extension Security (EA). In your search for A Rosetta Stone,
you'll find that this is about as stony as it gets. It will take some
time to discern the humour in that statement :)

Regards.....Peter

On Mon, Jun 29, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">hi, Peter,

&nbsp; firs dumb question - is here a single document which discusses the
security aspects built into the reference stack? 

What I have is someone who "wants DTN with security" but only because he
has been told from above that that is what he wants. 

He wants to take "a slow, phased approach, maybe just starting with
adding (H)MAC to the link establish, then working up to more in later
phases". It sounds from what you say that HMAC is already there (for
data bundles only? Control plane too?)

He is not too clear about what he wants, possibly because he himself&nbsp; is
being given instructions which vary. He has a cryptography (but not
necessarily a security) expert from the local university who is
"analyzing the code to find weak points" - some weeks I am just supposed
to fill these weak points with code, and other weeks I am supposed to be
providing security analysis and advice

I have been looking around, but I suppose that I ought have started by
asking if there is a Rosseta Stone for security in the reference stack.

Sorry to be such a nuisance.

Thanks, as always, for your help.

With best wishes,

Graham 

Peter Lovell wrote:
Hi Graham,

threats such as the ones you describe are handled by the Bundle Security
Protocol (BSP) code in the RI. Your application does not have to do
encryption etc - that is part of BSP RI code.

You *do* have to handle management of keys and that means that you have
to write some code that the RI code will call. The thumbnail sketch is
that the RI code needs protection applied to something (small, such as
an ephemeral key) and your code needs to select an appropriate key and
do it. There will be some sample code for this but it's not there yet.

Each bundle can have HMAC to protect against changes and also against
DOS injection attacks. This is standard already.

In short, you'll find that the fundamental capabilities you need are
already present but you have to supply the key-management code as
appropriate for your key mechanism.

Regards.....Peter

On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

That;'s the problem - I am not a security expert?

I guess encryption would be provided by the application which uses DTN?

What about add a MAC (or HMAC) for the link established stuff (or even
every bundle)?

How to denying man in the middle attacks or spoofed bundles, DOS at the
network layer by injecting many fake packets? That sort of thing ...

Thanks again for your help, Peter.

Peter Lovell wrote:
   
Hi Graham,

     
there is an agreed upon standard "reference implementation" of DTN 2.6
and Oasys 1.3, but  it lacks security features.

what security features do you find missing? The RI is not a turnkey
solution but more of a "reference framework".

I'm trying to help but am unsure of what's lacking.

Regards.....Peter

On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

     
hi, Peter,

there is an agreed upon standard "reference implementation" of DTN 2.6
and Oasys 1.3, but  it lacks security features.

Now, let us say that someone wants a "secure" implementation - but
doesn't care about the details of "secure", just that it is generally
agreed to be "secure" (or (much) more so than the standard
implementation. Is there a reference build for that which can be
       
downloaded?
   
My guess is that everyone's perception of "secure" differs and that even
for one person it is a matter of trade-offs, but I just though that I
would  ask if there is some consensus on what it means for DTN to be
"secure".

Thanks very much for taking the time to reply.

With best wishes,

Graham

Peter Lovell wrote:

On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

         
Is there a "secure" reference implementation of the DTN stack available
for download? Is there even agreement of what a "secure" implementation
should be, or is it all a question of trade-offs?

Thanks in advance for any help.

Graham

           
Hi Graham,

I'm not sure what you're expecting when you refer to a "secure"
reference implementation. Do you mean one with the security protocols,
or one that had been hardened, or one that has been certified by some
organization or other?

If you can give a little more context we can help fill in what you need.

Cheers.....Peter

         
--
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208

       

     
--
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208

_______________________________________________
dtn-security mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-security">http://maillists.intel-research.net/mailman/listinfo/dtn-security</a>

-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208
    </pre>
  </blockquote>
  <pre wrap=""><!---->

_______________________________________________
dtn-security mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-security">http://maillists.intel-research.net/mailman/listinfo/dtn-security</a>

  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="80">-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208
</pre>
</body>
</html>

--------------070301050606010205030707--

--------------010804040201090703040103
Content-Type: text/x-vcard; charset=utf-8;
 name="Graham.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Graham.vcf"

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet:[email-masked]
title:Technical director
tel;work:+65 6316 9968
tel;fax:+65 6316 9208
tel;cell:+65 9725 7353
x-mozilla-html:FALSE
url:http://leonixsolutions.com/
version:2.1
end:vcard

--------------010804040201090703040103--

From: Peter Lovell <[email-masked]>
To: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Date: Thu, 09 Jul 2009 00:14:17 -0400
Cc: [email-masked]
Subject: Re: [dtn-security] How do you feel about Bonjour/Avahi?

On Thu, Jul 9, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<[email-masked]> wrote:

> From a security standpoint?
>
>How secure is it to have all of my nodes blaring "here I am, bad guys,
>come and try to connect to me"?
>
>Would I be safer just using hard coded IP address?
>
>Thanks in advance for any opinions.
>
>~graham();

Hi Graham,

it depends.

Mostly it depends upon the definition you have in mind for "security".

In typical discussions, security encompasses integrity, confidentiality
and availability. Various organizations will prioritize those differently.

Many commercial transactions will place integrity uppermost, although
those containing sensitive personally-identifying data may have
confidentiality above all. Thinking about a personal stock trade account
as an example - my purchase instruction for a thousand shares of some
company is not very secret but the brokerage really does want to know
that it is accurate and came from me.

If I'm the exclusive retailer for a top-selling low-priced widget, I'll
probably tolerate some fraudulent transactions but I *really* need my
web site to be up all the time, taking orders.

If I'm part of law enforcement, I'll probably value confidentiality most
highly (although the courts may emphasize integrity and chain-of-custody
for evidence).

Bonjour is just a service discovery protocol, not a part of a security
system. And it's localized so that only your neighbours know. It
shouldn't make any difference to integrity or confidentiality as those
should be handled by the defenses you have deployed. At a stretch, it
might make adversaries aware of your system but if they see Bonjour
advertisements then they're close to you already and can see your
network traffic.

Bonjour and static IP addresses are solutions to different problems. An
IP address allows a system to send something to you. Bonjour allows a
nearby system to find you if it doesn't know your address.

If you are sensitive about denial-of-service attacks then I would
suggest strongly that you do not use a hard-coded IP address, but
specify a dns address instead.

Regards.....Peter

Date: Thu, 09 Jul 2009 11:13:39 +0800
From: "Graham Keellings (Leonix Solutions Pte Ltd)" <[email-masked]>
Organization: Leonix Solutions Pte Ltd
CC: [email-masked]
Subject: [dtn-security] How do you feel about Bonjour/Avahi?

This is a multi-part message in MIME format.
--------------080103000405080103060206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

 From a security standpoint?

How secure is it to have all of my nodes blaring "here I am, bad guys, 
come and try to connect to me"?

Would I be safer just using hard coded IP address?

Thanks in advance for any opinions.

~graham();

--------------080103000405080103060206
Content-Type: text/x-vcard; charset=utf-8;
 name="Graham.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Graham.vcf"

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet:[email-masked]
title:Technical director
tel;work:+65 6316 9968
tel;fax:+65 6316 9208
tel;cell:+65 9725 7353
x-mozilla-html:FALSE
url:http://leonixsolutions.com/
version:2.1
end:vcard

--------------080103000405080103060206--