Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5UCUioC003347 for ; Tue, 30 Jun 2009 05:30:44 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.4.98] (dsl092-149-198.wdc2.dsl.speakeasy.net [66.92.149.198]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KM100JX9XBVE180@asmtp020.mac.com> for dtn-security@maillists.intel-research.net; Tue, 30 Jun 2009 05:28:46 -0700 (PDT) From: Peter Lovell To: "Graham Keellings (Leonix Solutions Pte Ltd)" , "Eddy, Wesley M. (GRC-MS00)[Verizon]" Date: Tue, 30 Jun 2009 08:28:42 -0400 Message-id: <20090630122842.1049441707@smtp.mac.com> In-reply-to: <4A497B04.3070909@LeonixSolutions.com> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <"3A5AA67A8B120B48825BFFCF544385613 7E0B06196"@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <"029d01c 9e925$1e354880$5a9fd980$"@com> <4A46C257.3040006@LeonixSolutions.com> <"2009062 8050243.1566215671"@smtp.mac.com> <4A46FBB2.3080205@LeonixSolutions.com> <"2009 0628052255.640550503"@smtp.mac.com> <4A470CD7.4010502@LeonixSolutions.com> <"20 090628141313.1532044204"@smtp.mac.com> <4A4878A6.7010707@LeonixSolutions.com> <20090629123400.1726285002@smtp.mac.com> <4A497B04.3070909@LeonixSolutions.com> X-Mailer: CTM PowerMail version 6.0.2 build 4601 English (intel) Cc: dtn-security@maillists.intel-research.net Subject: [dtn-security] Re(many): Is there a "secure" referenceimplementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 12:30:44 -0000 Hi Graham, yes - an ad-hoc key server in a DTN environment doesn't make a lot of sense. We've tended to use PKI keys in examples as they simplify the distribution issue and have reasonable lifetimes for the tasks but, as you point out, key loss is problematic. Requiring CRL access does rather defeat the whole point of DTN. If it is important that you react very quickly to key loss, then group keying may be a better solution. If a node is compromised, the group is rekeyed as quickly as the key server can do it (after it finds out). Some nodes might be disconnected for a while and still have old keys but they won't be getting much (or any) traffic so this can be dealt with. The new key from the key server should arrive about the same time as any bundles using the new key. Obviously, group membership in this scenario is based upon being authorized, rather than which authorized nodes are currently connected (many groups work this way). Cheers.....Peter On Tue, Jun 30, 2009, Graham Keellings (Leonix Solutions Pte Ltd) wrote: >Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: >> As Peter mentioned earlier, even with a complete BSP implementation, >> you still have to figure out how to do key management on your own. >> This is the hardest and most complex part, >It certainly is. Since we are worried about security, we can consider >military or banking use, and think about the use cases, for isntance, >for 1) initial key distribution to the whole network 2) addition of a >new member 3) individual key revocation 4) mass update of all key? (if >even needed, and probably just use case 1) > >Some schemes, like Prophet, seem ok, but, if I understand correctly, >keys have a specific lifetime and then expire. What if the DTN device >falls into the wrong hands before then? One would want to revoke it >immediately, would one not? > >How does one distribute the keys, given that it makes little on no sense >to have a key server in an ad hoc network? (I suppose that before every >battle or at the start of each work day, each user could bring their >device within range of a "secure" key server, but that seems rather >contrived). If the number of nodes will never vary, then each could be >pre-programmed with the appropriate keys, but this seems rather >restrictive, and again there is the problem of revocation. > >This does need some serious thinking, which is probably why I have been >instructed to "ignore it until a future release" (lucky me ;-) > >Thanks again for the input. I am now off to struggle with Peter's >"stony" description of the existing security mechanism. > >With best wishes, > >Graham > > >> if you need it to scale >> to some level, be robust to disconnection, delay, and low bandwidth, >> and if you rely on the established keys to carry critical traffic. >> The BSP is only part of the solution you need, and the rest is left >> as an exercise to the user ... >> >> --------------------------- >> Wes Eddy Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5U2g62v008627 for ; Mon, 29 Jun 2009 19:42:06 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.138]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MLTGM-0006uo-LG; Mon, 29 Jun 2009 22:40:08 -0400 Message-ID: <4A497B04.3070909@LeonixSolutions.com> Date: Tue, 30 Jun 2009 10:40:04 +0800 From: "Graham Keellings (Leonix Solutions Pte Ltd)" Organization: Leonix Solutions Pte Ltd User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac. uk><4A12195A.6000207@LeonixSolutions.com><3A5AA67A8B120B48825BFFCF544385613 7E0B06196@NDJSSCC03.ndc.nasa.gov><4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com><4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov><029d01c 9e925$1e354880$5a9fd980$@com><4A46C257.3040006@LeonixSolutions.com><2009062 8050243.1566215671@smtp.mac.com><4A46FBB2.3080205@LeonixSolutions.com><2009 0628052255.640550503@smtp.mac.com><4A470CD7.4010502@LeonixSolutions.com><20 090628141313.1532044204@smtp.mac.com><4A4878A6.7010707@LeonixSolutions.com> <20090629123400.1726285002@smtp.mac.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090301010606060002070700" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sky.fastbighost.net X-AntiAbuse: Original Domain - maillists.intel-research.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - LeonixSolutions.com X-Source: X-Source-Args: X-Source-Dir: Cc: "dtn-security@maillists.intel-research.net" Subject: Re: [dtn-security] Re(2): Re(2): Is there a "secure" referenceimplementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:42:07 -0000 This is a multi-part message in MIME format. --------------090301010606060002070700 Content-Type: multipart/alternative; boundary="------------070501080804000605070402" --------------070501080804000605070402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > As Peter mentioned earlier, even with a complete BSP implementation, > you still have to figure out how to do key management on your own. > This is the hardest and most complex part, It certainly is. Since we are worried about security, we can consider military or banking use, and think about the use cases, for isntance, for 1) initial key distribution to the whole network 2) addition of a new member 3) individual key revocation 4) mass update of all key? (if even needed, and probably just use case 1) Some schemes, like Prophet, seem ok, but, if I understand correctly, keys have a specific lifetime and then expire. What if the DTN device falls into the wrong hands before then? One would want to revoke it immediately, would one not? How does one distribute the keys, given that it makes little on no sense to have a key server in an ad hoc network? (I suppose that before every battle or at the start of each work day, each user could bring their device within range of a "secure" key server, but that seems rather contrived). If the number of nodes will never vary, then each could be pre-programmed with the appropriate keys, but this seems rather restrictive, and again there is the problem of revocation. This does need some serious thinking, which is probably why I have been instructed to "ignore it until a future release" (lucky me ;-) Thanks again for the input. I am now off to struggle with Peter's "stony" description of the existing security mechanism. With best wishes, Graham > if you need it to scale > to some level, be robust to disconnection, delay, and low bandwidth, > and if you rely on the established keys to carry critical traffic. > The BSP is only part of the solution you need, and the rest is left > as an exercise to the user ... > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > >> -----Original Message----- >> From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn- >> security-bounces@maillists.intel-research.net] On Behalf Of Peter Lovell >> Sent: Monday, June 29, 2009 8:34 AM >> To: Graham Keellings (Leonix Solutions Pte Ltd) >> Cc: dtn-security@maillists.intel-research.net >> Subject: [dtn-security] Re(2): Re(2): Is there a "secure" >> referenceimplementation of the DTN stack? >> >> Hi Graham, >> >> the best document at this time is the Bundle Security Protocol >> Specification, available at > bundle-security-08.txt> >> >> 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) >> 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) >>> 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) >>> 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) >>> 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 >>> dtn-security@maillists.intel-research.net >>> 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 >> dtn-security@maillists.intel-research.net >> 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 --------------070501080804000605070402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: 
As Peter mentioned earlier, even with a complete BSP implementation,
you still have to figure out how to do key management on your own.
This is the hardest and most complex part,
It certainly is. Since we are worried about security, we can consider military or banking use, and think about the use cases, for isntance, for 1) initial key distribution to the whole network 2) addition of a new member 3) individual key revocation 4) mass update of all key? (if even needed, and probably just use case 1)

Some schemes, like Prophet, seem ok, but, if I understand correctly, keys have a specific lifetime and then expire. What if the DTN device falls into the wrong hands before then? One would want to revoke it immediately, would one not?

How does one distribute the keys, given that it makes little on no sense to have a key server in an ad hoc network? (I suppose that before every battle or at the start of each work day, each user could bring their device within range of a "secure" key server, but that seems rather contrived). If the number of nodes will never vary, then each could be pre-programmed with the appropriate keys, but this seems rather restrictive, and again there is the problem of revocation.

This does need some serious thinking, which is probably why I have been instructed to "ignore it until a  future release" (lucky me ;-)

Thanks again for the input. I am now off to struggle with Peter's "stony" description of the existing security mechanism.

With best wishes,

Graham


 if you need it to scale
to some level, be robust to disconnection, delay, and low bandwidth,
and if you rely on the established keys to carry critical traffic.
The BSP is only part of the solution you need, and the rest is left
as an exercise to the user ...

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

  
-----Original Message-----
From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn-
security-bounces@maillists.intel-research.net] On Behalf Of Peter Lovell
Sent: Monday, June 29, 2009 8:34 AM
To: Graham Keellings (Leonix Solutions Pte Ltd)
Cc: dtn-security@maillists.intel-research.net
Subject: [dtn-security] Re(2): Re(2): Is there a "secure"
referenceimplementation of the DTN stack?

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>

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)
<Graham@LeonixSolutions.com> 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)
<Graham@LeonixSolutions.com> 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)
<Graham@LeonixSolutions.com> 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)
<Graham@leonixsolutions.com> 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
dtn-security@maillists.intel-research.net
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
dtn-security@maillists.intel-research.net
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
--------------070501080804000605070402-- --------------090301010606060002070700 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:Graham@LeonixSolutions.com 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 --------------090301010606060002070700-- Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5TE4pxV006922 for ; Mon, 29 Jun 2009 07:04:51 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from [157.185.80.152] by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KM000BEJ70T1850@asmtp013.mac.com> for dtn-security@maillists.intel-research.net; Mon, 29 Jun 2009 07:02:57 -0700 (PDT) From: Peter Lovell To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , "Graham Keellings (Leonix Solutions Pte Ltd)" Date: Mon, 29 Jun 2009 10:02:54 -0400 Message-id: <20090629140254.662880797@smtp.mac.com> In-reply-to: References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <"3A5AA67A8B120B48825BFFCF544385613 7E0B06196"@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <"029d01c 9e925$1e354880$5a9fd980$"@com> <4A46C257.3040006@LeonixSolutions.com> <"2009062 8050243.1566215671"@smtp.mac.com> <4A46FBB2.3080205@LeonixSolutions.com> <"2009 0628052255.640550503"@smtp.mac.com> <4A470CD7.4010502@LeonixSolutions.com> <"20 090628141313.1532044204"@smtp.mac.com> <4A4878A6.7010707@LeonixSolutions.com> <20090629123400.1726285002@smtp.mac.com> X-Mailer: CTM PowerMail version 5.6.3 build 4504 English (PPC) Cc: dtn-security@maillists.intel-research.net Subject: [dtn-security] Re(2): Re(2): Re(2): Is there a "secure" referenceimplementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:04:52 -0000 Hi Wes, very true. I will soon be doing some work to help this within RI. I regard key distribution between nodes as a control-plane issue and one with which systems designers must deal. But we can help the problem of using keys within an individual node. Pre-placing PKI certificates will be an adequate solution for some systems and that's what I'll be using to start with. Regards.....Peter On Mon, Jun 29, 2009, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: >As Peter mentioned earlier, even with a complete BSP implementation, >you still have to figure out how to do key management on your own. >This is the hardest and most complex part, if you need it to scale >to some level, be robust to disconnection, delay, and low bandwidth, >and if you rely on the established keys to carry critical traffic. >The BSP is only part of the solution you need, and the rest is left >as an exercise to the user ... > >--------------------------- >Wes Eddy >Network & Systems Architect >Verizon FNS / NASA GRC >Office: (216) 433-6682 >--------------------------- > >>-----Original Message----- >>From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn- >>security-bounces@maillists.intel-research.net] On Behalf Of Peter Lovell >>Sent: Monday, June 29, 2009 8:34 AM >>To: Graham Keellings (Leonix Solutions Pte Ltd) >>Cc: dtn-security@maillists.intel-research.net >>Subject: [dtn-security] Re(2): Re(2): Is there a "secure" >>referenceimplementation of the DTN stack? >> >>Hi Graham, >> >>the best document at this time is the Bundle Security Protocol >>Specification, available at >bundle-security-08.txt> >> >>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 Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5TCZqta002903 for ; Mon, 29 Jun 2009 05:35:52 -0700 MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Received: from [157.185.80.152] by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KM0001NY2WN3000@asmtp021.mac.com> for dtn-security@maillists.intel-research.net; Mon, 29 Jun 2009 05:34:03 -0700 (PDT) From: Peter Lovell To: "Graham Keellings (Leonix Solutions Pte Ltd)" Date: Mon, 29 Jun 2009 08:34:00 -0400 Message-id: <20090629123400.1726285002@smtp.mac.com> In-reply-to: <4A4878A6.7010707@LeonixSolutions.com> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> <4A46C257.3040006@LeonixSolutions.com> <20090628050243.1566215671@smtp.mac.com> <4A46FBB2.3080205@LeonixSolutions.com> <20090628052255.640550503@smtp.mac.com> <4A470CD7.4010502@LeonixSolutions.com> <20090628141313.1532044204@smtp.mac.com> <4A4878A6.7010707@LeonixSolutions.com> X-Mailer: CTM PowerMail version 5.6.3 build 4504 English (PPC) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n5TCZqta002903 Cc: dtn-security@maillists.intel-research.net Subject: [dtn-security] Re(2): Re(2): Is there a "secure" reference implementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 12:35:52 -0000 Hi Graham, the best document at this time is the Bundle Security Protocol Specification, available at 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) 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) > 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) > 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) > 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 >dtn-security@maillists.intel-research.net >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 Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5T8JYoK023167 for ; Mon, 29 Jun 2009 01:19:34 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.138]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MLC3c-00059F-BC; Mon, 29 Jun 2009 04:17:45 -0400 Message-ID: <4A4878A6.7010707@LeonixSolutions.com> Date: Mon, 29 Jun 2009 16:17:42 +0800 From: "Graham Keellings (Leonix Solutions Pte Ltd)" Organization: Leonix Solutions Pte Ltd User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Peter Lovell References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> <4A46C257.3040006@LeonixSolutions.com> <20090628050243.1566215671@smtp.mac.com> <4A46FBB2.3080205@LeonixSolutions.com> <20090628052255.640550503@smtp.mac.com> <4A470CD7.4010502@LeonixSolutions.com> <20090628141313.1532044204@smtp.mac.com> In-Reply-To: <20090628141313.1532044204@smtp.mac.com> Content-Type: multipart/mixed; boundary="------------020502060700010401050006" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sky.fastbighost.net X-AntiAbuse: Original Domain - maillists.intel-research.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - LeonixSolutions.com X-Source: X-Source-Args: X-Source-Dir: Cc: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Re(2): Is there a "secure" reference implementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:19:35 -0000 This is a multi-part message in MIME format. --------------020502060700010401050006 Content-Type: multipart/alternative; boundary="------------010506000502030400080007" --------------010506000502030400080007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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) > 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) >>> 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) >>>>> 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 > dtn-security@maillists.intel-research.net > 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 --------------010506000502030400080007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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)
<Graham@LeonixSolutions.com> 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)
<Graham@LeonixSolutions.com> 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)
<Graham@leonixsolutions.com> 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
dtn-security@maillists.intel-research.net
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
--------------010506000502030400080007-- --------------020502060700010401050006 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:Graham@LeonixSolutions.com 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 --------------020502060700010401050006-- Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5SEEwE1006771 for ; Sun, 28 Jun 2009 07:14:58 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.107] (pa-67-234-153-81.dhcp.embarqhsd.net [67.234.153.81]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLY00M5QCU1IH80@asmtp018.mac.com> for dtn-security@maillists.intel-research.net; Sun, 28 Jun 2009 07:13:16 -0700 (PDT) From: Peter Lovell To: "Graham Keellings (Leonix Solutions Pte Ltd)" Date: Sun, 28 Jun 2009 10:13:13 -0400 Message-id: <20090628141313.1532044204@smtp.mac.com> In-reply-to: <4A470CD7.4010502@LeonixSolutions.com> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> <4A46C257.3040006@LeonixSolutions.com> <20090628050243.1566215671@smtp.mac.com> <4A46FBB2.3080205@LeonixSolutions.com> <20090628052255.640550503@smtp.mac.com> <4A470CD7.4010502@LeonixSolutions.com> X-Mailer: CTM PowerMail version 5.6.5 build 4509 English (intel) Cc: dtn-security@maillists.intel-research.net Subject: [dtn-security] Re(2): Is there a "secure" reference implementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 14:14:58 -0000 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) 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) >> 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) >>>> 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 > Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5S6QmV3019614 for ; Sat, 27 Jun 2009 23:26:48 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.138]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MKnp5-0005El-G4; Sun, 28 Jun 2009 02:25:08 -0400 Message-ID: <4A470CD7.4010502@LeonixSolutions.com> Date: Sun, 28 Jun 2009 14:25:27 +0800 From: "Graham Keellings (Leonix Solutions Pte Ltd)" Organization: Leonix Solutions Pte Ltd User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Peter Lovell References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> <4A46C257.3040006@LeonixSolutions.com> <20090628050243.1566215671@smtp.mac.com> <4A46FBB2.3080205@LeonixSolutions.com> <20090628052255.640550503@smtp.mac.com> In-Reply-To: <20090628052255.640550503@smtp.mac.com> Content-Type: multipart/mixed; boundary="------------040502040607010203000007" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sky.fastbighost.net X-AntiAbuse: Original Domain - maillists.intel-research.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - LeonixSolutions.com X-Source: X-Source-Args: X-Source-Dir: Cc: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Is there a "secure" reference implementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 06:26:48 -0000 This is a multi-part message in MIME format. --------------040502040607010203000007 Content-Type: multipart/alternative; boundary="------------000607070004040909090308" --------------000607070004040909090308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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) > 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) >>> 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 --------------000607070004040909090308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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)
<Graham@LeonixSolutions.com> 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)
<Graham@leonixsolutions.com> 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
--------------000607070004040909090308-- --------------040502040607010203000007 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:Graham@LeonixSolutions.com 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 --------------040502040607010203000007-- Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5S5OaJD016829 for ; Sat, 27 Jun 2009 22:24:36 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.107] (pa-67-234-153-81.dhcp.embarqhsd.net [67.234.153.81]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLX00H64OA7F750@asmtp020.mac.com> for dtn-security@maillists.intel-research.net; Sat, 27 Jun 2009 22:22:58 -0700 (PDT) From: Peter Lovell To: "Graham Keellings (Leonix Solutions Pte Ltd)" Date: Sun, 28 Jun 2009 01:22:55 -0400 Message-id: <20090628052255.640550503@smtp.mac.com> In-reply-to: <4A46FBB2.3080205@LeonixSolutions.com> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> <4A46C257.3040006@LeonixSolutions.com> <20090628050243.1566215671@smtp.mac.com> <4A46FBB2.3080205@LeonixSolutions.com> X-Mailer: CTM PowerMail version 5.6.5 build 4509 English (intel) Cc: dtn-security@maillists.intel-research.net Subject: [dtn-security] Re(2): Is there a "secure" reference implementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 05:24:36 -0000 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) 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) >> 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 > Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5S5Dc1n016311 for ; Sat, 27 Jun 2009 22:13:39 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.138]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MKmgG-0001Vz-Ls; Sun, 28 Jun 2009 01:11:57 -0400 Message-ID: <4A46FBB2.3080205@LeonixSolutions.com> Date: Sun, 28 Jun 2009 13:12:18 +0800 From: "Graham Keellings (Leonix Solutions Pte Ltd)" Organization: Leonix Solutions Pte Ltd User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Peter Lovell References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> <4A46C257.3040006@LeonixSolutions.com> <20090628050243.1566215671@smtp.mac.com> In-Reply-To: <20090628050243.1566215671@smtp.mac.com> Content-Type: multipart/mixed; boundary="------------020000080401080902050505" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sky.fastbighost.net X-AntiAbuse: Original Domain - maillists.intel-research.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - LeonixSolutions.com X-Source: X-Source-Args: X-Source-Dir: Cc: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Is there a "secure" reference implementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 05:13:39 -0000 This is a multi-part message in MIME format. --------------020000080401080902050505 Content-Type: multipart/alternative; boundary="------------050602060305070809070005" --------------050602060305070809070005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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) > 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 --------------050602060305070809070005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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)
<Graham@leonixsolutions.com> 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
--------------050602060305070809070005-- --------------020000080401080902050505 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:Graham@LeonixSolutions.com 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 --------------020000080401080902050505-- Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5S54PHh015898 for ; Sat, 27 Jun 2009 22:04:25 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.107] (pa-67-234-153-81.dhcp.embarqhsd.net [67.234.153.81]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLX00AWHNCLMX00@asmtp022.mac.com> for dtn-security@maillists.intel-research.net; Sat, 27 Jun 2009 22:02:47 -0700 (PDT) From: Peter Lovell To: "Graham Keellings (Leonix Solutions Pte Ltd)" , dtn-security@maillists.intel-research.net Date: Sun, 28 Jun 2009 01:02:43 -0400 Message-id: <20090628050243.1566215671@smtp.mac.com> In-reply-to: <4A46C257.3040006@LeonixSolutions.com> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> <4A46C257.3040006@LeonixSolutions.com> X-Mailer: CTM PowerMail version 5.6.5 build 4509 English (intel) Subject: Re: [dtn-security] Is there a "secure" reference implementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 05:04:26 -0000 On Sun, Jun 28, 2009, Graham Keellings (Leonix Solutions Pte Ltd) 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 Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n5S18s9h005308 for ; Sat, 27 Jun 2009 18:08:55 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.138]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MKirS-0007rj-Bx for dtn-security@maillists.intel-research.net; Sat, 27 Jun 2009 21:07:14 -0400 Message-ID: <4A46C257.3040006@LeonixSolutions.com> Date: Sun, 28 Jun 2009 09:07:35 +0800 From: "Graham Keellings (Leonix Solutions Pte Ltd)" Organization: Leonix Solutions Pte Ltd User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "dtn-security@maillists.intel-research.net" References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> In-Reply-To: <029d01c9e925$1e354880$5a9fd980$@com> Content-Type: multipart/mixed; boundary="------------070801090400010200030902" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sky.fastbighost.net X-AntiAbuse: Original Domain - maillists.intel-research.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - LeonixSolutions.com X-Source: X-Source-Args: X-Source-Dir: Subject: [dtn-security] Is there a "secure" reference implementation of the DTN stack? X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 01:08:55 -0000 This is a multi-part message in MIME format. --------------070801090400010200030902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------070801090400010200030902 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:Graham@LeonixSolutions.com 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 --------------070801090400010200030902-- Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n59LoXq7029691 for ; Tue, 9 Jun 2009 14:50:33 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [10.0.215.52] ([12.104.12.93]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KKZ00K0QQY5S980@asmtp017.mac.com> for dtn-security@maillists.intel-research.net; Tue, 09 Jun 2009 14:42:09 -0700 (PDT) From: Peter Lovell To: redi@bbn.com, "'Ivancic, William D. (GRC-RHN0)'" , "'Graham Keellings (Leonix Solutions Pte Ltd)'" Date: Tue, 09 Jun 2009 17:42:04 -0400 Message-id: <20090609214204.71935542@smtp.mac.com> In-reply-to: <029d01c9e925$1e354880$5a9fd980$@com> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> <029d01c9e925$1e354880$5a9fd980$@com> X-Mailer: CTM PowerMail version 5.6.5 build 4509 English (intel) Cc: dtn-security@maillists.intel-research.net Subject: [dtn-security] Re(2): Newbie seeking some security related advice X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 21:50:34 -0000 On Tue, Jun 9, 2009, Jason Redi wrote: >Strange - I think this email already came around about a month ago. >Armando responded then, but the original reappeared. Maybe there's some >delay in the relayer? > > > >Jason An example of delay-tolerance, perhaps ?? Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n59HIGGA017513 for ; Tue, 9 Jun 2009 10:18:16 -0700 Received: from mproxy02.bbn.com ([192.1.122.24]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ME4pn-0008SM-CN; Tue, 09 Jun 2009 13:10:03 -0400 Received: from godzilla.bbn.com ([128.89.68.89] helo=Godzilla) by mproxy02.bbn.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME4pn-00005S-HN; Tue, 09 Jun 2009 13:10:03 -0400 From: "Jason Redi" To: "'Ivancic, William D. \(GRC-RHN0\)'" , "'Graham Keellings \(Leonix Solutions Pte Ltd\)'" References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> In-Reply-To: <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> Date: Tue, 9 Jun 2009 13:09:53 -0400 Organization: BBN Technologies Message-ID: <029d01c9e925$1e354880$5a9fd980$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029E_01C9E903.9723A880" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnoxiQeFFO345L4QfqKOal4wck1FwAWwUHgAAD3MOA= Content-Language: en-us Cc: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Newbie seeking some security related advice X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: redi@bbn.com List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 17:18:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_029E_01C9E903.9723A880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Strange - I think this email already came around about a month ago. Armando responded then, but the original reappeared. Maybe there's some delay in the relayer? Jason From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov] Sent: Tuesday, June 09, 2009 12:49 PM To: Graham Keellings (Leonix Solutions Pte Ltd); redi@bbn.com Cc: 'Armando Caro'; dtn-security@maillists.intel-research.net Subject: RE: [dtn-security] Newbie seeking some security related advice Importance: High Graham, Some applications simply are not delay tolerant. If I need to say "Incoming, take cover!" 10 seconds delay is unacceptable. I hear some talk about DTN for air traffic control. Safety of flight, safety of life, ... I don't think so. I'll walk! Now, for some air traffic application such a perhaps passenger lists of fuel and weight, a few seconds or a minute may not be an issue, but at that point you have good links and don't need DTN. Beware of the Buzz Words and Marketing. DTN is great for some things, bad for others and there are situations were one could not communicate at all without DTN. You have to educate the customer. Do so in your proposal and point out the folly of DTN in a primarily voice network and you will take the contract from those proposing otherwise. /Will From: Graham Keellings (Leonix Solutions Pte Ltd) [mailto:Graham@LeonixSolutions.com] Sent: Tuesday, June 09, 2009 1:50 AM To: redi@bbn.com Cc: 'Armando Caro'; Ivancic, William D. (GRC-RHN0); dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Newbie seeking some security related advice .... As Armando describes, we are currently using streaming voice over BP. Individual packets contain 20-100ms of voice, so sending those individual buffers in an individual disrupted fashion would not make a whole lot of sense. Note that we are also working on providing voice-snippets of 1-10s Wow! That surely *is* delay tolerant (if not disruption tolerant). You have to wait until you have collected 10 seconds of voice at the sender before transmitting. That guarantees a lag of over 9 seconds at the receiver, or 18+ seconds to get a reply to a question. I think that I need to rethink :-) Or, at least, we can say that such delay might be acceptable in some scenarios, but not in others. Nasa might have no choice, given the lag inherent in very long range transmissions, but I doubt that DARPA can accept multi-seconds delays in combat scenarios. I am looking at a "real time" voice network, where it has been strongly "suggested" that I use DTN, but I am thinking that all that it will bring to my particular use case is that I don't have to worry about "link lost" for a short time bringing down the call. My personal feel is that DTN is not the right tool for the job for a mainly voice based short range system where speed of reply is of the essence. I don't see that the benefits justify it, but then I don't get to make the decision (and if I recommend against it, I probably don't get the contract. Sigh) Thank you very much for taking he time to reply and for helping me to clarify my thoughts. With best wishes, Graham ------=_NextPart_000_029E_01C9E903.9723A880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Strange – I think this email already came around = about a month ago.   Armando responded then, but the original reappeared.   Maybe there’s some delay in the = relayer?

 

Jason

 

 

 

From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov]
Sent: Tuesday, June 09, 2009 12:49 PM
To: Graham Keellings (Leonix Solutions Pte Ltd); redi@bbn.com
Cc: 'Armando Caro'; dtn-security@maillists.intel-research.net
Subject: RE: [dtn-security] Newbie seeking some security related = advice
Importance: High

 

Graham,

 

Some applications simply are not delay tolerant.  If = I need to say “Incoming, take cover!”  10 seconds delay is unacceptable.

 

I hear some talk about DTN for  air traffic = control.  Safety of flight, safety of life, ... I don’t think so.  = I’ll walk!

 

Now, for some air traffic application such a perhaps = passenger lists of fuel and weight, a few seconds or a minute may not be an issue, = but at that point you have good links and don’t need = DTN.

 

Beware of the Buzz Words and Marketing.  DTN is = great for some things, bad for others and there are situations were one could not communicate at all without DTN.

 

You have to educate the customer.   Do so in = your proposal and point out the folly of DTN in a primarily voice network and = you will take the contract from those proposing = otherwise.

 

 

/Will

 

From: Graham Keellings (Leonix = Solutions Pte Ltd) [mailto:Graham@LeonixSolutions.com]
Sent: Tuesday, June 09, 2009 1:50 AM
To: redi@bbn.com
Cc: 'Armando Caro'; Ivancic, William D. (GRC-RHN0); dtn-security@maillists.intel-research.net
Subject: Re: [dtn-security] Newbie seeking some security related = advice

 

....
As =
Armando describes, we are currently using streaming voice over =
BP.
Individual packets contain 20-100ms of voice, =
so sending those individual
buffers in an =
individual disrupted fashion would not make a whole lot =
of
sense.  
Note =
that we are also working on providing voice-snippets of =
1-10s
 

Wow! That surely *is* delay tolerant (if not disruption tolerant). You have to wait until you have collected 10 = seconds of voice at the sender before transmitting. That guarantees a lag of over 9 seconds at the receiver, or 18+ seconds to get a reply to a = question.

I think that I need to rethink :-)   Or,  at least, we = can say that such delay might be acceptable in some scenarios, but not in = others. Nasa might have no choice, given the lag inherent in very long range = transmissions, but I doubt that DARPA can accept multi-seconds delays in combat = scenarios.

I am looking at a "real time" voice network, where it has been strongly "suggested" that I use DTN, but I am thinking that = all that it will bring to my particular use case is that I don't have to worry = about "link lost" for a short time bringing down the call.  My personal feel is that DTN is not the right tool for the job for a mainly = voice based short range system where speed of reply is of the essence. I don't = see that the benefits justify it, but then I don't get to make the decision = (and if I recommend against it, I probably don't get the contract. Sigh)

Thank you very much for taking he time to reply and for helping me to = clarify my thoughts.

With best wishes,

Graham 

 
------=_NextPart_000_029E_01C9E903.9723A880-- Received: from TX2EHSOBE008.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n59H77mS016998 for ; Tue, 9 Jun 2009 10:07:07 -0700 Received: from mail55-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 8.1.340.0; Tue, 9 Jun 2009 16:58:56 +0000 Received: from mail55-tx2 (localhost.localdomain [127.0.0.1]) by mail55-tx2-R.bigfish.com (Postfix) with ESMTP id BE6B95A83FA; Tue, 9 Jun 2009 16:58:56 +0000 (UTC) X-SpamScore: -27 X-BigFish: VPS-27(zz1418M1432R98dR11f6O1805M1442J9371Pzz1202hzzz2dh17ch6bh87il) X-FB-SS: 5, X-FB-DOMAIN-IP-MATCH: fail Received: by mail55-tx2 (MessageSwitch) id 1244566732475649_2970; Tue, 9 Jun 2009 16:58:52 +0000 (UCT) Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail55-tx2.bigfish.com (Postfix) with ESMTP id 2EFB7190054; Tue, 9 Jun 2009 16:58:52 +0000 (UTC) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id A57D568005; Tue, 9 Jun 2009 17:58:51 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A04F7E990DE; Tue, 09 Jun 2009 17:58:51 +0100 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 9289C68005; Tue, 9 Jun 2009 17:58:51 +0100 (IST) Message-ID: <4A2E94CB.7030202@cs.tcd.ie> Date: Tue, 9 Jun 2009 17:58:51 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RHN0)" References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> In-Reply-To: <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="UTF-8" X-AntiVirus-Status: MessageID = A14F7E990DE X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.107.6) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n59H77mS016998 Cc: "dtn-security@maillists.intel-research.net" Subject: Re: [dtn-security] Newbie seeking some security related advice X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 17:07:07 -0000 I agree about being wary of marketing-speak. However, if you have an environment where you are sometimes disrupted then looking at a DTN option is quite reasonable. I can well imagine someone doing a good job with voice over the BP esp. with that superseding bundle stuff (2nd mention today:-), but of course doing it well would be non-trivial. Who's talking about DTN for air traffic control? S. Ivancic, William D. (GRC-RHN0) wrote: > Graham, > > > > Some applications simply are not delay tolerant. If I need to say > “Incoming, take cover!” 10 seconds delay is unacceptable. > > > > I hear some talk about DTN for air traffic control. Safety of flight, > safety of life, ... I don’t think so. I’ll walk! > > > > Now, for some air traffic application such a perhaps passenger lists of > fuel and weight, a few seconds or a minute may not be an issue, but at > that point you have good links and don’t need DTN. > > > > Beware of the Buzz Words and Marketing. DTN is great for some things, > bad for others and there are situations were one could not communicate > at all without DTN. > > > > You have to educate the customer. Do so in your proposal and point out > the folly of DTN in a primarily voice network and you will take the > contract from those proposing otherwise. > > > > > > /Will > > > > *From:* Graham Keellings (Leonix Solutions Pte Ltd) > [mailto:Graham@LeonixSolutions.com] > *Sent:* Tuesday, June 09, 2009 1:50 AM > *To:* redi@bbn.com > *Cc:* 'Armando Caro'; Ivancic, William D. (GRC-RHN0); > dtn-security@maillists.intel-research.net > *Subject:* Re: [dtn-security] Newbie seeking some security related advice > > > > .... > > As Armando describes, we are currently using streaming voice over BP. > > Individual packets contain 20-100ms of voice, so sending those individual > > buffers in an individual disrupted fashion would not make a whole lot of > > sense. > > Note that we are also working on providing voice-snippets of 1-10s > > > > Wow! That surely *is* delay tolerant (if not disruption tolerant). You > have to wait until you have collected 10 seconds of voice at the sender > before transmitting. That guarantees a lag of over 9 seconds at the > receiver, or 18+ seconds to get a reply to a question. > > I think that I need to rethink :-) Or, at least, we can say that such > delay might be acceptable in some scenarios, but not in others. Nasa > might have no choice, given the lag inherent in very long range > transmissions, but I doubt that DARPA can accept multi-seconds delays in > combat scenarios. > > I am looking at a "real time" voice network, where it has been strongly > "suggested" that I use DTN, but I am thinking that all that it will > bring to my particular use case is that I don't have to worry about > "link lost" for a short time bringing down the call. My personal feel > is that DTN is not the right tool for the job for a mainly voice based > short range system where speed of reply is of the essence. I don't see > that the benefits justify it, but then I don't get to make the decision > (and if I recommend against it, I probably don't get the contract. Sigh) > > Thank you very much for taking he time to reply and for helping me to > clarify my thoughts. > > With best wishes, > > Graham > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dtn-security mailing list > dtn-security@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-security Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n59GvI2j016521 for ; Tue, 9 Jun 2009 09:57:19 -0700 Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 90AD22D8428; Tue, 9 Jun 2009 11:49:08 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n59Gn8xc024649; Tue, 9 Jun 2009 11:49:08 -0500 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 9 Jun 2009 11:49:08 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Graham Keellings (Leonix Solutions Pte Ltd)" , "redi@bbn.com" Date: Tue, 9 Jun 2009 11:49:04 -0500 Thread-Topic: [dtn-security] Newbie seeking some security related advice Thread-Index: AcnoxiQeFFO345L4QfqKOal4wck1FwAWwUHg Message-ID: <3A5AA67A8B120B48825BFFCF5443856137E3553C4B@NDJSSCC03.ndc.nasa.gov> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> <4A2DF7FD.5020104@LeonixSolutions.com> In-Reply-To: <4A2DF7FD.5020104@LeonixSolutions.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3A5AA67A8B120B48825BFFCF5443856137E3553C4BNDJSSCC03ndcn_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-09_09:2009-06-01, 2009-06-09, 2009-06-08 signatures=0 Cc: "dtn-security@maillists.intel-research.net" Subject: Re: [dtn-security] Newbie seeking some security related advice X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 16:57:20 -0000 --_000_3A5AA67A8B120B48825BFFCF5443856137E3553C4BNDJSSCC03ndcn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Graham, Some applications simply are not delay tolerant. If I need to say "Incomin= g, take cover!" 10 seconds delay is unacceptable. I hear some talk about DTN for air traffic control. Safety of flight, saf= ety of life, ... I don't think so. I'll walk! Now, for some air traffic application such a perhaps passenger lists of fue= l and weight, a few seconds or a minute may not be an issue, but at that po= int you have good links and don't need DTN. Beware of the Buzz Words and Marketing. DTN is great for some things, bad = for others and there are situations were one could not communicate at all w= ithout DTN. You have to educate the customer. Do so in your proposal and point out th= e folly of DTN in a primarily voice network and you will take the contract = from those proposing otherwise. /Will From: Graham Keellings (Leonix Solutions Pte Ltd) [mailto:Graham@LeonixSolu= tions.com] Sent: Tuesday, June 09, 2009 1:50 AM To: redi@bbn.com Cc: 'Armando Caro'; Ivancic, William D. (GRC-RHN0); dtn-security@maillists.= intel-research.net Subject: Re: [dtn-security] Newbie seeking some security related advice .... As Armando describes, we are currently using streaming voice over BP. Individual packets contain 20-100ms of voice, so sending those individual buffers in an individual disrupted fashion would not make a whole lot of sense. Note that we are also working on providing voice-snippets of 1-10s Wow! That surely *is* delay tolerant (if not disruption tolerant). You have= to wait until you have collected 10 seconds of voice at the sender before = transmitting. That guarantees a lag of over 9 seconds at the receiver, or 1= 8+ seconds to get a reply to a question. I think that I need to rethink :-) Or, at least, we can say that such de= lay might be acceptable in some scenarios, but not in others. Nasa might ha= ve no choice, given the lag inherent in very long range transmissions, but = I doubt that DARPA can accept multi-seconds delays in combat scenarios. I am looking at a "real time" voice network, where it has been strongly "su= ggested" that I use DTN, but I am thinking that all that it will bring to m= y particular use case is that I don't have to worry about "link lost" for a= short time bringing down the call. My personal feel is that DTN is not th= e right tool for the job for a mainly voice based short range system where = speed of reply is of the essence. I don't see that the benefits justify it,= but then I don't get to make the decision (and if I recommend against it, = I probably don't get the contract. Sigh) Thank you very much for taking he time to reply and for helping me to clari= fy my thoughts. With best wishes, Graham --_000_3A5AA67A8B120B48825BFFCF5443856137E3553C4BNDJSSCC03ndcn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Graham,

 

Some applications simply are not delay tolerant.  If I = need to say “Incoming, take cover!”  10 seconds delay is unacceptable.

 

I hear some talk about DTN for  air traffic control.&nb= sp; Safety of flight, safety of life, ... I don’t think so.  I’= ;ll walk!

 

Now, for some air traffic application such a perhaps passeng= er lists of fuel and weight, a few seconds or a minute may not be an issue, bu= t at that point you have good links and don’t need DTN.<= /p>

 

Beware of the Buzz Words and Marketing.  DTN is great f= or some things, bad for others and there are situations were one could not communicate at all without DTN.

 

You have to educate the customer.   Do so in your proposal and point out the folly of DTN in a primarily voice network and yo= u will take the contract from those proposing otherwise.

 

 

/Will

 

From: Graham Keellings (Leonix Solutions= Pte Ltd) [mailto:Graham@LeonixSolutions.com]
Sent: Tuesday, June 09, 2009 1:50 AM
To: redi@bbn.com
Cc: 'Armando Caro'; Ivancic, William D. (GRC-RHN0); dtn-security@maillists.intel-research.net
Subject: Re: [dtn-security] Newbie seeking some security related adv= ice

 

....
As Arma=
ndo describes, we are currently using streaming voice over BP.
Individual packets contain 20-100ms of voice, so sending those ind=
ividual
buffers in an individual disrupted fashion wou=
ld not make a whole lot of
sense.  


Note that w=
e are also working on providing voice-snippets of 1-10s
  



Wow! That surely *is* del=
ay tolerant
(if not disruption tolerant). You have to wait until you have collected 10
seconds of voice at the sender before transmitting. That guarantees a lag o=
f
over 9 seconds at the receiver, or 18+ seconds to get a reply to a question=
.



I think that I need to rethink :-)   Or,  at least, we can s=
ay
that such delay might be acceptable in some scenarios, but not in others. N=
asa
might have no choice, given the lag inherent in very long range transmissio=
ns,
but I doubt that DARPA can accept multi-seconds delays in combat scenarios.=




I am looking at a "real time" voice network, where it has been
strongly "suggested" that I use DTN, but I am thinking that all t=
hat
it will bring to my particular use case is that I don't have to worry about
"link lost" for a short time bringing down the call.  My
personal feel is that DTN is not the right tool for the job for a mainly vo=
ice
based short range system where speed of reply is of the essence. I don't se=
e
that the benefits justify it, but then I don't get to make the decision (an=
d if
I recommend against it, I probably don't get the contract. Sigh)



Thank you very much for taking he time to reply and for helping me to clari=
fy
my thoughts.



With best wishes,



Graham 









 
--_000_3A5AA67A8B120B48825BFFCF5443856137E3553C4BNDJSSCC03ndcn_-- Received: from SG2EHSOBE002.bigfish.com (sg2ehsobe002.messaging.microsoft.com [207.46.51.76]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n59AAJOj030248 for ; Tue, 9 Jun 2009 03:10:20 -0700 Received: from mail2-sin-R.bigfish.com (10.210.100.240) by SG2EHSOBE002.bigfish.com (10.210.112.22) with Microsoft SMTP Server id 8.1.340.0; Tue, 9 Jun 2009 10:02:14 +0000 Received: from mail2-sin (localhost.localdomain [127.0.0.1]) by mail2-sin-R.bigfish.com (Postfix) with ESMTP id 046771650208; Tue, 9 Jun 2009 10:02:14 +0000 (UTC) X-SpamScore: -35 X-BigFish: VPS-35(zz1418M1432R98dR148cM1805Mzz1202hzz1033ILz2dh6bh17ch87il61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: by mail2-sin (MessageSwitch) id 1244541731899065_31084; Tue, 9 Jun 2009 10:02:11 +0000 (UCT) Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail2-sin.bigfish.com (Postfix) with ESMTP id 14B87A8052; Tue, 9 Jun 2009 10:02:11 +0000 (UTC) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 21F5968005; Tue, 9 Jun 2009 11:02:09 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A02988152C8; Tue, 09 Jun 2009 11:02:09 +0100 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id E989668005; Tue, 9 Jun 2009 11:02:08 +0100 (IST) Message-ID: <4A2E3321.901@cs.tcd.ie> Date: Tue, 9 Jun 2009 11:02:09 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: M.Bhutta@surrey.ac.uk References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B159@EVS-EC1-NODE2.surrey.ac.uk> In-Reply-To: <89E48AE60E64EF4E8EB32B0B7EC74920A1B159@EVS-EC1-NODE2.surrey.ac.uk> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A12988152C8 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.107.6) Cc: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Key Management hop-by-hop ciphersuite X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 10:10:21 -0000 Hi Nasir, M.Bhutta@surrey.ac.uk wrote: > Hi, > >>From internet-draft "Key Management Requirements", it is a requirement > that key management should support all mandatory ciphersuites. First I wouldn't take that (expired) draft as being something that's gotten broad consensus - at this stage I think its really just a set of opinions of mine, but I'm really happy to get others' input, so thanks for bringing it up. The point I was trying to make with that requirement is that if someone does go and define a (generic) key management scheme for DTNs, then they had better consider the existing ciphersuites. I've seen some papers both in DTN and more generally related to PKI where the authors define a key management scheme that won't do that (e.g. I guess some of the IBE things). The problem with that would be that we'd end up with a way to establish keys, but no (interoperable) way to use 'em. Were the authors of such key management schemes to also fully specify accompanying ciphersuites then I think that'd be fine. (I'm not saying I'd agree with 'em, but at that point at least we could have a good argument:-) > For Hop-by-Hop integrity and authentication, the ciphersuite > BAB-HMAC only supports symmetric cryptography.. > > 1. Does this means, when we are looking for key establishment > while assuming pre-installed public keys, then we also have to take > assumption that symmetric keys also exist between two nodes for > hop-by-hop authentication and integrity.. Not necessarily. If you assume pre-installed public keys, then you could define a new bundle payload protocol (or set of extension blocks, not sure) that'd allow you to do key transport or key agreement in order to manage those shared secrets. I'd really like to see someone write that I-D. The core of that is pretty easy, it probably just needs to adopt some CMS structures for key transport/agreement. I think the main issue though would be how to gracefully handle lost or badly delayed bundles. For example, if a key manager tries to distribute new keys to nodes 1 & 2 but the relevant bundles only arrive at node 1, then how do we ensure that we don't break BAB verification between nodes 1 & 2? Probably by allowing some kind of window but there's work to be done to get that right. Actually that might usefully use the stuff about superseding bundles [1] now that I think of it. And/or maybe node 1 could pass along the key mgmt extension to node 2 similar to how kerberos does things. Getting that right requires a bit of thought and consideration of various use cases and failure modes so its non-trivial. (But again, I'd love to see someone take it on.) > > 2. Are we not making Key Management dependent on distribution of > symmetric keys between forwarder and intermediate receiver while using > public key only.. No. See #1 above:-) S. [1] http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extension-block-00.txt > > Please comment... > > thanks > > regards, > Nasir > > > ------------------------------------------------------------------------ > > _______________________________________________ > dtn-security mailing list > dtn-security@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-security Received: from sky.fastbighost.net (sky.fastbighost.net [76.76.22.153]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n595w3nJ018811 for ; Mon, 8 Jun 2009 22:58:04 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.138]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MDuDe-0000aS-JQ; Tue, 09 Jun 2009 01:49:59 -0400 Message-ID: <4A2DF7FD.5020104@LeonixSolutions.com> Date: Tue, 09 Jun 2009 13:49:49 +0800 From: "Graham Keellings (Leonix Solutions Pte Ltd)" Organization: Leonix Solutions Pte Ltd User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: redi@bbn.com References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <4A12195A.6000207@LeonixSolutions.com> <3A5AA67A8B120B48825BFFCF5443856137E0B06196@NDJSSCC03.ndc.nasa.gov> <4A1DD73F.50000@bbn.com> <023601c9df2a$694fd5b0$3bef8110$@com> In-Reply-To: <023601c9df2a$694fd5b0$3bef8110$@com> Content-Type: multipart/mixed; boundary="------------010300070906010207070007" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sky.fastbighost.net X-AntiAbuse: Original Domain - maillists.intel-research.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - LeonixSolutions.com X-Source: X-Source-Args: X-Source-Dir: Cc: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Newbie seeking some security related advice X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 05:58:05 -0000 This is a multi-part message in MIME format. --------------010300070906010207070007 Content-Type: multipart/alternative; boundary="------------030302050908050209090405" --------------030302050908050209090405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jason Redi wrote: > Minor comment to Armando's email: > > >> -----Original Message----- >> From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn- >> security-bounces@maillists.intel-research.net] On Behalf Of Armando >> Caro >> Sent: Wednesday, May 27, 2009 8:14 PM >> To: Ivancic, William D. (GRC-RHN0) >> Cc: dtn-security@maillists.intel-research.net >> Subject: Re: [dtn-security] Newbie seeking some security related advice >> >> Ivancic, William D. (GRC-RHN0) wrote: >> >>> I believe DARPA is using DTN for voice networks but I believe the >>> >> disruption is expected to be very quick fades and the like or perhaps >> that voice simply will not make sense at certain times. >> >> I believe you are referring to the work that BBN is doing for the DARPA >> WNaN program. For this program, we run IP over DTN and use VoIP without >> modifications to the VoIP application. We are using the BPA as a >> forwarding engine that works in both connected and disconnected >> scenarios. VoIP traffic (and other delay sensitive traffic) are only >> routed/forwarded to destinations that are currently connected, since >> VoIP doesn't make sense for disconnected destinations. If a node >> receives VoIP traffic for a disconnected destination, the traffic is >> dropped. >> > > As Armando describes, we are currently using streaming voice over BP. > Individual packets contain 20-100ms of voice, so sending those individual > buffers in an individual disrupted fashion would not make a whole lot of > sense. > Note that we are also working on providing voice-snippets of 1-10s > Wow! That surely *is* delay tolerant (if not disruption tolerant). You have to wait until you have collected 10 seconds of voice at the sender before transmitting. That guarantees a lag of over 9 seconds at the receiver, or 18+ seconds to get a reply to a question. I think that I need to rethink :-) Or, at least, we can say that such delay might be acceptable in some scenarios, but not in others. Nasa might have no choice, given the lag inherent in very long range transmissions, but I doubt that DARPA can accept multi-seconds delays in combat scenarios. I am looking at a "real time" voice network, where it has been strongly "suggested" that I use DTN, but I am thinking that all that it will bring to my particular use case is that I don't have to worry about "link lost" for a short time bringing down the call. My personal feel is that DTN is not the right tool for the job for a mainly voice based short range system where speed of reply is of the essence. I don't see that the benefits justify it, but then I don't get to make the decision (and if I recommend against it, I probably don't get the contract. Sigh) Thank you very much for taking he time to reply and for helping me to clarify my thoughts. With best wishes, Graham > that could be sent in a disrupted fashion over the network. But ultimately > that's just data like any other bundle. The only real "work" there is in > the application, not the BP. > > The key point is that voice can either be streaming as little snippets or > buffered as a big blob. If it is a big blob, it's just another bundle. If > it is streaming, then one needs to make sure you have a BPA/router that adds > only a minimal amount of additional overhead to the forwarding process. (as > Armando says below) > > >> One important take-away from this work... the motivation of DTN is to >> support delay/disrupted scenarios and apps that can operate in that >> regime, but it is possible to implement a DTN stack that can also deal >> with time-sensitive traffic. >> >> Armando >> _______________________________________________ >> dtn-security mailing list >> dtn-security@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-security >> > > > _______________________________________________ > dtn-security mailing list > dtn-security@maillists.intel-research.net > 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 --------------030302050908050209090405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jason Redi wrote: 
Minor comment to Armando's email:

  
-----Original Message-----
From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn-
security-bounces@maillists.intel-research.net] On Behalf Of Armando
Caro
Sent: Wednesday, May 27, 2009 8:14 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-security@maillists.intel-research.net
Subject: Re: [dtn-security] Newbie seeking some security related advice

Ivancic, William D. (GRC-RHN0) wrote:
    
I believe DARPA is using DTN for voice networks but I believe the
      
disruption is expected to be very quick fades and the like or perhaps
that voice simply will not make sense at certain times.

I believe you are referring to the work that BBN is doing for the DARPA
WNaN program. For this program, we run IP over DTN and use VoIP without
modifications to the VoIP application. We are using the BPA as a
forwarding engine that works in both connected and disconnected
scenarios. VoIP traffic (and other delay sensitive traffic) are only
routed/forwarded to destinations that are currently connected, since
VoIP doesn't make sense for disconnected destinations. If a node
receives VoIP traffic for a disconnected destination, the traffic is
dropped.
    

As Armando describes, we are currently using streaming voice over BP.
Individual packets contain 20-100ms of voice, so sending those individual
buffers in an individual disrupted fashion would not make a whole lot of
sense.  
Note that we are also working on providing voice-snippets of 1-10s
Wow! That surely *is* delay tolerant (if not disruption tolerant). You have to wait until you have collected 10 seconds of voice at the sender before transmitting. That guarantees a lag of over 9 seconds at the receiver, or 18+ seconds to get a reply to a question.

I think that I need to rethink :-)   Or,  at least, we can say that such delay might be acceptable in some scenarios, but not in others. Nasa might have no choice, given the lag inherent in very long range transmissions, but I doubt that DARPA can accept multi-seconds delays in combat scenarios.

I am looking at a "real time" voice network, where it has been strongly "suggested" that I use DTN, but I am thinking that all that it will bring to my particular use case is that I don't have to worry about "link lost" for a short time bringing down the call.  My personal feel is that DTN is not the right tool for the job for a mainly voice based short range system where speed of reply is of the essence. I don't see that the benefits justify it, but then I don't get to make the decision (and if I recommend against it, I probably don't get the contract. Sigh)

Thank you very much for taking he time to reply and for helping me to clarify my thoughts.

With best wishes,

Graham 


that could be sent in a disrupted fashion over the network.  But ultimately
that's just data like any other bundle.  The only real "work" there is in
the application, not the BP.   

The key point is that voice can either be streaming as little snippets or
buffered as a big blob.  If it is a big blob, it's just another bundle.  If
it is streaming, then one needs to make sure you have a BPA/router that adds
only a minimal amount of additional overhead to the forwarding process.  (as
Armando says below)
 
  
One important take-away from this work... the motivation of DTN is to
support delay/disrupted scenarios and apps that can operate in that
regime, but it is possible to implement a DTN stack that can also deal
with time-sensitive traffic.

Armando
_______________________________________________
dtn-security mailing list
dtn-security@maillists.intel-research.net
http://maillists.intel-research.net/mailman/listinfo/dtn-security
    


_______________________________________________
dtn-security mailing list
dtn-security@maillists.intel-research.net
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
--------------030302050908050209090405-- --------------010300070906010207070007 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:Graham@LeonixSolutions.com 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 --------------010300070906010207070007-- Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id n58JEI6h022246 for ; Mon, 8 Jun 2009 12:14:18 -0700 X-VirusChecked: Checked X-Env-Sender: M.Bhutta@surrey.ac.uk X-Msg-Ref: server-10.tower-78.messagelabs.com!1244487989!63812660!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 13126 invoked from network); 8 Jun 2009 19:06:29 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-10.tower-78.messagelabs.com with SMTP; 8 Jun 2009 19:06:29 -0000 Received: from EVS-EC1-NODE2.surrey.ac.uk ([131.227.102.137]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Jun 2009 20:06:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E86C.39D8256A" Date: Mon, 8 Jun 2009 20:06:28 +0100 Message-ID: <89E48AE60E64EF4E8EB32B0B7EC74920A1B159@EVS-EC1-NODE2.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Key Management hop-by-hop ciphersuite Thread-Index: AcnobDnQ7GznLCbpR2esYNvzODafxw== From: To: X-OriginalArrivalTime: 08 Jun 2009 19:06:28.0909 (UTC) FILETIME=[3A4E45D0:01C9E86C] Subject: [dtn-security] Key Management hop-by-hop ciphersuite X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 19:14:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E86C.39D8256A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 >From internet-draft "Key Management Requirements", it is a requirement = that key management should support all mandatory ciphersuites.=20 For Hop-by-Hop integrity and authentication, the ciphersuite = BAB-HMAC only supports symmetric cryptography..=20 1. Does this means, when we are looking for key establishment = while assuming pre-installed public keys, then we also have to take = assumption that symmetric keys also exist between two nodes for = hop-by-hop authentication and integrity..=20 2. Are we not making Key Management dependent on distribution of = symmetric keys between forwarder and intermediate receiver while using = public key only..=20 Please comment...=20 thanks=20 regards, Nasir ------_=_NextPart_001_01C9E86C.39D8256A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Key Management hop-by-hop ciphersuite

Hi,

>From internet-draft "Key Management Requirements", it is a = requirement that key management should support all mandatory = ciphersuites.
      For Hop-by-Hop integrity and = authentication, the ciphersuite BAB-HMAC only supports symmetric = cryptography..

     1.  Does this means, when we are looking = for key establishment while assuming pre-installed public keys, then we = also have to take assumption that symmetric keys also exist between two = nodes for hop-by-hop authentication and integrity..

     2. Are we not making Key Management dependent = on distribution of symmetric keys between forwarder and intermediate = receiver while using public key  only..

Please comment...

thanks

regards,
Nasir

------_=_NextPart_001_01C9E86C.39D8256A--