Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6HJOlP4021837 for ; Fri, 17 Jul 2009 12:24:47 -0700 Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id AF5F53282DA; Fri, 17 Jul 2009 14:22:57 -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 n6HJMvAc011537; Fri, 17 Jul 2009 14:22:57 -0500 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Fri, 17 Jul 2009 14:22:57 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Peter Lovell , Sushil Chaudhari , "dtn-security@maillists.intel-research.net" Date: Fri, 17 Jul 2009 14:22:48 -0500 Thread-Topic: [dtn-security] Re(2): Header Encryption Thread-Index: AcoHC1+krIKKVPpwTpik5rGtrhVbzwACFR0Q Message-ID: <3A5AA67A8B120B48825BFFCF5443856137E5377269@NDJSSCC03.ndc.nasa.gov> References: <20090717155125.7458.qmail@mzeal.com> <20090717162014.1496793716@smtp.mac.com> In-Reply-To: <20090717162014.1496793716@smtp.mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" 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-07-17_12:2009-07-03, 2009-07-17, 2009-07-17 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n6HJOlP4021837 Subject: Re: [dtn-security] Re(2): Header Encryption 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: Fri, 17 Jul 2009 19:24:48 -0000 >>2.Does DTN2 can be used with IPSEC? if not do we need additional >>convergence layer for the support to IPSEC? > >I know of no particular reason it would be a problem but I must admit I >haven't tried it. I'm sure others have and maybe they'll comment on >successes or failure. > >Regards.....Peter > In the NASA internal multi-center testbed, the IP network bubble at each center are connected via IPsec tunnels. DTN over IP over IPsec tunnels is run all the time. IPsec is independent of DTN layer security. /Will Received: from mzeal.com (mzeal.com [199.237.228.71]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6HJ7xCa021073 for ; Fri, 17 Jul 2009 12:07:59 -0700 Received: (qmail 17427 invoked by uid 25671); 17 Jul 2009 19:06:10 -0000 Message-ID: <20090717190610.17426.qmail@mzeal.com> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8"; format="flowed" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.0104 (F2.72; T1.15; A1.47; B3.01; Q3.01) Date: Fri, 17 Jul 2009 19:06:10 +0000 From: "Sushil Chaudhari" To: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Header Encryption 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: Fri, 17 Jul 2009 19:08:00 -0000 Thank you for the replies. But please clearify the following questions: 1. Does IPSec require “gateway” nodes, as bundle-in-bundle encapsulation require? 2. Does IPSec provide bundle data integrity and authenticity validation? Received: from mzeal.com (mzeal.com [199.237.228.71]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6HIx9Xl020609 for ; Fri, 17 Jul 2009 11:59:09 -0700 Received: (qmail 12359 invoked by uid 25671); 17 Jul 2009 18:57:20 -0000 Message-ID: <20090717185720.12358.qmail@mzeal.com> Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII"; format="flowed" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.0104 (F2.72; T1.15; A1.47; B3.01; Q3.01) Date: Fri, 17 Jul 2009 18:57:20 +0000 From: "Sushil Chaudhari" To: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Header Encryption 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: Fri, 17 Jul 2009 18:59:10 -0000 Hi, We are using BSP and while observing bundles on Wireshark, the header seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-security-08, "every bundle must contain a primary block that contains the source and destination EID's that can not be encrypted" My question is, 1.Do we have some method for header encryption? 2.Does DTN2 can be used with IPSEC? if not do we need additional convergence layer for the support to IPSEC? Thanks.. 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 n6HIKrhn018925 for ; Fri, 17 Jul 2009 11:20:53 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from [157.185.80.152] by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMX009LNUVFTFA0@asmtp020.mac.com> for dtn-security@maillists.intel-research.net; Fri, 17 Jul 2009 11:18:55 -0700 (PDT) From: Peter Lovell To: Sushil Chaudhari , dtn-security@maillists.intel-research.net Date: Fri, 17 Jul 2009 12:20:14 -0400 Message-id: <20090717162014.1496793716@smtp.mac.com> In-reply-to: <20090717155125.7458.qmail@mzeal.com> References: <20090717155125.7458.qmail@mzeal.com> X-Mailer: CTM PowerMail version 5.6.3 build 4504 English (PPC) Subject: [dtn-security] Re(2): Header Encryption 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: Fri, 17 Jul 2009 18:20:54 -0000 On Fri, Jul 17, 2009, Sushil Chaudhari wrote: >We are using BSP and while observing bundles on Wireshark, the header >seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle- >security-08, "every bundle must contain a primary block that contains >the source and destination EID's that can not be encrypted" > >My question is, >1.Do we have some method for header encryption? The nodes need to be able to process the bundle, so you need basic things like addresses. If it's important to encrypt the headers, about your only choice is bundle-in-bundle encapsulation. You then encrypt the encapsulated bundle (PCB). But this new bundle *still* needs a primary block, and addresses, and the like. What goal are you trying to achieve? >2.Does DTN2 can be used with IPSEC? if not do we need additional >convergence layer for the support to IPSEC? I know of no particular reason it would be a problem but I must admit I haven't tried it. I'm sure others have and maybe they'll comment on successes or failure. Regards.....Peter 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 n6HHw5sf017865 for ; Fri, 17 Jul 2009 10:58:05 -0700 Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 0D17B2D81B6; Fri, 17 Jul 2009 12:56:16 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n6HHuFpc014187; Fri, 17 Jul 2009 12:56:15 -0500 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Fri, 17 Jul 2009 12:56:15 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Sushil Chaudhari , "dtn-security@maillists.intel-research.net" Date: Fri, 17 Jul 2009 12:56:06 -0500 Thread-Topic: [dtn-security] Header Encryption Thread-Index: AcoG+CsYD4EuVayXRDWqqrNBJDf4twADvBGA Message-ID: <3A5AA67A8B120B48825BFFCF5443856137E53771DB@NDJSSCC03.ndc.nasa.gov> References: <20090717160140.13080.qmail@mzeal.com> In-Reply-To: <20090717160140.13080.qmail@mzeal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" 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-07-17_12:2009-07-03, 2009-07-17, 2009-07-17 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n6HHw5sf017865 Subject: Re: [dtn-security] Header Encryption 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: Fri, 17 Jul 2009 17:58:06 -0000 DTN header compression can be done similar to IPsec tunnel mode via first doing bundle-in-bundle and then encrypting the internal bundle using PCB of the BSP. Basically you set a DTNsec tunnel mode. I haven't done it, but that would be how one would do it. IPsec if independent of DTN security. If you want IPsec "for linux" use the tools I pointed to a few days ago. IPsec Tools which get you SETKEY The "IP" command on newer builds also has static key configuration capability. There are a about 4 IKEv2 implementations I am aware of. My personal preference for what I needed was StrongSwan. Have fun with security. Remember - Security is the Ultimate Denial of Service and Security Breaks everything. If you are trying to learn DTN, my recommendation is do it without security first. /Will >-----Original Message----- >From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn- >security-bounces@maillists.intel-research.net] On Behalf Of Sushil >Chaudhari >Sent: Friday, July 17, 2009 12:02 PM >To: dtn-security@maillists.intel-research.net >Subject: Re: [dtn-security] Header Encryption > >Hi, > >We are using BSP and while observing bundles on Wireshark, the header >seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-security- >08, "every bundle must contain a primary block that contains the source >and destination EID's that can not be encrypted" > >My question is, >1.Do we have some method for header encryption? >2.Does DTN2 can be used with IPSEC? if not do we need additional >convergence layer for the support to IPSEC? > >Thanks.. >_______________________________________________ >dtn-security mailing list >dtn-security@maillists.intel-research.net >http://maillists.intel-research.net/mailman/listinfo/dtn-security Received: from mzeal.com (mzeal.com [199.237.228.71]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6HG3RTM012747 for ; Fri, 17 Jul 2009 09:03:28 -0700 Received: (qmail 13081 invoked by uid 25671); 17 Jul 2009 16:01:40 -0000 Message-ID: <20090717160140.13080.qmail@mzeal.com> Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII"; format="flowed" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.0104 (F2.72; T1.15; A1.47; B3.01; Q3.01) Date: Fri, 17 Jul 2009 16:01:40 +0000 From: "Sushil Chaudhari" To: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Header Encryption 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: Fri, 17 Jul 2009 16:03:28 -0000 Hi, We are using BSP and while observing bundles on Wireshark, the header seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-security-08, "every bundle must contain a primary block that contains the source and destination EID's that can not be encrypted" My question is, 1.Do we have some method for header encryption? 2.Does DTN2 can be used with IPSEC? if not do we need additional convergence layer for the support to IPSEC? Thanks.. Received: from mzeal.com (mzeal.com [199.237.228.71]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6HFrCPq012259 for ; Fri, 17 Jul 2009 08:53:13 -0700 Received: (qmail 7460 invoked by uid 25671); 17 Jul 2009 15:51:25 -0000 Message-ID: <20090717155125.7458.qmail@mzeal.com> Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII"; format="flowed" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.0104 (F2.72; T1.15; A1.47; B3.01; Q3.01) Date: Fri, 17 Jul 2009 15:51:25 +0000 From: "Sushil Chaudhari" To: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Header Encryption 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: Fri, 17 Jul 2009 15:53:13 -0000 Hi, We are using BSP and while observing bundles on Wireshark, the header seems to be unencrypted. Also as per draft-irtf-dtnrg-bundle-security-08, "every bundle must contain a primary block that contains the source and destination EID's that can not be encrypted" My question is, 1.Do we have some method for header encryption? 2.Does DTN2 can be used with IPSEC? if not do we need additional convergence layer for the support to IPSEC? Thanks.. Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6GJ6Gad020248 for ; Thu, 16 Jul 2009 12:06:16 -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 asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMW00LVT2BDGE00@asmtp015.mac.com> for dtn-security@maillists.intel-research.net; Thu, 16 Jul 2009 12:04:28 -0700 (PDT) From: Peter Lovell To: Sushil Chaudhari , dtn-security@maillists.intel-research.net Date: Thu, 16 Jul 2009 15:04:23 -0400 Message-id: <20090716190423.1267272697@smtp.mac.com> In-reply-to: <20090716180755.89960.qmail@mzeal.com> References: <20090716180755.89960.qmail@mzeal.com> X-Mailer: CTM PowerMail version 6.0.2 build 4601 English (intel) Subject: [dtn-security] Re(4): 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: Thu, 16 Jul 2009 19:06:16 -0000 On Thu, Jul 16, 2009, Sushil Chaudhari wrote: >Hi, > >It looks as PC3 ciphersuite actually implemented for AES GCM mode. If I >read RFC4106 correctly, it does provide confidentiality, data origin and >data integrity authentication... > >Apparently, it does fulfill the purpose of all 3 security blocks. > >Am I read something incorrectly? Your analysis is a bit to simplistic. PC3 does guarantee that the payload data (and only the payload data) has not been changed in transit. But there's no "certificate of authenticity". You do not know who originated the data. You know it is unmodified but you don't know if it's genuine. With PIB you get a signature from the sender so you know, within the constraints of your keying mechanism, who actually sent the data. Regards....Peter Received: from mzeal.com (mzeal.com [199.237.228.71]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6GI9aUR017614 for ; Thu, 16 Jul 2009 11:09:37 -0700 Received: (qmail 89961 invoked by uid 25671); 16 Jul 2009 18:07:55 -0000 Message-ID: <20090716180755.89960.qmail@mzeal.com> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8"; format="flowed" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.0104 (F2.72; T1.15; A1.47; B3.01; Q3.01) Date: Thu, 16 Jul 2009 18:07:55 +0000 From: "Sushil Chaudhari" To: plovell@mac.com, schaudhari@mzeal.com, dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Re(2): 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: Thu, 16 Jul 2009 18:09:37 -0000 Hi, It looks as PC3 ciphersuite actually implemented for AES GCM mode. If I read RFC4106 correctly, it does provide confidentiality, data origin and data integrity authentication… Apparently, it does fulfill the purpose of all 3 security blocks. Am I read something incorrectly? 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 n6G2DaI1006705 for ; Wed, 15 Jul 2009 19:13:36 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.103]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MRGRx-00052K-9R; Wed, 15 Jul 2009 22:11:57 -0400 Message-ID: <4A5E8C6C.5020506@LeonixSolutions.com> Date: Thu, 16 Jul 2009 10:11:56 +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> <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> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com> <20090709041417.302976474@smtp.mac.com> <4A56E1CA.7080000@LeonixSolutions.com> <20090710120958.2016629300@smtp.mac.com> <4A5AA83C.7030400@LeonixSolutions.com> <20090713134603.958934311@smtp.mac.com> <4A5D4703.1000002@LeonixSolutions.com> <20090715114903.2002525481@smtp.mac.com> In-Reply-To: <20090715114903.2002525481@smtp.mac.com> Content-Type: multipart/mixed; boundary="------------030706070700010003080008" 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] Encrypted IP headers 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: Thu, 16 Jul 2009 02:13:37 -0000 This is a multi-part message in MIME format. --------------030706070700010003080008 Content-Type: multipart/alternative; boundary="------------080800000701040905030407" --------------080800000701040905030407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Lovell wrote: > On Wed, Jul 15, 2009, Graham Keellings (Leonix Solutions Pte Ltd) > wrote: > > >>> Most systems have some interaction with the outside even >>> though the community may be a closed one. >>> >>> >> Many military, navy, government, financial systems have a hard >> requirement that they do not communicate with the internet (or even with >> anything that does). In my case, I can live with that. >> > > I guess I need to enlarge on the point I was trying to make. > Thanks again for replying , Peter. I think I grokked all that you said and we seem to be in understanding here. I do hope that these discussions don't take up too much of your time, but you are an invaluable sounding-board. > A fully-isolated system will be easier to secure but this requires full > isolation. That is, no networking contact at all with the outside. Well, no _intended_ contact with the outside world. It's easy enough to achieve no contact with wired networks (ignoring USB sticks, CDs, etc, introducing something into the system). But I am talking of a wireless network, so I can only say that my intention would be to have no contact to the outside world - but I can't stop IP packets floating around on the frequency to which my nodes are listening. And that introduces the potential for security problems. If possible, I would like to deflect these problems as early as possible, and IP header encryption seems a reasonable solution. > Once > you have that, I'm not sure that encrypting the IP headers etc gives you > a decent return on your effort. > > I can't say either way. Will probably have to build it and profile it. If I can deflect rogue packets "quickly enough" to prevent DOS, then it's worth it. If not, then my IP header encryption only exacerbates the problem by adding more overhead. Hmmm, thinking abut it, it does not seem to offer anything for DOS deflection... what about other security advantages? I am thinking here of TCP/IP, not DTN. Are there any TCP/IP exploits which I can defend against with IP header encryption? Man in the middle, IP spoofing, etc? > The challenging situations where dtn is attractive will probably have > interactions with the outside world, even though there might not be > "communication" in the sense of exchanging information. If you have a > portable radio, it has to deal with every packet in order to find the > ones of interest. So your community might be closed but, at the lowest > level, you have to listen to everything. And that's where the trouble starts. > Yes, I see that. So, I am adding overhead there and have to ask if a) it is tolerable in absolute timing terms (but routers do this all the time, with MAC address filtering) and b) the overhead brings be security gains in TCP/IP. And, coming from the GSM/ UMTS / Satellite world, I don't know enough about TCP/IP security, but am trying to get up to speed fast. Thanks, as always, for your insight. > Regards.....Peter > > > -- Technical Director Leonix Solutions (Pte) Ltd 18 Boon Lay Way #09-95 TradeHub 21 Singapore 609966 Telephone:+65 6316 9968 Fax: +65 6316 9208 --------------080800000701040905030407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Lovell wrote: 
On Wed, Jul 15, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<Graham@LeonixSolutions.com> wrote:

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

I guess I need to enlarge on the point I was trying to make.
Thanks again for replying , Peter. I think I grokked all that you said and we seem to be in understanding here. I do hope that these discussions don't take up too much of your time, but you are an invaluable sounding-board. 


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

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

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


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

Thanks, as always, for your insight.

Regards.....Peter


  


-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208
--------------080800000701040905030407-- --------------030706070700010003080008 Content-Type: text/x-vcard; charset=utf-8; name="Graham.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Graham.vcf" begin:vcard fn:Graham Keellings n:Keellings;Graham org:Leonix Solutions Pte Ltd adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore email;internet: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 --------------030706070700010003080008-- 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 n6FMMrRh028634 for ; Wed, 15 Jul 2009 15:22:53 -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 asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMU00IG3GRFA830@asmtp021.mac.com> for dtn-security@maillists.intel-research.net; Wed, 15 Jul 2009 15:21:19 -0700 (PDT) From: Peter Lovell To: Sushil Chaudhari , dtn-security@maillists.intel-research.net Date: Wed, 15 Jul 2009 18:21:15 -0400 Message-id: <20090715222115.1044991942@smtp.mac.com> In-reply-to: <20090715214939.91774.qmail@mzeal.com> References: <20090715214939.91774.qmail@mzeal.com> X-Mailer: CTM PowerMail version 6.0.2 build 4601 English (intel) Subject: [dtn-security] Re(2): 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: Wed, 15 Jul 2009 22:22:53 -0000 On Wed, Jul 15, 2009, Sushil Chaudhari wrote: >As mentioned in the draft-irtf-dtnrg-bundle-security-08 : >The BAB ciphersuite is based on shared secret using HMAC. >The PIB is based on digital signatures using RSA with SHA 256. >the PCB and ESB are based on RSA with AES. > >My question is, do we have (or can we implement) any common ciphersuite >for all of the security blocks? Well, there's no common ciiphersuite because they serve different purposes. PCB encrypts the data, for example, while PIB allows you to verify it hasn't been altered but does not make it secret. What are you trying to achieve? Regards.....Peter Received: from mzeal.com (mzeal.com [199.237.228.71]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6FLpDl7027128 for ; Wed, 15 Jul 2009 14:51:13 -0700 Received: (qmail 91775 invoked by uid 25671); 15 Jul 2009 21:49:39 -0000 Message-ID: <20090715214939.91774.qmail@mzeal.com> Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII"; format="flowed" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.0104 (F2.72; T1.15; A1.47; B3.01; Q3.01) Date: Wed, 15 Jul 2009 21:49:39 +0000 From: "Sushil Chaudhari" To: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] 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: Wed, 15 Jul 2009 21:51:13 -0000 Hi, As mentioned in the draft-irtf-dtnrg-bundle-security-08 : The BAB ciphersuite is based on shared secret using HMAC. The PIB is based on digital signatures using RSA with SHA 256. the PCB and ESB are based on RSA with AES. My question is, do we have (or can we implement) any common ciphersuite for all of the security blocks? Thanks 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 n6FFh5cF010155 for ; Wed, 15 Jul 2009 08:43:06 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from [157.185.80.152] by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMT000HUY91MT00@asmtp017.mac.com> for dtn-security@maillists.intel-research.net; Wed, 15 Jul 2009 08:41:34 -0700 (PDT) From: Peter Lovell To: "Ivancic, William D. (GRC-RHN0)" , Sushil Chaudhari , dtn-security@maillists.intel-research.net Date: Wed, 15 Jul 2009 11:41:25 -0400 Message-id: <20090715154125.1031934993@smtp.mac.com> In-reply-to: <3A5AA67A8B120B48825BFFCF5443856137E50D04FE@NDJSSCC03.ndc.nasa.gov> References: <20090714210539.45611.qmail@mzeal.com> <3A5AA67A8B120B48825BFFCF5443856137E50D04FE@NDJSSCC03.ndc.nasa.gov> X-Mailer: CTM PowerMail version 5.6.3 build 4504 English (PPC) Subject: [dtn-security] Re(2): Key generation 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: Wed, 15 Jul 2009 15:43:06 -0000 Hi Will, in this case, "setkey" is part of a small command set that's included in DTN2 RI. It doesn't support ciphersuites other than BA1 though. Your suggestion to use openssl for key creation is good -- I recommend it too. Regards.....Peter On Wed, Jul 15, 2009, Ivancic, William D. (GRC-RHN0) wrote: >SETKEY is for IPsec and comes from IPsec tools. So, SETKEY is for IP >not DTN. But the concepts apply. > >Openssl is what you want. Openssl can create all types of keys and >certificates. > >For a quick tutorial on setting up a test Certificate Authority and >associated keys, I recommend the Strongswan configuration guide. >Someone put a lot of time and money into Strongswan as the documentation >is very good - better than most commercial system IMHO. I read this >first then look at the appropriate Openssl man pages below, then run >through the sample here. After that, you should have a decent idea on >what you may want to do with Openssl and certificates. >http://www.strongswan.org/docs/readme42.htm#section_3 > > >Use Openssl to create keys. Having used Openssl, I found the books >rather limiting. You may want to go online and use the manuals as >there are lots of hyperlinks. >http://www.openssl.org/docs/apps/openssl.html > > >/Will > > >>-----Original Message----- >>From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn- >>security-bounces@maillists.intel-research.net] On Behalf Of Sushil >>Chaudhari >>Sent: Tuesday, July 14, 2009 5:06 PM >>To: dtn-security@maillists.intel-research.net >>Subject: Re: [dtn-security] Key generation >> >>Hi, >> >>There's setkey command used to set the key >>for the specified host and ciphersuite. >> >>What utility is used to produce the key? >> >>If security policy is set to use "confidentiality block" and no external >>key is provided, how's the key get generated by DTN2? >> Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6FCSha8001160 for ; Wed, 15 Jul 2009 05:28:43 -0700 Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id D7F692D82F5; Wed, 15 Jul 2009 07:27:11 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n6FCRCp1024466; Wed, 15 Jul 2009 07:27:12 -0500 Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Wed, 15 Jul 2009 07:27:11 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Sushil Chaudhari , "dtn-security@maillists.intel-research.net" Date: Wed, 15 Jul 2009 07:27:08 -0500 Thread-Topic: [dtn-security] Key generation Thread-Index: AcoExy3xLI6/+mVqQ6OPJsUGYqeR7AAfrgdg Message-ID: <3A5AA67A8B120B48825BFFCF5443856137E50D04FE@NDJSSCC03.ndc.nasa.gov> References: <20090714210539.45611.qmail@mzeal.com> In-Reply-To: <20090714210539.45611.qmail@mzeal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" 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-07-15_04:2009-07-03, 2009-07-15, 2009-07-15 signatures=0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by maillists.intel-research.net id n6FCSha8001160 Subject: Re: [dtn-security] Key generation 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: Wed, 15 Jul 2009 12:28:44 -0000 SETKEY is for IPsec and comes from IPsec tools. So, SETKEY is for IP not DTN. But the concepts apply. Openssl is what you want. Openssl can create all types of keys and certificates. For a quick tutorial on setting up a test Certificate Authority and associated keys, I recommend the Strongswan configuration guide. Someone put a lot of time and money into Strongswan as the documentation is very good - better than most commercial system IMHO. I read this first then look at the appropriate Openssl man pages below, then run through the sample here. After that, you should have a decent idea on what you may want to do with Openssl and certificates. http://www.strongswan.org/docs/readme42.htm#section_3 Use Openssl to create keys. Having used Openssl, I found the books rather limiting. You may want to go online and use the manuals as there are lots of hyperlinks. http://www.openssl.org/docs/apps/openssl.html /Will >-----Original Message----- >From: dtn-security-bounces@maillists.intel-research.net [mailto:dtn- >security-bounces@maillists.intel-research.net] On Behalf Of Sushil >Chaudhari >Sent: Tuesday, July 14, 2009 5:06 PM >To: dtn-security@maillists.intel-research.net >Subject: Re: [dtn-security] Key generation > >Hi, > >There’s setkey command used to set the key >for the specified host and ciphersuite. > >What utility is used to produce the key? > >If security policy is set to use “confidentiality block” and no external >key is provided, how’s the key get generated by DTN2? > >Thnks. >_______________________________________________ >dtn-security mailing list >dtn-security@maillists.intel-research.net >http://maillists.intel-research.net/mailman/listinfo/dtn-security 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 n6FCN9xL000904 for ; Wed, 15 Jul 2009 05:23:09 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from [157.185.80.152] by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMT00HMQP00UF50@asmtp022.mac.com> for dtn-security@maillists.intel-research.net; Wed, 15 Jul 2009 05:21:39 -0700 (PDT) From: Peter Lovell To: Sushil Chaudhari , dtn-security@maillists.intel-research.net Date: Wed, 15 Jul 2009 08:21:37 -0400 Message-id: <20090715122137.1825897882@smtp.mac.com> In-reply-to: <20090714210539.45611.qmail@mzeal.com> References: <20090714210539.45611.qmail@mzeal.com> X-Mailer: CTM PowerMail version 5.6.3 build 4504 English (PPC) Subject: [dtn-security] Re(2): Key generation 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: Wed, 15 Jul 2009 12:23:10 -0000 On Tue, Jul 14, 2009, Sushil Chaudhari wrote: >Hi, > >There's setkey command used to set the key >for the specified host and ciphersuite. > >What utility is used to produce the key? > >If security policy is set to use "confidentiality block" and no external >key is provided, how's the key get generated by DTN2? > Hi Sushil, this is used only by the BA1 ciphersuite. For other ciphersuites you need to manage the keys (typically RSA public/private key pairs) using the KeySteward class. There is no command-set to support those at present. Regards.....Peter Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6FBoZi9031866 for ; Wed, 15 Jul 2009 04:50:35 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from [157.185.80.152] by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMT00CYDNHQGR40@asmtp019.mac.com> for dtn-security@maillists.intel-research.net; Wed, 15 Jul 2009 04:49:05 -0700 (PDT) From: Peter Lovell To: "Graham Keellings (Leonix Solutions Pte Ltd)" Date: Wed, 15 Jul 2009 07:49:03 -0400 Message-id: <20090715114903.2002525481@smtp.mac.com> In-reply-to: <4A5D4703.1000002@LeonixSolutions.com> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <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> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com> <20090709041417.302976474@smtp.mac.com> <4A56E1CA.7080000@LeonixSolutions.com> <20090710120958.2016629300@smtp.mac.com> <4A5AA83C.7030400@LeonixSolutions.com> <20090713134603.958934311@smtp.mac.com> <4A5D4703.1000002@LeonixSolutions.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): Encrypted IP headers 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: Wed, 15 Jul 2009 11:50:36 -0000 On Wed, Jul 15, 2009, Graham Keellings (Leonix Solutions Pte Ltd) wrote: >> Most systems have some interaction with the outside even >> though the community may be a closed one. >> >Many military, navy, government, financial systems have a hard >requirement that they do not communicate with the internet (or even with >anything that does). In my case, I can live with that. I guess I need to enlarge on the point I was trying to make. A fully-isolated system will be easier to secure but this requires full isolation. That is, no networking contact at all with the outside. Once you have that, I'm not sure that encrypting the IP headers etc gives you a decent return on your effort. The challenging situations where dtn is attractive will probably have interactions with the outside world, even though there might not be "communication" in the sense of exchanging information. If you have a portable radio, it has to deal with every packet in order to find the ones of interest. So your community might be closed but, at the lowest level, you have to listen to everything. And that's where the trouble starts. Regards.....Peter 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 n6F357IL007853 for ; Tue, 14 Jul 2009 20:05:07 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.103]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MQumO-00047F-IO; Tue, 14 Jul 2009 23:03:37 -0400 Message-ID: <4A5D4703.1000002@LeonixSolutions.com> Date: Wed, 15 Jul 2009 11:03:31 +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> <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> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com> <20090709041417.302976474@smtp.mac.com> <4A56E1CA.7080000@LeonixSolutions.com> <20090710120958.2016629300@smtp.mac.com> <4A5AA83C.7030400@LeonixSolutions.com> <20090713134603.958934311@smtp.mac.com> In-Reply-To: <20090713134603.958934311@smtp.mac.com> Content-Type: multipart/mixed; boundary="------------030900030109090604070404" 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] Encrypted IP headers 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: Wed, 15 Jul 2009 03:05:07 -0000 This is a multi-part message in MIME format. --------------030900030109090604070404 Content-Type: multipart/alternative; boundary="------------060202050300050706050304" --------------060202050300050706050304 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Peter Lovell wrote: > On Mon, Jul 13, 2009, Graham Keellings (Leonix Solutions Pte Ltd) > wrote: > > >> What about this then - is it even feasible? If I know that I have a >> closed universe of nodes, can I encrypt the IP headers? That might help >> prevent DOS by repeated pinging. >> >> Am I on a totally wrong track here? Or could encrypted IP headers be one >> more layer of armour? >> >> > > I guess this could work for an isolated system, but those are of limited > interest. of limited interest ... or extremely secure ;-) > Most systems have some interaction with the outside even > though the community may be a closed one. > Many military, navy, government, financial systems have a hard requirement that they do not communicate with the internet (or even with anything that does). In my case, I can live with that. What if you effectively have two devices in one? Say you do your IP header en/de-cryption at driver level? Encrypt wifi and not BlueTooth? In my case, I can also live with that. > When faced with a DOS attack, the challenge is to get rid of as many > packets as possible with the absolute least effort. the question is -- > would encrypting the IP headers help or hinder this ?? > An excellent point and a very good question (drat!). Let me think it through. At first glance, it seems to add more processing, especially at a time-critical low-level. You _might_ save time at higher levels by doing so, but the bottle-neck is at the interrupt-handlers/drivers, trying to triage the IP packets at the earliest opportunity. I have seen devices do this - they are effectively routers. To answer that question, I guess I would have to "suck it and see" - code it up and profile it. Unless anyone else has experience, or even a gut feeling? Thanks, as always, Peter, for the provocation to thought. > Regards.....Peter > > > -- Technical Director Leonix Solutions (Pte) Ltd 18 Boon Lay Way #09-95 TradeHub 21 Singapore 609966 Telephone:+65 6316 9968 Fax: +65 6316 9208 --------------060202050300050706050304 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Peter Lovell wrote: 
On Mon, Jul 13, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<Graham@LeonixSolutions.com> wrote:

  
What about this then - is it even feasible? If I know that I have a 
closed universe of nodes, can I encrypt the IP headers? That might help 
prevent  DOS by repeated pinging.   <snip>

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

    

I guess this could work for an isolated system, but those are of limited
interest.
of limited interest ... or extremely secure ;-) 

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

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


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

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

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


  


-- 
Technical Director
Leonix Solutions (Pte) Ltd
18 Boon Lay Way
#09-95 TradeHub 21
Singapore 609966
Telephone:+65 6316 9968
Fax: +65 6316 9208
--------------060202050300050706050304-- --------------030900030109090604070404 Content-Type: text/x-vcard; charset=utf-8; name="Graham.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Graham.vcf" begin:vcard fn:Graham Keellings n:Keellings;Graham org:Leonix Solutions Pte Ltd adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore email;internet: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 --------------030900030109090604070404-- Received: from mzeal.com (mzeal.com [199.237.228.71]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6EL758W024064 for ; Tue, 14 Jul 2009 14:07:05 -0700 Received: (qmail 45612 invoked by uid 25671); 14 Jul 2009 21:05:39 -0000 Message-ID: <20090714210539.45611.qmail@mzeal.com> Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8"; format="flowed" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.0104 (F2.72; T1.15; A1.47; B3.01; Q3.01) Date: Tue, 14 Jul 2009 21:05:39 +0000 From: "Sushil Chaudhari" To: dtn-security@maillists.intel-research.net Subject: Re: [dtn-security] Key generation 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, 14 Jul 2009 21:07:06 -0000 Hi, There’s setkey command used to set the key for the specified host and ciphersuite. What utility is used to produce the key? If security policy is set to use “confidentiality block” and no external key is provided, how’s the key get generated by DTN2? Thnks. Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6DDlRm5002580 for ; Mon, 13 Jul 2009 06:47:27 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from [157.185.80.152] by asmtp012.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMQ00E563KR7W20@asmtp012.mac.com> for dtn-security@maillists.intel-research.net; Mon, 13 Jul 2009 06:46:06 -0700 (PDT) From: Peter Lovell To: "Graham Keellings (Leonix Solutions Pte Ltd)" Date: Mon, 13 Jul 2009 09:46:02 -0400 Message-id: <20090713134603.958934311@smtp.mac.com> In-reply-to: <4A5AA83C.7030400@LeonixSolutions.com> References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk> <"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> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com> <20090709041417.302976474@smtp.mac.com> <4A56E1CA.7080000@LeonixSolutions.com> <20090710120958.2016629300@smtp.mac.com> <4A5AA83C.7030400@LeonixSolutions.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): How do you feel about Bonjour/Avahi? 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, 13 Jul 2009 13:47:28 -0000 On Mon, Jul 13, 2009, Graham Keellings (Leonix Solutions Pte Ltd) wrote: >What about this then - is it even feasible? If I know that I have a >closed universe of nodes, can I encrypt the IP headers? That might help >prevent DOS by repeated pinging. > >Am I on a totally wrong track here? Or could encrypted IP headers be one >more layer of armour? > I guess this could work for an isolated system, but those are of limited interest. Most systems have some interaction with the outside even though the community may be a closed one. When faced with a DOS attack, the challenge is to get rid of as many packets as possible with the absolute least effort. the question is -- would encrypting the IP headers help or hinder this ?? Regards.....Peter 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 n6D3MsJ7006357 for ; Sun, 12 Jul 2009 20:22:54 -0700 Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.103]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MQC6i-0002bp-4w; Sun, 12 Jul 2009 23:21:36 -0400 Message-ID: <4A5AA83C.7030400@LeonixSolutions.com> Date: Mon, 13 Jul 2009 11:21:32 +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> <"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> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com> <20090709041417.302976474@smtp.mac.com> <4A56E1CA.7080000@LeonixSolutions.com> <20090710120958.2016629300@smtp.mac.com> In-Reply-To: <20090710120958.2016629300@smtp.mac.com> Content-Type: multipart/mixed; boundary="------------030806060009040706060507" 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): How do you feel about Bonjour/Avahi? 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, 13 Jul 2009 03:22:54 -0000 This is a multi-part message in MIME format. --------------030806060009040706060507 Content-Type: multipart/alternative; boundary="------------020008060004090908010308" --------------020008060004090908010308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Lovell wrote: > [snip] > > >>> Bonjour is just a service discovery protocol, not a part of a security >>> system. And it's localized so that only your neighbours know. It >>> shouldn't make any difference to integrity or confidentiality as those >>> should be handled by the defenses you have deployed. At a stretch, it >>> might make adversaries aware of your system but if they see Bonjour >>> advertisements then they're close to you already and can see your >>> network traffic. >>> >>> >> An excellent point, and one which worries me. How does "standard" >> security which is not int he DTN part of the system affect the overall >> system of which DTN is only a part? >> > > I'm not sure I understand your point here. DTN sits on top of various > transport mechanisms (referred to as "convergence layers" in the specs) > and these may have their own security mechanisms. These are in addition > to the dtn ones that only are invoked after coming through the lower > layers. As an example, if you are using TCP convergence layer, I would > expect that to defend against common TCP DOS attacks, such as syn-flood. > DTN doesn't have to deal with those. > > A point well made. It's not (currently) part of my remit to be concerned about TCP/IP, WEP/WPA, et al. But it surely needs to be considered in my system and I don't see who else will do it. Oh, well, that's why ssytems have v2.0 :-) > >>> Bonjour and static IP addresses are solutions to different problems. An >>> IP address allows a system to send something to you. Bonjour allows a >>> nearby system to find you if it doesn't know your address. >>> >>> >> In my idea of a "closed, secure" system, if someone does not know my IP >> address, then I don't even want him to know that I exist (al least, I >> think so ... ) >> > > You might indeed want him not to know, and it might be good to keep as > low a profile as possible. But in most cases (not all) I wouldn't > categorize that as real "security". It's like having secret crypto algorithms. > A very good point. Secret crypto is generally snake-oil and certainly not widely peer-reviewed. > Can it be one part of a layered defense? Certainly. Do I place much > reliance on it? No, with occasional exceptions. > > What about this then - is it even feasible? If I know that I have a closed universe of nodes, can I encrypt the IP headers? That might help prevent DOS by repeated pinging. Of course, there are only a limited number of public IP addresses, which could be quickly and easily tried, but it throws up one more roadblock. Or I could use "real" IP addresses - maybe IPv6 9after carefully reading http://www.seanconvery.com/ipv6.html) ... Am I on a totally wrong track here? Or could encrypted IP headers be one more layer of armour? >>> If you are sensitive about denial-of-service attacks then I would >>> suggest strongly that you do not use a hard-coded IP address, but >>> specify a dns address instead. >>> >>> >>> >> And that gets resolved to an IP address how? If I have an ad-hoc >> network, I don't want to have a DNS server. >> > > The non-Bonjour scenario uses a standard dns server -- nothing strange > there. Bonjour works in a standard local network (think of a small > office with DHCP, internet connectivity and with or without a dns server > for the local machines) or purely ad-hoc. In the ad-hoc case, the > machines self-assign link-local IP addresses in the range > 169.254.0.0/16. Discovery is done using multicast-dns. The machines > respond directly and there is no server involved. > > Thanks for clarifying. Looks like I need to re-read TCP/IP/DNS for Dummies. > Cheers.....Peter > > _______________________________________________ > dtn-security mailing list > 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 --------------020008060004090908010308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Lovell wrote:
[snip] 

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

I'm not sure I understand your point here. DTN sits on top of various
transport mechanisms (referred to as "convergence layers" in the specs)
and these may have their own security mechanisms. These are in addition
to the dtn ones that only are invoked after coming through the lower
layers. As an example, if you are using TCP convergence layer, I would
expect that to defend against common TCP DOS attacks, such as syn-flood.
DTN doesn't have to deal with those.
A point well made. It's not (currently) part of my remit to be concerned about TCP/IP, WEP/WPA, et al. But it surely needs to be considered in my system and I don't see who else will do it. Oh, well, that's why ssytems have v2.0 :-)

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

You might indeed want him not to know, and it might be good to keep as
low a profile as possible. But in most cases (not all) I wouldn't
categorize that as real "security". It's like having secret crypto algorithms.
A very good point. Secret crypto is generally snake-oil and certainly not widely peer-reviewed.


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

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





  

    

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

  
      

    

    
And that gets resolved to an IP address how? If I have an ad-hoc 
network, I don't want to have a DNS server.
    

  

  

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

  



Thanks for clarifying. Looks like I need to re-read TCP/IP/DNS for
Dummies.





  
Cheers.....Peter

_______________________________________________
dtn-security mailing list
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





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

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

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet: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


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


Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6ACwgfq032740 for ; Fri, 10 Jul 2009 05:58:43 -0700
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 59395A840B; Fri, 10 Jul 2009 07:57:46 -0500 (CDT)
Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n6ACvkpH012474; Fri, 10 Jul 2009 07:57:46 -0500
Received: from NDJSSCC03.ndc.nasa.gov ([198.117.4.170]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Fri, 10 Jul 2009 07:57:46 -0500
From: "Ivancic, William D. (GRC-RHN0)" 
To: Peter Lovell , "Graham Keellings (Leonix Solutions Pte Ltd)" 
Date: Fri, 10 Jul 2009 07:57:37 -0500
Thread-Topic: [dtn-security] Re(2): Re(2): Re(2): Is there a "secure" reference implementation of the DTN stack?
Thread-Index: AcoBWCAe/3WnkmYMRjGj5vz8dXWOrAABUtQg
Message-ID: <3A5AA67A8B120B48825BFFCF5443856137E3ACCE99@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> <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> <20090629123400.1726285002@smtp.mac.com> <4A56D108.9050303@LeonixSolutions.com> <20090710113509.2057557181@smtp.mac.com>
In-Reply-To: <20090710113509.2057557181@smtp.mac.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
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-07-10_09:2009-07-03, 2009-07-10, 2009-07-10 signatures=0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n6ACwgfq032740
Cc: "dtn-security@maillists.intel-research.net" 
Subject: Re: [dtn-security] Re(2): 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: Fri, 10 Jul 2009 12:58:43 -0000

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

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

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

/Will

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

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



Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6ACBTTr030611 for ; Fri, 10 Jul 2009 05:11:29 -0700
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII
Received: from [157.185.80.152] by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMK005ZVF4MRT40@asmtp019.mac.com> for dtn-security@maillists.intel-research.net; Fri, 10 Jul 2009 05:10:02 -0700 (PDT)
From: Peter Lovell 
To: "Graham Keellings (Leonix Solutions Pte Ltd)" 
Date: Fri, 10 Jul 2009 07:35:09 -0400
Message-id: <20090710113509.2057557181@smtp.mac.com>
In-reply-to: <4A56D108.9050303@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> <20090629123400.1726285002@smtp.mac.com> <4A56D108.9050303@LeonixSolutions.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" 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: Fri, 10 Jul 2009 12:11:29 -0000

On Fri, Jul 10, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
 wrote:

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


Hi Graham,

at the moment that is as good as it gets.

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

Cheers.....Peter



Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n6ACBTTt030611 for ; Fri, 10 Jul 2009 05:11:29 -0700
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII
Received: from [157.185.80.152] by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMK005ZVF4MRT40@asmtp019.mac.com> for dtn-security@maillists.intel-research.net; Fri, 10 Jul 2009 05:10:04 -0700 (PDT)
From: Peter Lovell 
To: "Graham Keellings (Leonix Solutions Pte Ltd)" 
Date: Fri, 10 Jul 2009 08:09:58 -0400
Message-id: <20090710120958.2016629300@smtp.mac.com>
In-reply-to: <4A56E1CA.7080000@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> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com> <20090709041417.302976474@smtp.mac.com> <4A56E1CA.7080000@LeonixSolutions.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):  How do you feel about Bonjour/Avahi?
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: Fri, 10 Jul 2009 12:11:30 -0000

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

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


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

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


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

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

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

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

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

Cheers.....Peter



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 n6A6m07R015382 for ; Thu, 9 Jul 2009 23:48:01 -0700
Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.103]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MP9su-0003x2-ET; Fri, 10 Jul 2009 02:47:05 -0400
Message-ID: <4A56E3E5.6010304@LeonixSolutions.com>
Date: Fri, 10 Jul 2009 14:47:01 +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: Kamal Srinivasan , "dtn-security@maillists.intel-research.net" 
References: <89E48AE60E64EF4E8EB32B0B7EC74920A1B0F5@EVS-EC1-NODE2.surrey.ac.uk>	 <4A46C257.3040006@LeonixSolutions.com>	 <4A46FBB2.3080205@LeonixSolutions.com>	 <4A470CD7.4010502@LeonixSolutions.com>	 <4A4878A6.7010707@LeonixSolutions.com>	 <20090629123400.1726285002@smtp.mac.com>	 	 <4A497B04.3070909@LeonixSolutions.com>	 <20090630122842.1049441707@smtp.mac.com>	 <4A556063.2010305@LeonixSolutions.com> <845de72a0907082029x46d47e89r6c46093c78d11ad5@mail.gmail.com>
In-Reply-To: <845de72a0907082029x46d47e89r6c46093c78d11ad5@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------060402000400060801090208"
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: Re: [dtn-security] How do you feel about Bonjour/Avahi?
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: Fri, 10 Jul 2009 06:48:01 -0000

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


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

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


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


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

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

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

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

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

/graham


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


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




  


Kamal Srinivasan wrote:


  
Graham,
Our research group @ Univ. of Wisconsin have been working on Anonymous
communication and Key Management in DTN.
  



There is a whole Venn-digram of terminology overlap here. Althogu I
mention DTN, ad-hoc is also a defining phrase for me - which means that
I can't have a dedicated node as a DNS or key server, since talking out
hat node makes my network useless. 







  
Short ans: Our perspective is...it boils down as to how paranoid the app.
developer over DTN is with security.  



As paranoid as possible, in my case - military grade or more - but of
course there is a trade-off in terms of time & resources needed to
add this security 







  
This really drives where the ACL policies reside in the stack.

  



All over, I think ... 





  
A not so short ans:

In DTNs, if the connectivity is sparse enough you want to exploit as many
opportunities as you could. 



That seems to imply an open and trusting network, whereas I am thinking
of a closed and mistrusting one. 





  
In such scenarios it would benefit from blaring
out than hard coding and relying on meeting the hard coded IP devices.  This
becomes a serious concern when you have unplanned mobility scenarios, where
you know lesser about the network. So it really depends on what class of DTN
you are looking into.
  



"Secure" whatever that means - enough to satisfy banking, the military,
etc - closed and suspicious, if not paranoid.  But I think we are
missing an overall discussion of this sort f thing - maybe even just a
table - showing the trade off between how much security you want and
what it will cost you. 





  
If you were to blare out and have approp. policies in place at the BP layer,
that can be controlled by the app. then you could blare out and still be
secure. Even if you were not to broadcast, many underlying comm. methods
would in common scenarios (for ex. in 802.11).



But there are many layers of worry - even bog-standard DOS attacks
could give grief to my network. 





  
 We tried to develop an
anonymous communication sub-layer on top of the sensor nodes (motes), but
the underlying layers were revealing enough entropy of information.

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

thanks,
kamal
  



Thanks _very_ much for taking the time to send such a long and well
formulated answer.



/graham 







  

On Wed, Jul 8, 2009 at 10:13 PM, Graham Keellings (Leonix Solutions Pte Ltd)
<Graham@leonixsolutions.com> wrote:

  

  

    
From a security standpoint?

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

Would I be safer just using hard coded IP address?

Thanks in advance for any opinions.

~graham();

_______________________________________________
dtn-security mailing list
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





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

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

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet: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


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


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 n6A6d3Qj014950 for ; Thu, 9 Jul 2009 23:39:03 -0700
Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.103]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MP9kE-0007Bb-Kv; Fri, 10 Jul 2009 02:38:07 -0400
Message-ID: <4A56E1CA.7080000@LeonixSolutions.com>
Date: Fri, 10 Jul 2009 14:38:02 +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> <"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> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com> <20090709041417.302976474@smtp.mac.com>
In-Reply-To: <20090709041417.302976474@smtp.mac.com>
Content-Type: multipart/mixed; boundary="------------080700040705050006030208"
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] How do you feel about Bonjour/Avahi?
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: Fri, 10 Jul 2009 06:39:03 -0000

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


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

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


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

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


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


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

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


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

/graham


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




  


Peter Lovell wrote:


  
On Thu, Jul 9, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<Graham@leonixsolutions.com> wrote:

  

  

    
From a security standpoint?

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

Would I be safer just using hard coded IP address?

Thanks in advance for any opinions.

~graham();
    

  

  


Hi Graham,

it depends.

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

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

  



Thanks very much for the swift reply, Peter. It came within ten minutes
and I am a day late in replying :-/





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





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

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

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

  



And military? I would imagine that since lives are at stake that might
be the defining peak of the pyramid... 







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



An excellent point, and one which worries me. How does "standard"
security which is not int he DTN part of the system affect the overall
system of which DTN is only a part? 







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



In my idea of a "closed, secure" system, if someone does not know my IP
address, then I don't even want him to know that I exist (al least, I
think so ... )





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

  



And that gets resolved to an IP address how? If I have an ad-hoc
network, I don't want to have a DNS server.







  
Regards.....Peter


  



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



/graham






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

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

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet: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


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


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 n6A5RXPB011712 for ; Thu, 9 Jul 2009 22:27:33 -0700
Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.103]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MP8d0-0002Vd-2A; Fri, 10 Jul 2009 01:26:34 -0400
Message-ID: <4A56D108.9050303@LeonixSolutions.com>
Date: Fri, 10 Jul 2009 13:26:32 +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>	<4A4878A6.7010707@LeonixSolutions.com> <20090629123400.1726285002@smtp.mac.com>
In-Reply-To: <20090629123400.1726285002@smtp.mac.com>
Content-Type: multipart/mixed; boundary="------------010804040201090703040103"
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" 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: Fri, 10 Jul 2009 05:27:34 -0000

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


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

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

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

~graham();





> This is quite a long document and describes both the general approach
> with ciphersuites and the specific implementation of suites for Bundle
> Authentication (BA), Payload Integrity (PI), Payload Confidentiality
> (PC) and Extension Security (EA). In your search for A Rosetta Stone,
> you'll find that this is about as stony as it gets. It will take some
> time to discern the humour in that statement :)
>
> Regards.....Peter
>
>
>
> On Mon, Jun 29, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
>  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


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




  


Peter Lovell wrote:


  
Hi Graham,

the best document at this time is the Bundle Security Protocol
Specification, available at <http://tools.ietf.org/id/draft-irtf-dtnrg-
bundle-security-08.txt>
  



wow, that did take some reading (and I doubt that I truly understood
half of it ;-)



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



~graham();













  
This is quite a long document and describes both the general approach
with ciphersuites and the specific implementation of suites for Bundle
Authentication (BA), Payload Integrity (PI), Payload Confidentiality
(PC) and Extension Security (EA). In your search for A Rosetta Stone,
you'll find that this is about as stony as it gets. It will take some
time to discern the humour in that statement :)

Regards.....Peter



On Mon, Jun 29, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
<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





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

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

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet: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


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


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 n694FgUn007885 for ; Wed, 8 Jul 2009 21:15:42 -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 asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMH002YDYFWSK30@asmtp022.mac.com> for dtn-security@maillists.intel-research.net; Wed, 08 Jul 2009 21:14:22 -0700 (PDT)
From: Peter Lovell 
To: "Graham Keellings (Leonix Solutions Pte Ltd)" 
Date: Thu, 09 Jul 2009 00:14:17 -0400
Message-id: <20090709041417.302976474@smtp.mac.com>
In-reply-to: <4A556063.2010305@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> <20090630122842.1049441707@smtp.mac.com> <4A556063.2010305@LeonixSolutions.com>
X-Mailer: CTM PowerMail version 6.0.2 build 4601 English (intel) 
Cc: dtn-security@maillists.intel-research.net
Subject: Re: [dtn-security] How do you feel about Bonjour/Avahi?
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: Thu, 09 Jul 2009 04:15:42 -0000

On Thu, Jul 9, 2009, Graham Keellings (Leonix Solutions Pte Ltd)
 wrote:

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


Hi Graham,

it depends.

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

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

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

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

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

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

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

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

Regards.....Peter



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 n693ET4W005096 for ; Wed, 8 Jul 2009 20:14:29 -0700
Received: from dyn98-b60-access.superdsl.com.sg ([202.73.60.98] helo=[192.9.200.103]) by sky.fastbighost.net with esmtpa (Exim 4.69) (envelope-from ) id 1MOk4q-0005BQ-Lm for dtn-security@maillists.intel-research.net; Wed, 08 Jul 2009 23:13:41 -0400
Message-ID: <4A556063.2010305@LeonixSolutions.com>
Date: Thu, 09 Jul 2009 11:13:39 +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
CC: dtn-security@maillists.intel-research.net
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> <20090630122842.1049441707@smtp.mac.com>
In-Reply-To: <20090630122842.1049441707@smtp.mac.com>
Content-Type: multipart/mixed; boundary="------------080103000405080103060206"
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] How do you feel about Bonjour/Avahi?
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: Thu, 09 Jul 2009 03:14:30 -0000

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

 From a security standpoint?

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

Would I be safer just using hard coded IP address?

Thanks in advance for any opinions.

~graham();

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

begin:vcard
fn:Graham Keellings
n:Keellings;Graham
org:Leonix Solutions Pte Ltd
adr:TradeHub 21;;18 Boon Lay Way #09-95;;;609966;Singapore
email;internet: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


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