From scott.c.burleigh@jpl.nasa.gov Tue Jan 22 14:37:36 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAE521F85C0 for ; Tue, 22 Jan 2013 14:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmW9nzIjHKCU for ; Tue, 22 Jan 2013 14:37:30 -0800 (PST) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5C721F85B4 for ; Tue, 22 Jan 2013 14:37:30 -0800 (PST) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0MMbRrO003643 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Tue, 22 Jan 2013 14:37:29 -0800 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.60]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.88]) with mapi id 14.02.0318.001; Tue, 22 Jan 2013 14:37:28 -0800 From: "Burleigh, Scott C (313B)" To: "dtn-security@irtf.org" Thread-Topic: Re(19): [dtn-security] Implementing Security Destinations in DTN2 Thread-Index: AQHNsJPIZoDaDqH290yQ8PpLOF/skJftUzPAgGkpYDA= Date: Tue, 22 Jan 2013 22:37:27 +0000 Message-ID: References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com> <6af37e4869b76826d4d2108e3eef82b3.squirrel@webmail.math.umd.edu> <20120923012212.319238544@smtp.mail.me.com> <3c1f477d9f6b104790e33e76236998e6.squirrel@webmail.math.umd.edu> <20120926214742.2066794613@smtp.mail.me.com> <20120927170104.253362480@smtp.mail.me.com> <20120927172602.1763958833@smtp.mail.me.com> <20121002225237.520325524@smtp.mail.me.com> <7249cc388d868cb16f14efe286351e37.squirrel@webmail.math.umd.edu> <20121004210719.1971171529@smtp.mail.me.com> <20121004220537.1202245607@smtp.mail.me.com> <20121016220658.793339059@smtp.mail.me.com> <20121022185905.200828573@smtp.mail.me.com> <20121022202820.71123343@smtp.mail.me.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: multipart/mixed; boundary="_004_A5BEAD028815CB40A32A5669CF737C3B2356FA44apembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: [dtn-security] FW: Re(19): Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 22:37:36 -0000 --_004_A5BEAD028815CB40A32A5669CF737C3B2356FA44apembxsp40RESAD_ Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B2356FA44apembxsp40RESAD_" --_000_A5BEAD028815CB40A32A5669CF737C3B2356FA44apembxsp40RESAD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. Late last September, several of us spun off a sub-thread talking about= how the processing of bundles with multiple security destinations could be= handled in DTN implementations. I won't try to recreate all of the argume= nts on all sides, but I think we did converge on agreement that the current= BSP mechanism for complex, multi-destination security could be difficult t= o realize in coherent fashion across the network. After puzzling over this= for a while, I came up with a concept (below) that I think would be simple= r, safer, and even more powerful than the current protocol design. How do = we all feel about this? Would it be worthwhile for DTNRG to invest in a 62= 57bis RFC along these lines? Scott _____________________________________________ From: Burleigh, Scott C (313B) Sent: Friday, November 16, 2012 5:05 PM To: 'Peter Lovell'; ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in D= TN2 Hi, Peter. At the risk (I know) of getting a lot of people severely ticked= off at me, I am going to offer a modest proposal for improving the Bundle = Security Protocol, inspired by this thread. I propose to adopt a new design principle for Bundle Security Protocol: the= routing element of a bundle protocol agent should never need to inspect a = bundle's BSP extension blocks in order to select the node(s) to forward the= bundle to. That is, BSP should provide security, not dictate routes. My rationale for proposing this principle is that I believe it would: * Simplify BSP, thereby reducing the incidence of bugs and making Bun= dle Security significantly less expensive to implement and sustain. * Broaden the scope of BSP deployment by eliminating its dependence o= n specific, BSP-aware routing implementations, thereby increasing the overa= ll security of DTN. * Reduce the cost of developing and improving routing implementations= by removing any requirement that they be BSP-aware, and broaden the scope = of deployment of non-BSP-aware routing implementations by enabling them to = be used in environments requiring arbitrarily powerful security. Thereby, = improve DTN operational performance. Here's how I would apply this principle: 1. Eliminate security sources and security destinations from all BSP b= locks. The security source of a BSP block would always be the bundle's sou= rce. The security destination of a BSP block would always be the bundle's = destination. 2. Add a new Administrative Record type for Bundle-in-Bundle encapsula= tion. 3. When additional security must be applied to a bundle on some segmen= t of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Enca= psulation Administrative Record that is the payload of a new bundle whose s= ource is the security source of the path segment and whose destination is t= he security destination of the path segment. Apply the additional bundle t= ransmission security measures to the encapsulating bundle: encrypt its payl= oad (the Administrative Record, containing the encapsulated bundle), encryp= t extension blocks as copied from the encapsulated bundle, etc. Then forwa= rd the encapsulating bundle. 4. When route service uncertainty forces a bundle to be routed over mu= ltiple parallel additionally secured segments of its end-to-end path, encap= sulate it as above but within multiple different encapsulating bundles, one= for each of the parallel segments, and forward all of them. 5. At the destination of a bundle, apply all relevant bundle reception= security measures and then, if the payload is an encapsulation Administrat= ive Record, extract the encapsulated bundle from the Administrative Record = and simply forward it. I believe this would have the following impacts on DTN security: * No EID references in BSP, simplifying canonicalization. * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the enca= psulated bundle encrypts all three at once), so no correlators in BSP. (Ex= cept for BABs, no bundle ever has more than one occurrence of any type of B= SP block. And there will never be more than two BABs, one immediately foll= owing the primary block and one that is the final block in the bundle, so t= hat correlation is structural.) * No delicate "replacement" process for unraveling PCB nesting at the= destination. * No possible confusion about the correct order of application of BSP= blocks. * No possible conflict among security destinations of different BSP b= locks. * Security paths can never overlap. * Any routing implementation can always accommodate any security regi= me: routes that must be followed to ensure security are encoded into routin= g information at the forwarding node, not into the bundle. (A little like = the late binding principle.) * Any routing environment can always be made arbitrarily secure - no = need to require specially BSP-aware routing elements. * Ciphersuite design is simplified, so a wider array of useful cipher= suites can be developed without imposing bug-prone complexity. Minimizes p= ossible security problems. As an example of how I think this could work, see the attached diagram: 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are wit= hin the low-risk "W" security region; nodes C and G are gateways between re= gion W and the more hazardous region X; node D is another node in X; nodes = E and F are gateways between region X and even more hazardous region Y; nod= es H and I are gateways between X and hazardous region Z. 2. At A the bundle is simply forwarded to B. 3. At B the routing element realizes that the bundle has to traverse r= egion X in order to get to K, so it forwards the bundle to C. 4. The routing element at C encapsulates the bundle in an Admin Record= , creates a new bundle destined for G (the egress from region X) whose sour= ce is C and whose payload is that Admin Record, encrypts the payload, attac= hes a PCB, and forwards the bundle to D. 5. D realizes that the bundle has to traverse region Y in order to get= to G, so it forwards the bundle to E. 6. E encapsulates the bundle in an Admin Record, creates a new bundle = destined for F (the egress from region Y) whose source is E and whose paylo= ad is that Admin Record, encrypts the payload, attaches a PCB, and forwards= the bundle to F. 7. The bundle protocol agent at F receives the bundle, decrypts it, an= d passes the payload (an Admin Record) to the application agent. The admin= istrative element of the application agent at F receives the Admin Record, = extracts the encapsulated bundle destined for G, and queues it to be forwar= ded. The routing element at F sees this bundle and forwards it to G. 8. The bundle protocol agent at G receives the bundle, decrypts it, an= d passes the payload (an Admin Record) to the application agent. The admin= istrative element of the application agent at G receives the Admin Record, = extracts the encapsulated bundle destined for K, and queues it to be forwar= ded. The routing element at G sees this bundle, realizes that the bundle h= as to traverse region Z in order to get to K, and therefore forwards the bu= ndle to H. 9. H encapsulates the bundle in an Admin Record, creates a new bundle = destined for I (the egress from region Z) whose source is H and whose paylo= ad is that Admin Record, encrypts the payload, attaches a PCB, and forwards= the bundle to I. 10. The bundle protocol agent at I receives the bundle, decrypts it, an= d passes the payload (an Admin Record) to the application agent. The admin= istrative element of the application agent at I receives the Admin Record, = extracts the encapsulated bundle destined for K, and queues it to be forwar= ded. The routing element at I sees this bundle and forwards it to J. 11. At J the bundle is simply forwarded to K. 12. At K the bundle's payload is passed to the application. I think this approach would combine simplicity with quite a lot of operatio= nal power, making everything cheaper and safer. So, having now stirred the hornet's nest, I will beat a hasty retreat for a= week while I am on vacation. I'll try to follow up when I get back. Have a nice Thanksgiving, everybody. Scott -----Original Message----- From: Peter Lovell [mailto:plovell@mac.com] Sent: Monday, October 22, 2012 1:28 PM To: Burleigh, Scott C (313B); ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2 On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: > In view of which, I've now become a bigger fan of bundle-in-bundle >tunneling than I've been in the past. Hi Scott, I agree. I'm also a big fan, for a bunch of reasons. However, as I mentione= d to Angela, the current [i.e. latest, expired] draft seems a bit "funky" t= o me. There's no indication in the bundle that it's BiB and you need some s= pecial EID to perform the decapsulation. Maybe that's just like an assigned= port in TCP but we don't yet have such a mechanism. The multiple-bundle th= ing is OK, I guess, but I don't see much use for it other than volume gatew= ay-to-gateway traffic and I think that such heavy-duty tunnels could be spe= cially optimized. I need to go back and review all the discussions about BiB -- we worked it = quite a bit but the spec never gained enough consensus to move forward. I t= hink it would be a good idea to revisit it now and get a solid draft that h= as wider support. Maybe the email discussions will help us get there. Thanks.....Peter --_000_A5BEAD028815CB40A32A5669CF737C3B2356FA44apembxsp40RESAD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi.  Late last September, several of us s= pun off a sub-thread talking about how the processing of bundles with multi= ple security destinations could be handled in DTN implementations.  I = won’t try to recreate all of the arguments on all sides, but I think we did converge on agreement that the current BSP me= chanism for complex, multi-destination security could be difficult to reali= ze in coherent fashion across the network.  After puzzling over this f= or a while, I came up with a concept (below) that I think would be simpler, safer, and even more powerful than t= he current protocol design.  How do we all feel about this?  Woul= d it be worthwhile for DTNRG to invest in a 6257bis RFC along these lines?<= /font>
 
Scott
_____= ________________________________________
From: Burleigh, Scott C (313B)
Sent: Friday, November 16, 2012 5:05 PM
To: 'Peter Lovell'; ahennes1@math.umd.edu
Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss
Subject: RE: Re(19): [dtn-security] Implementing Security Destinatio= ns in DTN2
 
 
Hi, Peter.  At the risk (I know) of = getting a lot of people severely ticked off at me, I am going to offer a mo= dest proposal for improving the Bundle Security Protocol, inspired by this = thread.
I propose to adopt a new design principle= for Bundle Security Protocol: the routing element of a bundle protocol age= nt should never need to inspect a bundle’s BSP extension blocks in or= der to select the node(s) to forward the bundle to.
That is, BSP should provide security, = not dictate routes.
My rationale for proposing this principle= is that I believe it would:
  • Simplify BSP, thereby reducing the inciden= ce of bugs and making Bundle Security significantly less expensive to imple= ment and sustain.
  • Broaden the scope of= BSP deployment by eliminating its dependence on specific, BSP-aware routin= g implementations, thereby increasing the overall security of DTN.
  • Reduce the cost of developing and improving ro= uting implementations by removing any requirement that they be BSP-aware, a= nd broaden the scope of deployment of non-BSP-aware routing implementations= by enabling them to be used in environments requiring arbitrarily powerful security.  Thereby, improv= e DTN operational performance.
Here's how I would apply this principle:<= /div>
  1. Eliminate security sources and security de= stinations from all BSP blocks.  The security source of a BSP block wo= uld always be the bundle’s source.  The security destination of = a BSP block would always be the bundle’s destination.
  2. Add a new Administrative Record type for Bundle-in-= Bundle encapsulation.
  3. When additional = security must be applied to a bundle on some segment of its end-to-end path= , encapsulate the bundle in a Bundle-in-Bundle Encapsulation Administrative= Record that is the payload of a new bundle whose source is the security source of the path segment and whose destination is the securi= ty destination of the path segment.  Apply the additional bundle trans= mission security measures to the encapsulating bundle: encrypt its payload = (the Administrative Record, containing the encapsulated bundle), encrypt extension blocks as copied from the encap= sulated bundle, etc.  Then forward the encapsulating bundle.
  4. When route service uncertainty forces a bundle = to be routed over multiple parallel additionally secured segments of its en= d-to-end path, encapsulate it as above but within multiple different encaps= ulating bundles, one for each of the parallel segments, and forward all of them.
  5. At the destination of a bundle, apply all relevant bundle rece= ption security measures and then, if the payload is an encapsulation Admini= strative Record, extract the encapsulated bundle from the Administrative Re= cord and simply forward it.
I believe this would have the following i= mpacts on DTN security:
  • No EID references in BSP, simplifying cano= nicalization.
  • PCBs only encrypt payloa= ds, never PIBs or PCBs (encrypting the encapsulated bundle encrypts all thr= ee at once), so no correlators in BSP.  (Except for BABs, no bundle ev= er has more than one occurrence of any type of BSP block.  And there will never be more than two BABs, one immediately following the p= rimary block and one that is the final block in the bundle, so that correla= tion is structural.)
  • No delicate ̶= 0;replacement” process for unraveling PCB nesting at the destination.=
  • No possible confusion about the corre= ct order of application of BSP blocks.
  • No possible conflict among security destinations of different BSP blocks.<= /li>
  • Security paths can never overlap.
    • =
  • Any routing implementation can always acco= mmodate any security regime: routes that must be followed to ensure securit= y are encoded into routing information at the forwarding node, not into the= bundle.  (A little like the late binding principle.)
  • Any routing enviro= nment can always be made arbitrarily secure – no need to require spec= ially BSP-aware routing elements.
  • Ciph= ersuite design is simplified, so a wider array of useful ciphersuites can b= e developed without imposing bug-prone complexity.  Minimizes possible= security problems.
As an example of how I think this could w= ork, see the attached diagram:
  1. Node A is sending a bundle to node K. = ; Nodes A, B, J, and K are within the low-risk “W” security reg= ion; nodes C and G are gateways between region W and the more hazardous reg= ion X; node D is another node in X; nodes E and F are gateways between region X and even more hazardous region Y; nodes H and I a= re gateways between X and hazardous region Z.
  2. At A the bundle is simply forwarded to B.
  3. At B the routing element realizes that the bundle has to traver= se region X in order to get to K, so it forwards the bundle to C.
  4. The routing element at C encapsulates the bundl= e in an Admin Record, creates a new bundle destined for G (the egress from = region X) whose source is C and whose payload is that Admin Record, encrypt= s the payload, attaches a PCB, and forwards the bundle to D.
  5. D realiz= es that the bundle has to traverse region Y in order to get to G, so it for= wards the bundle to E.
  6. E encapsulates = the bundle in an Admin Record, creates a new bundle destined for F (the egr= ess from region Y) whose source is E and whose payload is that Admin Record= , encrypts the payload, attaches a PCB, and forwards the bundle to F.
  7. The bundle protocol agent at F r= eceives the bundle, decrypts it, and passes the payload (an Admin Record) t= o the application agent.  The administrative element of the applicatio= n agent at F receives the Admin Record, extracts the encapsulated bundle destined for G, and queues it to be forwarded. = ; The routing element at F sees this bundle and forwards it to G.
  8. The bundle protocol agent at G receives the bun= dle, decrypts it, and passes the payload (an Admin Record) to the applicati= on agent.  The administrative element of the application agent at G re= ceives the Admin Record, extracts the encapsulated bundle destined for K, and queues it to be forwarded. = ; The routing element at G sees this bundle, realizes that the bundle has t= o traverse region Z in order to get to K, and therefore forwards the bundle= to H.
  9. H encapsulates the bundle in an= Admin Record, creates a new bundle destined for I (the egress from region = Z) whose source is H and whose payload is that Admin Record, encrypts the p= ayload, attaches a PCB, and forwards the bundle to I.
  10. The bundle protocol agent at I r= eceives the bundle, decrypts it, and passes the payload (an Admin Record) t= o the application agent.  The administrative element of the applicatio= n agent at I receives the Admin Record, extracts the encapsulated bundle destined for K, and queues it to be forwarded. = ; The routing element at I sees this bundle and forwards it to J.
  11. At J the bundle is simply forwarded to K.
    12. <= li style=3D"margin-bottom:6pt;">At K the bundle’s payload is passed t= o the application.
I think this approach would combine simpl= icity with quite a lot of operational power, making everything cheaper and = safer.
So, having now stirred the hornet’s= nest, I will beat a hasty retreat for a week while I am on vacation. = I’ll try to follow up when I get back.
Have a nice Thanksgiving, everybody.
Scott
 
-----Original Message-----
From: Peter Lovell [mailto:plovell@mac.com]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); ahennes1@math.umd.edu
Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter= Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2<= /div>
 
On Wed, Oct 24, 2012, Burleigh, Scott C (313B) <scott.c.burleigh@jpl.nasa.gov> wrote:<= /div>
 
> In view of which, I've now become a bigger fan of bundle-in-bundl= e
>tunneling than I've been in the past.
 
Hi Scott,
 
I agree. I'm also a big fan, for a bunch of reasons. However, as I men= tioned to Angela, the current [i.e. latest, expired] draft seems a bit &quo= t;funky" to me. There's no indication in the bundle that it's BiB and = you need some special EID to perform the decapsulation. Maybe that's just like an assigned port in TCP but we don't yet have such a= mechanism. The multiple-bundle thing is OK, I guess, but I don't see much = use for it other than volume gateway-to-gateway traffic and I think that su= ch heavy-duty tunnels could be specially optimized.
 
I need to go back and review all the discussions about BiB -- we worke= d it quite a bit but the spec never gained enough consensus to move forward= . I think it would be a good idea to revisit it now and get a solid draft t= hat has wider support. Maybe the email discussions will help us get there.
 
Thanks.....Peter
 
 
 --_000_A5BEAD028815CB40A32A5669CF737C3B2356FA44apembxsp40RESAD_-- --_004_A5BEAD028815CB40A32A5669CF737C3B2356FA44apembxsp40RESAD_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="BSPbis.pptx" Content-Description: BSPbis.pptx Content-Disposition: attachment; filename="BSPbis.pptx"; size=51349; creation-date="Fri, 16 Nov 2012 22:44:40 GMT"; modification-date="Sat, 17 Nov 2012 00:43:48 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDfzBj1wgEAAEYMAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM l8lOwzAQhu9IvEPkK2rcspRFTTmwnFgqAQ9gkmlrcGzLnpb27ZmkC6EKhCWIXCI5zvz/54mT/Omd zlIVTMF5aXTEOmGbBaBjk0g9itjD/WXriAUehU6EMhoiNgfPTvvbW737uQUfULX2ERsj2hPOfTyG VPjQWNA0MzQuFUhDN+JWxM9iBHy33e7y2GgEjS3MNFi/dw5DMVEYXMzo9ILkycKIBWeLCzOviMk0 E8gneGmNA+U3aoS1SsYCaXV8qpMNstaSKqTK/Bo/ltbvEDord8hm3kMVDZZ1t9ROJxMIBsLhjUgJ nVuL3DrwtOrcKPxcqQTVDIcyhsTEk5REwqJYqt4Nw1RIvVrERzBeEeG18Ei3nhcGnbrJCtpfYlrS /A1HFUHW1YEz1tfdhbVwFcFUwsufEKyFqwiQnmHg+fH3NyGXqXQUjwrucK6g9r7jm3QVRb5Rr8Tc THC5BxeD3zdh41ktGP2Uabfu/VkD014DmfYbyHTQQKZuA5kOG8h01ECm4wYyddpNhPqvNzmFtvyT TrnXwfcbswqpWXXLUjoBhxLWMbUs4a0dKZ5+33AjakKWyhNISrx5/hfQfwUAAP//AwBQSwMEFAAG AAgAAAAhAGj4dKEFAQAA4gIAAAsACAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskttKAzEQhu8F3yHMfTfb KiLSbG9E6J3I+gBjMrsb3RxIptK+vaHgYWEtgr2c0z9f8s96s3ejeKeUbfAKllUNgrwOxvpewXP7 sLgFkRm9wTF4UnCgDJvm8mL9RCNyGcqDjVkUFZ8VDMzxTsqsB3KYqxDJl0oXkkMuYeplRP2GPclV Xd/I9FMDmomm2BoFaWuuQLSHWDb/R1s6YjTIKHVItIipkCW25S2ixdQTKzBBP5Z0PnZUhRrkPNDq vEA87NyLRzvOoHzVqtdI/W9Ay78Dha6zmu6D3jnyPGOCnHZ8M8XIMibKZexo+6kfuj4nEO2ZvCFz 2jSM8ZNITi6z+QAAAP//AwBQSwMEFAAGAAgAAAAhADMOHgTBAAAANwEAACAAAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlMS54bWwucmVsc4SPQavCMBCE74L/IezdpL6DijTtRQThnUR/wJJs22CbhGx8 vP57c6wgeJwd5puduv2fRvFHiV3wGrayAkHeBOt8r+F+O28OIDijtzgGTxpmYmib9aq+0oi5hHhw kUWheNYw5ByPSrEZaEKWIZIvThfShLnI1KuI5oE9qZ+q2qm0ZEDzxhQXqyFd7BbEbY6l+Ts7dJ0z dArmOZHPHyoUj87SL87hmQsWU09Zg5TLOy/FXpb3QTW1epvbvAAAAP//AwBQSwMEFAAGAAgAAAAh ABsuNQcTAQAA0AMAAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzIKIEASigAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJPBSsQwEIbvgu8Q5m7TrrqIbLoXEfYgiK4PENtp G0yTkImrfXtjV2t3Weqll4T/D/nnYzJZrT9bzXboSVkjIEtSYGgKWypTC3jZ3l/cAKMgTSm1NSig Q4J1fn62ekItQ7xEjXLEYoohAU0I7pZzKhpsJSXWoYknlfWtDFH6mjtZvMka+SJNl9yPMyA/yGSb UoDflJfAtp2Llf/PtlWlCryzxXuLJpwowZ1HevTWUQyVvsYgYLCSSAr8NMRiTgjSqsQ/gF4S77ds CiKbHeJBUkB/hLI3f4D2YhJrOSdWkK8an0On45gNTzQyp/pzPStInODRI4Vvyft1shlXczLsFH4c Tetg/TaCH/zD/AsAAP//AwBQSwMEFAAGAAgAAAAhAGSNNdVNAgAAnAwAABQAAABwcHQvcHJlc2Vu dGF0aW9uLnhtbOyW4Y7aMAzHv0/aO1T5OnGlpdBSUU7aJqSTbhIa3AP4WgPVpWmVhA7u6eekYe2Y Jt0D9FuT2H87PxuT1eOl4l6LUpW1yFjwMGUeirwuSnHM2Mt+M0mYpzSIAngtMGNXVOxx/fnTqkkb iQqFBk2uHskIlULGTlo3qe+r/IQVqIe6QUFnh1pWoGkpj34h4RfJV9wPp9OFX0EpmPOXH/GvD4cy x+91fq4ofCcikds81Kls1E2t+Yja8BZ/p6Sgxd35VaHe1EIrosPWdG3Fix+gNMqn4lnpux2vLDIW BlEcJbNFROxkanbINmD+euX/x30o9VR0IvPlwDvsvYe2u3cvv2RsGUTRdEqly68ZWyTzxC70taGC qVwiiugyMwpNKmqNyrn9sTRuNw1rVeABzlzv8aJ3+spxvYKU9rZb6b5+bqXHwfQIisnLzmY3NOEt DxqyqUA+Z4wyA36k/uLMI5k9vO7ebxHpkppbE4Rn8VW+Gc6krUvhluR9olDUMtuzyHVXBxvMZKFI KaALM+8NpWlhaiqqE6Sq5mWxKTm3C9OO+I1LrwWKpi9dOe6sbFTPcDtATuy+VGLCtbkcpAh3Bwjd Qa7uDnLV46AMqeqQOh5GiD7DHk00j03CIx8LxfGZ9Xy6thz5tNxAcXyink8wi4PF2EDmV2WoOEDz AaAkTOx4GCeQoeIALXpAYZhQA40jiDrIUHGA4gGgOJqNM9r+cRkqDlDSAzJ06P0xDumWGyoO0HIA aDGPxyFtO8hQse/gf5+Y9DgePsbXvwEAAP//AwBQSwMEFAAGAAgAAAAhAO/HOWbwBwAAelIAABUA AABwcHQvc2xpZGVzL3NsaWRlMS54bWzsnFuPmzgUx99X2u+AeJ+G+yVqppqkM93upa06rfby5hIy QSKAjCeT2dV+9z22sQmNSbNJxEPjPkwJ4APGPw6Hc/7m5avNKjfWKa6zspiY9gvLNNIiKedZ8TAx P3+6u4pMoyaomKO8LNKJ+ZzW5qvrH394WY3rfG5A66Ieo4m5JKQaj0Z1skxXqH5RVmkB2xYlXiEC P/HDaI7RE1hd5SPHsoLRCmWF2bTHh7QvF4ssSV+XyeMqLQg3gtMcETjzeplVtbBWHWKtwmkNZljr zildQ8+S+3xO/6+rTzhN6VKxfoOr++oDZpvfrT9gI5vD9TKNAq3gspijZkOzG/tZwG6wMPqq+YOw hMabBV5dv0Rj6JuxmZhw8Z/pX2iExumGGAlfmbRrk+V7xb7J8lax90gcAM5AHpT2ivdI0R1P9Of9 GuWG7cpu0X13+iQM1Oy6iIPJ3thuaAcW75PrhAFd7vTMtbyIbqfda5bp5WoNVbgmb9JyZdCFiZnm OQxzatKrg9a/1oTvLfZiV5qfC3SSPOcwcmicFx/TBQwWXEmHtWSIprMcG9DHiYmSBDiw+aYlmqd8 tW/BP3q6cDqyBfvFDFLLiyzPpe3GAMV/1zY30+zPxnaxSBMiG1v7Tow3TkULduSyaBuvsqLEKgM5 9Ko5Mt+fXyB+Yaox2UzL+TM19wX+B6AxyWclXBEYEVQkyxLuyoRgPmR5Te5pQ7CHxsAP/IEWKH8A pyF3wnQ9hvU5ot4jLa4+34P3+BvuE7jlTWOeYcJINuoVmeUpgsYNEuT6hl5pwq4ws5MW8w8Io48H mOOdhLMCzkWvYJFzvod2v0u7R7sKN/+79VG0xxZlht3BmnZ5d1AkJLv8NtS0k+vp8LQHXdr9k2h3 /Nhivpu6bu3bxbNA0w7+fte3z4anPezSHpxEu2s7HnuCadrZA1pHMvsimdfD0w4vafw9hMft4Wm0 h66rfTt9J2iiZx7na9+u9O23w9Med2mPTqLd8+xYv6Vq2g97S70bnHYHXim3fXt8Eu2+5cQ6ktG0 H0b7m+FplxlVFskA/KfkZPwoCD2dk9GRzEEZyJ+Gp93p+HaHRZxHZyAD33e1b9e+/TDf/nZ42t0u 7c5Jvj20IlZRohUznYHU+fb91aWfh6e9W0t1TqulhgF4dh3J6EjmoEjml+Fp79ZSndNqqbHtibA9 iHyai4S3gFYREbq2zwIdKhzwvSigO/NcnRBUCE3AocoBNC7KO8jzsePkhfEE15kWdHldvcyzOd1K T6LGD1+keGBGb0px7LrdDUrZecHL7Y1mROsRzMH1CD0SAk7K/5YLON0CqnNiATW0fLtx6I5vezvi GMcLAxAUcHWMHTlRcxucII/RkH+HopszQ96tmwLzcLcc/Ubqxo7nNpCLGirzsELbFnhhKBhvPb1G XOvKtnVlZ0a8Wyx1TiuWBpYdy2JpIxPoIM4jd+7GNeIgeaRBVCMg4HowLZ2E0Fatdjw2VJEV0k/g aaflxnC6RVKDyiRBEdskHLeFyt8Q9W6XSxu0O7i7URxB2Mw1vUHsuizL0+/RMTySWZCtFPRuRSxM 0Mn110LjKZWrTxiB6LsAgbq5pWJl0Xp180ggsm+kwlzpSjfsClrV6tW9mtXfD3zPkkaOHE9X1gDl eHbLgMePpxvEthPC2xu8SinjUCrMjiFPzUTa3/uA/jHUgMoylxhQGGKAQ0Zaxw+oZ9se5Ea5Dtny 4yBgt3779nxRA/rnUAMqKzlyQLvFnOMHNHC8yJUDSmdMfJUOoRV9GOTLuEP/OuuAJpvivpkNM6OL X8/vcWUS955glD0siXGDcflkzMqigCdXiQ23TexKE5AlIvCDTxECE2z2CXuVYk96uQncbjMxhT4Y 2M0vbdBJQ+30oa3VfIZLO0mmmTtkByHLg7F6iOfEu5g4EdM5yclE/Q/luums7CUP0Xoe0U26zI/g McKeuW0ebGvuDJ9WQzZCVbeVLUPjZYrmt8XcIM8VTKYiOIMJJHnKs34EZbl6G3TggCzbAeGlekrP AfMUhhbCtpdvsTulhwIkeJYLxXoLHZjaAtNp6MQ1Vyaz+sFuE1zSRAdsQa8CbLB+NrAdx2rfsFRg uxEk0pqQU+Rie/LAGmw6D+67BlsmsPrBbpNaarAFvQqwwfr5wI5iXypPVWA72mP3zaW8QI8t01b9 YLepLDXYgl4F2GD9bGC7Dcy9ocj2xF/tsZsJyDw3cIFgy2RVP9ht9koNtqBXATZYPxvYnuXyGJpq jlQeW4civbPfLw9sT2bt+sFu03hqsAW9u2DTeQHnAzt0pOJCDfbWpxq0x75wj+3J7GUv2MC+SGcq wZb0KsAG62cD23ddEAfBrdLnsfkOPHmmwb50sGUWtx/sNq2rBlvQqwAbrJ8N7MAOITGyB2wdiuhQ RKb7PCm97we7leOrwRb0KsAG6+cDmwk+94CtsyIa7BbsbxdogP39oYigVwG2qN1wEcNpBZrQBVnz Po+twb4YsJmYRXxbECQ68C07WvynsshHnE3Mf6bTOHBm0fRqant3V97rOLy6uQv8qzvf9bzZNLqZ ubf/QrWtsr1xglP2GcO34nOMsHLnE4irLMFlXS7Ii6Rcjfi3FEdV+ZTiqszY5xRtq/kmI/ssnm3R ooodRqwKBOcL58ZqlOJsabWp+UxikuPfUPV+zRQ08PVHkmJQyMOqCr732FQ2211o3+Hziv8BAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDYueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+b YwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXi WcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxj Ip9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLx vgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHOE j8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LIC Qd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJT ryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95 LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7E sG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZ GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsD BBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePs MG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPc KcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1Qo Hp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3 AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzhI/BCsIw EETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8 r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2 pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H 1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQD lmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL 5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUd S/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAG AAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 MS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9 axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJ WYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNy plSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwA AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc4SPwQrCMBBE74L/ EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2u tiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVR ac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu +wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtsk ZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLi wUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6 Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwu cmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK7 4DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhd SBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrK GqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAGmiXyEeAQAAxwcAACwAAABwcHQv c2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TV3WrDIBQH8PvB3kHO/WKS tukHNb0Zg8KuRvcAEk8+WKKidixvPykMEiiOQsCbgIrn/Pgr5nj6GXryjcZ2SjLIkhQIykqJTjYM Pi9vLzsg1nEpeK8kMhjRwql8fjp+YM+d32TbTlviq0jLoHVOHyi1VYsDt4nSKP1KrczAnR+ahmpe ffEGaZ6mBTXTGlDOapKzYGDOwve/jNp3/r+2quuuwldVXQeU7k4LavtO4Dsf1dX5stw06BgkyXTe Tge7xPOB3petYspWIdk2pmwbkmX5kjTnrxnODvI2Q2/fLORYlPHorcpDsmzJgB6VBTMrYsqKYGZx QwumtomZ2iaYmn/r4z2tWRqyrWPS1iHZPqZs/yejs99v+QsAAP//AwBQSwMEFAAGAAgAAAAhAI+s LG6zAwAACQwAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1stFbNkto4EL6n at9B5T07/sE24BpIAR72ksxMBZK7YouxK7LklQSBpLYqr7V5nDxJWrLFZBhSgR32YozV/an7+7pb unq1rSnaECErzkZO8NJ3EGE5Lyp2P3LeLefuwEFSYVZgyhkZOTsinVfjP15cNamkxWu842uFAIPJ FI+cUqkm9TyZl6TG8iVvCIO1FRc1VvBX3HuFwJ8Au6Ze6PuJV+OKOZ2/OMWfr1ZVTjKer2vCVAsi CMUK4pdl1UiL1pyC1ggiAcZ4Pw5J7RrIFohRy0pRMmHFcusgYy82sBI4Y6AgX9ACMVzDh/dgWuWY ImOPgDG0JFtlzGSzFIRoB7b5SzSL5k4Y75vNnUBVodE6FMfrFjoz85eBGbx4B+73Fgmn25Wox1c4 BXbQduSAiDv9BCecQhAobz/mD1/z8vaIbV5eH7H27AYQwX5T0L9pM3qaTmjTOSAl2KfX+mDAeM3z jxIxDglrHto885uNRdXJ632aErWaKK2Hg7ioQLlWos6rNTU0WW9pqLbx7wlKknAY+S1NYT9KeoPH XIV+3DfrmrF4EAdxGJtNLBJs0kI3qdpOebHTTH+AXxBUF83IIVgn38JSqRZqR4nRA1jDKaQEDzCm WDcaYe67BTRarWaUYGjETjs1ntEq/4gUR6SoFHqDpSICGQqgLQHyCsRRUBsdJGHFHRb47QGyZhWn sDPEbeM1KWhmf61j76mOupruKM5JyWkBoYQ6Q2gEK9h/klQTd6AotAXUrK2H05WN4j4MFlP/x4RN /GA40Ov/l7BQb4hu6F7BZwqt6TY6y0dCt2IaReFhtzRsnVFbC5JzGFOUbAg9Ad5IfQb8sqzE6ei9 tlVO5mvO10KVJwcfnQtfrY6iwzy9aItFtsUyrMijzjKEPLezCgVT5TMchZiunK6nzGwxU1JPVvPy 87g0/WyHhB1qZnI9HWMrOP70+fUlyAbTrO/33Ww4m7uRP7l2p9EscWfDQTbpwTid+cN/nG6CF5Cq qmoyr+7Xgtyu9SF5yjSEQjdxqHEQeEECh38QPtQtxKJhLitPbOWZc64n78+jz5TUcwVaKdEq9Pca C9jBivSbyXeOSJdlJLGMLGhVEHSzrj8c8GJOyufyApdLgD5KjZlDF67faTIP4jgcuGGQXbvRfDJx B35w7Sa9KMuyyTyahtN9/UqdOYPozi3b71///fP7128XqFlzeLeXSnjV11BzClPxBje3GzNE4QIO 9TQznxq4ckPJaNMHE41hr/DjHwAAAP//AwBQSwMEFAAGAAgAAAAhANi5trJkAwAAKQsAACIAAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1srFbbctowEH3vTP9B4z47vnAJ8QAZwLgv uTCF9F2xZeyJbLmSoNBOZ/Jb7efkS7qSESkpmYGEF2Pk3aPds7tH6l6uCoqWhIuclT3LO3MtRMqY JXk571l3s8juWEhIXCaYspL0rDUR1mX/44duFQiaXOE1W0gEGKUIcM/KpKwCxxFxRgoszlhFSviW Ml5gCX/53Ek4/g7YBXV81207Bc5La+PPD/FnaZrHJGTxoiClrEE4oVhC/CLLK2HQqkPQKk4EwGjv 3ZDkuoJsgRg5W1lI2/ElrHhWH1KPpzRBJS5gYZZLShAQhL6CcR5jimZkJbWZqGacEOVQLj/zalpN uPa+WU44yhOFtkGxnM2HjZn+W4IZvDgv3OcGCQerlBf9Lg6AFbTqWVC8tXqCEw4gCBTXi/Hzapzd 7rGNs/Eea8dsABFsN4W6V3VG/6fjm3RqUrxtVrUpBtcrFj8IVDLIU6VfpxffLA2YylnBVxmqSyAV vxu7+qPmw9gL4FSTJVdDlqxV4vfwqxdxQIWcyjUlmhAIGwcADg+gn2LV4aS076bQ4YUcUYJhAjbk yf6I5vEDkgyRJJfoGgtJONLBwDwAZBfYkVCcDSQpkwnm+MsLZJUfDmBnCNpECK81ha8T2TBE7vQU mlAck4zRBELxT0GuospCjOcwBHW3W9CX0DSmMscwrmQEUAhWQavo9vEP5UJ0SbdEv7Meqsl1OcRO PWrONfHwMFvqpI5ogSmJGcw1JUtCD4DXFTkCfpbl/HD0Rs3owXxFbMFldnDwzWPh83QvOujOSSeh aSYhxJLsDIAmBKTYaMeb1CWRMPw/4KjANDWtryVAi4ySonepTQrHhNL5n17YGYbn7rkdXowiu+kO xvawOWrbo4tOOGj4bmvkXvyyNpKXQKoyL0iUzxec3C7UYXKIaNVSqGTJ8xyvDYej5z/3LcSiYE5b npYpT8SYEsh/FUq31HsLlEpeV+jbAnPYwRTpLQL1iiSdlpG2YWRK84Sgm0Vx/4KX1imUGy5fAL2X Gq1DJ+7fYTvyWi2/Y/teOLab0WBgd1xvbLcbzTAMB1Fz6A+3/StU5iVEd2zbPj3+/vT0+OcEPavP 2PryBa/quqbvV5Rf4+p2qUUULqjQTyO9VMGVVB3VYPpsojDMFbf/FwAA//8DAFBLAwQUAAYACAAA ACEACzmJXokEAAC1EAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbMxY23Li RhB9T1X+YUp5ZpGEkITKsGXAJA9e27V4P2CQBqPa0SWjgcCmUrW/lXzOfsmeHkmAHaeW2C6XX0DM pfv06dMzLc7ebzPJNkJVaZEPLeedbTGRx0WS5ndD69PtrBNarNI8T7gscjG0dqKy3o9+/umsjCqZ XPJdsdYMNvIq4kNrpXUZdbtVvBIZr94VpcgxtyxUxjV+qrtuovgfsJ3JrmvbfjfjaW41+9Up+4vl Mo3FtIjXmch1bUQJyTXwV6u0rFpr5SnWSiUqmDG770PSuxLRViL+TfDEYmah2mDIsUaIPZ7LhOU8 w8BcxOSc0UKhzGxV3iohaF2++VWV8/JGmU1XmxvF0oSMNJutbjPRLDM/cyzDQ/fB9rvWEo+2S5WN zngENth2aCFpO/rEJh6JrWZxPRgfRuPV9SNr49XFI6u7rQMg2DtFvss6on+H47bh3KZaCubso6qX cmy9LOLPFcsLxEnh1+HFV5vWGMVM5ssVq6nXZKpZV08aPtr1leG0BbpnInDdntMzdHie7Q/sB6QE QeB6GGREjdPzXTvoGyetJTipTZeR3o6LZEeULvCNzPE8XhVQqaYdPJKVnuudRJ7xvJEOEDEu71BG EirgUSKWHzFUfRlacAmfC5P4mIMBLmXjttmJdN+3CLJ5BErwASOSUz2KvPNpjnrM9EQKDkdNdHo0 kWn8memCiSTV7AOvtFDMUIjqBUayro0PY1LkyQ1XnOAdW6as8AiewUIbvSGEMvPf6QffdSnckvZu JI/FqpAoBuZSkKiWNs9PUgKxb6FsoOlWOE8ShDuw/QDiMMlrq+S+IPq27YRBk5m6yE4RxKK2+Zgg Mq4uTYGmeYKThh4pp4v1FY5Tg+RIJjgS6+mqkGkyS6WkteY0FROp2IZLqG9LRxDSmea6HgkA2ygB ydsvNqk8soO52pOZ2KvOSNcl6dZIvX4AFKD7BLhO+IpwCSOFDeS9A9yBgzI/Fa7/inAJYwPXO8B1 eoFDKE6jlyIzAngFNRDIBm//CG/ohpTkt4eXQDZ4/QNe1w1B71vESyAbvMER3sDrnV5ur6kHAtng DQ94Cezp9faaeAlkg3dwhNfvB2+z3ghkfRIfdRHmzif0OOT2l7sJ6+k9AF10pgWo7vUAT7nnvfae n3It7t3z5lJ97j2faLQ2aJZWXC7b+76+1qgRNnTRw9wwV7dpprtoO5W2TzO3ansXmx+G1yU6duq9 /3Sm4Xga2EFnOpjMOp59ftEZexO/MxmE03MovD+xB39ZTRuaIFSdZmKW3q2VuF5ri1T243QApHGt R47TdXy8qDjuIQHAQmZetg3rt+mZFQW1f8eNmEcdynMTtNSqztDva67goU3SD7oy4/nEJL0sI37L yBztlGBX62zxgBfT/D+XF7wIw/Sj1JgGGC3kS+p37M+cft8NO64zveh4s/PzTmg7Fx2/502n0/OZ N3bHe/1WFHkOdP9Xtt++/v3Lt6//vIBmTQddvxDjkd6cjRSl+sDL64053vBnAfSEFhdDJf4egGRo 6WEJ2Wj/bhh9BwAA//8DAFBLAwQUAAYACAAAACEAXFHBZE0DAADyCgAAIQAAAHBwdC9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQyLnhtbKxWW3LaMBT970z3oHG/Hdu8QjxABjD0p0mYQhag2DJ2I0uu JFxopzPZVrucrKRXsk0aQmeg8OOHfHV077nHR+pdrzOKCiJkylnf8i5cCxEW8ihly751v5jaXQtJ hVmEKWekb22ItK4H79/1cl/S6BPe8JVCgMGkj/tWolTuO44ME5JhecFzwuBbzEWGFbyKpRMJ/A2w M+o0XLfjZDhlVjVfHDKfx3EakoCHq4wwVYIIQrGC/GWS5rJGyw9BywWRAGNmv05JbXKolj98sZAJ EgW8etYA6g7nNEIMZzCwSBUlCNhBY84UIJkAmS8EITqUFR9FPs9nwsy7LWYCpZHGqeZbTvWhCjOv DMLgwdmZvqyRsL+ORTboYR/IQOu+BT3b6CtMwj5ZKxSWg+HLaJjc7YkNk8meaKdeADLYLgrtzsuK 3pbTqMsp6fC2VZWhGKZ+4uGjRIxDnbr8srzwtqjBdM0aPk9QybzSzFZx5UfDRx0vgVNDllqPeLTR hT/A3Qxin0o1VxtKDCGQNvYBHC5AP8Va2ITZ93MQdqbGlGAQfkWeGoxpGj4ixRGJUoVusFREIJMM /AYA2QN2FDSngiQsmmGBP+8g6/qwDytD0nWG8FhS+G8imzWRlZrQjOKQJJxGkETjNFrTCERRM38G RqEBiBZ0S92JDGvZGoLlK4ZLFg2VcKmXNGUc0dQ5CTn8o5QUhB4Ab5g+An6RpOJw9Kbu4xHoU74S Kjk4+dax8Gm8Fx2c5KzabtXaDrAir4RtCAFbrd3gv/wiUvA7fwfPxzS2wGS12M1PbWxDm8tJ/hGD 5Wvn/uEF3VFw6V7awdV4arfc4cQetcYde3zVDYbNhtseu1c/rcrEIihVpRmZpsuVIHcrvT1A53fM 4q0NleamjcbzHK8Du5zXeNEt5KJhztuedt2eKefa8v52HiOpUxsUK1F26OsKC1ihbtIZLem8jHRq RuY0jQi6XWUPO7y0T3PkcqODUxRA76XG+NCZ9TvqTL12u9G1G14wsVvT4dDuut7E7jRbQRAMp61R Y7TVr9SVM8juWNk+P/368Pz0+wyaNbtmeZyCR330MicmKm5wfleYTQdOmqCnsRnK4WypN18IfQnR GPVZdfAHAAD//wMAUEsDBBQABgAIAAAAIQCtj1y6OQQAAGEQAAAhAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDEueG1szFhdbuM2EH4v0DsQ6rPWkqw/C7EXthX3JZsE6+wBGIm2haV+StGu 3aLAXqs9zp6kM6RoOVkXmxZG4ReHooajb+ab4czk5v2+5GTHRFvU1dhy3zkWYVVW50W1HlufnhZ2 bJFW0iqnvK7Y2Dqw1no/+fGHmyZpeX5HD/VWEtBRtQkdWxspm2QwaLMNK2n7rm5YBe9WtSiphEex HuSC/gq6Sz7wHCcclLSorO68eMv5erUqMpbW2bZkldRKBONUAv52UzSt0da8RVsjWAtq1OmXkOSh AWtlITmziBITO9hwrQlYni15TipawsYTSpAlL3KmXrXNk2AMhardz6JZNo9CnbjfPQpS5KihO2kN uhedmHqsQAwWg1fH10YTTfYrUU5uaAKOIPuxBXwd8BcO0YTtJcn0ZtbvZpuHM7LZ5vaM9MB8ABAc PwpUN9qib83xjDnaEe7RKi1K4ehdnX1uSVWDnWi+Ni+73xllaDOqbzZEez2TQmnrRPV75RJzpFVu NViPzgjjIHa0Rzx36Phe8NIvURR5Pgqgd1w/chwtcWq1Vt0kcj+r8wN69Rn+KlZowlu5lAfOlLfB JzQB5PAD3HKKGcMq+9MSMqaUc84oZFTHjJzMeZF9JrImLC8k+UBbyQSRKnpaVHkDICQw36lkVf5I Bf34SjM6jybwZXCHQQhLzc8/szQ0LC23z/qb3iWIarfPmiiIbAg7w+3bCXOHkRt2jA3jOIQ74SVj IdClKFWMRYGH0toJOhGU8Tp+jD/OMoY08R13IXBIScWdypyiyiH71ZLyNbAFkQdZDAq293DbKZZz tgIScLOtIcsXBefqAa84NueC7CiHi2KPNwMwWFRS70SBc4Sq7kMUVuyd6AEujX5YdvhQDyy9Hqof ROgZcn14EWSHd9jjHbm+SrPrw4sgO7x+j/cYhtcHGFF2gIMTwLEXq7S4PsCIsgMc9oA9L4bMvcoQ RpQd4OgEcOQPrzTnEGUHOO4BI9orTTpE2QEenQAOg0jd/dcXw4hSXdWm3iP6C5R7qJf/V8X3TcVP qWTkkdOMbWqeQ88xvETlzyU0Ob9Bi035CuqSqv66MGPnqryHi6VyJPYnqoHqe5azNbrvqlbQX2Oz /LubxrM0ciI7Hc0Xtu9Mb+2ZPw/t+ShOpxDywdwZ/WF1fWMOpsqiZItivRXsYSst5O37zZkGh+2X 6w7cEIYK1+vbMcCCai7bkAWGnkVdYyN4SpB/CYJW0Mkohn7ZUgFfMCR9p0cDCt5M0mU9EhqPqFmK 3G/L51d+Uc08DF9mcvhPswUMraD6rGtUS6zGjMvF7yxcuEHgxbbnpre2v5hO7dhxb+1w6KdpOl34 M292jN8Wp8gK0P3bsP365c+fvn756wIxq9ppPcHCEudcNaRy8YE2Dzt1i8NgD/EEzSxsNTDKYzcO or0I6jD/Gpj8DQAA//8DAFBLAwQUAAYACAAAACEAbAsY1Z4HAAAzLwAAIQAAAHBwdC9zbGlkZU1h c3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxab27iRhT/Xql3sNyPFQv+i0EhqwChXSm7G22yBxjsAdwM tmsPlGxVae/QG/QWbb/1KHuSvvdmbEwCu0QhUhJFisCeefNm5v3e/3D0ejUXxpLnRZwmPdN61TIN noRpFCfTnvnxctQITKOQLImYSBPeM695Yb4+/v67o6xbiOgtKyTPDeCRFF3WM2dSZt1mswhnfM6K V2nGE5ibpPmcSXjNp80oZ78B77lo2q2W35yzODH1+nyf9elkEod8mIaLOU+kYpJzwSScv5jFWVFy y/bhluW8ADa0euNIx3C/8EJE+D2eqs8PfGLE0Qqk1GpZ5vER69I9+UDkxpKJnjmeWmbz+KiJS4BY P+HiIrvMOcenZPlTnl1k5zm+hO+W5znwBJamkbA5yBcZ0IQmo9cEyBTjjeXTkhPrrib5HE8E4jHg hIDiNX7CItblK2mEajBcj4az91tow9npFupmuQFcrdoUb6VudPs6dnmdy1gKbpwLFvJZKiLQFRIR 3VAtAylmZ2l4VRhJCndGUairgnBKxnh/3CqbGfI6AylJZKvp1CScLKnoC5JveehKKq7XBqUj0dht 13eCTfkEtt3xcR6lZFmu04IXPMuaUZYX8ieezg186Jk5DyUpAlueFVKRliSEvjpI1pWrfhpdIxhj +AbMweJg/SzNP5mGeJMUPbNjuS7sLemFTmoaeX1mvDEjxSAFlYMVLAmBT88MZU5nScDaThYyncT6 RGpL3FwU8kJeC05qAeCxLogVPuBAgqHB86Tx8QIMfi4HgjNwCFqF5PFAxOGVIVODR7E0tN0TDOAe gCVKSZKsiCVPonOWsw83OGsRkWxKmQBySpF2q5NTqRPqcl2bbATovtqEAjK1ad9HqSzQHlQwEm9p dRta5Xq21/Gdx69VqBZ3UiSwOEMsSSPp+vdULJQe6VWxoVigZKS26qPckjzGHXT5godpEhmCL7nY gz3p2B3YX87ifH/upAx34D5KF7mc7X14V2nj3nCM4slW7hBGDmrSbmnSQyY3AwQJ5L4mHUnwYp/A wzIx0aZNMFKYwGByx3jhOx783TBt23KcKmA4vmfZ3uO37I14QaZaRgWKEEthoSkzMQXvL0wci/gE /TiK00L3hmNFKuJoFAtBL5jurdMguVLZkYwTqRKjtrcOpVXORMGixgdsW+1EE+BL8CDqWYct3Iss fyIiypp+t4ZBf9hutRvDzmDUcFsnp42+O/Abg04wPHHsljdodf6AoEpJQwSaJuM5H8XTRc7fL1To /nbwg2OQnOSxZTUtH3JOy167DTgLnuuw1uGV1jFKU0yw6yGPLPq+9jGBZIEQ/XXBcthB24iKTJhK 7WsjjmW7ZVK13UiCjvesjaTMux6fmRxWJ/1SJy/A9LnxbjEf39BM8n731UyoKoH1NuUkxb+TA/c9 D5yAyvi3K+dz9+CqJHh8qll58L4/sjzPDhq2NTxtuKOTk0bQsk4bvuMOh8OTkdu3+5UHL1DzEtAO 9Lh3cdxfPv/9w5fP/xzAa1O1oop5eCxbBKHI37LMgAYABE0JxTzEwJ4ZXcHTeGrjGFTEcgVP0RU8 sTCErgNQ6IdyBObVSEXjlCNQAqkptxyBDEqNeOUIRA014pcjYLMzESdXkAjhl2lMUvGzGiifMGOh Xs4Zu04X8k0EleyNEYq1tuW23cDx3Q7UpV3sWeRvIl3Mg82WqzdoIWFa0+pSbSctyKriq3PAnbQg n4pWx8OdtCC5ilZ7qJ20INOK1r8lmc27gbQr2vY3aAGHipa6DhsS3+TbrtF2vsEXmnMVX4uy068w 3gCu7LLURKGBlyvqERSoBFTg0ytanM7JdHKIcc8Az3LJxheQGlL/AvGWqi3B2VnSz0HzAFdszyX6 FUhm0GuAHuD5IgmhCaJbaVnYx5YZtoPC81AnjnQlSAxhTM+OF++gD0n5WM2rQesE+F7xHHuY++ao wARZ1zNZOiilixPoWPXMH+e/NIREECDDYzcmOFMTYXFjIixwYlc+uylV6BVC9+GWiOcsP+uZjmt3 8GJxAm4PRNUoB8r0/KHlD6KE/bWgahiMUkjtMatWYjrJYyZMI4tlOBuxeSyggeaALYUzlhccDq4L p/FiACM03DO/fP5Lya+Go4rWD4FjsgvHpLEDx6TxVRzJHGyslRRWbcAK/V2FlR14UPeAS9al1NPG 6s9bWNnBQ9ncAbFCgLTrctZYlc3dGlh2QEXK8wDrtmHZD+YgDwgWIqTBcmtg6a7qcwVri2Wh032Q aHZAsBAhDZa3BgtaLm1StbUbfEaW9d+/t73gU8AKAdJY+TWsPMslp/cssdqWXmA68+gNCxHSYLVr YHXaFgXcF7C+1nfeK6c/oBdEhDRYwRoslaZvJIPPyAs+WctChDRYnRpYQeBTk/DFsh6TZSFCUERv 1MdZN5UznlfVMlSO5wpSXUPWf8VQleCapOxeqHLtQQqzWiWrnPWTrGTLn8kcvhZ6avLZXj2Wna4X +ewo2Jw2/hLmITofT02BthdJVmAHlMu9aNCOyoSypRcNgpC1oxpou6pV+qJBOzJwyOioD/EioB1Z r++1X5w0NfGrTLOeXELiuf5HGP7Tt/yx+/H/AAAA//8DAFBLAwQUAAYACAAAACEAn+nAORQEAADE EQAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbOxY3XLiNhS+70zfQeNee/2D bcAT2AEc92Y3yRT2ARRbBHdly5UEge10Zl+rfZx9kh7JFiGEFGi4zE1i5E+fdL7zo2NdfVyXFK0I FwWrBpb3wbUQqTKWF9XDwPoyS+2ehYTEVY4pq8jA2hBhfRz+/NNVHQuaf8IbtpQIOCoR44G1kLKO HUdkC1Ji8YHVpIJ3c8ZLLOEnf3Byjh+Bu6SO77qRU+Kistr5/JT5bD4vMpKwbFmSSjYknFAsYf9i UdTCsNWnsNWcCKDRs59vSW5qsFY+stv73y2kcXwFI541BNOzKc1RhUsYmD0yNGGVBBr9StQzTogC VatfeT2t77iecbO646jIFUM703LaFy1M/6wABg/O3vQHw4Tj9ZyXwyscgxJoPbDAYRv1FybhmKwl yprB7Gk0W9wewGaL6wNoxywAO9guCr6uG4temuMbc2aFpAR5W6saKIapn1j2VaCKgZ3K/Ma87GZl yJTNir5eoFZ2RdXimpdaD4MXoKkWS67HLN8ow+/hvx7EMRVyKjeUaEFg2zgGcvgD8lOsoppU9pcp RHUpJ5RgiPpWPDmc0CL7iiRDJC8k+oyFJBxJbZdQlFegjgTntJSkyu8wx7/tMSv7cAwrw6bNDuGx kfB1ITtGyDaa0B3FGVkwmsMm/LfJKr5BNmA6tyACITyMD17RVsm1F2VB2IV81aHmRa6rnrW+JuAC t9ODcQupsAtCP+xHHe1Aw6QFaNxsNDnoNbU2XVFPpw2OczJX8qr9+71mUdB2BwCP/gFssIs1AMB2 DmDdXawBADZ4ifWe7cEAABsewxoAYKNjWAMAbPcY1gAA2zuGNQDA9o9hG4DSuk0n5RidTTATAcM2 bd6YXSqCdHKJZ9nVZND+kjpwz0joKclYlSNKVoSeQK+z7Az62aLgp7PrhDiDPWVLLhcnbz5oMvJk d6TF/CA7nCIXrWvBf9U1rQmcp+YwOPO42Ktr2n/6qFCVRj/snhmH6loU9N4LG5wI74Utfi9s20bo vbCd0LCFprAlWJJn3Zouxf+/qjVNcC6hR93r27SDXi9w5zTFc/iCUZ8jf3pJb5x03a6d9CepHbij a3scTCJ70u8lo47vhhO3/5fVduY5mCqLkqTFw5KT26X65oEjba8DftlbQ27pflEOPc/xIvhu8/yn Axn2omgue+5Exj0pY6qP322nQ3VWvtVBc8kbD/2xxBxWMM31ke76HCddVpGuUWRKi5ygm2V5v6dL dAld4F4AqA9Kc+SAPkeabfyOo9QLQ79n+15ybQfpaGT3XO/ajjpBkiSjNBj74238CmV5Bbs7N2x/ fP/7lx/f/7lAzOrK0twRwKO6SdChSPlnXN+udPsGdycQTxM9VMNtCeiioE8QxWFuX4b/AgAA//8D AFBLAwQUAAYACAAAACEA5utg7nIFAACTGwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ1LnhtbOxZ23LiRhB9T1X+QaU8szBCSIIybBkwefHarsB+wCANRlndIg3YJJWq/a3kc/ZL0t3S gLitBeZhq8ILCHF01Jfpo57WzcfXMNCWIs38OOrq7END10Tkxp4fPXf1z5NRzdG1TPLI40Ecia6+ Epn+sffzTzdJJwu8e76KF1IDjijr8K4+lzLp1OuZOxchzz7EiYjgv1mchlzCz/S57qX8BbjDoG40 GlY95H6kF9enVa6PZzPfFcPYXYQikjlJKgIuwf5s7ieZYkuqsCWpyICGrt42Sa4S8Fa+xJPXyUv8 OP1d1wicLuE003vgvzsOPC3iIZwYxGHCUz+LI/onSyapEIiJlr+myTh5SumCh+VTqvkeEhQX6vXi jwJGPyOAwUF95/JnxcQ7r7M07N3wDkRDe+3qkLQVfsJFvCNepebmJ93NWXf+eADrzu8OoOvqBmDB +qaQ7yT3aN8dQ7kz8WUgNLb2KodyuPQ+dr9kWhSDn+h+7p77sFRk6DPSJ3OtCD1SFbj8T4qHwmcQ UwqWfO3H3godn8I3neSdIJNjuQogBXC8DBglgHc8MfstD23pNHhbhoOTvAOmwAckK+BYByKqfR5D HYRyEAgOdVKEWvYGge9+0WSsCc+X2ieeSZFqkqKQoQE3wC4hlQWliLwnnnIwYosZo8E7cGdwUfkD h3nAj4e9uQ475vwp4K6Yx4EHFhiXyADGU4flCmtJJexIIjBaO0vSbNlQ4LQuWavZYqyJJm1Wp9kw G8wBccE1ajXbtkU2QxhyInI/XxIqIirDGo/ceQxqMc0py9krkq2FPL2nuvAjDwocD/Hu08UDqBgZ kq8FLfuzqxsmWjpVbpbWBh0asHoKQuVVJdbGPitSoR1gZnPD2mYmWVCFlTn7rEhVsJobVta0mYXg SrSE3A4BchW0rRKtYzhkw7m0yFXQWhtaw3DAhHdYi1wFrV2itc0mrcNzrUWugtbZ0CJn9ZQdiC1y FbTtEq3Vst+VMuQiLSnXBCka3gRW3Vq66O7nKxwKDglctqVw56iYqVRsEEcSanVLyEg14FGrHhQn Pkqwuuc8mBUylksMPlYpTHhQfp5gQo7LmMFs07Fb35GxZrvFoDgQUUXHSIbKidp7Um3UKacsAeBQ iUlZybCE1lgFAKySiBKWlGSNVQDAqrovY3FVrrEKAFhVzEexCgBYVaFHsQoAWFV2R7EKAFhVS0ex CgDYvEBUJ0DxJZFc+/ZjVBA1A/Chipaevye0JWPhxpGnBWIpggMFuktPdXEC/WTup9XZiyd/ZcUZ xYtUzisbb+YVWZ3enx1kh97kot1ZS+naZLc7I4vPF7W8P867MxS4PxY8hbaz0DiKNrXKlTXOMlsN A8yFTuxYr8ZsUL5rr9bVr70a9MvXXq2rN/+PvZqlNO1Qr0at0fmyti9lpJNnS9mxfm0jZdd+DWO+ 3f9c+7UjM53v7nh2G6prv4YjtHw3uBubH7Vfs5W2DbkUW5tQCzvM84Ut79c8CQPE7e0oy/dUR/ej dNfd6Rec3Aws6Qft72cwi8bJ8l9s6PSHdsOuDduDUc1s3N7V+ubAqg3azvAW5hatQaP9t14MWT1w VfqhGPnPi1Q8LqSO7G+PBWBjQreWPcbqzIIxPDM2+wywBWku207DqDCftY/iGIes5XGnfYkEzSS0 0PsPIfbG7POUJF02Im0VkXHge0J7WITTnbjQKOK9Cxde8wD1wdC8MU85JTTr9du3RqzVMpyawYZ3 NXN0e1tzGuyuZjXN4XB4OzL7Rn+9fjP0PALrTl22377+88u3r/9eYM3SoDp/3QOH+E6ItCJIP/Hk cUm7UngVBit2QKcSePkFcUHoBoIc6mVa7z8AAAD//wMAUEsDBBQABgAIAAAAIQCzeW7i2QIAABUI AAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1srFVbbtswEPwv0DsQ7Leihx9x BNuBLdn9SWKjTg7ASJQlhCJVknbtFgVyrfY4OUmXlJSkaQqkqH5sitwd7swOyfH5oWRoT6UqBJ9g /8TDiPJEpAXfTvDN9dIZYaQ04SlhgtMJPlKFz6fv342rULH0ghzFTiPA4CokE5xrXYWuq5KclkSd iIpyWMuELImGT7l1U0m+AHbJ3MDzhm5JCo6bfPmWfJFlRUJjkexKynUNIikjGupXeVGpFq16C1ol qQIYm/17SfpYAVtdaEZXnB0xsqFyD5M+ngL7ZMNSxEkJE9cmCtkws6Kqa0mpGfH9R1ltqrW0CVf7 tURFagCaROw2C02Y/eQQBgP3Rfq2RSLhIZPldExC0AIdJhhadjS/kERCetAoqSeTp9kkX70Sm+SL V6LddgOo4HFTw6pm9CedoKVT6+A/sqpDCaReiOROIS6Ap6Ff00uu9i2Y4Wzgqxw9E76JqxetHm28 Ak2tWPowF+nREL+FfztJQqb0Rh8ZtYJA2SQEcPgB+RkxvqbcudmAr0sdMUrA9414ehqxIrlDWiCa FhpdEqWpRNYFcAoAcgzqaGhOA0l5uiaSfHqBbPiREHaGotsKYVhL+Hche62QMdEUrRlJaC5YChUE XWiaaqD8FY4FYRkGI4JLfEvcSmsa8F8aZ3AejLu/+fFoHp96p058Fi2dvjdbOPN+NHSis1E86wXe IPLOvuOm0SlQ1UVJl8V2J+lqp/HbWlUbwDTD911/CBeBHzw1B2oxMN22p9+2ZymEscXzBvW6aFCm Zd2hzzsiYYe2Se2B6eAgdKvIoFVkw4qUoqtdeftCl34XusBDA9CvSmMPRsf+nQ+X/mAQjJzAjxdO fzmbOSPPXzjDXj+O49myPw/mj/5VhjmH6v7Vtg/3Pz483P/swLP2ZqmfHBiad8m+Kkxekmq1t1cf PMbgp8hOVfD8NhfwU4jBaJ/z6S8AAAD//wMAUEsDBBQABgAIAAAAIQBjDDJjqQIAAMMGAAAhAAAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcueG1srFXtbtowFP0/ae9geb/TfEApjYCKELI/ XYtG+wC3iUOiOk5mGwabJvW1tsfpk+zaIe3GOqnT+APOzb3H95xz7YwuthUnGyZVWYsx9U88SphI 66wUqzG9vUmcISVKg8iA14KN6Y4pejF5+2bUhIpnl7Cr15oghlAhjGmhdRO6rkoLVoE6qRsm8F1e ywo0PsqVm0n4jNgVdwPPG7gVlILu6+Vr6us8L1MW1+m6YkK3IJJx0Ni/KspGdWjNa9AayRTC2Orf W9K7BtnecRD3lNg0ucGATyfIPF3yjAioMBDZDBNUzY1kzKzE5r1sls1C2tyrzUKSMjO1+xrq7l/s 0+yjwDRcuAflqw4Jwm0uq8kIQpSAbMcUndqZXyyCkG01Sdtg+hxNi+sXctNi/kK2222AHTxtali1 jP6kE3R0YtCMLDikrKh5xiTxnwi2VYAol3V6r4iokbJRomWaXm06XEPf7NQUpJU+0zh4X9BE4DlF /ZCcb8lahUyyXXT1CuW2OuptVGc7o8kd/tsghFzppd5xZrVCRhDm6KAx5asfD6P4zDtz4vNZ4vS9 6dyJ+rOBMzsfxtNe4J3OvPNvtGsKqeqyYkm5Wkt2vdY4DhBKNBjHAA8ME87tEvuu9IwzwAO1t6dt DkI98X3XH+DY+sEIFdfIwvZiPRTZAiR8PEAzUkGITSPfjhwuW2P+bk+vsyepa42m/GpQcAyDci1b hz6tQeIOnUmdua2j/2USO6oi/U6RJS8zRq7W1d2BLr1j6ILXIkK/KI3V3SpyvPmNBol/ehoMncCP 504/mU6doefPnUGvH8fxNOlHQfQ0v8owF9jdv47t48P3d48PP44ws3Z025sSl+YmtZchlx+gud7g sYYQPx04TzMbavBjsb8snlMMRvfxmfwEAAD//wMAUEsDBBQABgAIAAAAIQDUNUdE8AQAAB4SAAAh AAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1szFjLktpGFN2nKv/QpawxtF4I1YBr gCGb8cxUwB/QSM1IcesRqcGQVKr8W8nn+Etyb0sNAmMjZmaRDQhx+vR9ntvSzfttIsiGF2WcpUOD vusZhKdBFsbp89D4uJh1PIOUkqUhE1nKh8aOl8b70c8/3eR+KcJ7tsvWkgBHWvpsaERS5n63WwYR T1j5Lst5Cv+tsiJhEn4Wz92wYJ+BOxFds9dzuwmLU6NeX7RZn61WccCnWbBOeCorkoILJsH+Morz UrPlbdjygpdAo1YfmyR3OXibLX9fbA2iYMUGblBjBJ4HcxGSlCVwY5KlEhjI51hGZMJytENhynxR cI7odPNrkc/zp0Itfdg8FSQOkaqmMLr1HzVM/UwBBhfdk+XPmon521WRjG6YDxEh26EBidvhJyxi Pt9KElQ3g8PdIHo8gw2iuzPort4ALNhvCjnPK4++dcfU7ixiKTihe68qKIOl91nwqSRpBn6i+5V7 wcNGk6HPSJ9HpAq/RKoaV/2p4qHxpYqpNnQfCdvpQ22pcJh9q+ecxMTq9TyLWgbByFDqmjWi6XHF nPtyO87CHUZ0Cd+QOJYGUQaFuqziLEo5lzsBaWa+2AgKBhEmnqGTBBQB80O++g1ulX8ODTAJbFpq x/d4yDFcN3ggwsyHOMAHLBUMG5GnnY9zaMRETgRnQF/7JEcTEQefiMwID2NJPrBS8oKouEHbgmXI LtUeipKn4RMrGBrVZMZUMB92hvhqn+Gyyvb3cw5BPO6CJ8ECHmUiBCPM11VAHEL96iJpn3zL6TuY UGyGc9l3KKWAqLLveI5FoRQq96uGUm5XdagjobOvWquZqjrlJ5m2sPoqygYALs26XptV4TWxGgBY 6wzWbmI1ALD2GSxW294GDQCscwmrAYB1L2E1ALD9S1gNAKx3CasBgB1cwlaAcz0EKwkw7JvllT2F mqpaqjzqqapvVPPAh95SFe4VbTznQZaGRPANFy3oVW9dQb+I4qI9u2qIK9hn2bqA6dfWeBsL8xr6 eHWWHcbcm6qZrdVsgaluSpkKCIx9PapeNMxwgoCEwyiImFgZcAYAgVOJVEMNJUddzFXFo/jirR9N N2pbDq36/DDyj8ab7Q5oz321wJGEFffqiBGnIZx28BJNW64f4FCostnQNHqkUzgTEQudiPJWU+kZ 3YrvSE9PNLLmG1AbdyWt+I608URHaz5q9anblnDwA63VfJ7podS3MvCI70SPaz7T9MC8l/CdaLbm 69tqbF1v34mu13xI1johR/6eaL/mc53+y/Lx/5gP0Nn6NKEOGHjM/f65ytFKNGWSHymR0s7XKlEo v9EhWp0W8GnjrBBBjx88OHseUiqgzq4reDjCB5y/6NQbT/u9fmc6mMw6du/2rjO2J25nMvCmt1Ah zqQ3+Nuoz/ohuCrjhM/i53XBH9dSKczlIzBoitpajijtUheeCKl5mKBgC4rP2w4KV6dnlmV43G6O CgeH22sTtJJFlaE/1qyAHephQS8ch69J0ttGpK8jMhdxyMnDOlmexMV9i7jAGwegPhuaC4P0mtDs 63fszqjjmF7HpNO7jj27ve14PXrXcS17Op3ezuyxOd7Xb4mep2Ad1ts1Zfv1yz+/fP3y7xvUrFKW 6q0DXOJLClWKovjA8seNmsLwVgbqaaJu5fAeBuKC0AMEOfR7ndF/AAAA//8DAFBLAwQUAAYACAAA ACEA+OhJwK4EAACNEQAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbKxY25La OBB936r9B5X32QEZ33ANpAAP+zKZoQL5AGELcMW3tQWBbG1Vfmv3c/Il6ZYtwBNmhyF+AWNaR+ru 06fbvnu/T2Ky40UZZelAo++6GuFpkIVRuh5onxZT3dVIKVgasjhL+UA78FJ7P/z9t7vcK+PwgR2y rSCAkZYeG2gbIXKv0ymDDU9Y+S7LeQr/rbIiYQJ+FutOWLAvgJ3EHaPbtTsJi1KtXl9csz5braKA +1mwTXgqKpCCx0zA+ctNlJcKLb8GLS94CTBydfNI4pCDt3kULPYakWbFDm5QbQieB/M4JClL4MYs CsS24ORLJDZkwnI8h7Qp80XBOVqnuz+LfJ7PCrn0cTcrSBQiVA2hdeo/ajP5MwUzuOg8W75WSMzb r4pkeMc8iAjZDzRI3AE/YRHz+F6QoLoZnO4Gm6cLtsHm/oJ1R20AJzhuCjnPK49+dsdQ7iwiEXNC j15VpgyWPmTB55KkGfiJ7lfuBY87BYY+I3y+IVX4BULVdtWfMh7KvpQxVQc9RoI6fcNwgbfguekC y7rPomKZrm3CTYKxsWzb6blyE4UEm1TQuSf24yw8YEiX8A2ZY2mwyYCpS1zBvLgUc3GIIc9wvYsp nIiweA2lFAMLmBfy1Ue4VX4daMB32HKpPD/aQ5KbOBBi5kEg4AOWxgwrkaf6pzlUYiImMWcAX7sk hpM4Cj4TkREeRoJ8YKXgBZGBg7qFkyG6kHtISJ6GM1YwPNQ5MuaCebAz+K58lmHAfLyc9J5KuiqD WcwCvsniEA5hYIigWFSCb6IAVKAG5QJcVoS5jQg2NRzHqpKmqqPBA5NSJMu1RHgx+wkrHmQ1RmkI 0oKXmMrl9hH0U64640QPSFHvWLMHbeHSQCJVUKbloBW5Bs84eVCD1Hi9E16fmpL8V+GhZcUNwEOQ Gs884dGeQ7HErjsgFsEREFFqQOsM0IXqvQ0QUWpA+wQIagAHvOmEiFIDOmeAjikzd4PLiFIDuidA RLs+KY0YIkoN2D8DtC3nxqQgymVNalc7TKUdC6zHc+HoIUN+VThQr0EwQXg3LF7VGiIlSfYQ6SM2 17l0Vym+agEXm4nVg1ZR9YpTi22IiNuF1lJtopD+p5lINbjUQd6kIbRRo9iBajrcqCG0oUkIUuPd qCG0QdcWNKTfsoQ08FpQkAZeCwLSwGtBPxp4LchHA+9l9QAiEWgix9FF0ur2CQdFQw44ZWPCuWWK sZQS+UzwhhKZbShRKH7SIVo1QdSfi0Ik9U/NYWr2bMiF/CEnxRU8i+DzxN/Ud8e+03V0vz+Z6mZ3 dK+PzYmtT/quP4IOY026/X+0erQOwVURJXwareHx5WkrNKzy19MBWZRbiyGlHWrDAxg1TgmAsyBM u43CVumZZhkOt+etQk50v9oqVqKoMvTXlhWwgxo4X5k435KkdiPiqIjM4yjk5HGbLJ/FxW6DuPCA D9AXQ/NKI31LaI78HdtTalmGqxvUv9fN6Wiku116r9s90/f90dQcG+Mjf0v0PIXTvZW237/9+8f3 b/+1wFnZ2auHfLjEdwJyaomLDyx/2kl5g5cgwKeJvJXDaw+IC5qeTBBDvUYZ/gAAAP//AwBQSwME FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0NS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBv dpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnF ZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6d pTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhAPnPCTmDBgAAXBsA ABQAAABwcHQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixm61NG8Ruhx5p iZZYU6JA0kl9G9rjgAHDumGXAbvtMGwr0AK7dJ8mW4etA/oV9khKshjLSNIG27DFh0Qif3z/3+Mj df3Go5ihQyIk5Unbq1+teYgkPg9oEra9e8P+lQ0PSYWTADOekLY3I9K7sfX+e9fxpopITBCsT+Qm bnuRUunmyor0YRjLqzwlCcyNuYixglcRrgQCHwHdmK2s1mrrKzGmiYcSHAPZu+Mx9QkaapLeVk68 x+A1UVIP+EwMNGnirDDYYFLXCDmTXSbQIWZtD/gE/GhIHikPMSwVTLS9mvl5K1vXV/BmtoipJWtL 6/rml63LFgSTVcNThKOCab3faF3bKegbAFOLuF6v1+3VC3oGgH0fNLWylGk2+hv1Tk6zBLKPi7S7 tWat4eJL9NcWZG51Op1mK5PFEjUg+9hYwG/U1hvbqw7egCy+uYBvdLa73XUHb0AWv76A719rrTdc vAFFjCaTBbR2aL+fUS8gY852K+EbAN+oZfA5CqKhiC7NYswTtSzWYvyQiz4ANJBhRROkZikZYx+i uIsZHQmqGeBNgkszdsiXC0OaF5K+oKlqex+mGDJiTu/Ny+/fvHyO3rx8dvz4xfHjn46fPDl+/KOl 5SzcxUlYXvj628/+/Ppj9Mfzb14//aIaL8v4X3/45JefP68GQgbNJXr15bPfXjx79dWnv3/3tAK+ LfCoDB/SmEh0hxyhAx6DbsYwruRkJM63YhhhWl6xnYQSJ1hzqaDfU5GDvjPDDFfgOsS14H0BFaQK eHP60BF4EImpylzuaHYrih3gHuesw0WlFW5pXiUzD6dJWM1cTMu4A4wPq3h3ceL4tzdNoXTSKpLd iDhi7jOcKByShCik5/iEkAp7PaDUsese9QWXfKzQA4o6mFaaZEhHTjTNF+3SGPwyqxIQ/O3YZu8+ 6nBWpfUOOXSRkBWYVQg/JMwx4008VTiuIjnEMSsb/DZWUZWQg5nwy7ieVODpkDCOegGRsmrNXQH6 lpx+C6pHtdv32Cx2kULRSRXN25jzMnKHT7oRjtMq7IAmURn7gZxAiGK0z1UVfI+7GaLfwQ84Weru +5Q47j69GtyjoSPSPED0zFRoX0K1dopwTJPLinzmirwtaGVK7J6ow8twJ6tvl4uA/vuL7w6eJvsE 4n1xB7qsvZe11/vP195l+XzWijsvslB/dZ9jG2TTLsdLu+UxZWygZozclqZhlrBhBH0Y1OvMSZEU p6c0gseswDu4UGCzBgmuPqIqGkQ4hWa77mkiocxIhxKlXMIhzwxX0tZ4aNiVPSI29eHB1gOJ1R4P 7PCaHs7PCAUZs+2E5iCaM1rTBM7KbO1aRhTUfhtmdS3UmbnVjWim1DncCpXBh4uqwWBhTehEEPQv YOV1OKtr1nBIwYwE2u52E87dYrxwkS6SEQ5I5iOt96KP6sZJeayYWwGInQof6QPfKVYrcWtpsu/A 7SxOKrNrLGGXe+9dvJRH8NxLOm9PpCNLysnJEnTU9lrN1aaHfJy2vTGcb+ExTsHrUjd/mIVwSeQr YcP+1GQ2WT73ZitXzE2COlxZWLsvKOzUgVRItYNlZEPDTGUhwBLNycq/2gSzXpQCNtLfQoq1DQiG f0wKsKPrWjIeE1+VnV0a0bazr1kp5VNFxCAKjtCITcUBBvfrUAV9AirhmsJUBP0Cd2ra2mbKLc5Z 0pVvsgzOjmOWRjgrtzpF80y2cJPHhQzmrSQe6FYpu1Hu/KqYlL8gVcph/D9TRe8ncGWwFmgP+HCl KzDS+dr2uFARhyqURtTvC2gcTO2AaIF7WZiGoIKLZfNfkEP93+acpWHSGk5+6oCGSFDYj1QkCNmH smSi7xRi9WzvsiRZRshEVElcmVqxR+SQsKGuget6b/dQBKFuqklWBgzuZPy571kGjULd5JTzzakh xd5rc+Dv7nxsMoNSbh02DU1u/0LEil3VrjfL8723rIiemLdZjTwrgFlpK2hlaf+WIpxzq7UVa0Hj 1WYuHHhxUWMYLBqiFC5+kP4D+x8VPrNfKfSGOuQHUFsRfHTQxCBsIKqv2MYD6QJpB0fQONlBG0ya lDVt1jppq+Wb9QV3ugXfE8bWkp3F3+c0dtGcueycXLxIY2cWdmxtx5aaGjx7MkVhaJwfZIxjzOet 8hcoPnoIjt6Bu/4pU9IEE3xfEhhaz4HJA0h+y9Es3foLAAD//wMAUEsDBAoAAAAAAAAAIQAoew9x AFQAAABUAAAXAAAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWf/2P/gABBKRklGAAEBAQBgAGAAAP/b AEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAMABAAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAA AAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUG BwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS 8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri 4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo or5a8VftZeA7fxDq3w/+EWieKP2jPijo12+maz4M+Ddtp2saT4O1RQA9p8Tvihq+oaP8Kvhlc2u+ O5utB8V+MbTxzd6f59z4a8HeI54DZthXxNDDRjKvUjT53y04u7qVZ2vyUaUU6lao1tTpRnOXSLPU yrJc1zurUpZXgq2K9hTVbF1oqNPCYHD8yi8XmOOrSp4PLsHCTXtcZjq+HwtJa1K0FqfUtYfiTxR4 a8G6PeeIvF/iHQ/Cvh/TozLqGu+JNWsND0exiAJMl5qep3FrZW0YAJLzzooAJzxXyt/wg/7YPxV+ b4gfFbwZ+zb4XuP9Z4M/Z506H4kfEp7dvvW+o/HX4u+FrfwxZx3kB8i9s/C37P2m61pUjTvoPxDN wlnqkW54b/Yp/Zr0PWbPxXrfw5i+K/jqwkFxafEL49a74k+PfjqwuyQZLnQ/Enxe1bxjfeFFdhiP T/CDaBo9jAI7HTdOstPgt7SLm+s4yt/u2C5IdKuOq/V+ZPadPD04V67tvKniY4Oey0bbj7n9i8N5 dpnfE31nEr4sv4VwKzn2VSH8TD4zOMbisqymnzu0KWNySrxLhX79S0oxhGriN+3b+zvqrNF8NNU+ IPx7mYlLS5/Z5+DnxW+NXhW+kBxiP4meAfB+sfCiyhYgqt/rHjrTNNMimL7b52Iy3/hoH9ovxF8/ gP8AYg+JllaN8tvqXxr+LHwQ+GVrdk9LmPTfBXjL4z+LbKxBKo/9teF9J1cPHcFdFeEWk179iqqo qoihUUBVVQFVVUYVVUYAAAAAAwBwKWj6tj6n8bMfZtbfUcJRop/4/rrzFy8uR0+l1vc/trhPCf8A Iv4LWN5v4j4p4izTMnH/ALBv9WYcFqkn1WIWMertJXXL8c/27+3/AK188Xww/ZD+HcX3447343fG P4tXksY5SO7js/gJ8HrTTrmVZR56Wt9rltZS2bxQXWqxagtzpx/ZX/BQOf8Aff8ACe/sc6Vv5/s/ /hUfxr1/7L28v+2P+F2eG/t2cb/N/sPTsbvL8ltnmyfY1ebfF7w94x8T/DrxLpnw71eHQ/H8MNjr ngm9vda1vw/os3izwxqtj4l8P6R4q1Tw7Bd61F4K8QarpNroPje3sLHUZb/wjqWtWDaZqUdy9jPF TBSjCU54rM8TKMXLkp4inQqVOXVxpxoLB0PaSV1TjOVKnKbSnUppupG4cWJThTwXDHBuXwlKMEp5 RPMoQUml79fiHGZxX5U7SlUnWlOKTtJRcoy8C/sb/goGvzf8LI/Y5n2/N5P/AApP412vnY58r7T/ AML/ALz7P5n3PP8Asl15OfM+zz7fKY/tP/goHpf7/wD4Qj9jnxzn/mG/8LR+Nfwq244x/bf/AAp/ 4yb/ADN/mbv+EfTyfs/lbbj7b51h3H7M3w3+L3wy8GavoXxo+I0vxO8QxeIG0/w34jk1vWtYuJvh /oOl6bovhWfXf7XsNOEXjTVktL7XfGc9tFfLd61qkivrmsR21vcj6OraeWxptexzDHWlCnUjUhia lVNVKcakb0sdSm4TipctSjWoxnTqKVOrTU4NLKPGTrL/AGzhfhHFU7yjKjPIaeWNqMnGUfbZFXyr EpOUbxq0cSpOKUqNb2c25/HP/C8v2p9A/eeMv2JNd123j/4+ZPgZ8fPhF49nVe8trZ/Fy5/Z2nvI ohmSaNRHfNGCLKxvrox2rn/DcXwf0X938UvC3x5+Bs0f/H5c/Fn4AfFjRvCGnY+8b74saB4X8TfB mJEypeVPiLLEoZSX64+xqKj6tjoa0synUfVY3C4atD1isHHLpp+cqk1/dK/tvhbFe7j+CcPg6cdY z4Xz/OstxMpdq1TiWrxnh50/7tHB4epf/l7bQ4b4ffFD4afFrQIfFfwq+Ifgb4meF7jb9n8SfD7x boHjPQJ96708nWPDmoalp0u9PnXZctuX5hkc13NfOXxB/ZH/AGcPibr83jLxN8J/Dtn8QJ92/wCK HgaXV/hb8W13t5jCH4s/DHUvCHxIt1Mv77bb+KIlEwEwHmgOOG/4U/8AtM/C3978Ffj/AA/E3w9b /NF8MP2qdOn8SziBP9XpXhz4++BrfSfiJoKNtXfrvxN8K/tA6vl7jcsoe3Foe3x1H+PhI14LT2uB q803bepPC4hUpU421UKGIxlW/uqMrph/ZXCmZf8AIp4jr5ViZe8sBxTgHRwylPSnhMNn+UTzCliq 3PaMsXmuUcN4CMH7WrWoRUor7Gor5Cs/2t9J8F3droP7T/gTXf2ZtauLmCwtvFvinULXxN+z9r9/ cSrBbReHPj9pFtaeFtMOoXMkdnouj/FzTfhH431y7LRaX4NuVCyP9cQzw3MMVxbyxXFvcRRzQTwu ssM0MqB4pYpYyySRSIyvHIjMjowZSQQa6KGKw+J5vY1FKULe0pSjKnWpN3sq1CpGFai5WvFVIRbW qTWp4+a5Dm+SOi8xwc6VDFc7wWOo1KGNyzMI0uVVZ5bmuCq4jLcxhRlOMK1TA4rEQpVG6VSUaicV LRRRXQeOFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFeJfFb47+FPhfe6T4UhsNa8f/FfxXaz3Pgf4 O+BYLXU/HfiiCCZbafV5oru6sdG8H+C7C7eO21r4ieOtW8N+BdFuJbexvtfTVb7TdOvuM8ZfFfxf 4+8T6z8Iv2d30+TX9CvDpPxQ+M2q2Lat4D+DUxSOSfQdLtCYrP4i/GdraVZLPwJbXqaJ4Hjlt/Ef xRvrKKXwx4J+IHo/wp+C3gj4PWWrjw3Dqeq+JvFN1Bqfjz4ieLtSm8R/ET4ha1bxNDDqvjHxTeKL u/NpE8ltomiWcen+FvCWmMmg+DdA8PeHrWz0m24ZV6uIlKng3GMItwq4yS54QknadPDQ+GvWjrGU 2/q9CppL29SlWwy+so5Vl+TUaWO4ljWq4qvSp4nL+GqFT2GJxFGrCNTDYvO8Sr1Mpy7EQlCvh8LS g83zTB2qUf7JweNy/OqniX/Ckfix8cv9O/ae8Yw6F4KuPnh/Zs+C2va3pnguW1blbT4u/FhYNA8f fF2fqt7oGg2nwv8Ahfe2dxcaB4n8EeP7aGPW7r6m8K+EvCvgTw9pPhHwP4Z8P+DfCeg2iWGh+GPC ui6d4e8PaNYxkmOy0nRdItrPTdOtIyxKW9nbQwqSdqDJroKK1oYSjh26kVKpXmuWpiaz9piKivfl dR/DT5vejQpqnQptv2VKCdjz804hzLNaVLB1J0sJlWHqe0weS5dSWDynCT5XTVWGEpu2IxnsbUau aY6eLzbF04Q+vY/EzXOyiiiuk8MKKKKACiiigAooooAKKKKACiiigCveWdpqFpdWF/a299YX1vPZ 3tleQR3NpeWlzE0Nza3VtMrw3FvcQu8U8EqPFLE7RyKysQfkaf8AZl1f4UzS63+yL4ssPg+hlkur /wCBuvafd69+zX4kkdzLMmmeCbK5tNU+CurXTmUR658Hb7QvDn269ute8YfDf4h6gsMa/YNFc9fC 0MRyyqQ/eU7+yrQcqdele3N7KtBxqQUrJTjGXLUj7tSMoNxfs5Vn+aZN7angsQng8U4fXssxdKlj cqzBU+b2Sx+WYqFXB4qVFzlPDVatF18HWaxGEq0MRCFWPzv8N/2gbPxH4nh+FfxQ8L3XwZ+OLWl5 fQfDzXtUh1jR/Gum6dGJdQ8RfB3x9DZ6Zo/xR8OWUJW41SOxstI8b+FLaW0k8f8AgXwc+oafFd/R FcF8SPhj4E+Lnhibwf8AELw9beIdEe8s9UtA1xe6bquia5pshm0jxL4X8Q6Rc2HiDwn4q0S4P2vQ vFPhrU9K8Q6JeBbvStStLlVlHgFl498Z/s33lp4Z+OWu33jL4NXVzb6d4P8A2jNTjtI9T8IS3Mq2 +neEv2ivsEFpYWAeV47Tw78b7Sy0/wAK60TFovxIt/CnitdL8RfEjn9tWwjUcXJVcPtHG2jBw6JY 2nCMacL7/WqSjQb5lUpYZRg6vrSy3LeIk6vDtCWAzdJyrcMSq1cRTxWnNKfDOLxFSpi8S0+aP9hY +piM1hCNKWDzDPKlavTwP15RRRXoHyAUUUUAFFFFABRRRQAUUUUAFfL3jnxj4n+K/jfXfgX8Jtav fDdj4YTT4/jr8XtJZBe+B49asodTsPhh8P7pkltv+FweItBubXWdT1ORZl+Ffg7WND8T3NpNr3iz wTFJtfH34leJ/DqeD/hd8LZLI/Gv4yahqOi+CZ760XU9P8D+GtEhtbn4hfGTxFpZdFvfDvw20q/s Ps1hcyW1j4m+IHiL4f8AgO5v9OPjGK+t/Sfhj8NvDPwk8F6T4G8Jx3radppvLu91XWLttT8R+J/E Gr3s+q+JfGHizWZESfXfF3izXby/8QeJtbuVFxqms6heXbqnmCNOGrKWKrSwtOUoUqXL9cqxbjJu cVOGEpyVnCc4SjVr1E1OnQnTjT9/EKtQ+swFGjkWW0M/xlKnXzDH+1/1awNenGpRhDD15YfEcQ42 hUThiMLhsTRr4HKsJOE8Pjc0oYytjHLC5RVy/NNjwb4N8L/D7wxo3gzwXoll4d8MeH7MWOk6RYIy wW0PmPPNJJJK8lxeXt7dTT32palezXGo6pqNzdalqN1dX11cXEvTUUV2xjGEYwhFRhFKMYxSjGMY q0YxirJJJJJJWS0R8xWr1sTWq4jEVauIxGIq1K1evWnOrWrVqs3OrVq1ZuU6lWpOUp1Kk5SlOcnK TbbYUUUUzIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACq17ZWepWd3p2o2ltf6ff209lfWN7 BFdWd7Z3UTwXNpd2s6SQXNtcwSPDPBMjxTRO8ciMjEGzRQ9dGrp6NPqOMpRalFuMotSjKLacWndN Napp6prVM+Q9Nvbz9ljXPD/g7WLu51D9m3xZrWn+F/h/4i1CeW5vfgN4o1m4jsfDXw18S6jcu8l3 8JPE2pS2/h/4Za9fTG88CeI7vRvhtfzX3h3W/Bz+GvrysPxN4a8P+M/DuueEfFmjad4i8MeJtKv9 C8QaDq9rFe6XrGj6pbSWeoadf2k6vFcWl5azSwTxSKVdHI96+cfgn4l8QeAPG2tfsxfETWdR17U/ DWgL4w+CXjrX7qW81r4n/BmC6s9IvLTXdSuGabWfiL8HNavtK8JePtSkea717Qtf+GvjzVLh9c8b a1Z6b58L4KrCg/8AdK0uTDN/8w1WzawrfSjUSf1Vv3ac08KpJTwtI+uxMVxPgMVmsEv9YcspPE53 TiknnWX88ISz2EFpPM8JOpCOexpr2mMw8o55OnUqUc+xx9VUUUV6B8gFFFFABRRRQAVXu7u1sLW5 vr65t7Kysrea7vLy7mjt7W0tbeNpri5ubiZkigt4IkeWaaV1jijRndlVSRYr4+/bMmm8U+B/Av7P enSyrqX7UPxN8PfCHVUt5HjkT4UW9rqXxB+PsszxESWltqPwT8FeOfCNpqLFbeHxN4s8NWbtJcaj a2tzz4qv9Ww9Wso88oRtSp35XWrTahQop2dpVq0oUouz96aPZ4fypZ3nOX5ZOs8Lh8RX5sdjeT2k cvyzDwnis0zKpT5oc9LLcuo4rHVo88b0sPPVD/2W7S6+JEni79q/xJbXC6n8cmtYfhPZ6hDJDc+D /wBmrQZ7g/CvTbe0nVJNMvviStzqHxr8Wxyww6uNS8eaV4S1uW6tvh/4dh076+qKGGG2hit7eGK3 t7eKOGCCGNYoYYYkCRRRRRhUjijRVSONFVERQqgAAVLRhaH1ahCk5e0mryrVbcrrV6jc61Zq75XU qylPlT5YJqEbRikln2avOs0xOOjQ+qYZ+yw+X4FT9rHL8rwdKGEyzL41XGEqywWBo0MO8ROKrYmd OWJruVerUnIoooroPHCiiigAorzD4p/Fvwx8JdHsL7WrfWte13xDqH9ieCPAPhCwj1rx78QfERt5 bsaB4P0KS6skvbqGygudT1fUtQvdM8OeF9Cs9R8TeLdb0Hw1pep6vZ+Ef8Kv/aA+OP8AxM/jL8SP EPwI8EXfNr8DvgD4ni03xZPpzconxN/aFs9Og8ZRa1PGVludK+A9z8N7fwzfLLptt8R/iHYRx63d 8lbFqFR0KNKpicQknKnT5YwpKXwyxFabVOkndNQTniJwvOlQqqMrfRZdw+8Tho5nmmPwuR5PKU40 sZjFVrYnHzpStVo5RlmGjUxmYVY2nB4iUcNlFDERjhswzbA1a1JT9w+J3x2+CfwUtLe9+MPxd+Gn wutr0D7A3xA8b+G/CT6m7yGGKDSoNd1Kxn1S6uJwba1tNPjubm6uittbRSzssZ8P/wCG+P2XJedO 8Z+NPEKD/WTeEvgX8fPGNvAT91bq48K/DHWILR5RloUupInnRWkhV0VmHq3ww/Zp/Z/+DN3car8M Pg98P/CHiK/LPq/jLT/Denz+PvEVw8YhkvfFXxA1CG88a+K9SlhVIJdT8Sa9qmoSwRxwyXLRRRou Josv7QDftM+MY9Zt2j/Zri+Hunf8ITcq/ggajcfFB59EPitNWhtpJfFY8GwaMNM/4Vxcq1vqs3i+ X45QeO7GPwtZ/Au+1HKMc1qzgvbZfhef2vuyw+IxkKfscPWxF54n61gP4vsfY0o/Vo3xFWjSu+fm Xf7XgHDQqR/s/i/OvZKnL65/bOS8Mzr+1xFGhyU8n/sLi3kdH23taklnVbmw9KtW9nTVNwfCf8N/ fsjW3zeIfi9D4Bt0+a7vvir4K+I3wj0vS4O19rmq/E/wh4S03QNMY4CaprV1YadISoS6YsoP074P 8c+CviHolv4l8AeMPC3jjw5dgG01/wAH+INJ8TaJdAqGBt9V0W7vbGYFWVh5c7fKQehFdTXzF4w/ Y4/Zy8W61ceMLX4aaT8O/iTOS4+Lfwalu/g58WFlBMkYu/iD8N5/DfiTXdPWc+dP4e8S3uteGNTO 6DWNE1G0mntpS2a09XLAYtdYKliMA15qo62Yqb7QdOmr71ELm4Bxn7tUOLeHmtViqmNyji2FRvRU 54OGXcGzw0F8UsRDF42drqODk7X+naK+Oft/7Rn7Pf77xJdeIP2sfhDF8174j03QPDOk/tK+BbZe JL7U/CPhDS/C3gb43+HrWEG5vP8AhBNB8E/E6wgt/s+ieB/izrGopHZfUnhLxd4Y8e+GtE8ZeC9e 0vxP4V8R2EGqaHr+i3cV9pmp2FwMx3FrcwMyOMho5EJEsEySQTpHNFJGu9DFRrSdOVOrQrxXNLD1 1FVFG6XPGUJVKVaGsbzoVakIykoTcal4Ly81yHEZbRp42jisFm2U16nscPm+V1KtTCTrqLk8NiKO Jo4XMMuxaUajhhM0wWCxFelTnisLTr4N08TPoqKKK6TwwooooAKKKKACiiigAr50/aZ+HXibxl4E tfFnwzgtz8bvg7q8XxO+Dk01wtjHqnibRLa4j1b4d6pfsGS28L/F3wpca58MvE8s0c8enad4nHiO zhTXfD+i3tl9F0VjXowxFGpRndRqRtzRdpwktYVKcrPkq0pqNSlNawqRjNapHo5TmeIybMsHmeFV OdbB1o1fY14uphsVSacMRgsZSUofWMDjsPKrhMdhpSUMThK9bD1L06kk+E+GHxF8NfF34d+C/id4 OnuJ/DPjrw5pXiXSPttu1nqVrb6pax3DabrGnyEzaXrmkztLpmuaRdBbzSdXtL3TbyOO6tZo17uv jn4B/wDFtPjv+0r8A5P9H0S+1/R/2m/hbaD5LW38J/G+TVLT4maJp44jkudL+PfhD4i+N9ait0Rb C2+LXhpZk3XsU1x9jVngq06+HhKpZVoSqUK6irR9vh6kqNZwTbapzqU5Tpc3vOlKDe53cT5Zh8qz nEUMC6kstxNHBZrlMq0lOusqzjBYfNMupYmpCMac8ZhsLi6WFx7pL2ccdQxNOGkAooorqPACiiig Ar46l/4rT9ve2ib99Y/s+fsryX2w/NbReJP2oPig9laXGOY21fS/D37MGrW8bcXWnaV4uuFwlt4h /f8A2LXx18CP9P8A2ov259X+8dN8bfAjwJvPOxdE+AXg/wAbi2DfMVEbfExrjytyhTeNKIUMxmuP Px3vVMtpP4K2YR513+r4XF42l/4DiMLRn58tup9hwp+5wfGuYQ0xWXcH4j6rP+T+2c+4f4Yx+nX2 uUZ9mWH8nW5tbWf2LRXAfFT4n+DPgx8O/F/xT+IerJofgzwPotzrmu6gyGWVbeDbHBZ2VspEl9qu qXsttpej6bBuudS1W8s7C1R7i5iRvyU8Cf8ABaX4b6z8TPDnhb4mfBPxp8Hvh542a2l8J/E3xD4p 8P6p5Olapqs+laJ4g8b+GLO1tl8LaBeTWs/27U9M8ReLINKUJey+foXna1B9blfDOfZ3hsXjMqyz E43DYG/1mrRULRkqU6zp01OcZV6yownVdDDxq1lTi5uHLqfnOPz3KMrxGGwuYY+hhcRi9aFOo5Xl H2kKPtJuMZKjS9tVp0vbVnTpe0nGHPzNI/aqivln46ftmfs9/ADwV498XeKfiD4d1/UPh3caTpeu eAPBfiDw3r/xEPiLxDeX+n+H/DY8MLrNtcadqusXekayIP7ck0qzgtdD17UL27t7HRNTuLX5G+B/ /BVHw149+Pdv+zt8Z/g1r/7P3jjXdQ0vR/B91qnjXQPG+havreu2Fvqnh7QtW1HS7HRxomq+J7K+ 03/hGPsaa9pWr319b6Z/a1tfXWmw6jOB4czzMsBi8zwOW18TgcFCtUxFen7P3aeHVJ4idOlKca1e GGVei8TKhTqrDxrUnWcFOLbxeeZTgcZh8Bi8dRoYvFypwoUp8/vTrOoqEJzUXTpSrulVVCNacHWd OoqSm4St+r9cJ8TviP4Y+EXgDxV8SfGU91B4c8I6VLql+un2kmoarfSb47bT9H0XTYiJtU17XdTu LPRtB0qA+fqesX9lYQfvbhKt/wDCw/AB8Lp43Hjjwf8A8IXJeR6dH4v/AOEm0X/hF31CbXV8LQ2K a/8Abf7Ja8l8TOnhyO2W7Mz66y6QqHUGFufw6/b5/wCCmfw38M/tE/Cn4FaN4J1X4n+E/gn8XLX4 l/Hh7HxR4a8M2eq658MbMT+EfBnhlNZllm8W6v4A+KuveCviDrWm2senNH4k+HtlpRvhp1n4qu9L 8ujl2a5lGpRyfB1MZi+bC0acYpezp1swx2GyzByrylOnGNOeOxuGpWc4ynKooU7zlFP6fJllM81w sM8xTwuV0qOaZpmHs5cuKrZZw9k+YcRZvQwP7ur/ALbUynKcasLKVOVKFbknW5aUZyX6z/A/4Z+J Le5vPjR8Zba2uPjr48sSt7YR3q6tpHwc8GXctve6Z8F/Al0p+yDTtG+z2U/jzxTYRW918T/HVvde Jb/yfD9j4I8M+Evo6vnHwX+1v+zr438AeAviNa/FnwRoGjfEjwrqPi/wzpvi/wAUeH/DniW40vQb XW7rxVE2g32qC9mvPB58MeKLfxOmni/t9Lm8M68zXUltps9wv5w6j/wWk+H2m69oWtzfArxs/wAA fEetX2k6Z8WYPGfg268XfZtOmms5vEGo/BizkufEWhaLdXNte3OjJ4g1zSte1/R9N1W50bQ73VtK 1HQrX0cm4RzzH/W8JleV4vFVcunKGOUvZwrLFN1OenVdaVL2uOqzpVpfVqaliKjp1PZ0eWDUfH4j 4ywFbFUcxzbH4TCxzCMVl1Cgqn1PD4ClCP1fD4GlD231fLMFh5UqdKc5eypUuSVWtKc5VJ/tZRXn Fh8YvhNqej/8JBY/EzwFPoosPAuqSan/AMJZoUdrbaf8T2tE+G91eSTX0f2KLx9Lf2UHg43YhPiS 4u7e30cXc0yRt+aH7Vn/AAVm8Lfs9658WtM8BfBjWvjfpXwCk0bTfjJ4nsPH3hjwTpfhvxR4l1a1 8P6F4T8OWmp2ur6t401s+IbtNC1qOwsrG10PVVltrm7kWz1ObT+XCZbjsc8WsNh51PqOHq4rGSbh ShhqFJqM51p1pQhBupKNKnTcvaVq04UaUJ1Zxg7jUhPFZdgoSUsVm+PwuWZbQj708ZjcbUVPD0KS je/PJ80qjtSpU1KtWnTpQnOP6e+PPif8NfhXplvrfxP+Ifgb4caNd3IsrXV/Hni3QPCGmXN4V3i0 t7/xDqGnWs1yU+YQRytKV+bZjmtDwd458FfETQrfxR8P/GHhbx14Zu5JYrXxF4O8QaT4n0K5lgIE 0Vvq+iXd9p80kJZRKkdwzRkgOBkV+cXwi8BfC/8AaO+BOl/FLTfiH4W+IP7V/wAYvhVF8QtI+Juu 3dpa+JfCmraLrluf+EV8IeGp4Nb1LwD8CPBXxO06PwJ4p8EaLo99oXiS3s9WsviKfHXibxBr+qa5 5/8Atf8AxJ+Bf7FHg3wl8Z/gNPbX3x1j8Xab8LofB/gLWtEuZf2j2+HtxZab8QPAPx2uEuP7Mv8A xJ4f0sXFnH8UfENvdfEH4ZeO9V0uOCS80zxD4l8GeKfLpYbPauJnh1lkpYmNV0/7KpxqzzSKpxqy xClFR9n9awvsZLEYPlUY3fs8ZV9nNH2LwnBE1SwNHiLFfWq040qPEleGEocJ18TVnRo4aFq1SnmG GynGVqy+qZ9WnKq6MI1cbkWXqral+w1fG/xLjj/Zg8WXHx38PqLD4JeK9aB/aV8LW48vSvCl/rl1 BbWv7SWiWa/uNNm0jUpYbb45w2sdtba94Pvp/ifqEv8AbngHUY/F3kP7Hf8AwU0+Dn7VOl+MU12w h+CHi3wFo9v4n8RaP4w8YeHtQ8NSeErvVINGTxLovjlDpOn32nWWq32kabrDX+naR9jv9c0aK0bU oNQhuj7l+1l+0P8As/fCT4IfFq++L97pnjLwxb26/C7xn8NdEvdL1XxJr+rfEbw55ln8OrvRzqNq dO1HxR4S1ZtZaDV7jTVj8JTT+InkXSkFy3fj+H81eMpZTHCVI5zOWHll1OCVaVWtioQng5UZ0HUj iMNjIVYJyoTnTxGGqy5J2kpLwsh4kwGU1q2KzGUqnD8nXwHE+DqXw85YHD15Usyo1KWJVP6pmmWV aU6+CniaaqZfmuGoVp026UqcvrSivxV/4Jpf8FMPD/xi8N+EP2e/jVpOrfD/AOMXgLwTrOhHxR4r 8T6HrOmfEBPg5He6F4s1LXNYt00ttC8d22neGdV8SeKtLvdOTT/K0rxBqsWoWq27aZB+zmmapput 6bp+s6NqFjq+j6vY2mp6Tq2mXcF/pup6bf28d3Y6hp99aSS2t7Y3trLFc2l3bSy29zbyxzQyPG6s VXweNwkMHLHYSrhJ43AYPMqFOq4S58JjqMa+HqwnTlOnUhOErc0JyjzRlFtSjJLDMKFHBZtnWVUs XRxsskznM8lxGIoRqRpzxOV4urhKzjCrGFWEZyp+0pqpFSdKcJq8ZJu9RXx/+0t+2p8Jv2cfCNlr Dzj4m+M/EXji6+F/gz4beA9Z0G88Q698RbJLc6j4e1G5n1BLPw1F4fe+0weKrzVCbnQv7V0u3/s2 91TVdK0y/wDzo+Cv7dXhL9vv47eMv2f/AI/eHPEf7OHhT4Z6Z4hh1T4Lan42MNj8a/GfhT7Vf/Eb RviT4xtNO8G61Z+GPhVoNgTq3wmmg0zS/GMr+PX+IA13w74MOitvPKM5eWLNcNllbE4WpOvClOMo QjJYWKli8RKN5V1gcFFx+uY2FCrRw8506Mm8RWo0akZVLKcbmOKwePzalllDLsPQxeZ4h0Z4mrRp 4uvDDYHCYWgp0KWKzfM681SyzLamLwssQoYjF1q2Fy3BY/HYX9Zn/ad/Zrj8Tt4Jk/aF+B0fjNdS /sdvCL/FnwEviddX3+X/AGU2gtr41Ual5n7v7CbT7Vv+Xyt3Fe41+X2ifAH4OfD747/Fb4v+O/DP 7PPh79kT4i/BX4beB/hJZ3X7Q3jzX/htrcuk6RrPirxabL9krxd4XtP2VvAVrqvhTTbW90jxX8It a1bxD4k8N+FdX1fWtMSPxDr08P5veCf+Cu3wj/Z4+MGn6R4H+GPxUg/Yg8XayfBuijV9fsdWvPhl 4mgksmtPEXwv8FXv2nW/Dnwr1RNUtbC4+Fd14ruY/D8N34ZuPh/4c8G+TrHgPUOfKcm4mzTC1cbh 8r+vYXDQU8xrYFVIrLFUxlbC0PbxxLhKrTqKnGtKpy4etTpylXWEngoSxi9jH1OCJ4hZblma5jl+ cVIyeVYHPFg6sOJPq+WUsyxkMvxGAUHgsypxlWo4bK6tHHUcZWoSwlLN1mlTCZdiv6YqK+efGH7W H7OfgfwhrHjTWvjF8P307R/h1H8V30zTfFWh6j4o1HwHdWej3ula/o3ha3vzrup2eur4j8N22hy2 1i0eqX3iPQLO2kabV7FZvzS+HH/BbH4WeKfiNonh7x78HfFfwq+G3izVJNL8OfFHWPGHhrWlsQ+p LptnqXj3wzp8EC+EtJ81gurX+neIvFcOjMwuJzNpEd3q9p6+V8L8QZ1h8bisryrF4zD5ddYypSjF eylGEqkqajOUZ1q0acZTlQoxqVlBczglZnxOPz/J8srYXD4/MMPhq2Nt9WhUk/3ilONOM3KMZRp0 pTnGCq1XCm5NRU76H7Z0V8s/HT9sz9nv4AeCvHvi7xT8QfDuv6h8O7jSdL1zwB4L8QeG9f8AiIfE XiG8v9P8P+Gx4YXWba407VdYu9I1kQf25JpVnBa6Hr2oXt3b2OiancWvyB+z3/wVZ8J/Fb4peCPh V8VPhBrPwJ1T4sWWl3vwm1rUPHXh3xrovig669wnh7TtbbT7LRNR8Jat4okhS28L211Yaha6xqEs Wni+trm80ldTnBcN55mOXYrNsFluIxGX4NzjXxMORRUqVL21aNOEpxq4iVGj++rrDwqujSTqVeSC cisVnmU4LG0MuxWOo0cbiYxnSoS53JwnVjQpzqSjFwoxq15xo0pVpU1VqyjTpuU2kfT/AMb/APij /wBqP9jX4kJ+5g8Vat8aP2adcnX5YhYfEj4dN8Z9ClvzwrIniz9m7SdF0uaUs9vqPig2VqE/tm68 z7Gr45/bW/0PwP8ABTxB90+Hv2xv2O8S9DF/wmX7Q/gD4YnD8bPPXx01mfnTzFuTAfNEpt5vsavk 8N7mNzKl/PPC4xeSrYeOFsl25sDKV+rk+13+i55/tPC/BOPWiwuGz7huS35qmXZzVz/2je/M6PFl GjybRp0KbT96yKKKK9A+PCiiigAr45+AH+g/tLft4aV0OofFX4K+NtvcrrH7Mvwo8GiT6M3w6eMY 4zE3fNfY1fHWkf8AFG/t6eNNPP7my+PX7Lvg7xVp8HSObxH+zl8SvEPhjxrqcYH3ru68PftCfCnT r0yZza6FpQgC+XclvPx2lXLKj0hTzBc8ukfbYLG4Wnf/ABV69KmvOaPsOFv3mXcc4OHvYnGcHv6t SXxVf7N4o4Xz3Hcq6/V8qynMMbU7UcLUfQ9W/aR+Bfhz9pb4IfEL4IeKr260vSPHekW1qmr2UYnu tE1rR9V0/wAR+GNditmlgS9Oh+JtH0jVmsHuLeO/SzaykuIEnaVPwT8If8ETPj74k8d6Jonx9+MH w41j4E6DcNYyQ+Ftf8f694z1vwdFeI0/hfT/AAx4j8KaJ4f8Bx+JNOSSzvrmw8X+JotAa4aa1std aFC/9LdFfd5DxrxFw1g8bgMoxqw+Gx0pVKkZUKFaVKtKi8PLEYadWEpYevKg/ZSqQabgopr3Uz8u zfhbJM9xWExmZYR16+DUY05RrVaUalONVVo0a8Kc4xrUo1VzqE00pOVt2fit8Uv+CC3/AATu1K2+ IPjL9nv9nn4Y/s6/H/xfdRaxp/xY8JaLq08OmanHqmq6rf6fD4TfXY9B0Lw/4nGuarpviG18HWXh 6SezfR/MF5a+GND0y38F+Cn/AARt+LPib4v6V43/AG4PHnwz+K/gfQbjRb268Hafr3jX4q3PxLHh mCG38NeG/G158SPBvhO2sPB2l/2fo/2rRPs/iy31XRtNHhXytO06c3cX9EdFLKuNOIclyjHZJl2M hRwGPVeNaLw9CpWprF06dHFLD4idOVWgsTSpU4VVCST5IyjyzXMGYcL5LmmZYXNsbhZVMbg1SVOS rVoU5qhVdegq9GE1TrKjVbnTU4vV+9zJJL8tT/wRG/4JFH4ep8MT/wAE6P2S/wDhG454bhdSHwe8 LD4hGSDxGnilFf4uCzHxXkgbU0W1mtZPGjW1x4cL+D54pPCMkmiN+Xf7Zf8AwSe8Y+DP2nfhtrH7 NHjLwH8Nvg3+0b4u8VfCu+8JapN4j8G+HPAGp+J9BT4o/wDCGvZeDtE1nS9Z8Da94g+Er3/gnRbq 08PaZYeMT4S8GRok76HrB/qOryT45fCi1+NXwy1/wFJq9x4a1W4uNB8ReD/Ftnbx3d94L+IHgnxB pfjP4feMrG2leJbm48L+MtB0TWvsZnt11CGzl0+S4hiupHHh4LOs3yRVcRk1WEMTz4DEeyq0qNWj iamVZng84wdKpGvGVOL+u4DDuNXR0neV3FyjL7HKMPk1fN8JHPVOGX18NneT4nGUpV418uwfFGQZ pwvmGYUo4ZqtWngsBnOJxKw0NcS6SopwlKM4/mFp/wDwQT/4Jk6x4e+Hk3xf/Zm+Hvxb+L3gjw3c aZe/GrVdO1DQ/FPiPxDqb+J73UvE+p6ZpOrroeq3Nnq/jDWbzwnD4rs/FU3hiKz8KxQ315deEdBv 7P44v/8Agi1+1Te69pPw5l/aJ8BXn7PGga5f3fh6/wBS1j4h3PirQbTVxEdV1bS/g6+gv4EtPE1+ YYYtQmsviVZwanJBFe3MyALYR/vn8DPizcfE/wAN6jZ+KNKtvCfxZ8Aao3g74weAYbmS5HhbxlaQ Rzi70me4WK61LwN4y0yWz8ZfDnxDPBBJr3gzWtJub2107Wo9X0fTPbK9vIOPuIsonmGPyrMI+0zq pLFYypiMLQrzljHKs3ilCvSbw2NpTr4iMmowlCU6lOpC8eWPzHEvAWWyxFDKM6y9wqZH/suHp0MV UjS+qSp0uSNKvhqvs8bl2Lw0aFbDV6dSrQxeFnSxGHqzo1o1J/lJN/wQ5/4JMalpWs6f4j/YQ/Z9 8W6h4ksfhvZ+IvFniTwRYX3jbVJfhbHpkfh/U4fFUItNW8O6nrR0m2b4h3HhCfw9H8UY5L2z+IkH ibTtQvLOb88P29f+CQXxjto/jN4x/ZF8QeFNP+EPiebTfih4n+BEF34q8Mamt34F8R6V8Q5fBngn wj4T8P6v4W8fWF1rmi3uqeDPDeqXHg1NCvr600DSVuGtrXUH/pqory8Dnma5as1+pYr2Us5y/F5d jnUpUsQqtDGJ883CtGcfbU6nLWo1UlOnVipRkrtP1cLRwdDNeHc0rYSGJnwznmVZ7gKLq1qEPrOV YqliaVKc6E4VPYVlS9hXgnadGcla9mvyD+A//BHz/gl1feBvhd8SPEP7Lv7NP7UnirVfhRpdsfjd 8UPhF4L+IVv8TdH8W6k/xD/4TJfDvi2w8Q+GRNqeoa1LN4Y1yaxv/Feh+Dp7LwjD4nudGhlhuPAf 22f+CSv7IHwf/Zz8afED9kf4U/Cr9lnxx4P8WeJ/ifDZeAvCE2k6T8T/ABd4/l0zSLP4aW+neHVl 1HS77xJ4vi8HaF8I/DnhbTbnRPDety2nhHwf4OsrTxE4tf1B1L9nz4peA9S1K7/ZZ+MnhX4R6Dr+ o3+sa18MPin8JtX+N3wm07W9Uu5r/Vdb+H3h/wAP/Fz4J+LPh7c61e3M95rOg6V48uvAE2oPJq+m +CdJ1vUfEGpa3q+EfgD401bxRoXj39pD4qWHxp8UeD79NW8CeGPCfgGf4T/BXwTrkcUsKeLtK+G1 544+Jmu6943iimeLTfEnxA+IvjT/AIRUA3HgTT/CWoX2tX2rebhuIuJMLmn9r4aNWhnvt6+JebOW DqYT61ifafWcS6TrSxFWFVVqrdCeEh7Vz9jOVKEnWj9VLhfgB0IRxOfYXH8MUXh5R4VWDz2hxNXw OFqU54bKquI/smHD2GxH7qlRr5jRz2vSw1FTx2Gw+NxFOnllb8f/ANjz/gg78J7H4W3Hh/8A4KCe CPhT+0FcX/gbwt4N0n4aqmq+IPCng2DR7nQNZv8AXh4rvLPw3rUvja/1Hw7o1k174dt9JttJ0u11 vSU1fxLpviW7MP1B8af+CL/7CEnw7+LM37OnwG+BX7JvxJ8Zap4V8c3PxC+Hfw/0Xwh4bs9S+Heg XOhafpt94d0D+xtD8L+Br/w3daxB4j0zwha6Bpc2ualcfETV9M13xTFdz6l+wlfH/wC0ZfT/ABlv pf2Q/B95Mtx8QvD7z/H/AMSabcOj/DX4C6q76brmmfa7VxNp3xA+NFsNT8B/DyDzrK90/SW8c/Em zmmb4fQaVrfdi+J82oY7CZ4sTKWa5fHL6GVuMacGp5fRpYfLsNTgoOnyRhRpwm5wlD2aqVcReCqy PGy7hzCcUY/H4DGxhhsszfF5pnHE+N5ak6OCwWYYurj89zSonUVSTg8RWnh8PCqq+KxU8Nl+CVTF 4jDUZ/iL/wAE9P8Agj5ZfFrwNonxf/bltvAfxk+G3xP8K+OPGPhr4Q6oviPxVD4kt/jpd+JvEB8W +P7rxdonh680i/GkeOtZ1vRdK020m1yz8Ra5Y+LJ/EGh+IdHfTpP1o0X/gkP/wAEqNA0bSdCsf8A gmx+wnPZaLplhpNnPrX7KPwO8SazNa6daxWdvLq3iLxF4H1XxBr+pyQwo9/rWu6nqOs6rdGW+1O/ vL2ee4k/Qq0tLWwtbaxsba3srKyt4bSzs7SGO3tbS1t41ht7a2t4VSKC3giRIoYYkSOKNFRFVVAF ioxuaZjmkcA8yxEcTVy/LMDlVCUKUKFOGFwFFUqUIUqaUYpvnqyb5pSqVJylJtnPjvqVbOM/zPA4 R4Knnuf5xn9TDyrTxEqdfNsbVxc4OtOzn7GM4UINRhFU6UFGEEkl+J/x0/4Iifsof8IfqN7+xP8A CP4Pfsm/FxvGup+Pzqvgjwo3hbwr4sv9Vs7WC48M61H4Zia58JeHLS603S9Q8K2/hPSpdD8DXcGo yaB4P/4nuqCb4o/Ye/4I7+ELj4p/HD4aft52Hwz+KbeEpPE2paf8E0h1jxR4P+IPhH432OqSWfxa HiHxHpHha+1TRNEudZ8efD/S4bLw/p+u+H/H3hmfXn1DRpdL8Lz61/UPXjvxY+Cnhn4sDQ9Vn1Tx J4I+IHg06jL4A+KngLUotG8d+CptWFmdUgsbm7tNS0XX/DusvpulyeIvAvjTRPE3gPxO+laVJ4h8 NalPpOly2fZ/rVxJhcojlGAxqWCp08fh5YZ06KnUwGayozzLBU8TKEp0oYirh6NdK9nUhKlz0aeI rTSyrKuGa2LzCOd0J0oZrPKsVHMqUatf+zs6yKWIWTZrWwUKtN4ujQw+OzDL8VTpy9rTw2N+vUqG NxWX4XBV/hTxR/wRF/4JJ+KvBvh/wTN/wT3/AGVtBs/CyWJ0HxB4N+D/AIO8HePLe60zQb7w9p9/ q/j/AMO6Xp/jDxjdQWt/JqFwPHGs+JrXV/EVvp/ifXLbVPEGm2Go2/4v/F3/AII3/HKz+MPwk+AW l/F74ba34L8dfEOy8R6XrNlJ4tPxE8KfDP4cap4b8UeNviX4g+G0nh5fCNhaafcab4Q8DvPb/Exv 7e8WeKvBulwx20F9PJov9E//AArn9usf8S5f2rv2dzov+o/tST9jLxk3xE+ydDcnX4/2w4vAB1zH IvB8KF0UNgnw2Vyh9g+E/wAEfDvwrk1zXTrXijx/8R/GKWA8d/FTx/qi6x4y8Vf2W13Jpunqtpb6 f4d8I+FNJm1DUZ9C8A+AtC8LeBtEudS1TUNO8Pw6rrGs6hqPLk/FvEuVYTNcryuNXLcFnmH+qZq8 XHLsR7TDONSlNYaNKti5wxU6Favh41eahGlTrTq3qzp06Uvar8NcH5fmWU8S4zPcs4nzfhzE/wBo cO4TJKHE2GVHOKUoVsDi80r51k+RUf7OwGMo4fMJYehDMa2Pr4Sjl86GFw2Kr4/Dfmp4t/4IKf8A BMDW1vfE3hr9mHwF4K+NUfga18JeHPjhpdnqE3i3QtZ0rRvD2laN4/m0RNVsfB+q+NYX8LaTd6p4 jfQ7PXtWa48SL/bFlL4s8QXN98X+Cv8AgiJ8ddc8daJoXx1+LPwy1L4D6Dcz2UkHhHW/Hms+Mda8 HvrFxql94X07wv4g8JaH4e8Bp4r+3am+p3Vh4u8TRaJf6tfahBZa/cu8k39MNFe7kfHHEvDuFzDC ZVj/AGNHM6kq2I56FGtUjiJ05UZ4mhUqwlKjiJ0puEqkHdxtpdJn57mvCmR51XwWJzDB+1qYCMad Dkq1aUHRhUjVhQrQpzjGrRjUipqE00nfufit8Uv+CC3/AATu1K2+IPjL9nv9nn4Y/s6/H/xfdRax p/xY8JaLq08OmanHqmq6rf6fD4TfXY9B0Lw/4nGuarpviG18HWXh6SezfR/MF5a+GND0y38V/ZX/ AOCQPxr8IfG74c/Er9pP4lfD3VfC/wAHfEHhvxb4M8NfDrxJ448Xahq2t+C9VTX/AAfZXl/4u8He B7fwjoGheJLTTNflsNLt/EQ1P7HLpAXToryTUU/oToqcq414jyTJ8dkWXY1UMuzB1nWpvD0KlWDx FJUMQ8PXnCVWg69GKp1HCS0V4ck25N5jwtkma5nhM3xuFdXG4L2SpTVarCnJUKrrUFWpQmqdb2NV ucOeL1dpc0Ukvjn9tz/Svhv8JNDHLa7+2N+xHtA+8f8AhE/2rfhH8RH29/li8GSO+P8AlmrhvlLV 9jV8c/tEf8VX8ev2LPhcn7yH/hafj748eJLTr9o8KfBP4V+ItFsJHU/KE0/4u/Fr4QamJCGKz2cC IqvKJofsavhMN7+OzKr/AM+3hMH5/uqH1u/p/t9l5qWmzf6jnX+zcJ8F4Hd4tcRcS3XwqOY5nT4d UH19opcISlJbeznSabbkolFFFegfHhRRRQAV8c/taf8AFC3/AMBP2jYP3S/BL4vaLo/jmdfl8z4M /HJofhD8QPt0nBi0LwlrfiHwF8YtadWBS3+FEchWVY2gl+xq53xf4T8OePfCfifwN4w0m01/wl4z 8P6z4V8T6HfoZLLWfD3iHTrnSdZ0u8RSrNbahp13c2s4VlYxyttZTgjmxlCWIw1WlBqNW0alCcr8 sMRRnGthqkkrtxp16dOco2fMotNNOx7nDea0smzvAY/E06lfAKdbCZrh6PKq2KybMsPWy3OsJRlJ xVOri8qxeMw1KrzRdKdWNSMoyipLoqK+W/2VvFniN/CfiP4L/EXVrvWfir+ztr6fDLxRreqODqvj zwmmn2+qfCb4t3BxGLyX4kfDy50e+8S6hZxDSbf4n6Z8R/CtlLJP4Vvkh+pKrDV44mhTrRi48696 nK3PSqRbhVo1LXSqUasZ0qivpOEl0OfOsrq5LmmMyyrUp1/q1RexxdHm+r47B16cMRgMxwrmlKWD zHBVsPjsJOSTqYbEUp2XMFFFFbnlhRRRQB4b8Vfg3N4y1TS/iF8P/EkXw0+NvhiwfS/DXxDTRTr+ naloUlxJeT+BfiV4Ui1XQf8AhYHw6vbuWa7fw/LrmjatoWpzSa/4J8SeFPETNqzeYRftX2Xwzlj8 P/tZ+HB8AdZjkS3i+JU02p65+zV4oVmEUOpaV8bH0jT9C8BzXshVP+ER+MyfD7xNHfG4tNBj8X6T axeJb/7BqOWKKeKWCeKOaCaN4poZUWSKWKRSkkUsbhkkjkQlXRgVZSVYEEiuKrhZqcq2ErLDVZu9 SMqftsNWdkuerQVSlL2qirKrRq0ZytBVnWhThCP02Cz7DTwtHLeIctlnOX4aLhgq2HxccuzvLKbk 6jw+AzSeEx9KWBnVbnLL8ywGY4ag54mplsctxWMxWKq19P1Cw1axtNT0q+s9T03ULaG8sNR0+5hv LG+tLiNZbe6tLu2eS3ubaeJlkhnhkeKWNldGZSDVyvkXUP2G/wBnOO+u9Y+H/hnxJ8Bddvbia+uN U/Zw+Ifjz4CW15qVw7S3Go654T+F/iHw34C8X3FzO73V3H418J+JLO9vW+33lrPeqlwtP/hlr4pW 3y6N+3z+2NosbczRf2f+x14m85hwjef48/ZE8W3dtsXK7LG4tY5c77hJpFR1j6xj6f8AFy/2vZ4L FUamneSxiwHK29eWMqiS+23o+r+x+EsXrgOMpYC3xQ4n4fzHBWb1So1OGp8W+3hFXi6talg5yqWt h4wk5w+xq4zx98Rvh/8ACrw1eeM/ib428KfD7wlp7Il74l8Z+INL8NaJbyyhzDA+paxdWlp9puPL cW1qspuLl1McEUj/AC182f8ADJ/jLUf3fi79tj9sbxfay/u7+0/4SH4DfDj+0LUfdtf7Q+CH7P3w r1nSNpwft/hrU9E1h8Yl1J1Zg3aeAf2Qv2c/hx4ls/HOifDSx134iaeHWx+J/wATNc8U/GP4qWfm lGnNp8T/AIt65428e2rXLRxNdG38QxfaWihM+/yYth7bMKulLBU8Ono54zERc4X2lGhhFiIVVHrB 4ug2/dU0vfR/ZnB2B1x3E+NzipH344fhvJa8MLiFHehUzXiKpk+Jy+VV6QxNPh7No0oP2s8NOa+r vi/+Fx/Fj49/8Sz9nDw1qXgLwNP+71T9ov4y+BvEXh+A278TJ8Gvg54qtvDfi/x7qzRHdYeNvG1p 4T+FdqLmw13Qpfi5aQah4Zb6B+GPwu8KfCbw6/h/wvDezzahqFxr3ijxPrl42reLvHPiu/jhTVfF /jPX5kS51vxDqYt4I5bh1hs7CwtrDQ9EsdK8P6VpWk2PotFa0cK4T9vXqvEYmziqjjyU6UZWcoYa inJUoNr3pSlVrzSjGrXqRhTUfPzLPY4jDf2ZlOBhk2TKpGpPCQrPFY3MK1O6pYnOsylTozzDEU4u 1KlSoYLKsLOVWrgMrwdbE4udcooorrPnwooooAKKKKACiiigAoorxP8AaF+K158HvhbrfifQdLt/ Efj7VLnSvBXwo8IXEskKeMviv421CDw54A8OTvBuubfSLjxBf2l74q1W3jl/4RzwdYeIfFF2q6do l5LHnWrQoUqlaq+WnShKpNpNtRgnJ2Su5Oy0ik3J2STbO3LcvxWbZhgsswNNVMZmGKoYPDQlONOD rYipGlD2lWo406VNSkpVKtSUadKmpVKkowjKS8l+F3/FzP2s/j98U3/f6D8FtA8M/su+A5T80S+I Lu20n4xfHfVtOlPEttq1/r/wd8E6iIQEt9f+EWqWc0ktzbSRWf2NXkvwM+FVp8FfhX4T+HUGqXHi HUdJtr3UfFni29ijh1Pxz8QPE+qXvij4h+PtXii/dR6v458b6zr/AIr1OKHFvBeatNBbJHbRQxp6 1XPgaU6WHTqq1etOpia6upctWvOVR0udfGsPGUcPCfWnShaysl63FWYYXH5vOOXTdTKsswuCyXKq nJOksRgcpwtLBRzBYaai8LUzitSr51isPa9PG5jieeVSo51JlFFFdh84FFFFABRRRQB8sfHrwv4i 8I+J/DH7THw30bUdd8WfD3TZfDPxQ8GaFbPdav8AFb4D3t+NS1/RNM06AGTWvHvw01FpviL8KrMR 3F/qF6njP4c6K2nH4sarqMX0T4W8UeHfG/hvQfGHhHWdP8ReFvFGk2GveHte0m4S703V9H1S2jvN P1CyuYyUmt7q2ljljYc7WwwVgQN6vkDVLW5/ZY8UeJPG2nW89z+zV421e88T/EPRrGKSeT4C+NtW uZbvxJ8UNI0+FXc/CPxleTPrfxT07T4wfAPiyTVfin9juvD/AIo+ImqeGPPmng608Qv91ryUsUl/ zD1VFRWKXVUZxjGOKt7tNxjiWox+tVH9fhGuJsuw2USa/wBYMrpyo5FJu0s4wE6rqvh9vSM8ww1a rXxORuf77GRrYjJY1K1ZZFgo/X9FQWt1bXttb3tlcQXdndwRXVpd2ssdxbXVtcRrLBcW88TPFNBN E6SRSxu0ckbK6MysCZ69C58i04txkmmm000001o009U09GnsFFFFAgooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKAGu6RI8kjrHHGrPJI7BEREBZndmIVVVQWZmIAAJJAFfH3wxR/2hvitF+0 TfK03wi+H1tqnhz9mO0mUi28U6hq9vPpfxD/AGilgcbZrTxJp7N8PfgzqXlrIPh0PHHjLSL/AFDw 18abFLOTxbcXH7U2saj8M/DdxNF+zz4f1m70f40eNLWV4Yvi9qejXUlrq/wL8C3cLK174Rt9Sgl0 v45eMbWT+zZI7bUPg5oMup67e/ES6+HX1zbW9vZ28FpaQQ2tpawxW1ra20SQW9tbwIsUMEEMSrHD DDGqxxRRqqRoqoihQBXn/wC/VYSX+54epGpF9MViabvCS6PD4aaU4S19riYwnBxhh06/2D/4xbL8 RSlpxLnGEqYWtDafD+TYuHJiaU2vfhnOd4eU8LiKN4LL8jrYnC4mFfE5xOGUzUUUV6B8eFFFFABR RRQAUUUUAFIQCCCAQQQQRkEHggg8EEdRS0UAfINz4X8a/sx3NxrXwv0bVvH37Pks8174i+CmjWp1 Dxl8IIppGnvtf+A9nDtuPEfgi2Z5r7VvgSFuNV06184/BNy9lpPwk1/6R8DePPBnxM8LaV42+H/i bRvF/hTW4pZNN13Qr2K+sZ2t55LW8tneJi1tqGnXsFxp+qabdpBqGlalbXWnajbWt9bT28fW18ze OfgDe23ijVfiz8A/Elv8JvizqssV74qtJLB9Q+FHxlmtYI7eG2+L/gm2ktvtOtPZwQadYfFTwpca J8TNFt7TSrS71nxR4R0p/A2pef7Ktg9cLD22G+1g01GpRXfByk1DkX/QJNwhFfwKlNQjQqfXrHZd xIlTzzERyzPLJU+InSqVMJmTWnJxJRw9OeJWKkve/t/B0cTiq1SNs1wWNq4qrm2D+maK+WvCn7Tl jZeI9I+HH7QHhK7/AGf/AIoa3eR6V4dg8QarDrnwo+JWqSBjFbfCP4xQ2Wl6D4nv7oLIbTwT4q07 wH8WHjgubx/hymkRwardfUtdNDE0cTFyoz5uV8tSDjKFWlO1+StRqKNWjOzT5KkIys07Wab8TNcl zPJatKlmOFlRWIp+2wmIp1KOKwOOoKTg8Rl2Y4SpXwOYYZVIypvEYLEV6KqQnTdT2kJxRRRRW55Y UUUUAFFFFABRRRQAUUUUAFFFFABRRXzv8SP2kvCHgrxLL8NfCOjeIvjN8ahaWt4PhD8MItO1TxFo tlqCs2na18Rdc1PUNK8G/CbwzeqsstjrvxH8Q+HU16O2u7Xwha+JtZhTSJsq1ejh4c9aapxclGN7 uU5u/LTpwinOrVlZ8lOnGVSb0jFvQ9HLMqzHOMS8LluEq4qtGnKvWceWFHC4am4qtjMbiasoYbA4 GhzRlicdjKtDCYaD9pXrU4JyXu+r6xpPh/StS13XtU07RNE0axutT1fWdXvbbTdK0rTbGF7m91DU tQvZYbSxsbO3jknuru6mit7eGN5ZZERWYfJf9t+M/wBqz/R/Bt9r/wAOP2Zpvl1D4g2b33h/4j/H 2xfifTvho7RW2rfD34RalATBL8VY3s/HXjuyluLj4Wp4U8PP4d+KXiHQ0j4E+L/irqum+Nf2qr/Q vEf9mX1rq/hT9nzwneXmqfA3wNqVjOl1peseJLjVdJ0PVPjl450y7iiv9P8AEXjfQ9K8HeG9TtdM 1XwR8NfDnifSR4u1L61rk5a2N/ixnhsI9fYtuOJxK6e3ad8PQe7oRft6qcY15UI+2w1T3/bZXwx/ uFahnXEcdHmUIxrZLklTeX9lKpG2cZpTf7qOa1accrwNSNatlNLM6jy3PMLlaDoWieFtE0jw14a0 jTfD/h3w/ptjo2haFo1jbaZpGjaRpltHZ6dpel6dZxw2ljYWNpDFbWlpbRRwW8EccUUaIiqNWiiu 9JRSjFJJJJJKySWiSS0SS0SWx8lUqVKs51as51KlScqlSpUlKc6k5tynOc5NylOUm5SlJtybbbbY UUUUyAooooAKKKKACiiigAooooAKKKKAOf8AFfhLwr478Oax4P8AG/hrQPGPhLxBZyadr3hjxTo+ n6/4e1qwlKtJZato2q293p2o2jsis1vd200RZVYplQR8s/8ADOnxJ+E3+lfsvfGHUtA0S3+dPgZ8 b5dc+LPwfljXl7Hwp4jv9UX4wfCnzU/0XTIdE8ZeJ/hz4WgEX9l/CG5gg+wy/Y1Fc1fCUMRKM5wc a0FywxFKU6OIhG9+WNak41ORvWVJydKb+OEloe5lXEebZRSqYXDYiFbLq9T2uJyjMMPQzLJ8TV5V BV62WY6nXwf1uNNezo4+nSp4/DRb+q4mhL3l8c/8NU+Ivh7/AKP+0v8AAP4jfCKGHi5+I/gSC7/a A+BrY/1l0/jP4faJF8QfCOkW4DSXuv8Axb+EPwy0CziKPJqrAuY/or4efFP4ZfF3QY/FXwp+Ifgj 4leGpWCJr/gLxVofi7RzIwJ8ptR0G+v7RJhtYNC8qyoysrorKwHeV87fEP8AZL/Zy+KOvSeMPFnw l8Mx+PpFZf8AhZ3hAaj8OPizCrEErafFj4dX3hX4j2QDqkqi08UQBZo4p1xNFG64ezzKj/Dr0MbD pHFx+q19d3LE4WlOjJL7MI5fB2+Kq2rv1PrfBeZ643K814YxD1lX4eqrPcrSjpGnSyPPsdhcypzq L3quJq8X4iEZp+ywMYSUIfRNFfHP/DNHxe8K/wDJKP2zfjrollB/x4eE/i3pHwy+PXhO3A+5Hd63 4r8HaV8ctVT+GVtQ+N81zIoUi4jk3yOY/wCCgPhj92n/AAx98bFj+ZbqeT4z/sxzXKjpBNaw2/7W cNvKQAHv4p5Y3ZzImlQrGIHPrtWH8fLsbTS+KpSVDFU79eSGHr1MXOPZvCxbXxRi9A/1Xy7E/wDI q4y4ZxlSfvUcHjZZtkOLUHssTiM5yvCZBQrRulUpwz6vTUr+yrVoJzPsaivjn/hc/wC11o/7vxJ+ xVb65L9zzPhD+0n8O/FVkZOm8TfFfQPgPefZMxzkynThdBJdOIsS9xqEekn/AA0v8c4P3V1/wTy/ ayuLhOJZtF+IH7B95pUjdc2VzrH7Z/h3U5osEAteaLp8m8OohKBZHP7Tw3/PvMP/AA05r/8AMYf6 j51/0G8H/wDiw+AP/omPsaivjn/hpr43N8qf8E7v2wEdvlRrnxz+wFHbqx4Vp5Lf9uG7uEhU4Mrw WtzMqBmit5nCxsf8Lw/as1L9zon7D+u6TcjrP8SP2g/gx4f0gk8rsuvh7qHxc1UhVSQSltCQrK9o sSzxy3U1if2nhv8An3mH/hpzX/5jD/UfOv8AoN4P/wDFh8Af/RMfY1FfHP8AaP8AwUB8R/uk8I/s ffB9ZeF1Cf4g/Gf9oqazXtLNoUPw2/ZihvZWGDJaReJ7OOF8xpqN0oEzH/DP37RXir5viX+2v8Qb KCXm+0D9n34V/Cb4PeHLxT1tkv8Ax3onx4+KOlWwwrpLoXxR0vV1kXDau9s8ls59eqT/AIGX4+tH ZTlCjhY36c0MbXw+IS6tqhKy2Tegf6qYTD6Zrxhwnl1Ze9LC0cXmWf1pQXxeyxPDGVZ1k8qj1jCn VzWipStzTp037VfU3ifxZ4W8EaLeeJPGfiXw/wCEfDunqHv9f8T6zp2gaLYoc4e81TVbm0sbZTg4 aadAcHnivlo/tjeHPG5Np+zT8OPiH+07PISkHi/wFp9l4a+BsRbiO+k+PXj678OfD7xNpKEq943w lvPil4gt4JIpovDd0JYlff8ADH7Fn7NPhzWrPxXqPw1t/iZ45sG82z+Ifx017xR8fPiBYTtgyy6N 4w+MmteN9b8NxykcWHhm70bS7aER2djYWtjBb2sX1KAAAAAAAAABgADgAAcAAdBRy5lW0nUw2Bhs /q/NjK7W/NCtiKVChSl0cZ4PFJq7Uk7WPb8E5b72GwedcUYhe9CWcex4cyqElo6WJyzKMdmmaZhS avONbD8R5HVjLlUqU4qUZfHf/Cov2iPjF+++PXxbT4WeELj5pfgv+y9revaHcXNu/wB/TvGf7Smp 6f4f+KeuIOGiuvhF4d/Z8vYXUwXd9rVm7pJ9D/Df4WfDr4P+GYvB3wv8GeH/AAP4bju7rUZNM8Pa dDYpf6tfsJNR1vV7hQbzW9f1WZRcatr2r3F7rGq3Ja61G+ubhmkPfUVtRwdCjP2tpVcQ04vE15Or XalZyjGcv4VOUlzewoKlQUtY0onn5nxNmuZ4ZZe50cvyeFSNWlkmVUIZflUalNShRrVsNQtLMMbS pS9is0zWpj82qUlGOIx1Zq4UUUV1Hz4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf//ZAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwMEFAAG AAgAAAAhAA8tr65RAQAAiwIAABEAAABwcHQvcHJlc1Byb3BzLnhtbKyQzWrDMBCE74W+g9FdkSw7 dmxiBzt2odBDDu0DCFtOBNYPkvJTSt+9wnFLQy859LbLMrPfzHpzEWNwYsZyJQsQLjAImOxUz+W+ AG+vT3AFAuuo7OmoJCvAO7NgUz4+rHWuDbNMOuq8dGcCbyRtTgtwcE7nCNnuwAS1C6WZ9LdBGUGd X80e9Yae/QMxIoJxggTlEsx6c49eDQPvWKO6o/AAVxPDxonEHri23276HrffOW6QSh+SXdyLdfMU HA0vwEebJts2iyuY4GgL4zAmsM7aGiZNGKUYh7gi6SfwmjDOe247avpnQfes7blrqKNzVH/+gyd4 Z5RVg1t0SqBrTqTVmRmt+BQ1xHNfJzoWAANUrtGEecvYRGGFE1LBNFtVMI5IBqu6aWBdV6tlkhC8 DPEPIxvocXQTY6P5P+IRcgN4BZ369OPv3nem/AIAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAA tgAAABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHp QGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sU V+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vl iGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBLAwQUAAYACAAAACEAr0HbUo8BAADUAwAAEQAA AHBwdC92aWV3UHJvcHMueG1sxFM9b8IwEN0r9T9Y3iEJoimNCCxVJ4ZK0O6WcwmWEtvymc9f33MC JRQGtk65z3fv3TnT+b6p2RYcKqNzngxjzkBLUyhd5fxr9TGYcIZe6ELURkPOD4B8Pnt+mtpsq2D3 6RgBaMxEztfe2yyKUK6hETg0FjTlSuMa4cl1VVQ4sSPgpo5GcZxGjVCan/rdI/2mLJWEdyM3DWjf gTiohSfyuFYWz2j2ETTrAAmm7b6iNCNxOtCuv1uJwadabxwUCyg9wyOt6iUdxTzq51bGtqm3cZq2 qegWB2tVwAVWLuui53Um2wq3lKKmdSc8DMDgzKYiwz0LV4rpKEX4tlMofLgTpuGnPpsZpyql2T7n gyRJUs4OZE3GgT6VyQuDakP0FujD1NZm1EpLon0ad+TMGsz5KOnknUu64GRy1nwBCeA9hYHStX5t POAK9v5CocfmRje9znu6r8JhSLevvm4qIc1nhr8zqPgOBTTOg/s/Sn/nV04VSysk/TtM0hFf6emR IEmKOrO747Z7rT8AAAD//wMAUEsDBBQABgAIAAAAIQCt0u5yeQEAAMoCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8klFLwzAUhd8F/0PI k4JdmlXmKF0Hm/ikMHCi+BaSuy3YJiW52u3fm3RbnSiDvCT33I9zz00x3dYV+QLntTUTygcpJWCk VdqsJ/Rl+ZCMKfEojBKVNTChO/B0Wl5eFLLJpXWwcLYBhxo8CSTjc9lM6AaxyRnzcgO18IOgMKG4 sq4WGK5uzRohP8Qa2DBNR6wGFEqgYBGYND2RHpBK9sjm01UdQEkGFdRg0DM+4OxHi+Bq/29DVzlR 1hp3TZjpYPeUreS+2Ku3XvfCtm0HbdbZCP45e3t6fO5GTbSJWUmgZaFkjhorKBe2Bbew2iBZOPDB scAQdsF6RdRKBwKtK2dhQNDrzQ15lhaRzMlVxrPZdSc/imL4lfD4FPa00qBmuzN9f7Wx3cGXjjsv eVaw03sw0+W0dwSKhMnzfU7Hyms2v18+0DIuL0nHCR8t0zTvznv0+as/JrF/qA9uzxL5MOE84XeR eJvlt+MT4hFQdo5//77yGwAA//8DAFBLAwQUAAYACAAAACEALX+1pvsBAABoBAAAEAAIAWRvY1By b3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACkVE2P2jAQvVfq f7Byag/gsKWrChmvKlYrDqUgkd2e3XhCrDq2Zbvs0l/fSUwglFUPbU5vPjJ+82ZsdvfSaLIHH5Q1 82wyzjMCprRSmd08eyweRp8yEqIwUmhrYJ4dIGR3/O0btvHWgY8KAsESJsyzOkY3ozSUNTQijDFs MFJZ34iIpt9RW1WqhHtb/mzARHqT57cUXiIYCXLkTgWzVHG2j/9aVNqy5ReeioNDwpwVNgpdqAb4 JL9l9Gyyb9bLwCcfGU2IfXZOq1JEFISvVOltsFUk64462dhn8BurTGR0mIhyQMCeut8eupb52oxC 6QEM2db2mbybzj68Z/SVRLYRXuy8cHUiMjDZVisJ6Gb0iNhXG9GRM5oAWyopwRyj6L6w2Wq10Mp1 +T1k21JoWKA+vBI6AJY+OdgSRDv7jVA+cLaPsz2U0XoS1C+c/jQj30WAVtV5thdeCRNR3TYtGR3W LkTPC1wDrI2xZHdwmDbEatq2iLkI/pqYanXdkkJFDeH/j2jPTW3i2ZcCpCPWFY4kvqLHzVCPjlpS I7E87syVECdJzttEhmtx1VE3AuT2B5uFbZwwBwyc0BdlfoRHV9h7EaEf76WTbWvhQeIt7ONnB1vi ZL1uiyxqYXYg+5zrQHtRntLDwSfTcY5fdyd6X7vq/RPBfwMAAP//AwBQSwECLQAUAAYACAAAACEA 38wY9cIBAABGDAAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQBo+HShBQEAAOICAAALAAAAAAAAAAAAAAAAAPsDAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQAzDh4EwQAAADcBAAAgAAAAAAAAAAAAAAAAADEHAABwcHQvc2xpZGVzL19yZWxzL3Ns aWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQAbLjUHEwEAANADAAAfAAAAAAAAAAAAAAAAADAI AABwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGSNNdVNAgAA nAwAABQAAAAAAAAAAAAAAAAAiAoAAHBwdC9wcmVzZW50YXRpb24ueG1sUEsBAi0AFAAGAAgAAAAh AO/HOWbwBwAAelIAABUAAAAAAAAAAAAAAAAABw0AAHBwdC9zbGlkZXMvc2xpZGUxLnhtbFBLAQIt ABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAACoVAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAs AAAAAAAAAAAAAAAAADIWAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54bWwu cmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAADoXAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLx vgAAADcBAAAtAAAAAAAAAAAAAAAAAEIYAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0MTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABL GQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJlbHNQSwECLQAUAAYA CAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAABTGgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAA AAAAAAAAAAAAXBsAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAZBwAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA NwEAACwAAAAAAAAAAAAAAAAAbB0AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQz LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAdB4AAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh AGmiXyEeAQAAxwcAACwAAAAAAAAAAAAAAAAAfB8AAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xp ZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAI+sLG6zAwAACQwAACIAAAAAAAAAAAAA AAAA5CAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEA 2Lm2smQDAAApCwAAIgAAAAAAAAAAAAAAAADXJAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDEwLnhtbFBLAQItABQABgAIAAAAIQALOYleiQQAALUQAAAhAAAAAAAAAAAAAAAAAHsoAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWxQSwECLQAUAAYACAAAACEAXFHBZE0DAADyCgAA IQAAAAAAAAAAAAAAAABDLQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIueG1sUEsBAi0A FAAGAAgAAAAhAK2PXLo5BAAAYRAAACEAAAAAAAAAAAAAAAAAzzAAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQxLnhtbFBLAQItABQABgAIAAAAIQBsCxjVngcAADMvAAAhAAAAAAAAAAAAAAAA AEc1AABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEAn+nA ORQEAADEEQAAIQAAAAAAAAAAAAAAAAAkPQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQu eG1sUEsBAi0AFAAGAAgAAAAhAObrYO5yBQAAkxsAACEAAAAAAAAAAAAAAAAAd0EAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQCzeW7i2QIAABUIAAAhAAAA AAAAAAAAAAAAAChHAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWxQSwECLQAUAAYA CAAAACEAYwwyY6kCAADDBgAAIQAAAAAAAAAAAAAAAABASgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhANQ1R0TwBAAAHhIAACEAAAAAAAAAAAAAAAAAKE0A AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbFBLAQItABQABgAIAAAAIQD46EnArgQA AI0RAAAhAAAAAAAAAAAAAAAAAFdSAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWxQ SwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABEVwAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHNQSwECLQAUAAYACAAAACEA+c8JOYMGAABc GwAAFAAAAAAAAAAAAAAAAABMWAAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwECLQAKAAAAAAAAACEA KHsPcQBUAAAAVAAAFwAAAAAAAAAAAAAAAAABXwAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQSwEC LQAUAAYACAAAACEADy2vrlEBAACLAgAAEQAAAAAAAAAAAAAAAAA2swAAcHB0L3ByZXNQcm9wcy54 bWxQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAAC2tAAAcHB0L3RhYmxl U3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQCvQdtSjwEAANQDAAARAAAAAAAAAAAAAAAAAJO1AABw cHQvdmlld1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQCt0u5yeQEAAMoCAAARAAAAAAAAAAAAAAAA AFG3AABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQAtf7Wm+wEAAGgEAAAQAAAAAAAA AAAAAAAAAAG6AABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAAlACUATQsAADK9AAAAAA== --_004_A5BEAD028815CB40A32A5669CF737C3B2356FA44apembxsp40RESAD_-- From stephen.farrell@cs.tcd.ie Tue Jan 22 15:09:24 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC0021F871F for ; Tue, 22 Jan 2013 15:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ-aFd6lNCI6 for ; Tue, 22 Jan 2013 15:09:22 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 68AB121F8A25 for ; Tue, 22 Jan 2013 15:09:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93F3ABE58; Tue, 22 Jan 2013 23:08:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6YLos3VzEBe; Tue, 22 Jan 2013 23:08:56 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.26.104]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DCE53BE55; Tue, 22 Jan 2013 23:08:55 +0000 (GMT) Message-ID: <50FF1C07.80708@cs.tcd.ie> Date: Tue, 22 Jan 2013 23:08:55 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Burleigh, Scott C (313B)" References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120927172602.1763958833@smtp.mail.me.com> <20121002225237.520325524@smtp.mail.me.com> <7249cc388d868cb16f14efe286351e37.squirrel@webmail.math.umd.edu> <20121004210719.1971171529@smtp.mail.me.com> <20121004220537.1202245607@smtp.mail.me.com> <20121016220658.793339059@smtp.mail.me.com> <20121022185905.200828573@smtp.mail.me.com> <20121022202820.71123343@smtp.mail.me.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:09:24 -0000 Hi Scott, FWIW, I also think the BSP ended up a bit of a rat's nest. However I think that's because security was as usual an afterthought so I'm not sure this proposal will really work out simpler. However, I have no objection at all to it being tried, so I'd say fire away and write it up in a draft. Only thing I'd recommend would be to try keep things common with the BSP RFCs to the extent possible so that the code we have now can be re-used if someone wants to do this new scheme or both schemes. I'd be happy to comment on a proposal to the extent that time permits. Cheers, S. On 01/22/2013 10:37 PM, Burleigh, Scott C (313B) wrote: > Hi. Late last September, several of us spun off a sub-thread talking about how the processing of bundles with multiple security destinations could be handled in DTN implementations. I won't try to recreate all of the arguments on all sides, but I think we did converge on agreement that the current BSP mechanism for complex, multi-destination security could be difficult to realize in coherent fashion across the network. After puzzling over this for a while, I came up with a concept (below) that I think would be simpler, safer, and even more powerful than the current protocol design. How do we all feel about this? Would it be worthwhile for DTNRG to invest in a 6257bis RFC along these lines? > > Scott > _____________________________________________ > From: Burleigh, Scott C (313B) > Sent: Friday, November 16, 2012 5:05 PM > To: 'Peter Lovell'; ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss > Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in DTN2 > > > Hi, Peter. At the risk (I know) of getting a lot of people severely ticked off at me, I am going to offer a modest proposal for improving the Bundle Security Protocol, inspired by this thread. > I propose to adopt a new design principle for Bundle Security Protocol: the routing element of a bundle protocol agent should never need to inspect a bundle's BSP extension blocks in order to select the node(s) to forward the bundle to. > That is, BSP should provide security, not dictate routes. > My rationale for proposing this principle is that I believe it would: > * Simplify BSP, thereby reducing the incidence of bugs and making Bundle Security significantly less expensive to implement and sustain. > * Broaden the scope of BSP deployment by eliminating its dependence on specific, BSP-aware routing implementations, thereby increasing the overall security of DTN. > * Reduce the cost of developing and improving routing implementations by removing any requirement that they be BSP-aware, and broaden the scope of deployment of non-BSP-aware routing implementations by enabling them to be used in environments requiring arbitrarily powerful security. Thereby, improve DTN operational performance. > Here's how I would apply this principle: > 1. Eliminate security sources and security destinations from all BSP blocks. The security source of a BSP block would always be the bundle's source. The security destination of a BSP block would always be the bundle's destination. > 2. Add a new Administrative Record type for Bundle-in-Bundle encapsulation. > 3. When additional security must be applied to a bundle on some segment of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Encapsulation Administrative Record that is the payload of a new bundle whose source is the security source of the path segment and whose destination is the security destination of the path segment. Apply the additional bundle transmission security measures to the encapsulating bundle: encrypt its payload (the Administrative Record, containing the encapsulated bundle), encrypt extension blocks as copied from the encapsulated bundle, etc. Then forward the encapsulating bundle. > 4. When route service uncertainty forces a bundle to be routed over multiple parallel additionally secured segments of its end-to-end path, encapsulate it as above but within multiple different encapsulating bundles, one for each of the parallel segments, and forward all of them. > 5. At the destination of a bundle, apply all relevant bundle reception security measures and then, if the payload is an encapsulation Administrative Record, extract the encapsulated bundle from the Administrative Record and simply forward it. > I believe this would have the following impacts on DTN security: > * No EID references in BSP, simplifying canonicalization. > * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the encapsulated bundle encrypts all three at once), so no correlators in BSP. (Except for BABs, no bundle ever has more than one occurrence of any type of BSP block. And there will never be more than two BABs, one immediately following the primary block and one that is the final block in the bundle, so that correlation is structural.) > * No delicate "replacement" process for unraveling PCB nesting at the destination. > * No possible confusion about the correct order of application of BSP blocks. > * No possible conflict among security destinations of different BSP blocks. > * Security paths can never overlap. > * Any routing implementation can always accommodate any security regime: routes that must be followed to ensure security are encoded into routing information at the forwarding node, not into the bundle. (A little like the late binding principle.) > * Any routing environment can always be made arbitrarily secure - no need to require specially BSP-aware routing elements. > * Ciphersuite design is simplified, so a wider array of useful ciphersuites can be developed without imposing bug-prone complexity. Minimizes possible security problems. > > As an example of how I think this could work, see the attached diagram: > 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are within the low-risk "W" security region; nodes C and G are gateways between region W and the more hazardous region X; node D is another node in X; nodes E and F are gateways between region X and even more hazardous region Y; nodes H and I are gateways between X and hazardous region Z. > 2. At A the bundle is simply forwarded to B. > 3. At B the routing element realizes that the bundle has to traverse region X in order to get to K, so it forwards the bundle to C. > 4. The routing element at C encapsulates the bundle in an Admin Record, creates a new bundle destined for G (the egress from region X) whose source is C and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the bundle to D. > 5. D realizes that the bundle has to traverse region Y in order to get to G, so it forwards the bundle to E. > 6. E encapsulates the bundle in an Admin Record, creates a new bundle destined for F (the egress from region Y) whose source is E and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the bundle to F. > 7. The bundle protocol agent at F receives the bundle, decrypts it, and passes the payload (an Admin Record) to the application agent. The administrative element of the application agent at F receives the Admin Record, extracts the encapsulated bundle destined for G, and queues it to be forwarded. The routing element at F sees this bundle and forwards it to G. > 8. The bundle protocol agent at G receives the bundle, decrypts it, and passes the payload (an Admin Record) to the application agent. The administrative element of the application agent at G receives the Admin Record, extracts the encapsulated bundle destined for K, and queues it to be forwarded. The routing element at G sees this bundle, realizes that the bundle has to traverse region Z in order to get to K, and therefore forwards the bundle to H. > 9. H encapsulates the bundle in an Admin Record, creates a new bundle destined for I (the egress from region Z) whose source is H and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the bundle to I. > 10. The bundle protocol agent at I receives the bundle, decrypts it, and passes the payload (an Admin Record) to the application agent. The administrative element of the application agent at I receives the Admin Record, extracts the encapsulated bundle destined for K, and queues it to be forwarded. The routing element at I sees this bundle and forwards it to J. > 11. At J the bundle is simply forwarded to K. > 12. At K the bundle's payload is passed to the application. > I think this approach would combine simplicity with quite a lot of operational power, making everything cheaper and safer. > So, having now stirred the hornet's nest, I will beat a hasty retreat for a week while I am on vacation. I'll try to follow up when I get back. > Have a nice Thanksgiving, everybody. > Scott > > -----Original Message----- > From: Peter Lovell [mailto:plovell@mac.com] > Sent: Monday, October 22, 2012 1:28 PM > To: Burleigh, Scott C (313B); ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell > Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2 > > On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: > >> In view of which, I've now become a bigger fan of bundle-in-bundle >> tunneling than I've been in the past. > > Hi Scott, > > I agree. I'm also a big fan, for a bunch of reasons. However, as I mentioned to Angela, the current [i.e. latest, expired] draft seems a bit "funky" to me. There's no indication in the bundle that it's BiB and you need some special EID to perform the decapsulation. Maybe that's just like an assigned port in TCP but we don't yet have such a mechanism. The multiple-bundle thing is OK, I guess, but I don't see much use for it other than volume gateway-to-gateway traffic and I think that such heavy-duty tunnels could be specially optimized. > > I need to go back and review all the discussions about BiB -- we worked it quite a bit but the spec never gained enough consensus to move forward. I think it would be a good idea to revisit it now and get a solid draft that has wider support. Maybe the email discussions will help us get there. > > Thanks.....Peter > > > > > > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security > From scott.c.burleigh@jpl.nasa.gov Tue Jan 22 15:22:30 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857E21F8570 for ; Tue, 22 Jan 2013 15:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpYgULgiMt9G for ; Tue, 22 Jan 2013 15:22:26 -0800 (PST) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id A7AE321F8AFE for ; Tue, 22 Jan 2013 15:22:23 -0800 (PST) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0MNMGih030937 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 22 Jan 2013 15:22:17 -0800 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.60]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.02.0318.001; Tue, 22 Jan 2013 15:22:16 -0800 From: "Burleigh, Scott C (313B)" To: Stephen Farrell Thread-Topic: [dtn-security] FW: Re(19): Implementing Security Destinations in DTN2 Thread-Index: AQHN+PV6E0mDGQeTfUOaSAgW29u2tJhV+pZQ Date: Tue, 22 Jan 2013 23:22:16 +0000 Message-ID: References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120927172602.1763958833@smtp.mail.me.com> <20121002225237.520325524@smtp.mail.me.com> <7249cc388d868cb16f14efe286351e37.squirrel@webmail.math.umd.edu> <20121004210719.1971171529@smtp.mail.me.com> <20121004220537.1202245607@smtp.mail.me.com> <20121016220658.793339059@smtp.mail.me.com> <20121022185905.200828573@smtp.mail.me.com> <20121022202820.71123343@smtp.mail.me.com> <50FF1C07.80708@cs.tcd.ie> In-Reply-To: <50FF1C07.80708@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:22:30 -0000 Thanks, Stephen, and I completely agree that any 6257bis RFC should retain = as much of 6257 as possible. People have invested in that RFC already, and= I'm opposed to revising more deeply than would be needed to implement this= proposal. Scott -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Tuesday, January 22, 2013 3:09 PM To: Burleigh, Scott C (313B) Cc: dtn-security@irtf.org Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations = in DTN2 Hi Scott, FWIW, I also think the BSP ended up a bit of a rat's nest. However I think = that's because security was as usual an afterthought so I'm not sure this p= roposal will really work out simpler. However, I have no objection at all t= o it being tried, so I'd say fire away and write it up in a draft. Only thing I'd recommend would be to try keep things common with the BSP RF= Cs to the extent possible so that the code we have now can be re-used if so= meone wants to do this new scheme or both schemes. I'd be happy to comment on a proposal to the extent that time permits. Cheers, S. On 01/22/2013 10:37 PM, Burleigh, Scott C (313B) wrote: > Hi. Late last September, several of us spun off a sub-thread talking abo= ut how the processing of bundles with multiple security destinations could = be handled in DTN implementations. I won't try to recreate all of the argu= ments on all sides, but I think we did converge on agreement that the curre= nt BSP mechanism for complex, multi-destination security could be difficult= to realize in coherent fashion across the network. After puzzling over th= is for a while, I came up with a concept (below) that I think would be simp= ler, safer, and even more powerful than the current protocol design. How d= o we all feel about this? Would it be worthwhile for DTNRG to invest in a = 6257bis RFC along these lines? >=20 > Scott > _____________________________________________ > From: Burleigh, Scott C (313B) > Sent: Friday, November 16, 2012 5:05 PM > To: 'Peter Lovell'; ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss > Subject: RE: Re(19): [dtn-security] Implementing Security Destinations=20 > in DTN2 >=20 >=20 > Hi, Peter. At the risk (I know) of getting a lot of people severely tick= ed off at me, I am going to offer a modest proposal for improving the Bundl= e Security Protocol, inspired by this thread. > I propose to adopt a new design principle for Bundle Security Protocol: t= he routing element of a bundle protocol agent should never need to inspect = a bundle's BSP extension blocks in order to select the node(s) to forward t= he bundle to. > That is, BSP should provide security, not dictate routes. > My rationale for proposing this principle is that I believe it would: > * Simplify BSP, thereby reducing the incidence of bugs and making B= undle Security significantly less expensive to implement and sustain. > * Broaden the scope of BSP deployment by eliminating its dependence= on specific, BSP-aware routing implementations, thereby increasing the ove= rall security of DTN. > * Reduce the cost of developing and improving routing implementatio= ns by removing any requirement that they be BSP-aware, and broaden the scop= e of deployment of non-BSP-aware routing implementations by enabling them t= o be used in environments requiring arbitrarily powerful security. Thereby= , improve DTN operational performance. > Here's how I would apply this principle: > 1. Eliminate security sources and security destinations from all BSP= blocks. The security source of a BSP block would always be the bundle's s= ource. The security destination of a BSP block would always be the bundle'= s destination. > 2. Add a new Administrative Record type for Bundle-in-Bundle encapsu= lation. > 3. When additional security must be applied to a bundle on some segm= ent of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle En= capsulation Administrative Record that is the payload of a new bundle whose= source is the security source of the path segment and whose destination is= the security destination of the path segment. Apply the additional bundle= transmission security measures to the encapsulating bundle: encrypt its pa= yload (the Administrative Record, containing the encapsulated bundle), encr= ypt extension blocks as copied from the encapsulated bundle, etc. Then for= ward the encapsulating bundle. > 4. When route service uncertainty forces a bundle to be routed over = multiple parallel additionally secured segments of its end-to-end path, enc= apsulate it as above but within multiple different encapsulating bundles, o= ne for each of the parallel segments, and forward all of them. > 5. At the destination of a bundle, apply all relevant bundle recepti= on security measures and then, if the payload is an encapsulation Administr= ative Record, extract the encapsulated bundle from the Administrative Recor= d and simply forward it. > I believe this would have the following impacts on DTN security: > * No EID references in BSP, simplifying canonicalization. > * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the en= capsulated bundle encrypts all three at once), so no correlators in BSP. (= Except for BABs, no bundle ever has more than one occurrence of any type of= BSP block. And there will never be more than two BABs, one immediately fo= llowing the primary block and one that is the final block in the bundle, so= that correlation is structural.) > * No delicate "replacement" process for unraveling PCB nesting at t= he destination. > * No possible confusion about the correct order of application of B= SP blocks. > * No possible conflict among security destinations of different BSP= blocks. > * Security paths can never overlap. > * Any routing implementation can always accommodate any security re= gime: routes that must be followed to ensure security are encoded into rout= ing information at the forwarding node, not into the bundle. (A little lik= e the late binding principle.) > * Any routing environment can always be made arbitrarily secure - n= o need to require specially BSP-aware routing elements. > * Ciphersuite design is simplified, so a wider array of useful ciph= ersuites can be developed without imposing bug-prone complexity. Minimizes= possible security problems. >=20 > As an example of how I think this could work, see the attached diagram: > 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are w= ithin the low-risk "W" security region; nodes C and G are gateways between = region W and the more hazardous region X; node D is another node in X; node= s E and F are gateways between region X and even more hazardous region Y; n= odes H and I are gateways between X and hazardous region Z. > 2. At A the bundle is simply forwarded to B. > 3. At B the routing element realizes that the bundle has to traverse= region X in order to get to K, so it forwards the bundle to C. > 4. The routing element at C encapsulates the bundle in an Admin Reco= rd, creates a new bundle destined for G (the egress from region X) whose so= urce is C and whose payload is that Admin Record, encrypts the payload, att= aches a PCB, and forwards the bundle to D. > 5. D realizes that the bundle has to traverse region Y in order to g= et to G, so it forwards the bundle to E. > 6. E encapsulates the bundle in an Admin Record, creates a new bundl= e destined for F (the egress from region Y) whose source is E and whose pay= load is that Admin Record, encrypts the payload, attaches a PCB, and forwar= ds the bundle to F. > 7. The bundle protocol agent at F receives the bundle, decrypts it, = and passes the payload (an Admin Record) to the application agent. The adm= inistrative element of the application agent at F receives the Admin Record= , extracts the encapsulated bundle destined for G, and queues it to be forw= arded. The routing element at F sees this bundle and forwards it to G. > 8. The bundle protocol agent at G receives the bundle, decrypts it, = and passes the payload (an Admin Record) to the application agent. The adm= inistrative element of the application agent at G receives the Admin Record= , extracts the encapsulated bundle destined for K, and queues it to be forw= arded. The routing element at G sees this bundle, realizes that the bundle= has to traverse region Z in order to get to K, and therefore forwards the = bundle to H. > 9. H encapsulates the bundle in an Admin Record, creates a new bundl= e destined for I (the egress from region Z) whose source is H and whose pay= load is that Admin Record, encrypts the payload, attaches a PCB, and forwar= ds the bundle to I. > 10. The bundle protocol agent at I receives the bundle, decrypts it, = and passes the payload (an Admin Record) to the application agent. The adm= inistrative element of the application agent at I receives the Admin Record= , extracts the encapsulated bundle destined for K, and queues it to be forw= arded. The routing element at I sees this bundle and forwards it to J. > 11. At J the bundle is simply forwarded to K. > 12. At K the bundle's payload is passed to the application. > I think this approach would combine simplicity with quite a lot of operat= ional power, making everything cheaper and safer. > So, having now stirred the hornet's nest, I will beat a hasty retreat for= a week while I am on vacation. I'll try to follow up when I get back. > Have a nice Thanksgiving, everybody. > Scott >=20 > -----Original Message----- > From: Peter Lovell [mailto:plovell@mac.com] > Sent: Monday, October 22, 2012 1:28 PM > To: Burleigh, Scott C (313B);=20 > ahennes1@math.umd.edu > Cc: Amy Alford;=20 > Cherita.Corbett@jhuapl.edu; Howard=20 > Weiss; Peter Lovell > Subject: Re(19): [dtn-security] Implementing Security Destinations in=20 > DTN2 >=20 > On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: >=20 >> In view of which, I've now become a bigger fan of bundle-in-bundle=20 >> tunneling than I've been in the past. >=20 > Hi Scott, >=20 > I agree. I'm also a big fan, for a bunch of reasons. However, as I mentio= ned to Angela, the current [i.e. latest, expired] draft seems a bit "funky"= to me. There's no indication in the bundle that it's BiB and you need some= special EID to perform the decapsulation. Maybe that's just like an assign= ed port in TCP but we don't yet have such a mechanism. The multiple-bundle = thing is OK, I guess, but I don't see much use for it other than volume gat= eway-to-gateway traffic and I think that such heavy-duty tunnels could be s= pecially optimized. >=20 > I need to go back and review all the discussions about BiB -- we worked i= t quite a bit but the spec never gained enough consensus to move forward. I= think it would be a good idea to revisit it now and get a solid draft that= has wider support. Maybe the email discussions will help us get there. >=20 > Thanks.....Peter >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security >=20 From stephen.farrell@cs.tcd.ie Tue Jan 22 15:29:17 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CCB21F8856 for ; Tue, 22 Jan 2013 15:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLcGK4VTtRRq for ; Tue, 22 Jan 2013 15:29:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EA34C21F84F8 for ; Tue, 22 Jan 2013 15:29:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2F4B9BE58; Tue, 22 Jan 2013 23:28:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SozJoLE7XS21; Tue, 22 Jan 2013 23:28:50 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.26.104]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1418BBE55; Tue, 22 Jan 2013 23:28:48 +0000 (GMT) Message-ID: <50FF20A6.60503@cs.tcd.ie> Date: Tue, 22 Jan 2013 23:28:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Burleigh, Scott C (313B)" References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20121002225237.520325524@smtp.mail.me.com> <7249cc388d868cb16f14efe286351e37.squirrel@webmail.math.umd.edu> <20121004210719.1971171529@smtp.mail.me.com> <20121004220537.1202245607@smtp.mail.me.com> <20121016220658.793339059@smtp.mail.me.com> <20121022185905.200828573@smtp.mail.me.com> <20121022202820.71123343@smtp.mail.me.com> <50FF1C07.80708@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:29:17 -0000 Ah - why call it a -bis? Its just another approach. There's no need to OBSOLETE 6257, nor aim to at this point. If your proposal is so obviously better then maybe we'll want to do that but that's something to think about later. For now, I'd say shoot out the I-D and we can figure process things when that's ready to rock and roll. S. On 01/22/2013 11:22 PM, Burleigh, Scott C (313B) wrote: > Thanks, Stephen, and I completely agree that any 6257bis RFC should retain as much of 6257 as possible. People have invested in that RFC already, and I'm opposed to revising more deeply than would be needed to implement this proposal. > > Scott > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, January 22, 2013 3:09 PM > To: Burleigh, Scott C (313B) > Cc: dtn-security@irtf.org > Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations in DTN2 > > > Hi Scott, > > FWIW, I also think the BSP ended up a bit of a rat's nest. However I think that's because security was as usual an afterthought so I'm not sure this proposal will really work out simpler. However, I have no objection at all to it being tried, so I'd say fire away and write it up in a draft. > > Only thing I'd recommend would be to try keep things common with the BSP RFCs to the extent possible so that the code we have now can be re-used if someone wants to do this new scheme or both schemes. > > I'd be happy to comment on a proposal to the extent that time permits. > > Cheers, > S. > > On 01/22/2013 10:37 PM, Burleigh, Scott C (313B) wrote: >> Hi. Late last September, several of us spun off a sub-thread talking about how the processing of bundles with multiple security destinations could be handled in DTN implementations. I won't try to recreate all of the arguments on all sides, but I think we did converge on agreement that the current BSP mechanism for complex, multi-destination security could be difficult to realize in coherent fashion across the network. After puzzling over this for a while, I came up with a concept (below) that I think would be simpler, safer, and even more powerful than the current protocol design. How do we all feel about this? Would it be worthwhile for DTNRG to invest in a 6257bis RFC along these lines? >> >> Scott >> _____________________________________________ >> From: Burleigh, Scott C (313B) >> Sent: Friday, November 16, 2012 5:05 PM >> To: 'Peter Lovell'; ahennes1@math.umd.edu >> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations >> in DTN2 >> >> >> Hi, Peter. At the risk (I know) of getting a lot of people severely ticked off at me, I am going to offer a modest proposal for improving the Bundle Security Protocol, inspired by this thread. >> I propose to adopt a new design principle for Bundle Security Protocol: the routing element of a bundle protocol agent should never need to inspect a bundle's BSP extension blocks in order to select the node(s) to forward the bundle to. >> That is, BSP should provide security, not dictate routes. >> My rationale for proposing this principle is that I believe it would: >> * Simplify BSP, thereby reducing the incidence of bugs and making Bundle Security significantly less expensive to implement and sustain. >> * Broaden the scope of BSP deployment by eliminating its dependence on specific, BSP-aware routing implementations, thereby increasing the overall security of DTN. >> * Reduce the cost of developing and improving routing implementations by removing any requirement that they be BSP-aware, and broaden the scope of deployment of non-BSP-aware routing implementations by enabling them to be used in environments requiring arbitrarily powerful security. Thereby, improve DTN operational performance. >> Here's how I would apply this principle: >> 1. Eliminate security sources and security destinations from all BSP blocks. The security source of a BSP block would always be the bundle's source. The security destination of a BSP block would always be the bundle's destination. >> 2. Add a new Administrative Record type for Bundle-in-Bundle encapsulation. >> 3. When additional security must be applied to a bundle on some segment of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Encapsulation Administrative Record that is the payload of a new bundle whose source is the security source of the path segment and whose destination is the security destination of the path segment. Apply the additional bundle transmission security measures to the encapsulating bundle: encrypt its payload (the Administrative Record, containing the encapsulated bundle), encrypt extension blocks as copied from the encapsulated bundle, etc. Then forward the encapsulating bundle. >> 4. When route service uncertainty forces a bundle to be routed over multiple parallel additionally secured segments of its end-to-end path, encapsulate it as above but within multiple different encapsulating bundles, one for each of the parallel segments, and forward all of them. >> 5. At the destination of a bundle, apply all relevant bundle reception security measures and then, if the payload is an encapsulation Administrative Record, extract the encapsulated bundle from the Administrative Record and simply forward it. >> I believe this would have the following impacts on DTN security: >> * No EID references in BSP, simplifying canonicalization. >> * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the encapsulated bundle encrypts all three at once), so no correlators in BSP. (Except for BABs, no bundle ever has more than one occurrence of any type of BSP block. And there will never be more than two BABs, one immediately following the primary block and one that is the final block in the bundle, so that correlation is structural.) >> * No delicate "replacement" process for unraveling PCB nesting at the destination. >> * No possible confusion about the correct order of application of BSP blocks. >> * No possible conflict among security destinations of different BSP blocks. >> * Security paths can never overlap. >> * Any routing implementation can always accommodate any security regime: routes that must be followed to ensure security are encoded into routing information at the forwarding node, not into the bundle. (A little like the late binding principle.) > >> * Any routing environment can always be made arbitrarily secure - no need to require specially BSP-aware routing elements. >> * Ciphersuite design is simplified, so a wider array of useful ciphersuites can be developed without imposing bug-prone complexity. Minimizes possible security problems. >> >> As an example of how I think this could work, see the attached diagram: >> 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are within the low-risk "W" security region; nodes C and G are gateways between region W and the more hazardous region X; node D is another node in X; nodes E and F are gateways between region X and even more hazardous region Y; nodes H and I are gateways between X and hazardous region Z. >> 2. At A the bundle is simply forwarded to B. >> 3. At B the routing element realizes that the bundle has to traverse region X in order to get to K, so it forwards the bundle to C. >> 4. The routing element at C encapsulates the bundle in an Admin Record, creates a new bundle destined for G (the egress from region X) whose source is C and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the bundle to D. >> 5. D realizes that the bundle has to traverse region Y in order to get to G, so it forwards the bundle to E. >> 6. E encapsulates the bundle in an Admin Record, creates a new bundle destined for F (the egress from region Y) whose source is E and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the bundle to F. >> 7. The bundle protocol agent at F receives the bundle, decrypts it, and passes the payload (an Admin Record) to the application agent. The administrative element of the application agent at F receives the Admin Record, extracts the encapsulated bundle destined for G, and queues it to be forwarded. The routing element at F sees this bundle and forwards it to G. >> 8. The bundle protocol agent at G receives the bundle, decrypts it, and passes the payload (an Admin Record) to the application agent. The administrative element of the application agent at G receives the Admin Record, extracts the encapsulated bundle destined for K, and queues it to be forwarded. The routing element at G sees this bundle, realizes that the bundle has to traverse region Z in order to get to K, and therefore forwards the bundle to H. >> 9. H encapsulates the bundle in an Admin Record, creates a new bundle destined for I (the egress from region Z) whose source is H and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the bundle to I. >> 10. The bundle protocol agent at I receives the bundle, decrypts it, and passes the payload (an Admin Record) to the application agent. The administrative element of the application agent at I receives the Admin Record, extracts the encapsulated bundle destined for K, and queues it to be forwarded. The routing element at I sees this bundle and forwards it to J. >> 11. At J the bundle is simply forwarded to K. >> 12. At K the bundle's payload is passed to the application. >> I think this approach would combine simplicity with quite a lot of operational power, making everything cheaper and safer. >> So, having now stirred the hornet's nest, I will beat a hasty retreat for a week while I am on vacation. I'll try to follow up when I get back. >> Have a nice Thanksgiving, everybody. >> Scott >> >> -----Original Message----- >> From: Peter Lovell [mailto:plovell@mac.com] >> Sent: Monday, October 22, 2012 1:28 PM >> To: Burleigh, Scott C (313B); >> ahennes1@math.umd.edu >> Cc: Amy Alford; >> Cherita.Corbett@jhuapl.edu; Howard >> Weiss; Peter Lovell >> Subject: Re(19): [dtn-security] Implementing Security Destinations in >> DTN2 >> >> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: >> >>> In view of which, I've now become a bigger fan of bundle-in-bundle >>> tunneling than I've been in the past. >> >> Hi Scott, >> >> I agree. I'm also a big fan, for a bunch of reasons. However, as I mentioned to Angela, the current [i.e. latest, expired] draft seems a bit "funky" to me. There's no indication in the bundle that it's BiB and you need some special EID to perform the decapsulation. Maybe that's just like an assigned port in TCP but we don't yet have such a mechanism. The multiple-bundle thing is OK, I guess, but I don't see much use for it other than volume gateway-to-gateway traffic and I think that such heavy-duty tunnels could be specially optimized. >> >> I need to go back and review all the discussions about BiB -- we worked it quite a bit but the spec never gained enough consensus to move forward. I think it would be a good idea to revisit it now and get a solid draft that has wider support. Maybe the email discussions will help us get there. >> >> Thanks.....Peter >> >> >> >> >> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security >> > > From scott.c.burleigh@jpl.nasa.gov Tue Jan 22 15:35:46 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B953621F87DC for ; Tue, 22 Jan 2013 15:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9c-sF07sOFg for ; Tue, 22 Jan 2013 15:35:38 -0800 (PST) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id DE25021F86CC for ; Tue, 22 Jan 2013 15:35:37 -0800 (PST) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0MNZaMw001697 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 22 Jan 2013 15:35:37 -0800 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.60]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.88]) with mapi id 14.02.0318.001; Tue, 22 Jan 2013 15:35:36 -0800 From: "Burleigh, Scott C (313B)" To: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" , "dtn-security@irtf.org" Thread-Topic: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 Thread-Index: AQHN+PenH0ya9RV+Q02UlP2uaZf/xphV/v4w Date: Tue, 22 Jan 2013 23:35:35 +0000 Message-ID: References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com><6af37e4869b76826d4d2108e3eef82b3.squirrel @webmail.math.umd.edu><20120923012212.319238544@smtp.mail.me.com><3c1f477d9 f6b104790e33e76236998e6.squirrel@webmail.math.umd.edu><20120926214742.2066794613@smtp. mail.me.com><20120927170104.253362480@smtp.mail.me.com><20120927172602.1763958833@smtp.mail.m e.com><20121002225237.520325524@smtp.mail.me.com><7249cc388d868cb16f14efe286351e37.squ irrel@webmail.math.umd.edu><20121004210719.1971171529@smtp.mail.me.com><20121004220537.1202245607 @smtp.mail.me.com><20121016220658.793339059@smtp.mail.me.com><20121022185905.200828573@smtp.mai l.me.com> <20121022202820.71123343@smtp.mail.me.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B2356FAD8apembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:35:46 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B2356FAD8apembxsp40RESAD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wes, I agree that some code change would be entailed in implementing this p= roposal, but I think a large proportion of the code - the general flow of p= rocessing the extension blocks, the canonicalization, the ciphersuites, rea= lly almost everything that would have been implemented to handle the simple= case of security source/destination being identical to bundle source/desti= nation - would be preserved. I suspect that much of what I was proposing h= ere involves removing functionality that most developers haven't implemente= d yet anyway, because of the potential pitfalls. Scott From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy@n= asa.gov] Sent: Tuesday, January 22, 2013 3:20 PM To: Burleigh, Scott C (313B); dtn-security@irtf.org Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 It looks like basically a good idea to me. I recall sometime in 2006 or 2007ish pointing out that security destination= s needed to work more like IPsec tunnel-mode endpoints in order to make the= routing work correctly, and I think what you're proposing here accomplishe= s that in a better way. Though I think cycles would be better spent on KMP issues that are actually= HARD, and *then* circling back to see what could be tweaked in the BSP, I = definitely think this proposed change is something that would improve the B= SP a bit in the meantime. I don't think it can be done in a way that's friendly to the existing codeb= ase like Stephen suggests shooting for. ________________________________ From: dtn-security-bounces@irtf.org [= dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B) [scott= .c.burleigh@jpl.nasa.gov] Sent: Tuesday, January 22, 2013 5:37 PM To: dtn-security@irtf.org Subject: [dtn-security] FW: Re(19): Implementing Security Destinations inDT= N2 Hi. Late last September, several of us spun off a sub-thread talking about= how the processing of bundles with multiple security destinations could be= handled in DTN implementations. I won't try to recreate all of the argume= nts on all sides, but I think we did converge on agreement that the current= BSP mechanism for complex, multi-destination security could be difficult t= o realize in coherent fashion across the network. After puzzling over this= for a while, I came up with a concept (below) that I think would be simple= r, safer, and even more powerful than the current protocol design. How do = we all feel about this? Would it be worthwhile for DTNRG to invest in a 62= 57bis RFC along these lines? Scott _____________________________________________ From: Burleigh, Scott C (313B) Sent: Friday, November 16, 2012 5:05 PM To: 'Peter Lovell'; ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in D= TN2 Hi, Peter. At the risk (I know) of getting a lot of people severely ticked= off at me, I am going to offer a modest proposal for improving the Bundle = Security Protocol, inspired by this thread. I propose to adopt a new design principle for Bundle Security Protocol: the= routing element of a bundle protocol agent should never need to inspect a = bundle's BSP extension blocks in order to select the node(s) to forward the= bundle to. That is, BSP should provide security, not dictate routes. My rationale for proposing this principle is that I believe it would: * Simplify BSP, thereby reducing the incidence of bugs and making B= undle Security significantly less expensive to implement and sustain. * Broaden the scope of BSP deployment by eliminating its dependence= on specific, BSP-aware routing implementations, thereby increasing the ove= rall security of DTN. * Reduce the cost of developing and improving routing implementatio= ns by removing any requirement that they be BSP-aware, and broaden the scop= e of deployment of non-BSP-aware routing implementations by enabling them t= o be used in environments requiring arbitrarily powerful security. Thereby= , improve DTN operational performance. Here's how I would apply this principle: 1. Eliminate security sources and security destinations from all BSP = blocks. The security source of a BSP block would always be the bundle's so= urce. The security destination of a BSP block would always be the bundle's= destination. 2. Add a new Administrative Record type for Bundle-in-Bundle encapsul= ation. 3. When additional security must be applied to a bundle on some segme= nt of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Enc= apsulation Administrative Record that is the payload of a new bundle whose = source is the security source of the path segment and whose destination is = the security destination of the path segment. Apply the additional bundle = transmission security measures to the encapsulating bundle: encrypt its pay= load (the Administrative Record, containing the encapsulated bundle), encry= pt extension blocks as copied from the encapsulated bundle, etc. Then forw= ard the encapsulating bundle. 4. When route service uncertainty forces a bundle to be routed over m= ultiple parallel additionally secured segments of its end-to-end path, enca= psulate it as above but within multiple different encapsulating bundles, on= e for each of the parallel segments, and forward all of them. 5. At the destination of a bundle, apply all relevant bundle receptio= n security measures and then, if the payload is an encapsulation Administra= tive Record, extract the encapsulated bundle from the Administrative Record= and simply forward it. I believe this would have the following impacts on DTN security: * No EID references in BSP, simplifying canonicalization. * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the en= capsulated bundle encrypts all three at once), so no correlators in BSP. (= Except for BABs, no bundle ever has more than one occurrence of any type of= BSP block. And there will never be more than two BABs, one immediately fo= llowing the primary block and one that is the final block in the bundle, so= that correlation is structural.) * No delicate "replacement" process for unraveling PCB nesting at t= he destination. * No possible confusion about the correct order of application of B= SP blocks. * No possible conflict among security destinations of different BSP= blocks. * Security paths can never overlap. * Any routing implementation can always accommodate any security re= gime: routes that must be followed to ensure security are encoded into rout= ing information at the forwarding node, not into the bundle. (A little lik= e the late binding principle.) * Any routing environment can always be made arbitrarily secure - n= o need to require specially BSP-aware routing elements. * Ciphersuite design is simplified, so a wider array of useful ciph= ersuites can be developed without imposing bug-prone complexity. Minimizes= possible security problems. As an example of how I think this could work, see the attached diagram: 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are wi= thin the low-risk "W" security region; nodes C and G are gateways between r= egion W and the more hazardous region X; node D is another node in X; nodes= E and F are gateways between region X and even more hazardous region Y; no= des H and I are gateways between X and hazardous region Z. 2. At A the bundle is simply forwarded to B. 3. At B the routing element realizes that the bundle has to traverse = region X in order to get to K, so it forwards the bundle to C. 4. The routing element at C encapsulates the bundle in an Admin Recor= d, creates a new bundle destined for G (the egress from region X) whose sou= rce is C and whose payload is that Admin Record, encrypts the payload, atta= ches a PCB, and forwards the bundle to D. 5. D realizes that the bundle has to traverse region Y in order to ge= t to G, so it forwards the bundle to E. 6. E encapsulates the bundle in an Admin Record, creates a new bundle= destined for F (the egress from region Y) whose source is E and whose payl= oad is that Admin Record, encrypts the payload, attaches a PCB, and forward= s the bundle to F. 7. The bundle protocol agent at F receives the bundle, decrypts it, a= nd passes the payload (an Admin Record) to the application agent. The admi= nistrative element of the application agent at F receives the Admin Record,= extracts the encapsulated bundle destined for G, and queues it to be forwa= rded. The routing element at F sees this bundle and forwards it to G. 8. The bundle protocol agent at G receives the bundle, decrypts it, a= nd passes the payload (an Admin Record) to the application agent. The admi= nistrative element of the application agent at G receives the Admin Record,= extracts the encapsulated bundle destined for K, and queues it to be forwa= rded. The routing element at G sees this bundle, realizes that the bundle = has to traverse region Z in order to get to K, and therefore forwards the b= undle to H. 9. H encapsulates the bundle in an Admin Record, creates a new bundle= destined for I (the egress from region Z) whose source is H and whose payl= oad is that Admin Record, encrypts the payload, attaches a PCB, and forward= s the bundle to I. 10. The bundle protocol agent at I receives the bundle, decrypts it, and = passes the payload (an Admin Record) to the application agent. The adminis= trative element of the application agent at I receives the Admin Record, ex= tracts the encapsulated bundle destined for K, and queues it to be forwarde= d. The routing element at I sees this bundle and forwards it to J. 11. At J the bundle is simply forwarded to K. 12. At K the bundle's payload is passed to the application. I think this approach would combine simplicity with quite a lot of operatio= nal power, making everything cheaper and safer. So, having now stirred the hornet's nest, I will beat a hasty retreat for a= week while I am on vacation. I'll try to follow up when I get back. Have a nice Thanksgiving, everybody. Scott -----Original Message----- From: Peter Lovell [mailto:plovell@mac.com] Sent: Monday, October 22, 2012 1:28 PM To: Burleigh, Scott C (313B); ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2 On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: > In view of which, I've now become a bigger fan of bundle-in-bundle >tunneling than I've been in the past. Hi Scott, I agree. I'm also a big fan, for a bunch of reasons. However, as I mentione= d to Angela, the current [i.e. latest, expired] draft seems a bit "funky" t= o me. There's no indication in the bundle that it's BiB and you need some s= pecial EID to perform the decapsulation. Maybe that's just like an assigned= port in TCP but we don't yet have such a mechanism. The multiple-bundle th= ing is OK, I guess, but I don't see much use for it other than volume gatew= ay-to-gateway traffic and I think that such heavy-duty tunnels could be spe= cially optimized. I need to go back and review all the discussions about BiB -- we worked it = quite a bit but the spec never gained enough consensus to move forward. I t= hink it would be a good idea to revisit it now and get a solid draft that h= as wider support. Maybe the email discussions will help us get there. Thanks.....Peter --_000_A5BEAD028815CB40A32A5669CF737C3B2356FAD8apembxsp40RESAD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wes, I agree that some co= de change would be entailed in implementing this proposal, but I think a la= rge proportion of the code – the general flow of processing the extension blocks, the canonicalization, the ciphersuites, really almos= t everything that would have been implemented to handle the simple case of = security source/destination being identical to bundle source/destination &#= 8211; would be preserved.  I suspect that much of what I was proposing here involves removing functionality that mos= t developers haven’t implemented yet anyway, because of the potential= pitfalls.

 <= /p>

Scott

 <= /p>

From: Eddy, We= sley M. (GRC-MS00)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy@nasa.gov]
Sent: Tuesday, January 22, 2013 3:20 PM
To: Burleigh, Scott C (313B); dtn-security@irtf.org
Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destin= ations inDTN2

 

It looks like basically a goo= d idea to me.

 

I recall sometime in 2006 or = 2007ish pointing out that security destinations needed to work more like IP= sec tunnel-mode endpoints in order to make the routing work correctly, and I think what you're proposing here accomplishes that in a b= etter way.

 

Though I think cycles would b= e better spent on KMP issues that are actually HARD, and *then* circling ba= ck to see what could be tweaked in the BSP, I definitely think this proposed change is something that would improve = the BSP a bit in the meantime.

 

I don't think it can be done = in a way that's friendly to the existing codebase like Stephen suggests sho= oting for.

 

From: dtn-security-bounces@irtf.= org [dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313= B) [scott.c.burleigh@jpl.nasa.gov]
Sent: Tuesday, January 22, 2013 5:37 PM
To: dtn-security@irtf.org
Subject: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns inDTN2

Hi.  Late last Septe= mber, several of us spun off a sub-thread talking about how the processing = of bundles with multiple security destinations could be handled in DTN implementations.  I won’t try to recreate all of the arg= uments on all sides, but I think we did converge on agreement that the curr= ent BSP mechanism for complex, multi-destination security could be difficul= t to realize in coherent fashion across the network.  After puzzling over this for a while, I came up with a conc= ept (below) that I think would be simpler, safer, and even more powerful th= an the current protocol design.  How do we all feel about this?  = Would it be worthwhile for DTNRG to invest in a 6257bis RFC along these lines?<= /span>

 

Scott

 

 

Hi, Peter.  At the ris= k (I know) of getting a lot of people severely ticked off at me, I am going= to offer a modest proposal for improving the Bundle Security Protocol, inspired by this thread.

I propose to adopt a new de= sign principle for Bundle Security Protocol: the routing element of a bundl= e protocol agent should never need to inspect a bundle’s BSP extension blocks in order to select the node(s) to forward the bundle = to.

That is, BSP should provide security, not dictate routes.

My rationale for proposing = this principle is that I believe it would:

·       &nb= sp; Simplify BSP, there= by reducing the incidence of bugs and making Bundle Security significantly = less expensive to implement and sustain.

·       &nb= sp; Broaden the scope o= f BSP deployment by eliminating its dependence on specific, BSP-aware routi= ng implementations, thereby increasing the overall security of DTN.

·       &nb= sp; Reduce the cost of = developing and improving routing implementations by removing any requiremen= t that they be BSP-aware, and broaden the scope of deployment of non-BSP-aware routing implementations by enabling them to be used in en= vironments requiring arbitrarily powerful security.  Thereby, improve = DTN operational performance.

Here's how I would apply th= is principle:

1.  &nb= sp;    Eliminate security = sources and security destinations from all BSP blocks.  The security s= ource of a BSP block would always be the bundle’s source.  The security destination of a BSP block would always be the bundle’s= destination.

2.  &nb= sp;    Add a new Administr= ative Record type for Bundle-in-Bundle encapsulation.

3.  &nb= sp;    When additional sec= urity must be applied to a bundle on some segment of its end-to-end path, e= ncapsulate the bundle in a Bundle-in-Bundle Encapsulation Administrative Record that is the payload of a new bundle whose source is = the security source of the path segment and whose destination is the securi= ty destination of the path segment.  Apply the additional bundle trans= mission security measures to the encapsulating bundle: encrypt its payload (the Administrative Record, containing the enc= apsulated bundle), encrypt extension blocks as copied from the encapsulated= bundle, etc.  Then forward the encapsulating bundle.

4.  &nb= sp;    When route service = uncertainty forces a bundle to be routed over multiple parallel additionall= y secured segments of its end-to-end path, encapsulate it as above but within multiple different encapsulating bundles, one for e= ach of the parallel segments, and forward all of them.

5.  &nb= sp;    At the destination = of a bundle, apply all relevant bundle reception security measures and then= , if the payload is an encapsulation Administrative Record, extract the encapsulated bundle from the Administrative Record and simply = forward it.

I believe this would have t= he following impacts on DTN security:

·       &nb= sp; No EID references i= n BSP, simplifying canonicalization.

·       &nb= sp; PCBs only encrypt p= ayloads, never PIBs or PCBs (encrypting the encapsulated bundle encrypts al= l three at once), so no correlators in BSP.  (Except for BABs, no bundle ever has more than one occurrence of any type of BSP block= .  And there will never be more than two BABs, one immediately followi= ng the primary block and one that is the final block in the bundle, so that= correlation is structural.)

·       &nb= sp; No delicate “= replacement” process for unraveling PCB nesting at the destination.

·       &nb= sp; No possible confusi= on about the correct order of application of BSP blocks.

·       &nb= sp; No possible conflic= t among security destinations of different BSP blocks.

·       &nb= sp; Security paths can = never overlap.

·       &nb= sp; Any routing impleme= ntation can always accommodate any security regime: routes that must be fol= lowed to ensure security are encoded into routing information at the forwarding node, not into the bundle.  (A little like the late= binding principle.)

·       &nb= sp; Any routing environ= ment can always be made arbitrarily secure – no need to require speci= ally BSP-aware routing elements.

·       &nb= sp; Ciphersuite design = is simplified, so a wider array of useful ciphersuites can be developed wit= hout imposing bug-prone complexity.  Minimizes possible security problems.

As an example of how I thin= k this could work, see the attached diagram:

1.  &nb= sp;    Node A is sending a= bundle to node K.  Nodes A, B, J, and K are within the low-risk ̶= 0;W” security region; nodes C and G are gateways between region W and the more hazardous region X; node D is another node in X; nodes E and = F are gateways between region X and even more hazardous region Y; nodes H a= nd I are gateways between X and hazardous region Z.

2.  &nb= sp;    At A the bundle is = simply forwarded to B.

3.  &nb= sp;    At B the routing el= ement realizes that the bundle has to traverse region X in order to get to = K, so it forwards the bundle to C.

4.  &nb= sp;    The routing element= at C encapsulates the bundle in an Admin Record, creates a new bundle dest= ined for G (the egress from region X) whose source is C and whose payload is that Admin Record, encrypts the payload, attaches a= PCB, and forwards the bundle to D.

5.  &nb= sp;    D realizes that the= bundle has to traverse region Y in order to get to G, so it forwards the b= undle to E.

6.  &nb= sp;    E encapsulates the = bundle in an Admin Record, creates a new bundle destined for F (the egress = from region Y) whose source is E and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the = bundle to F.

7.  &nb= sp;    The bundle protocol= agent at F receives the bundle, decrypts it, and passes the payload (an Ad= min Record) to the application agent.  The administrative element of the application agent at F receives the Admin Record, extracts = the encapsulated bundle destined for G, and queues it to be forwarded. = ; The routing element at F sees this bundle and forwards it to G.

8.  &nb= sp;    The bundle protocol= agent at G receives the bundle, decrypts it, and passes the payload (an Ad= min Record) to the application agent.  The administrative element of the application agent at G receives the Admin Record, extracts = the encapsulated bundle destined for K, and queues it to be forwarded. = ; The routing element at G sees this bundle, realizes that the bundle has t= o traverse region Z in order to get to K, and therefore forwards the bundle to H.

9.  &nb= sp;    H encapsulates the = bundle in an Admin Record, creates a new bundle destined for I (the egress = from region Z) whose source is H and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the = bundle to I.

10.   The bundle protocol= agent at I receives the bundle, decrypts it, and passes the payload (an Ad= min Record) to the application agent.  The administrative element of the application agent at I receives the Admin Record, extracts = the encapsulated bundle destined for K, and queues it to be forwarded. = ; The routing element at I sees this bundle and forwards it to J.

11.   At J the bundle is = simply forwarded to K.

12.   At K the bundleR= 17;s payload is passed to the application.

I think this approach would= combine simplicity with quite a lot of operational power, making everythin= g cheaper and safer.

So, having now stirred the = hornet’s nest, I will beat a hasty retreat for a week while I am on v= acation.  I’ll try to follow up when I get back.

Have a nice Thanksgiving, e= verybody.

Scott

 

-----Original Message-----<= br> From: Peter Lovell [mailto:plovell@mac.c= om]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); ahen= nes1@math.umd.edu
Cc: Amy Alford; Cherita.Corbe= tt@jhuapl.edu; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2<= o:p>

 

On Wed, Oct 24, 2012, Burle= igh, Scott C (313B) <sc= ott.c.burleigh@jpl.nasa.gov> wrote:

 

> In view of which, I've= now become a bigger fan of bundle-in-bundle

>tunneling than I've bee= n in the past.

 

Hi Scott,=

 

I agree. I'm also a big fan= , for a bunch of reasons. However, as I mentioned to Angela, the current [i= .e. latest, expired] draft seems a bit "funky" to me. There's no indication in the bundle that it's BiB and you need some special EID to= perform the decapsulation. Maybe that's just like an assigned port in TCP = but we don't yet have such a mechanism. The multiple-bundle thing is OK, I = guess, but I don't see much use for it other than volume gateway-to-gateway traffic and I think that such = heavy-duty tunnels could be specially optimized.

 

I need to go back and revie= w all the discussions about BiB -- we worked it quite a bit but the spec ne= ver gained enough consensus to move forward. I think it would be a good idea to revisit it now and get a solid draft that has wide= r support. Maybe the email discussions will help us get there.

 

Thanks.....Peter=

 

 

--_000_A5BEAD028815CB40A32A5669CF737C3B2356FAD8apembxsp40RESAD_-- From wesley.m.eddy@nasa.gov Tue Jan 22 15:24:43 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8431921F8ACE for ; Tue, 22 Jan 2013 15:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcjADto4gRo6 for ; Tue, 22 Jan 2013 15:24:41 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 828A421F86EF for ; Tue, 22 Jan 2013 15:24:40 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 13A1E2D8335; Tue, 22 Jan 2013 17:24:38 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r0MNObP2002161; Tue, 22 Jan 2013 17:24:37 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 22 Jan 2013 17:24:37 -0600 From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" To: "Burleigh, Scott C" , "dtn-security@irtf.org" Date: Tue, 22 Jan 2013 17:19:48 -0600 Thread-Topic: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 Thread-Index: AQHNsJPIZoDaDqH290yQ8PpLOF/skJftUzPAgGkpYDCAABA3hA== Message-ID: References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com><6af37e4869b76826d4d2108e3eef82b3.squirrel @webmail.math.umd.edu><20120923012212.319238544@smtp.mail.me.com><3c1f477d9 f6b104790e33e76236998e6.squirrel@webmail.math.umd.edu><20120926214742.2066794613@smtp. mail.me.com><20120927170104.253362480@smtp.mail.me.com><20120927172602.1763958833@smtp.mail.m e.com><20121002225237.520325524@smtp.mail.me.com><7249cc388d868cb16f14efe286351e37.squ irrel@webmail.math.umd.edu><20121004210719.1971171529@smtp.mail.me.com><20121004220537.1202245607 @smtp.mail.me.com><20121016220658.793339059@smtp.mail.me.com><20121022185905.200828573@smtp.mai l.me.com> <20121022202820.71123343@smtp.mail.me.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C304DB494AC0C04C87C6A6E2FF5603DB011416DB6897NDJSSCC01nd_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-22_10:2013-01-22, 2013-01-22, 1970-01-01 signatures=0 X-Mailman-Approved-At: Tue, 22 Jan 2013 15:49:22 -0800 Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:24:43 -0000 --_000_C304DB494AC0C04C87C6A6E2FF5603DB011416DB6897NDJSSCC01nd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It looks like basically a good idea to me. I recall sometime in 2006 or 2007ish pointing out that security destination= s needed to work more like IPsec tunnel-mode endpoints in order to make the= routing work correctly, and I think what you're proposing here accomplishe= s that in a better way. Though I think cycles would be better spent on KMP issues that are actually= HARD, and *then* circling back to see what could be tweaked in the BSP, I = definitely think this proposed change is something that would improve the B= SP a bit in the meantime. I don't think it can be done in a way that's friendly to the existing codeb= ase like Stephen suggests shooting for. ________________________________ From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On Beha= lf Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] Sent: Tuesday, January 22, 2013 5:37 PM To: dtn-security@irtf.org Subject: [dtn-security] FW: Re(19): Implementing Security Destinations inDT= N2 Hi. Late last September, several of us spun off a sub-thread talking about= how the processing of bundles with multiple security destinations could be= handled in DTN implementations. I won=92t try to recreate all of the argu= ments on all sides, but I think we did converge on agreement that the curre= nt BSP mechanism for complex, multi-destination security could be difficult= to realize in coherent fashion across the network. After puzzling over th= is for a while, I came up with a concept (below) that I think would be simp= ler, safer, and even more powerful than the current protocol design. How d= o we all feel about this? Would it be worthwhile for DTNRG to invest in a = 6257bis RFC along these lines? Scott _____________________________________________ From: Burleigh, Scott C (313B) Sent: Friday, November 16, 2012 5:05 PM To: 'Peter Lovell'; ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in D= TN2 Hi, Peter. At the risk (I know) of getting a lot of people severely ticked= off at me, I am going to offer a modest proposal for improving the Bundle = Security Protocol, inspired by this thread. I propose to adopt a new design principle for Bundle Security Protocol: the= routing element of a bundle protocol agent should never need to inspect a = bundle=92s BSP extension blocks in order to select the node(s) to forward t= he bundle to. That is, BSP should provide security, not dictate routes. My rationale for proposing this principle is that I believe it would: * Simplify BSP, thereby reducing the incidence of bugs and making Bundle= Security significantly less expensive to implement and sustain. * Broaden the scope of BSP deployment by eliminating its dependence on s= pecific, BSP-aware routing implementations, thereby increasing the overall = security of DTN. * Reduce the cost of developing and improving routing implementations by= removing any requirement that they be BSP-aware, and broaden the scope of = deployment of non-BSP-aware routing implementations by enabling them to be = used in environments requiring arbitrarily powerful security. Thereby, imp= rove DTN operational performance. Here's how I would apply this principle: 1. Eliminate security sources and security destinations from all BSP bloc= ks. The security source of a BSP block would always be the bundle=92s sour= ce. The security destination of a BSP block would always be the bundle=92s= destination. 2. Add a new Administrative Record type for Bundle-in-Bundle encapsulatio= n. 3. When additional security must be applied to a bundle on some segment o= f its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Encapsu= lation Administrative Record that is the payload of a new bundle whose sour= ce is the security source of the path segment and whose destination is the = security destination of the path segment. Apply the additional bundle tran= smission security measures to the encapsulating bundle: encrypt its payload= (the Administrative Record, containing the encapsulated bundle), encrypt e= xtension blocks as copied from the encapsulated bundle, etc. Then forward = the encapsulating bundle. 4. When route service uncertainty forces a bundle to be routed over multi= ple parallel additionally secured segments of its end-to-end path, encapsul= ate it as above but within multiple different encapsulating bundles, one fo= r each of the parallel segments, and forward all of them. 5. At the destination of a bundle, apply all relevant bundle reception se= curity measures and then, if the payload is an encapsulation Administrative= Record, extract the encapsulated bundle from the Administrative Record and= simply forward it. I believe this would have the following impacts on DTN security: * No EID references in BSP, simplifying canonicalization. * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the encapsu= lated bundle encrypts all three at once), so no correlators in BSP. (Excep= t for BABs, no bundle ever has more than one occurrence of any type of BSP = block. And there will never be more than two BABs, one immediately followi= ng the primary block and one that is the final block in the bundle, so that= correlation is structural.) * No delicate =93replacement=94 process for unraveling PCB nesting at th= e destination. * No possible confusion about the correct order of application of BSP bl= ocks. * No possible conflict among security destinations of different BSP bloc= ks. * Security paths can never overlap. * Any routing implementation can always accommodate any security regime:= routes that must be followed to ensure security are encoded into routing i= nformation at the forwarding node, not into the bundle. (A little like the= late binding principle.) * Any routing environment can always be made arbitrarily secure =96 no n= eed to require specially BSP-aware routing elements. * Ciphersuite design is simplified, so a wider array of useful ciphersui= tes can be developed without imposing bug-prone complexity. Minimizes poss= ible security problems. As an example of how I think this could work, see the attached diagram: 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are within= the low-risk =93W=94 security region; nodes C and G are gateways between r= egion W and the more hazardous region X; node D is another node in X; nodes= E and F are gateways between region X and even more hazardous region Y; no= des H and I are gateways between X and hazardous region Z. 2. At A the bundle is simply forwarded to B. 3. At B the routing element realizes that the bundle has to traverse regi= on X in order to get to K, so it forwards the bundle to C. 4. The routing element at C encapsulates the bundle in an Admin Record, c= reates a new bundle destined for G (the egress from region X) whose source = is C and whose payload is that Admin Record, encrypts the payload, attaches= a PCB, and forwards the bundle to D. 5. D realizes that the bundle has to traverse region Y in order to get to= G, so it forwards the bundle to E. 6. E encapsulates the bundle in an Admin Record, creates a new bundle des= tined for F (the egress from region Y) whose source is E and whose payload = is that Admin Record, encrypts the payload, attaches a PCB, and forwards th= e bundle to F. 7. The bundle protocol agent at F receives the bundle, decrypts it, and p= asses the payload (an Admin Record) to the application agent. The administ= rative element of the application agent at F receives the Admin Record, ext= racts the encapsulated bundle destined for G, and queues it to be forwarded= . The routing element at F sees this bundle and forwards it to G. 8. The bundle protocol agent at G receives the bundle, decrypts it, and p= asses the payload (an Admin Record) to the application agent. The administ= rative element of the application agent at G receives the Admin Record, ext= racts the encapsulated bundle destined for K, and queues it to be forwarded= . The routing element at G sees this bundle, realizes that the bundle has = to traverse region Z in order to get to K, and therefore forwards the bundl= e to H. 9. H encapsulates the bundle in an Admin Record, creates a new bundle des= tined for I (the egress from region Z) whose source is H and whose payload = is that Admin Record, encrypts the payload, attaches a PCB, and forwards th= e bundle to I. 10. The bundle protocol agent at I receives the bundle, decrypts it, and p= asses the payload (an Admin Record) to the application agent. The administ= rative element of the application agent at I receives the Admin Record, ext= racts the encapsulated bundle destined for K, and queues it to be forwarded= . The routing element at I sees this bundle and forwards it to J. 11. At J the bundle is simply forwarded to K. 12. At K the bundle=92s payload is passed to the application. I think this approach would combine simplicity with quite a lot of operatio= nal power, making everything cheaper and safer. So, having now stirred the hornet=92s nest, I will beat a hasty retreat for= a week while I am on vacation. I=92ll try to follow up when I get back. Have a nice Thanksgiving, everybody. Scott -----Original Message----- From: Peter Lovell [mailto:plovell@mac.com] Sent: Monday, October 22, 2012 1:28 PM To: Burleigh, Scott C (313B); ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2 On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: > In view of which, I've now become a bigger fan of bundle-in-bundle >tunneling than I've been in the past. Hi Scott, I agree. I'm also a big fan, for a bunch of reasons. However, as I mentione= d to Angela, the current [i.e. latest, expired] draft seems a bit "funky" t= o me. There's no indication in the bundle that it's BiB and you need some s= pecial EID to perform the decapsulation. Maybe that's just like an assigned= port in TCP but we don't yet have such a mechanism. The multiple-bundle th= ing is OK, I guess, but I don't see much use for it other than volume gatew= ay-to-gateway traffic and I think that such heavy-duty tunnels could be spe= cially optimized. I need to go back and review all the discussions about BiB -- we worked it = quite a bit but the spec never gained enough consensus to move forward. I t= hink it would be a good idea to revisit it now and get a solid draft that h= as wider support. Maybe the email discussions will help us get there. Thanks.....Peter --_000_C304DB494AC0C04C87C6A6E2FF5603DB011416DB6897NDJSSCC01nd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
It looks like basically a good idea to me.
 
I recall sometime in 2006 or 2007ish pointing out= that security destinations needed to work more like IPsec tunnel-mode endp= oints in order to make the routing work correctly, and I think what you're = proposing here accomplishes that in a better way.
 
Though I think cycles would be better spent on KM= P issues that are actually HARD, and *then* circling back to see what could= be tweaked in the BSP, I definitely think this proposed change&n= bsp;is something that would improve the BSP a bit in the meantime.
 
I don't think it can be done in a way that's frie= ndly to the existing codebase like Stephen suggests shooting for.
&= nbsp;
From: dtn-securit= y-bounces@irtf.org [dtn-security-bounces@irtf.org] On Behalf Of Burleigh, S= cott C (313B) [scott.c.burleigh@jpl.nasa.gov]
Sent: Tuesday, January 22, 2013 5:37 PM
To: dtn-security@irtf.org
Subject: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns inDTN2

Hi.  Late last September, several of us s= pun off a sub-thread talking about how the processing of bundles with multi= ple security destinations could be handled in DTN implementations.  I = won=92t try to recreate all of the arguments on all sides, but I think we did converge on agreement that the current BSP m= echanism for complex, multi-destination security could be difficult to real= ize in coherent fashion across the network.  After puzzling over this = for a while, I came up with a concept (below) that I think would be simpler, safer, and even more powerful than = the current protocol design.  How do we all feel about this?  Wou= ld it be worthwhile for DTNRG to invest in a 6257bis RFC along these lines?=
 
Scott
_____= ________________________________________
From: Burleigh, Scott C (313B)
Sent: Friday, November 16, 2012 5:05 PM
To: 'Peter Lovell'; ahennes1@math.umd.edu
Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss
Subject: RE: Re(19): [dtn-security] Implementing Security Destinatio= ns in DTN2
 
 
Hi, Peter.  At the risk (I know) of = getting a lot of people severely ticked off at me, I am going to offer a mo= dest proposal for improving the Bundle Security Protocol, inspired by this = thread.
I propose to adopt a new design principle= for Bundle Security Protocol: the routing element of a bundle protocol age= nt should never need to inspect a bundle=92s BSP extension blocks in order = to select the node(s) to forward the bundle to.
That is, BSP should provide security, = not dictate routes.
My rationale for proposing this principle= is that I believe it would:
  • Simplify BSP, thereby reducing the inciden= ce of bugs and making Bundle Security significantly less expensive to imple= ment and sustain.
  • Broaden the scope of BSP deployment b= y eliminating its dependence on specific, BSP-aware routing implementations= , thereby increasing the overall security of DTN.
  • Reduce the cost of developing and imp= roving routing implementations by removing any requirement that they be BSP= -aware, and broaden the scope of deployment of non-BSP-aware routing implem= entations by enabling them to be used in environments requiring arbitrarily powerful security.  Thereby, impro= ve DTN operational performance.
Here's how I would apply this principle:<= /div>
  1. Eliminate security sources and security de= stinations from all BSP blocks.  The security source of a BSP block wo= uld always be the bundle=92s source.  The security destination of a BS= P block would always be the bundle=92s destination.
  2. Add a new Administrative Record type = for Bundle-in-Bundle encapsulation.
  3. When additional security must be appl= ied to a bundle on some segment of its end-to-end path, encapsulate the bun= dle in a Bundle-in-Bundle Encapsulation Administrative Record that is the p= ayload of a new bundle whose source is the security source of the path segment and whose destination is the secur= ity destination of the path segment.  Apply the additional bundle tran= smission security measures to the encapsulating bundle: encrypt its payload= (the Administrative Record, containing the encapsulated bundle), encrypt extension blocks as copied from the enca= psulated bundle, etc.  Then forward the encapsulating bundle.
  4. When route service uncertainty forces= a bundle to be routed over multiple parallel additionally secured segments= of its end-to-end path, encapsulate it as above but within multiple differ= ent encapsulating bundles, one for each of the parallel segments, and forward all of them.
  5. At the destination of a bundle, apply all relevant bundle re= ception security measures and then, if the payload is an encapsulation Admi= nistrative Record, extract the encapsulated bundle from the Administrative = Record and simply forward it.
I believe this would have the following i= mpacts on DTN security:
  • No EID references in BSP, simplifying cano= nicalization.
  • PCBs only encrypt payloads, never PIB= s or PCBs (encrypting the encapsulated bundle encrypts all three at once), = so no correlators in BSP.  (Except for BABs, no bundle ever has more t= han one occurrence of any type of BSP block.  And there will never be more than two BABs, one immediately following the = primary block and one that is the final block in the bundle, so that correl= ation is structural.)
  • No delicate =93replacement=94 process= for unraveling PCB nesting at the destination.
  • No possible confusion about the corre= ct order of application of BSP blocks.
  • No possible conflict among security d= estinations of different BSP blocks.
  • Security paths can never overlap.
  • Any routing implementation can always ac= commodate any security regime: routes that must be followed to ensure secur= ity are encoded into routing information at the forwarding node, not into t= he bundle.  (A little like the late binding principle.)
  • Any routing envi= ronment can always be made arbitrarily secure =96 no need to require specia= lly BSP-aware routing elements.
  • Ciphersuite design is simplified, so = a wider array of useful ciphersuites can be developed without imposing bug-= prone complexity.  Minimizes possible security problems.
As an example of how I think this could w= ork, see the attached diagram:
  1. Node A is sending a bundle to node K. = ; Nodes A, B, J, and K are within the low-risk =93W=94 security region; nod= es C and G are gateways between region W and the more hazardous region X; n= ode D is another node in X; nodes E and F are gateways between region X and even more hazardous region Y; nodes H and I = are gateways between X and hazardous region Z.
  2. At A the bundle is simply forwarded t= o B.
  3. At B the routing element realize= s that the bundle has to traverse region X in order to get to K, so it forw= ards the bundle to C.
  4. The routing element at C encapsulates= the bundle in an Admin Record, creates a new bundle destined for G (the eg= ress from region X) whose source is C and whose payload is that Admin Recor= d, encrypts the payload, attaches a PCB, and forwards the bundle to D.
  5. D real= izes that the bundle has to traverse region Y in order to get to G, so it f= orwards the bundle to E.
  6. E encapsulates the bundle in an Admin= Record, creates a new bundle destined for F (the egress from region Y) who= se source is E and whose payload is that Admin Record, encrypts the payload= , attaches a PCB, and forwards the bundle to F.
  7. The bundle protocol agent at F= receives the bundle, decrypts it, and passes the payload (an Admin Record)= to the application agent.  The administrative element of the applicat= ion agent at F receives the Admin Record, extracts the encapsulated bundle destined for G, and queues it to be forwarded.&nbs= p; The routing element at F sees this bundle and forwards it to G.
  8. The bundle protocol agent at G receiv= es the bundle, decrypts it, and passes the payload (an Admin Record) to the= application agent.  The administrative element of the application age= nt at G receives the Admin Record, extracts the encapsulated bundle destined for K, and queues it to be forwarded.&nbs= p; The routing element at G sees this bundle, realizes that the bundle has = to traverse region Z in order to get to K, and therefore forwards the bundl= e to H.
  9. H encapsulates the bundle in an Admin= Record, creates a new bundle destined for I (the egress from region Z) who= se source is H and whose payload is that Admin Record, encrypts the payload= , attaches a PCB, and forwards the bundle to I.
  10. The bundle protocol agent at I= receives the bundle, decrypts it, and passes the payload (an Admin Record)= to the application agent.  The administrative element of the applicat= ion agent at I receives the Admin Record, extracts the encapsulated bundle destined for K, and queues it to be forwarded.&nbs= p; The routing element at I sees this bundle and forwards it to J.
  11. At J the bundle is simply forwarded t= o K.
  12. At K the bundle=92s payload is p= assed to the application.
I think this approach would combine simpl= icity with quite a lot of operational power, making everything cheaper and = safer.
So, having now stirred the hornet=92s nes= t, I will beat a hasty retreat for a week while I am on vacation.  I= =92ll try to follow up when I get back.
Have a nice Thanksgiving, everybody.
Scott
 
-----Original Message-----
From: Peter Lovell [mailto:plovell@mac.com]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); ahennes1@math.umd.edu
Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter= Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2<= /div>
 
On Wed, Oct 24, 2012, Burleigh, Scott C (313B) <scott.c.burleigh@jpl.nasa.gov> wrote:<= /div>
 
> In view of which, I've now become a bigger fan of bundle-in-bundl= e
>tunneling than I've been in the past.
 
Hi Scott,
 
I agree. I'm also a big fan, for a bunch of reasons. However, as I men= tioned to Angela, the current [i.e. latest, expired] draft seems a bit &quo= t;funky" to me. There's no indication in the bundle that it's BiB and = you need some special EID to perform the decapsulation. Maybe that's just like an assigned port in TCP but we don't yet have such = a mechanism. The multiple-bundle thing is OK, I guess, but I don't see much= use for it other than volume gateway-to-gateway traffic and I think that s= uch heavy-duty tunnels could be specially optimized.
 
I need to go back and review all the discussions about BiB -- we worke= d it quite a bit but the spec never gained enough consensus to move forward= . I think it would be a good idea to revisit it now and get a solid draft t= hat has wider support. Maybe the email discussions will help us get there.
 
Thanks.....Peter
 
 
--_000_C304DB494AC0C04C87C6A6E2FF5603DB011416DB6897NDJSSCC01nd_-- From wesley.m.eddy@nasa.gov Tue Jan 22 15:47:52 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BED021F8753 for ; Tue, 22 Jan 2013 15:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIQJxbDj7mgy for ; Tue, 22 Jan 2013 15:47:49 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2AD21F86E8 for ; Tue, 22 Jan 2013 15:47:49 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 41E901082DC; Tue, 22 Jan 2013 17:47:48 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r0MNllc6022463; Tue, 22 Jan 2013 17:47:47 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Tue, 22 Jan 2013 17:47:47 -0600 From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" To: "Burleigh, Scott C" , "dtn-security@irtf.org" Date: Tue, 22 Jan 2013 17:47:47 -0600 Thread-Topic: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 Thread-Index: AQHN+PenH0ya9RV+Q02UlP2uaZf/xphV/v4wgAAB0cQ= Message-ID: References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com><6af37e4869b76826d4d2108e3eef82b3.squirrel @webmail.math.umd.edu><20120923012212.319238544@smtp.mail.me.com><3c1f477d9 f6b104790e33e76236998e6.squirrel@webmail.math.umd.edu><20120926214742.2066794613@smtp. mail.me.com><20120927170104.253362480@smtp.mail.me.com><20120927172602.1763958833@smtp.mail.m e.com><20121002225237.520325524@smtp.mail.me.com><7249cc388d868cb16f14efe286351e37.squ irrel@webmail.math.umd.edu><20121004210719.1971171529@smtp.mail.me.com><20121004220537.1202245607 @smtp.mail.me.com><20121016220658.793339059@smtp.mail.me.com><20121022185905.200828573@smtp.mai l.me.com> <20121022202820.71123343@smtp.mail.me.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C304DB494AC0C04C87C6A6E2FF5603DB011416DB6898NDJSSCC01nd_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-22_10:2013-01-22, 2013-01-22, 1970-01-01 signatures=0 X-Mailman-Approved-At: Tue, 22 Jan 2013 15:49:22 -0800 Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:47:52 -0000 --_000_C304DB494AC0C04C87C6A6E2FF5603DB011416DB6898NDJSSCC01nd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agreed; that makes sense. ________________________________ From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] Sent: Tuesday, January 22, 2013 6:35 PM To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.org Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 Wes, I agree that some code change would be entailed in implementing this p= roposal, but I think a large proportion of the code =96 the general flow of= processing the extension blocks, the canonicalization, the ciphersuites, r= eally almost everything that would have been implemented to handle the simp= le case of security source/destination being identical to bundle source/des= tination =96 would be preserved. I suspect that much of what I was proposi= ng here involves removing functionality that most developers haven=92t impl= emented yet anyway, because of the potential pitfalls. Scott From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy@n= asa.gov] Sent: Tuesday, January 22, 2013 3:20 PM To: Burleigh, Scott C (313B); dtn-security@irtf.org Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 It looks like basically a good idea to me. I recall sometime in 2006 or 2007ish pointing out that security destination= s needed to work more like IPsec tunnel-mode endpoints in order to make the= routing work correctly, and I think what you're proposing here accomplishe= s that in a better way. Though I think cycles would be better spent on KMP issues that are actually= HARD, and *then* circling back to see what could be tweaked in the BSP, I = definitely think this proposed change is something that would improve the B= SP a bit in the meantime. I don't think it can be done in a way that's friendly to the existing codeb= ase like Stephen suggests shooting for. ________________________________ From: dtn-security-bounces@irtf.org [= dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B) [scott= .c.burleigh@jpl.nasa.gov] Sent: Tuesday, January 22, 2013 5:37 PM To: dtn-security@irtf.org Subject: [dtn-security] FW: Re(19): Implementing Security Destinations inDT= N2 Hi. Late last September, several of us spun off a sub-thread talking about= how the processing of bundles with multiple security destinations could be= handled in DTN implementations. I won=92t try to recreate all of the argu= ments on all sides, but I think we did converge on agreement that the curre= nt BSP mechanism for complex, multi-destination security could be difficult= to realize in coherent fashion across the network. After puzzling over th= is for a while, I came up with a concept (below) that I think would be simp= ler, safer, and even more powerful than the current protocol design. How d= o we all feel about this? Would it be worthwhile for DTNRG to invest in a = 6257bis RFC along these lines? Scott _____________________________________________ From: Burleigh, Scott C (313B) Sent: Friday, November 16, 2012 5:05 PM To: 'Peter Lovell'; ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in D= TN2 Hi, Peter. At the risk (I know) of getting a lot of people severely ticked= off at me, I am going to offer a modest proposal for improving the Bundle = Security Protocol, inspired by this thread. I propose to adopt a new design principle for Bundle Security Protocol: the= routing element of a bundle protocol agent should never need to inspect a = bundle=92s BSP extension blocks in order to select the node(s) to forward t= he bundle to. That is, BSP should provide security, not dictate routes. My rationale for proposing this principle is that I believe it would: =95 Simplify BSP, thereby reducing the incidence of bugs and making= Bundle Security significantly less expensive to implement and sustain. =95 Broaden the scope of BSP deployment by eliminating its dependen= ce on specific, BSP-aware routing implementations, thereby increasing the o= verall security of DTN. =95 Reduce the cost of developing and improving routing implementat= ions by removing any requirement that they be BSP-aware, and broaden the sc= ope of deployment of non-BSP-aware routing implementations by enabling them= to be used in environments requiring arbitrarily powerful security. There= by, improve DTN operational performance. Here's how I would apply this principle: 1. Eliminate security sources and security destinations from all BSP = blocks. The security source of a BSP block would always be the bundle=92s = source. The security destination of a BSP block would always be the bundle= =92s destination. 2. Add a new Administrative Record type for Bundle-in-Bundle encapsul= ation. 3. When additional security must be applied to a bundle on some segme= nt of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Enc= apsulation Administrative Record that is the payload of a new bundle whose = source is the security source of the path segment and whose destination is = the security destination of the path segment. Apply the additional bundle = transmission security measures to the encapsulating bundle: encrypt its pay= load (the Administrative Record, containing the encapsulated bundle), encry= pt extension blocks as copied from the encapsulated bundle, etc. Then forw= ard the encapsulating bundle. 4. When route service uncertainty forces a bundle to be routed over m= ultiple parallel additionally secured segments of its end-to-end path, enca= psulate it as above but within multiple different encapsulating bundles, on= e for each of the parallel segments, and forward all of them. 5. At the destination of a bundle, apply all relevant bundle receptio= n security measures and then, if the payload is an encapsulation Administra= tive Record, extract the encapsulated bundle from the Administrative Record= and simply forward it. I believe this would have the following impacts on DTN security: =95 No EID references in BSP, simplifying canonicalization. =95 PCBs only encrypt payloads, never PIBs or PCBs (encrypting the = encapsulated bundle encrypts all three at once), so no correlators in BSP. = (Except for BABs, no bundle ever has more than one occurrence of any type = of BSP block. And there will never be more than two BABs, one immediately = following the primary block and one that is the final block in the bundle, = so that correlation is structural.) =95 No delicate =93replacement=94 process for unraveling PCB nestin= g at the destination. =95 No possible confusion about the correct order of application of= BSP blocks. =95 No possible conflict among security destinations of different B= SP blocks. =95 Security paths can never overlap. =95 Any routing implementation can always accommodate any security = regime: routes that must be followed to ensure security are encoded into ro= uting information at the forwarding node, not into the bundle. (A little l= ike the late binding principle.) =95 Any routing environment can always be made arbitrarily secure = =96 no need to require specially BSP-aware routing elements. =95 Ciphersuite design is simplified, so a wider array of useful ci= phersuites can be developed without imposing bug-prone complexity. Minimiz= es possible security problems. As an example of how I think this could work, see the attached diagram: 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are wi= thin the low-risk =93W=94 security region; nodes C and G are gateways betwe= en region W and the more hazardous region X; node D is another node in X; n= odes E and F are gateways between region X and even more hazardous region Y= ; nodes H and I are gateways between X and hazardous region Z. 2. At A the bundle is simply forwarded to B. 3. At B the routing element realizes that the bundle has to traverse = region X in order to get to K, so it forwards the bundle to C. 4. The routing element at C encapsulates the bundle in an Admin Recor= d, creates a new bundle destined for G (the egress from region X) whose sou= rce is C and whose payload is that Admin Record, encrypts the payload, atta= ches a PCB, and forwards the bundle to D. 5. D realizes that the bundle has to traverse region Y in order to ge= t to G, so it forwards the bundle to E. 6. E encapsulates the bundle in an Admin Record, creates a new bundle= destined for F (the egress from region Y) whose source is E and whose payl= oad is that Admin Record, encrypts the payload, attaches a PCB, and forward= s the bundle to F. 7. The bundle protocol agent at F receives the bundle, decrypts it, a= nd passes the payload (an Admin Record) to the application agent. The admi= nistrative element of the application agent at F receives the Admin Record,= extracts the encapsulated bundle destined for G, and queues it to be forwa= rded. The routing element at F sees this bundle and forwards it to G. 8. The bundle protocol agent at G receives the bundle, decrypts it, a= nd passes the payload (an Admin Record) to the application agent. The admi= nistrative element of the application agent at G receives the Admin Record,= extracts the encapsulated bundle destined for K, and queues it to be forwa= rded. The routing element at G sees this bundle, realizes that the bundle = has to traverse region Z in order to get to K, and therefore forwards the b= undle to H. 9. H encapsulates the bundle in an Admin Record, creates a new bundle= destined for I (the egress from region Z) whose source is H and whose payl= oad is that Admin Record, encrypts the payload, attaches a PCB, and forward= s the bundle to I. 10. The bundle protocol agent at I receives the bundle, decrypts it, and = passes the payload (an Admin Record) to the application agent. The adminis= trative element of the application agent at I receives the Admin Record, ex= tracts the encapsulated bundle destined for K, and queues it to be forwarde= d. The routing element at I sees this bundle and forwards it to J. 11. At J the bundle is simply forwarded to K. 12. At K the bundle=92s payload is passed to the application. I think this approach would combine simplicity with quite a lot of operatio= nal power, making everything cheaper and safer. So, having now stirred the hornet=92s nest, I will beat a hasty retreat for= a week while I am on vacation. I=92ll try to follow up when I get back. Have a nice Thanksgiving, everybody. Scott -----Original Message----- From: Peter Lovell [mailto:plovell@mac.com] Sent: Monday, October 22, 2012 1:28 PM To: Burleigh, Scott C (313B); ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2 On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: > In view of which, I've now become a bigger fan of bundle-in-bundle >tunneling than I've been in the past. Hi Scott, I agree. I'm also a big fan, for a bunch of reasons. However, as I mentione= d to Angela, the current [i.e. latest, expired] draft seems a bit "funky" t= o me. There's no indication in the bundle that it's BiB and you need some s= pecial EID to perform the decapsulation. Maybe that's just like an assigned= port in TCP but we don't yet have such a mechanism. The multiple-bundle th= ing is OK, I guess, but I don't see much use for it other than volume gatew= ay-to-gateway traffic and I think that such heavy-duty tunnels could be spe= cially optimized. I need to go back and review all the discussions about BiB -- we worked it = quite a bit but the spec never gained enough consensus to move forward. I t= hink it would be a good idea to revisit it now and get a solid draft that h= as wider support. Maybe the email discussions will help us get there. Thanks.....Peter --_000_C304DB494AC0C04C87C6A6E2FF5603DB011416DB6898NDJSSCC01nd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Agreed; = that makes sense.
 
From: Burleigh, S= cott C (313B) [scott.c.burleigh@jpl.nasa.gov]
Sent: Tuesday, January 22, 2013 6:35 PM
To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf= .org
Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destin= ations inDTN2

Wes, I agree that some code change would b= e entailed in implementing this proposal, but I think a large proportion of= the code =96 the general flow of processing the extension blocks, the canonicalization, the ciphersuites, really almos= t everything that would have been implemented to handle the simple case of = security source/destination being identical to bundle source/destination = =96 would be preserved.  I suspect that much of what I was proposing here involves removing functionality that mos= t developers haven=92t implemented yet anyway, because of the potential pit= falls.

 

Scott

 

From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] = [mailto:wesley.m.eddy@nasa.gov]
Sent: Tuesday, January 22, 2013 3:20 PM
To: Burleigh, Scott C (313B); dtn-security@irtf.org
Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destin= ations inDTN2

 

It looks like basically a good idea to me.

 

I recall sometime in 2006 or 2007ish pointing = out that security destinations needed to work more like IPsec tunnel-mode e= ndpoints in order to make the routing work correctly, and I think what you're proposing here accomplishes that i= n a better way.

 

Though I think cycles would be better spent on= KMP issues that are actually HARD, and *then* circling back to see what co= uld be tweaked in the BSP, I definitely think this proposed change is something that would improve = the BSP a bit in the meantime.

 

I don't think it can be done in a way that's f= riendly to the existing codebase like Stephen suggests shooting for.=

 

From:= dtn-security-bounces@irtf.= org [dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313= B) [scott.c.burleigh@jpl.nasa.gov]
Sent: Tuesday, January 22, 2013 5:37 PM
To: dtn-security@irtf.org
Subject: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns inDTN2

Hi.  Late last September, several of = us spun off a sub-thread talking about how the processing of bundles with m= ultiple security destinations could be handled in DTN implementations.  I won=92t try to recreate all of the argumen= ts on all sides, but I think we did converge on agreement that the current = BSP mechanism for complex, multi-destination security could be difficult to= realize in coherent fashion across the network.  After puzzling over this for a while, I came up with a conc= ept (below) that I think would be simpler, safer, and even more powerful th= an the current protocol design.  How do we all feel about this?  = Would it be worthwhile for DTNRG to invest in a 6257bis RFC along these lines?

 

Scott

 

 

Hi, Peter.  At the risk (I know) of get= ting a lot of people severely ticked off at me, I am going to offer a modes= t proposal for improving the Bundle Security Protocol, inspired by this thread.

I propose to adopt a new design principle fo= r Bundle Security Protocol: the routing element of a bundle protocol agent = should never need to inspect a bundle=92s BSP extension blocks in order to select the node(s) to forward the bundle = to.

That is, BSP should provide security, not dictate routes.

My rationale for proposing this principle is= that I believe it would:

= =B7    &nbs= p;    Simplify BSP, thereby reducing the incidence o= f bugs and making Bundle Security significantly less expensive to implement= and sustain.

= =B7    &nbs= p;    Broaden the scope of BSP deployment by elimina= ting its dependence on specific, BSP-aware routing implementations, thereby= increasing the overall security of DTN.

= =B7    &nbs= p;    Reduce the cost of developing and improving ro= uting implementations by removing any requirement that they be BSP-aware, a= nd broaden the scope of deployment of non-BSP-aware routing implementations by enabling them to be used in en= vironments requiring arbitrarily powerful security.  Thereby, improve = DTN operational performance.

Here's how I would apply this principle:

1.  &nb= sp;    Eliminate security sources and security destin= ations from all BSP blocks.  The security source of a BSP block would = always be the bundle=92s source.  The security destination of a BSP block would always be the bundle=92s destination.

2.  &nb= sp;    Add a new Administrative Record type for Bundl= e-in-Bundle encapsulation.

3.  &nb= sp;    When additional security must be applied to a = bundle on some segment of its end-to-end path, encapsulate the bundle in a = Bundle-in-Bundle Encapsulation Administrative Record that is the payload of a new bundle whose source is the security so= urce of the path segment and whose destination is the security destination = of the path segment.  Apply the additional bundle transmission securit= y measures to the encapsulating bundle: encrypt its payload (the Administrative Record, containing the encapsulate= d bundle), encrypt extension blocks as copied from the encapsulated bundle,= etc.  Then forward the encapsulating bundle.

4.  &nb= sp;    When route service uncertainty forces a bundle= to be routed over multiple parallel additionally secured segments of its e= nd-to-end path, encapsulate it as above but within multiple different encapsulating bundles, one for each of= the parallel segments, and forward all of them.

5.  &nb= sp;    At the destination of a bundle, apply all rele= vant bundle reception security measures and then, if the payload is an enca= psulation Administrative Record, extract the encapsulated bundle from the Administrative Record and simply forward = it.

I believe this would have the following impa= cts on DTN security:

= =B7    &nbs= p;    No EID references in BSP, simplifying canonica= lization.

= =B7    &nbs= p;    PCBs only encrypt payloads, never PIBs or PCBs= (encrypting the encapsulated bundle encrypts all three at once), so no cor= relators in BSP.  (Except for BABs, no bundle ever has more than one occurrence of any type of BSP block. = ; And there will never be more than two BABs, one immediately following the= primary block and one that is the final block in the bundle, so that corre= lation is structural.)

= =B7    &nbs= p;    No delicate =93replacement=94 process for unra= veling PCB nesting at the destination.

= =B7    &nbs= p;    No possible confusion about the correct order = of application of BSP blocks.

= =B7    &nbs= p;    No possible conflict among security destinatio= ns of different BSP blocks.

= =B7    &nbs= p;    Security paths can never overlap.

= =B7    &nbs= p;    Any routing implementation can always accommod= ate any security regime: routes that must be followed to ensure security ar= e encoded into routing information at the forwarding node, not into the bundle.  (A little like the late= binding principle.)

= =B7    &nbs= p;    Any routing environment can always be made arb= itrarily secure =96 no need to require specially BSP-aware routing elements= .

= =B7    &nbs= p;    Ciphersuite design is simplified, so a wider a= rray of useful ciphersuites can be developed without imposing bug-prone com= plexity.  Minimizes possible security problems.

As an example of how I think this could work= , see the attached diagram:

1.  &nb= sp;    Node A is sending a bundle to node K.  No= des A, B, J, and K are within the low-risk =93W=94 security region; nodes C= and G are gateways between region W and the more hazardous region X; node D is another node in X; nodes E and F are ga= teways between region X and even more hazardous region Y; nodes H and I are= gateways between X and hazardous region Z.

2.  &nb= sp;    At A the bundle is simply forwarded to B.

3.  &nb= sp;    At B the routing element realizes that the bun= dle has to traverse region X in order to get to K, so it forwards the bundl= e to C.

4.  &nb= sp;    The routing element at C encapsulates the bund= le in an Admin Record, creates a new bundle destined for G (the egress from= region X) whose source is C and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and fo= rwards the bundle to D.

5.  &nb= sp;    D realizes that the bundle has to traverse reg= ion Y in order to get to G, so it forwards the bundle to E.

6.  &nb= sp;    E encapsulates the bundle in an Admin Record, = creates a new bundle destined for F (the egress from region Y) whose source= is E and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the bundle to F= .

7.  &nb= sp;    The bundle protocol agent at F receives the bu= ndle, decrypts it, and passes the payload (an Admin Record) to the applicat= ion agent.  The administrative element of the application agent at F receives the Admin Record, extracts the enca= psulated bundle destined for G, and queues it to be forwarded.  The ro= uting element at F sees this bundle and forwards it to G.

8.  &nb= sp;    The bundle protocol agent at G receives the bu= ndle, decrypts it, and passes the payload (an Admin Record) to the applicat= ion agent.  The administrative element of the application agent at G receives the Admin Record, extracts the enca= psulated bundle destined for K, and queues it to be forwarded.  The ro= uting element at G sees this bundle, realizes that the bundle has to traver= se region Z in order to get to K, and therefore forwards the bundle to H.

9.  &nb= sp;    H encapsulates the bundle in an Admin Record, = creates a new bundle destined for I (the egress from region Z) whose source= is H and whose payload is that Admin Record, encrypts the payload, attaches a PCB, and forwards the bundle to I= .

10.   The bundle protocol agent at I receives the bu= ndle, decrypts it, and passes the payload (an Admin Record) to the applicat= ion agent.  The administrative element of the application agent at I receives the Admin Record, extracts the enca= psulated bundle destined for K, and queues it to be forwarded.  The ro= uting element at I sees this bundle and forwards it to J.

11.   At J the bundle is simply forwarded to K.

12.   At K the bundle=92s payload is passed to the a= pplication.

I think this approach would combine simplici= ty with quite a lot of operational power, making everything cheaper and saf= er.

So, having now stirred the hornet=92s nest, = I will beat a hasty retreat for a week while I am on vacation.  I=92ll= try to follow up when I get back.

Have a nice Thanksgiving, everybody.<= /p>

Scott

 

-----Original Message-----
From: Peter Lovell [mailto:plovell@mac.c= om]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); ahen= nes1@math.umd.edu
Cc: Amy Alford; Cherita.Corbe= tt@jhuapl.edu; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2<= /span>

 

On Wed, Oct 24, 2012, Burleigh, Scott C (313= B) <scott.c.burleigh@jp= l.nasa.gov> wrote:

 

> In view of which, I've now become a big= ger fan of bundle-in-bundle

>tunneling than I've been in the past.

 

Hi Scott,

 

I agree. I'm also a big fan, for a bunch of = reasons. However, as I mentioned to Angela, the current [i.e. latest, expir= ed] draft seems a bit "funky" to me. There's no indication in the bundle that it's BiB and you need some specia= l EID to perform the decapsulation. Maybe that's just like an assigned port= in TCP but we don't yet have such a mechanism. The multiple-bundle thing i= s OK, I guess, but I don't see much use for it other than volume gateway-to-gateway traffic and I think that s= uch heavy-duty tunnels could be specially optimized.

 

I need to go back and review all the discuss= ions about BiB -- we worked it quite a bit but the spec never gained enough= consensus to move forward. I think it would be a good idea to revisit it now and get a solid draft that has w= ider support. Maybe the email discussions will help us get there.

 

Thanks.....Peter

 

 

--_000_C304DB494AC0C04C87C6A6E2FF5603DB011416DB6898NDJSSCC01nd_-- From Edward.Birrane@jhuapl.edu Wed Jan 23 09:52:47 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70F121F84F2 for ; Wed, 23 Jan 2013 09:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofa4OOL4pxD3 for ; Wed, 23 Jan 2013 09:52:40 -0800 (PST) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1448221F84E3 for ; Wed, 23 Jan 2013 09:52:39 -0800 (PST) Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 150a_05d5_af6b45d0_6935_49d5_a9d5_4858082365e1; Wed, 23 Jan 2013 12:52:38 -0500 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Wed, 23 Jan 2013 12:51:22 -0500 From: "Birrane, Edward J." To: "dtn-security@irtf.org" Date: Wed, 23 Jan 2013 12:51:20 -0500 Thread-Topic: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 Thread-Index: AQHN+PenH0ya9RV+Q02UlP2uaZf/xphV/v4wgAAB0cSAAPdeUA== Message-ID: <329D879C76FDD04AAAE84BB1D89B3970073C20BE1E@aplesfreedom.dom1.jhuapl.edu> References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com><6af37e4869b76826d4d2108e3eef82b3.squirrel @webmail.math.umd.edu><20120923012212.319238544@smtp.mail.me.com><3c1f477d9 f6b104790e33e76236998e6.squirrel@webmail.math.umd.edu><20120926214742.2066794613@smtp. mail.me.com><20120927170104.253362480@smtp.mail.me.com><20120927172602.1763958833@smtp.mail.m e.com><20121002225237.520325524@smtp.mail.me.com><7249cc388d868cb16f14efe286351e37.squ irrel@webmail.math.umd.edu><20121004210719.1971171529@smtp.mail.me.com><20121004220537.1202245607 @smtp.mail.me.com><20121016220658.793339059@smtp.mail.me.com><20121022185905.200828573@smtp.mai l.me.com> <20121022202820.71123343@smtp.mail.me.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_329D879C76FDD04AAAE84BB1D89B3970073C20BE1Eaplesfreedomd_" MIME-Version: 1.0 Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 17:52:47 -0000 --_000_329D879C76FDD04AAAE84BB1D89B3970073C20BE1Eaplesfreedomd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also agreed. Having worked through the spec to implement PIB/PCB/BAB in the ION codebase= , the core parts of the specification (canonicalization and extension block= s) are good, excepting minor changes that are emerging in the 6257 errata. = However, the tight coupling of routing and security imposes the difficult = requirement that we understand the topology and policy of portions of the n= etwork that may be unknowable. A simplified approach should remove this coupling and thus the need for tri= cky tasks like dictionary surgery, block nesting, path uniqueness, etc... T= he security use cases that I am aware of can be equally satisfied with a si= mplified BSP cooperating with some type of encapsulation approach (such as = Scott's bundle-in-bundle idea). A small group, in a small amount of time, could create a sample internet dr= aft based on 6257 that provides these simplifications, includes those appro= priate errata accumulated so far, and would serve as a good baseline for di= scussion going forward. -Ed --- Ed Birrane Senior Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] = On Behalf Of Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] Sent: Tuesday, January 22, 2013 6:48 PM To: Burleigh, Scott C; dtn-security@irtf.org Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 Agreed; that makes sense. ________________________________ From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] Sent: Tuesday, January 22, 2013 6:35 PM To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.org Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 Wes, I agree that some code change would be entailed in implementing this p= roposal, but I think a large proportion of the code - the general flow of p= rocessing the extension blocks, the canonicalization, the ciphersuites, rea= lly almost everything that would have been implemented to handle the simple= case of security source/destination being identical to bundle source/desti= nation - would be preserved. I suspect that much of what I was proposing h= ere involves removing functionality that most developers haven't implemente= d yet anyway, because of the potential pitfalls. Scott From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy@n= asa.gov] Sent: Tuesday, January 22, 2013 3:20 PM To: Burleigh, Scott C (313B); dtn-security@irtf.org Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 It looks like basically a good idea to me. I recall sometime in 2006 or 2007ish pointing out that security destination= s needed to work more like IPsec tunnel-mode endpoints in order to make the= routing work correctly, and I think what you're proposing here accomplishe= s that in a better way. Though I think cycles would be better spent on KMP issues that are actually= HARD, and *then* circling back to see what could be tweaked in the BSP, I = definitely think this proposed change is something that would improve the B= SP a bit in the meantime. I don't think it can be done in a way that's friendly to the existing codeb= ase like Stephen suggests shooting for. ________________________________ From: dtn-security-bounces@irtf.org [= dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B) [scott= .c.burleigh@jpl.nasa.gov] Sent: Tuesday, January 22, 2013 5:37 PM To: dtn-security@irtf.org Subject: [dtn-security] FW: Re(19): Implementing Security Destinations inDT= N2 Hi. Late last September, several of us spun off a sub-thread talking about= how the processing of bundles with multiple security destinations could be= handled in DTN implementations. I won't try to recreate all of the argume= nts on all sides, but I think we did converge on agreement that the current= BSP mechanism for complex, multi-destination security could be difficult t= o realize in coherent fashion across the network. After puzzling over this= for a while, I came up with a concept (below) that I think would be simple= r, safer, and even more powerful than the current protocol design. How do = we all feel about this? Would it be worthwhile for DTNRG to invest in a 62= 57bis RFC along these lines? Scott _____________________________________________ From: Burleigh, Scott C (313B) Sent: Friday, November 16, 2012 5:05 PM To: 'Peter Lovell'; ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in D= TN2 Hi, Peter. At the risk (I know) of getting a lot of people severely ticked= off at me, I am going to offer a modest proposal for improving the Bundle = Security Protocol, inspired by this thread. I propose to adopt a new design principle for Bundle Security Protocol: the= routing element of a bundle protocol agent should never need to inspect a = bundle's BSP extension blocks in order to select the node(s) to forward the= bundle to. That is, BSP should provide security, not dictate routes. My rationale for proposing this principle is that I believe it would: * Simplify BSP, thereby reducing the incidence of bugs and making B= undle Security significantly less expensive to implement and sustain. * Broaden the scope of BSP deployment by eliminating its dependence= on specific, BSP-aware routing implementations, thereby increasing the ove= rall security of DTN. * Reduce the cost of developing and improving routing implementatio= ns by removing any requirement that they be BSP-aware, and broaden the scop= e of deployment of non-BSP-aware routing implementations by enabling them t= o be used in environments requiring arbitrarily powerful security. Thereby= , improve DTN operational performance. Here's how I would apply this principle: 1. Eliminate security sources and security destinations from all BSP = blocks. The security source of a BSP block would always be the bundle's so= urce. The security destination of a BSP block would always be the bundle's= destination. 2. Add a new Administrative Record type for Bundle-in-Bundle encapsul= ation. 3. When additional security must be applied to a bundle on some segme= nt of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Enc= apsulation Administrative Record that is the payload of a new bundle whose = source is the security source of the path segment and whose destination is = the security destination of the path segment. Apply the additional bundle = transmission security measures to the encapsulating bundle: encrypt its pay= load (the Administrative Record, containing the encapsulated bundle), encry= pt extension blocks as copied from the encapsulated bundle, etc. Then forw= ard the encapsulating bundle. 4. When route service uncertainty forces a bundle to be routed over m= ultiple parallel additionally secured segments of its end-to-end path, enca= psulate it as above but within multiple different encapsulating bundles, on= e for each of the parallel segments, and forward all of them. 5. At the destination of a bundle, apply all relevant bundle receptio= n security measures and then, if the payload is an encapsulation Administra= tive Record, extract the encapsulated bundle from the Administrative Record= and simply forward it. I believe this would have the following impacts on DTN security: * No EID references in BSP, simplifying canonicalization. * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the en= capsulated bundle encrypts all three at once), so no correlators in BSP. (= Except for BABs, no bundle ever has more than one occurrence of any type of= BSP block. And there will never be more than two BABs, one immediately fo= llowing the primary block and one that is the final block in the bundle, so= that correlation is structural.) * No delicate "replacement" process for unraveling PCB nesting at t= he destination. * No possible confusion about the correct order of application of B= SP blocks. * No possible conflict among security destinations of different BSP= blocks. * Security paths can never overlap. * Any routing implementation can always accommodate any security re= gime: routes that must be followed to ensure security are encoded into rout= ing information at the forwarding node, not into the bundle. (A little lik= e the late binding principle.) * Any routing environment can always be made arbitrarily secure - n= o need to require specially BSP-aware routing elements. * Ciphersuite design is simplified, so a wider array of useful ciph= ersuites can be developed without imposing bug-prone complexity. Minimizes= possible security problems. As an example of how I think this could work, see the attached diagram: 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are wi= thin the low-risk "W" security region; nodes C and G are gateways between r= egion W and the more hazardous region X; node D is another node in X; nodes= E and F are gateways between region X and even more hazardous region Y; no= des H and I are gateways between X and hazardous region Z. 2. At A the bundle is simply forwarded to B. 3. At B the routing element realizes that the bundle has to traverse = region X in order to get to K, so it forwards the bundle to C. 4. The routing element at C encapsulates the bundle in an Admin Recor= d, creates a new bundle destined for G (the egress from region X) whose sou= rce is C and whose payload is that Admin Record, encrypts the payload, atta= ches a PCB, and forwards the bundle to D. 5. D realizes that the bundle has to traverse region Y in order to ge= t to G, so it forwards the bundle to E. 6. E encapsulates the bundle in an Admin Record, creates a new bundle= destined for F (the egress from region Y) whose source is E and whose payl= oad is that Admin Record, encrypts the payload, attaches a PCB, and forward= s the bundle to F. 7. The bundle protocol agent at F receives the bundle, decrypts it, a= nd passes the payload (an Admin Record) to the application agent. The admi= nistrative element of the application agent at F receives the Admin Record,= extracts the encapsulated bundle destined for G, and queues it to be forwa= rded. The routing element at F sees this bundle and forwards it to G. 8. The bundle protocol agent at G receives the bundle, decrypts it, a= nd passes the payload (an Admin Record) to the application agent. The admi= nistrative element of the application agent at G receives the Admin Record,= extracts the encapsulated bundle destined for K, and queues it to be forwa= rded. The routing element at G sees this bundle, realizes that the bundle = has to traverse region Z in order to get to K, and therefore forwards the b= undle to H. 9. H encapsulates the bundle in an Admin Record, creates a new bundle= destined for I (the egress from region Z) whose source is H and whose payl= oad is that Admin Record, encrypts the payload, attaches a PCB, and forward= s the bundle to I. 10. The bundle protocol agent at I receives the bundle, decrypts it, and = passes the payload (an Admin Record) to the application agent. The adminis= trative element of the application agent at I receives the Admin Record, ex= tracts the encapsulated bundle destined for K, and queues it to be forwarde= d. The routing element at I sees this bundle and forwards it to J. 11. At J the bundle is simply forwarded to K. 12. At K the bundle's payload is passed to the application. I think this approach would combine simplicity with quite a lot of operatio= nal power, making everything cheaper and safer. So, having now stirred the hornet's nest, I will beat a hasty retreat for a= week while I am on vacation. I'll try to follow up when I get back. Have a nice Thanksgiving, everybody. Scott -----Original Message----- From: Peter Lovell [mailto:plovell@mac.com] Sent: Monday, October 22, 2012 1:28 PM To: Burleigh, Scott C (313B); ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2 On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: > In view of which, I've now become a bigger fan of bundle-in-bundle >tunneling than I've been in the past. Hi Scott, I agree. I'm also a big fan, for a bunch of reasons. However, as I mentione= d to Angela, the current [i.e. latest, expired] draft seems a bit "funky" t= o me. There's no indication in the bundle that it's BiB and you need some s= pecial EID to perform the decapsulation. Maybe that's just like an assigned= port in TCP but we don't yet have such a mechanism. The multiple-bundle th= ing is OK, I guess, but I don't see much use for it other than volume gatew= ay-to-gateway traffic and I think that such heavy-duty tunnels could be spe= cially optimized. I need to go back and review all the discussions about BiB -- we worked it = quite a bit but the spec never gained enough consensus to move forward. I t= hink it would be a good idea to revisit it now and get a solid draft that h= as wider support. Maybe the email discussions will help us get there. Thanks.....Peter --_000_329D879C76FDD04AAAE84BB1D89B3970073C20BE1Eaplesfreedomd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also agre= ed.

 

Having worked through the spec to implem= ent PIB/PCB/BAB in the ION codebase, the core parts of the specification (c= anonicalization and extension blocks) are good, excepting minor changes tha= t are emerging in the 6257 errata.  However, the tight coupling of rou= ting and security imposes the difficult requirement that we understand the = topology and policy of portions of the network that may be unknowable.

 

<= p class=3DMsoNormal>A simplified approach should remove this couplin= g and thus the need for tricky tasks like dictionary surgery, block nesting= , path uniqueness, etc... The security use cases that I am aware of can be = equally satisfied with a simplified BSP cooperating with some type of encap= sulation approach (such as Scott’s bundle-in-bundle idea).

 

A small group, in a small amount of time, could create= a sample internet draft based on 6257 that provides these simplifications,= includes those appropriate errata accumulated so far, and would serve as a= good baseline for discussion going forward.

-Ed<= o:p>

 

---Ed Birrane
Senior Professional Staff, Space Department
Johns Hopkin= s Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
&nbs= p;

From: dtn-security-bounces@irtf.or= g [mailto:dtn-security-bounces@irtf.org] On Behalf Of Eddy, Wesley M= . (GRC-MS00)[MTI SYSTEMS, INC.]
Sent: Tuesday, January 22, 2013 6= :48 PM
To: Burleigh, Scott C; dtn-security@irtf.org
Subject= : Re: [dtn-security] FW: Re(19): Implementing Security Destinations inD= TN2

 =

Agreed; that makes sense.

 

From: Burleigh, Scott C= (313B) [scott.c.burleigh@jpl.nasa.gov]
Sent: Tuesday, January 22= , 2013 6:35 PM
To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.];= dtn-security@irtf.org
S= ubject: RE: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns inDTN2

= Wes, I agree that some code change would be entailed in implementing this p= roposal, but I think a large proportion of the code – the general flo= w of processing the extension blocks, the canonicalization, the ciphersuite= s, really almost everything that would have been implemented to handle the = simple case of security source/destination being identical to bundle source= /destination – would be preserved.  I suspect that much of what = I was proposing here involves removing functionality that most developers h= aven’t implemented yet anyway, because of the potential pitfalls.

 

Scott

 

From: Eddy, Wesley M. (GRC-MS00)[MT= I SYSTEMS, INC.] [mailto:wesley.m= .eddy@nasa.gov]
Sent: Tuesday, January 22, 2013 3:20 PM
<= b>To: Burleigh, Scott C (313B); dtn-security@irtf.org
Subject: RE: [dtn-security] FW: Re(19= ): Implementing Security Destinations inDTN2

 

It looks like basically a good idea to me.

<= div>

 

I recall sometime in 2006 or 2007ish pointing out that security desti= nations needed to work more like IPsec tunnel-mode endpoints in order to ma= ke the routing work correctly, and I think what you're proposing here accom= plishes that in a better way.

 

Though I th= ink cycles would be better spent on KMP issues that are actually HARD, and = *then* circling back to see what could be tweaked in the BSP, I defini= tely think this proposed change is something that would impr= ove the BSP a bit in the meantime.

 

I don'= t think it can be done in a way that's friendly to the existing codebase li= ke Stephen suggests shooting for.

 

From: dtn-security-bounces@irtf.org [dtn-security-bounces@= irtf.org] On Behalf Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.= gov]
Sent: Tuesday, January 22, 2013 5:37 PM
To: dtn-security@irtf.org
Subject:= [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2

Hi.  L= ate last September, several of us spun off a sub-thread talking about how t= he processing of bundles with multiple security destinations could be handl= ed in DTN implementations.  I won’t try to recreate all of the a= rguments on all sides, but I think we did converge on agreement that the cu= rrent BSP mechanism for complex, multi-destination security could be diffic= ult to realize in coherent fashion across the network.  After puzzling= over this for a while, I came up with a concept (below) that I think would= be simpler, safer, and even more powerful than the current protocol design= .  How do we all feel about this?  Would it be worthwhile for DTN= RG to invest in a 6257bis RFC along these lines?

 

Scott

= _____________________________________________
From: Burleigh, Sco= tt C (313B)
Sent: Friday, November 16, 2012 5:05 PM
To: 'Peter Lovell'; ahennes1@math.um= d.edu
Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss
Subject: RE: = Re(19): [dtn-security] Implementing Security Destinations in DTN2

 

 

Hi, Peter.  At the risk (I know) of= getting a lot of people severely ticked off at me, I am going to offer a m= odest proposal for improving the Bundle Security Protocol, inspired by this= thread.

I propose to adopt a new design principle for Bundle = Security Protocol: the routing element of a bundle protocol agent should ne= ver need to inspect a bundle’s BSP extension blocks in order to selec= t the node(s) to forward the bundle to.

That is, BSP should= provide security, not dictate routes.

My rationale for pr= oposing this principle is that I believe it would:

·     = ;    Simplify BSP, thereby reducing the incidenc= e of bugs and making Bundle Security significantly less expensive to implem= ent and sustain.

·         Broade= n the scope of BSP deployment by eliminating its dependence on specific, BS= P-aware routing implementations, thereby increasing the overall security of= DTN.

·&nbs= p;        Reduce the cost of= developing and improving routing implementations by removing any requireme= nt that they be BSP-aware, and broaden the scope of deployment of non-BSP-a= ware routing implementations by enabling them to be used in environments re= quiring arbitrarily powerful security.  Thereby, improve DTN operation= al performance.

Here's how I would apply this principle:=

1. =       Eliminate security sources and s= ecurity destinations from all BSP blocks.  The security source of a BS= P block would always be the bundle’s source.  The security desti= nation of a BSP block would always be the bundle’s destination.

2. = ;      Add a new Administrative Record= type for Bundle-in-Bundle encapsulation.

3.     &nb= sp; When additional security must be applied to a bundle on som= e segment of its end-to-end path, encapsulate the bundle in a Bundle-in-Bun= dle Encapsulation Administrative Record that is the payload of a new bundle= whose source is the security source of the path segment and whose destinat= ion is the security destination of the path segment.  Apply the additi= onal bundle transmission security measures to the encapsulating bundle: enc= rypt its payload (the Administrative Record, containing the encapsulated bu= ndle), encrypt extension blocks as copied from the encapsulated bundle, etc= .  Then forward the encapsulating bundle.

4.    &nbs= p;  When route service uncertainty forces a bundle to be r= outed over multiple parallel additionally secured segments of its end-to-en= d path, encapsulate it as above but within multiple different encapsulating= bundles, one for each of the parallel segments, and forward all of them. <= /span>

5.&= nbsp;      At the destination of a bun= dle, apply all relevant bundle reception security measures and then, if the= payload is an encapsulation Administrative Record, extract the encapsulate= d bundle from the Administrative Record and simply forward it.<= /o:p>

I bel= ieve this would have the following impacts on DTN security:

&mid= dot;   &n= bsp;     No EID references in BSP, simplify= ing canonicalization.

·         PC= Bs only encrypt payloads, never PIBs or PCBs (encrypting the encapsulated b= undle encrypts all three at once), so no correlators in BSP.  (Except = for BABs, no bundle ever has more than one occurrence of any type of BSP bl= ock.  And there will never be more than two BABs, one immediately foll= owing the primary block and one that is the final block in the bundle, so t= hat correlation is structural.)

·         No delicate “replacement” process for unraveling PCB ne= sting at the destination.

·         No possible confusion about the correct order of application of BSP bloc= ks.

· =         No possible conflict= among security destinations of different BSP blocks.

·=      &= nbsp;   Security paths can never overlap.

&midd= ot;   &nb= sp;     Any routing implementation can alwa= ys accommodate any security regime: routes that must be followed to ensure = security are encoded into routing information at the forwarding node, not i= nto the bundle.  (A little like the late binding principle.)

&mi= ddot;   &= nbsp;     Any routing environment can alway= s be made arbitrarily secure – no need to require specially BSP-aware= routing elements.

·         Ciphe= rsuite design is simplified, so a wider array of useful ciphersuites can be= developed without imposing bug-prone complexity.  Minimizes possible = security problems.

=

As an example of how I think this could work, see= the attached diagram:

1.       Node A is sending a bundle to node K.  Nodes A, B, J, and K are with= in the low-risk “W” security region; nodes C and G are gateways= between region W and the more hazardous region X; node D is another node i= n X; nodes E and F are gateways between region X and even more hazardous re= gion Y; nodes H and I are gateways between X and hazardous region Z.

2. =       At A the bundle is simply forwar= ded to B.

3.       At B the routing= element realizes that the bundle has to traverse region X in order to get = to K, so it forwards the bundle to C.

4.       = The routing element at C encapsulates the bundle in an Admin Re= cord, creates a new bundle destined for G (the egress from region X) whose = source is C and whose payload is that Admin Record, encrypts the payload, a= ttaches a PCB, and forwards the bundle to D.

5.    &nbs= p;  D realizes that the bundle has to traverse region Y in= order to get to G, so it forwards the bundle to E.

<= p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-indent:-.25in'>6= .    = ;   E encapsulates the bundle in an Admin Record, cre= ates a new bundle destined for F (the egress from region Y) whose source is= E and whose payload is that Admin Record, encrypts the payload, attaches a= PCB, and forwards the bundle to F.

7.       The bundle protocol agent at F receives the bundle, decrypts it, = and passes the payload (an Admin Record) to the application agent.  Th= e administrative element of the application agent at F receives the Admin R= ecord, extracts the encapsulated bundle destined for G, and queues it to be= forwarded.  The routing element at F sees this bundle and forwards it= to G.

8.       The bundle protocol= agent at G receives the bundle, decrypts it, and passes the payload (an Ad= min Record) to the application agent.  The administrative element of t= he application agent at G receives the Admin Record, extracts the encapsula= ted bundle destined for K, and queues it to be forwarded.  The routing= element at G sees this bundle, realizes that the bundle has to traverse re= gion Z in order to get to K, and therefore forwards the bundle to H.

9. =       H encapsulates the bundle in an = Admin Record, creates a new bundle destined for I (the egress from region Z= ) whose source is H and whose payload is that Admin Record, encrypts the pa= yload, attaches a PCB, and forwards the bundle to I.

=

= 10.   <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:bla= ck'>The bundle protocol agent at I receives the bundle, decrypts it, and pa= sses the payload (an Admin Record) to the application agent.  The admi= nistrative element of the application agent at I receives the Admin Record,= extracts the encapsulated bundle destined for K, and queues it to be forwa= rded.  The routing element at I sees this bundle and forwards it to J.=

11.   At J the bundle is simply forwarded to K.

12. = ;  At K the bundle’s payload is passed to the applic= ation.

I think this approach would combine simplicity with quite a l= ot of operational power, making everything cheaper and safer.

= So, having now stirred the hornet’s nest, I will beat a hasty retreat= for a week while I am on vacation.  I’ll try to follow up when = I get back.

<= p class=3DMsoNormal>Have a nice Thanksgiving, everybody.

= Scott

 

-----Original Message-----
Fro= m: Peter Lovell [mailto:plovell@mac.com<= /a>]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (3= 13B); ahennes1@math.umd.eduCc: Amy Alford; Cherita.Corb= ett@jhuapl.edu; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-sec= urity] Implementing Security Destinations in DTN2

 

On Wed, Oct 24, 2012, Burleigh, Scott C (313B) <scott.c.burleigh@jpl.nasa.gov> w= rote:

 

> In view of which, I've now b= ecome a bigger fan of bundle-in-bundle

>tunneling than I've been in the past.

 

=

Hi Scott,

 

I a= gree. I'm also a big fan, for a bunch of reasons. However, as I mentioned t= o Angela, the current [i.e. latest, expired] draft seems a bit "funky&= quot; to me. There's no indication in the bundle that it's BiB and you need= some special EID to perform the decapsulation. Maybe that's just like an a= ssigned port in TCP but we don't yet have such a mechanism. The multiple-bu= ndle thing is OK, I guess, but I don't see much use for it other than volum= e gateway-to-gateway traffic and I think that such heavy-duty tunnels could= be specially optimized.

 

I need to go b= ack and review all the discussions about BiB -- we worked it quite a bit bu= t the spec never gained enough consensus to move forward. I think it would = be a good idea to revisit it now and get a solid draft that has wider suppo= rt. Maybe the email discussions will help us get there.

 

Thanks.....Peter

 

 

= --_000_329D879C76FDD04AAAE84BB1D89B3970073C20BE1Eaplesfreedomd_-- From ahennes1@gmail.com Wed Jan 23 10:03:17 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5116621F85E2 for ; Wed, 23 Jan 2013 10:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bG0I9IqKCBc for ; Wed, 23 Jan 2013 10:03:15 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id BA22B21F8542 for ; Wed, 23 Jan 2013 10:03:14 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id j14so1672947lbo.24 for ; Wed, 23 Jan 2013 10:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4ONJ+3VKTJIlU0wkIDsyZXZ1u0DweuhQlkaiOwHRqyc=; b=c/dJb86EZhrWC9Fb3w89ZFqueHDPgMwfIpnRRfFx3u1E+LY0uygDdo7eQ7/N+3N4Y4 gVELmFaNMVMMXznnufjRy5otAd2bUZbcRg6Sv/7f3ZS/VNsrC1ly53pI+39FoqHuTR0b pHpsybmHTaDcoycojAYM0LlirAz9StvvY/KLbwREFZh3t8JNPZukxyQSnbMfGbh21dtz ZRjtpLMldU0PlCx56Tehx0FlkdN0vssQvHsuDnh2fzXO4V2L+FYsTJyu2Y/hLPSMJJQl sgIG5AWS6kdUjc4uq+XLfiUfbrpeMDgUBbOIajWJE2lrvhj1x6+WKwMROe1n9ukthrLx TfhQ== MIME-Version: 1.0 X-Received: by 10.152.132.137 with SMTP id ou9mr2232405lab.7.1358964193473; Wed, 23 Jan 2013 10:03:13 -0800 (PST) Sender: ahennes1@gmail.com Received: by 10.112.150.39 with HTTP; Wed, 23 Jan 2013 10:03:13 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Jan 2013 13:03:13 -0500 X-Google-Sender-Auth: P0M8al3u9PrydnVYc0vz1phM9ec Message-ID: From: Angela Hennessy To: dtn-security@irtf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 18:03:17 -0000 Hi Scott, I like how this approach simplifies the routing and gets rid of the security src/dest and EID refs. I was a little confused though about how this would work with some of the combinations of security blocks: If a node just wants to add a signature to a bundle, would this require the bundle to be encapsulated? One of the advantages of BSP is that non security-aware nodes can still access the payload by just ignoring the PIB block. Wouldn't we lose that feature if the bundle were encapsulated? If a node wants to sign and then encrypt the bundle, does this require the bundle to be encapsulated twice? How would we handle signing/encrypting extension blocks? Would this require a third encapsulation? Wouldn't we still need correlators in case multiple extension blocks are encrypted with the same key, or would we not allow different extension blocks to be encrypted with different keys? Thanks, Angela On Tue, Jan 22, 2013 at 6:49 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.irtf.org/mailman/listinfo/dtn-security > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send dtn-security mailing list submissions to > dtn-security@irtf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/dtn-security > or, via email, send a message with subject or body 'help' to > dtn-security-request@irtf.org > > You can reach the person managing the list at > dtn-security-owner@irtf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dtn-security digest..." > > Today's Topics: > > 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 > (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) > 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 > (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) > > > ---------- Forwarded message ---------- > From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" > To: "Burleigh, Scott C" , "dtn-security@ir= tf.org" > Cc: > Date: Tue, 22 Jan 2013 17:19:48 -0600 > Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destination= s inDTN2 > It looks like basically a good idea to me. > > I recall sometime in 2006 or 2007ish pointing out that security destinati= ons needed to work more like IPsec tunnel-mode endpoints in order to make t= he routing work correctly, and I think what you're proposing here accomplis= hes that in a better way. > > Though I think cycles would be better spent on KMP issues that are actual= ly HARD, and *then* circling back to see what could be tweaked in the BSP, = I definitely think this proposed change is something that would improve the= BSP a bit in the meantime. > > I don't think it can be done in a way that's friendly to the existing cod= ebase like Stephen suggests shooting for. > > ________________________________ > From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On Be= half Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] > Sent: Tuesday, January 22, 2013 5:37 PM > To: dtn-security@irtf.org > Subject: [dtn-security] FW: Re(19): Implementing Security Destinations in= DTN2 > > Hi. Late last September, several of us spun off a sub-thread talking abo= ut how the processing of bundles with multiple security destinations could = be handled in DTN implementations. I won=92t try to recreate all of the ar= guments on all sides, but I think we did converge on agreement that the cur= rent BSP mechanism for complex, multi-destination security could be difficu= lt to realize in coherent fashion across the network. After puzzling over = this for a while, I came up with a concept (below) that I think would be si= mpler, safer, and even more powerful than the current protocol design. How= do we all feel about this? Would it be worthwhile for DTNRG to invest in = a 6257bis RFC along these lines? > > Scott > _____________________________________________ > From: Burleigh, Scott C (313B) > Sent: Friday, November 16, 2012 5:05 PM > To: 'Peter Lovell'; ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss > Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in= DTN2 > > > Hi, Peter. At the risk (I know) of getting a lot of people severely tick= ed off at me, I am going to offer a modest proposal for improving the Bundl= e Security Protocol, inspired by this thread. > I propose to adopt a new design principle for Bundle Security Protocol: t= he routing element of a bundle protocol agent should never need to inspect = a bundle=92s BSP extension blocks in order to select the node(s) to forward= the bundle to. > That is, BSP should provide security, not dictate routes. > My rationale for proposing this principle is that I believe it would: > > Simplify BSP, thereby reducing the incidence of bugs and making Bundle Se= curity significantly less expensive to implement and sustain. > Broaden the scope of BSP deployment by eliminating its dependence on spec= ific, BSP-aware routing implementations, thereby increasing the overall sec= urity of DTN. > Reduce the cost of developing and improving routing implementations by re= moving any requirement that they be BSP-aware, and broaden the scope of dep= loyment of non-BSP-aware routing implementations by enabling them to be use= d in environments requiring arbitrarily powerful security. Thereby, improv= e DTN operational performance. > > Here's how I would apply this principle: > > Eliminate security sources and security destinations from all BSP blocks.= The security source of a BSP block would always be the bundle=92s source.= The security destination of a BSP block would always be the bundle=92s de= stination. > Add a new Administrative Record type for Bundle-in-Bundle encapsulation. > When additional security must be applied to a bundle on some segment of i= ts end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Encapsulat= ion Administrative Record that is the payload of a new bundle whose source = is the security source of the path segment and whose destination is the sec= urity destination of the path segment. Apply the additional bundle transmi= ssion security measures to the encapsulating bundle: encrypt its payload (t= he Administrative Record, containing the encapsulated bundle), encrypt exte= nsion blocks as copied from the encapsulated bundle, etc. Then forward the= encapsulating bundle. > When route service uncertainty forces a bundle to be routed over multiple= parallel additionally secured segments of its end-to-end path, encapsulate= it as above but within multiple different encapsulating bundles, one for e= ach of the parallel segments, and forward all of them. > At the destination of a bundle, apply all relevant bundle reception secur= ity measures and then, if the payload is an encapsulation Administrative Re= cord, extract the encapsulated bundle from the Administrative Record and si= mply forward it. > > I believe this would have the following impacts on DTN security: > > No EID references in BSP, simplifying canonicalization. > PCBs only encrypt payloads, never PIBs or PCBs (encrypting the encapsulat= ed bundle encrypts all three at once), so no correlators in BSP. (Except f= or BABs, no bundle ever has more than one occurrence of any type of BSP blo= ck. And there will never be more than two BABs, one immediately following = the primary block and one that is the final block in the bundle, so that co= rrelation is structural.) > No delicate =93replacement=94 process for unraveling PCB nesting at the d= estination. > No possible confusion about the correct order of application of BSP block= s. > No possible conflict among security destinations of different BSP blocks. > Security paths can never overlap. > Any routing implementation can always accommodate any security regime: ro= utes that must be followed to ensure security are encoded into routing info= rmation at the forwarding node, not into the bundle. (A little like the la= te binding principle.) > Any routing environment can always be made arbitrarily secure =96 no need= to require specially BSP-aware routing elements. > Ciphersuite design is simplified, so a wider array of useful ciphersuites= can be developed without imposing bug-prone complexity. Minimizes possibl= e security problems. > > As an example of how I think this could work, see the attached diagram: > > Node A is sending a bundle to node K. Nodes A, B, J, and K are within th= e low-risk =93W=94 security region; nodes C and G are gateways between regi= on W and the more hazardous region X; node D is another node in X; nodes E = and F are gateways between region X and even more hazardous region Y; nodes= H and I are gateways between X and hazardous region Z. > At A the bundle is simply forwarded to B. > At B the routing element realizes that the bundle has to traverse region = X in order to get to K, so it forwards the bundle to C. > The routing element at C encapsulates the bundle in an Admin Record, crea= tes a new bundle destined for G (the egress from region X) whose source is = C and whose payload is that Admin Record, encrypts the payload, attaches a = PCB, and forwards the bundle to D. > D realizes that the bundle has to traverse region Y in order to get to G,= so it forwards the bundle to E. > E encapsulates the bundle in an Admin Record, creates a new bundle destin= ed for F (the egress from region Y) whose source is E and whose payload is = that Admin Record, encrypts the payload, attaches a PCB, and forwards the b= undle to F. > The bundle protocol agent at F receives the bundle, decrypts it, and pass= es the payload (an Admin Record) to the application agent. The administrat= ive element of the application agent at F receives the Admin Record, extrac= ts the encapsulated bundle destined for G, and queues it to be forwarded. = The routing element at F sees this bundle and forwards it to G. > The bundle protocol agent at G receives the bundle, decrypts it, and pass= es the payload (an Admin Record) to the application agent. The administrat= ive element of the application agent at G receives the Admin Record, extrac= ts the encapsulated bundle destined for K, and queues it to be forwarded. = The routing element at G sees this bundle, realizes that the bundle has to = traverse region Z in order to get to K, and therefore forwards the bundle t= o H. > H encapsulates the bundle in an Admin Record, creates a new bundle destin= ed for I (the egress from region Z) whose source is H and whose payload is = that Admin Record, encrypts the payload, attaches a PCB, and forwards the b= undle to I. > The bundle protocol agent at I receives the bundle, decrypts it, and pass= es the payload (an Admin Record) to the application agent. The administrat= ive element of the application agent at I receives the Admin Record, extrac= ts the encapsulated bundle destined for K, and queues it to be forwarded. = The routing element at I sees this bundle and forwards it to J. > At J the bundle is simply forwarded to K. > At K the bundle=92s payload is passed to the application. > > I think this approach would combine simplicity with quite a lot of operat= ional power, making everything cheaper and safer. > So, having now stirred the hornet=92s nest, I will beat a hasty retreat f= or a week while I am on vacation. I=92ll try to follow up when I get back. > Have a nice Thanksgiving, everybody. > Scott > > -----Original Message----- > From: Peter Lovell [mailto:plovell@mac.com] > Sent: Monday, October 22, 2012 1:28 PM > To: Burleigh, Scott C (313B); ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell > Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN= 2 > > On Wed, Oct 24, 2012, Burleigh, Scott C (313B) wrote: > >> In view of which, I've now become a bigger fan of bundle-in-bundle >>tunneling than I've been in the past. > > Hi Scott, > > I agree. I'm also a big fan, for a bunch of reasons. However, as I mentio= ned to Angela, the current [i.e. latest, expired] draft seems a bit "funky"= to me. There's no indication in the bundle that it's BiB and you need some= special EID to perform the decapsulation. Maybe that's just like an assign= ed port in TCP but we don't yet have such a mechanism. The multiple-bundle = thing is OK, I guess, but I don't see much use for it other than volume gat= eway-to-gateway traffic and I think that such heavy-duty tunnels could be s= pecially optimized. > > I need to go back and review all the discussions about BiB -- we worked i= t quite a bit but the spec never gained enough consensus to move forward. I= think it would be a good idea to revisit it now and get a solid draft that= has wider support. Maybe the email discussions will help us get there. > > Thanks.....Peter > > > > > ---------- Forwarded message ---------- > From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" > To: "Burleigh, Scott C" , "dtn-security@ir= tf.org" > Cc: > Date: Tue, 22 Jan 2013 17:47:47 -0600 > Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destination= s inDTN2 > Agreed; that makes sense. > > ________________________________ > From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] > Sent: Tuesday, January 22, 2013 6:35 PM > To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.org > Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destination= s inDTN2 > > Wes, I agree that some code change would be entailed in implementing this= proposal, but I think a large proportion of the code =96 the general flow = of processing the extension blocks, the canonicalization, the ciphersuites,= really almost everything that would have been implemented to handle the si= mple case of security source/destination being identical to bundle source/d= estination =96 would be preserved. I suspect that much of what I was propo= sing here involves removing functionality that most developers haven=92t im= plemented yet anyway, because of the potential pitfalls. > > > > Scott > > > > From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy= @nasa.gov] > Sent: Tuesday, January 22, 2013 3:20 PM > To: Burleigh, Scott C (313B); dtn-security@irtf.org > Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destination= s inDTN2 > > > > It looks like basically a good idea to me. > > > > I recall sometime in 2006 or 2007ish pointing out that security destinati= ons needed to work more like IPsec tunnel-mode endpoints in order to make t= he routing work correctly, and I think what you're proposing here accomplis= hes that in a better way. > > > > Though I think cycles would be better spent on KMP issues that are actual= ly HARD, and *then* circling back to see what could be tweaked in the BSP, = I definitely think this proposed change is something that would improve the= BSP a bit in the meantime. > > > > I don't think it can be done in a way that's friendly to the existing cod= ebase like Stephen suggests shooting for. > > > > ________________________________ > > From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On Be= half Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] > Sent: Tuesday, January 22, 2013 5:37 PM > To: dtn-security@irtf.org > Subject: [dtn-security] FW: Re(19): Implementing Security Destinations in= DTN2 > > Hi. Late last September, several of us spun off a sub-thread talking abo= ut how the processing of bundles with multiple security destinations could = be handled in DTN implementations. I won=92t try to recreate all of the ar= guments on all sides, but I think we did converge on agreement that the cur= rent BSP mechanism for complex, multi-destination security could be difficu= lt to realize in coherent fashion across the network. After puzzling over = this for a while, I came up with a concept (below) that I think would be si= mpler, safer, and even more powerful than the current protocol design. How= do we all feel about this? Would it be worthwhile for DTNRG to invest in = a 6257bis RFC along these lines? > > > > Scott > > _____________________________________________ > From: Burleigh, Scott C (313B) > Sent: Friday, November 16, 2012 5:05 PM > To: 'Peter Lovell'; ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss > Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in= DTN2 > > > > > > Hi, Peter. At the risk (I know) of getting a lot of people severely tick= ed off at me, I am going to offer a modest proposal for improving the Bundl= e Security Protocol, inspired by this thread. > > I propose to adopt a new design principle for Bundle Security Protocol: t= he routing element of a bundle protocol agent should never need to inspect = a bundle=92s BSP extension blocks in order to select the node(s) to forward= the bundle to. > > That is, BSP should provide security, not dictate routes. > > My rationale for proposing this principle is that I believe it would: > > =B7 Simplify BSP, thereby reducing the incidence of bugs and maki= ng Bundle Security significantly less expensive to implement and sustain. > > =B7 Broaden the scope of BSP deployment by eliminating its depend= ence on specific, BSP-aware routing implementations, thereby increasing the= overall security of DTN. > > =B7 Reduce the cost of developing and improving routing implement= ations by removing any requirement that they be BSP-aware, and broaden the = scope of deployment of non-BSP-aware routing implementations by enabling th= em to be used in environments requiring arbitrarily powerful security. The= reby, improve DTN operational performance. > > Here's how I would apply this principle: > > 1. Eliminate security sources and security destinations from all BS= P blocks. The security source of a BSP block would always be the bundle=92= s source. The security destination of a BSP block would always be the bund= le=92s destination. > > 2. Add a new Administrative Record type for Bundle-in-Bundle encaps= ulation. > > 3. When additional security must be applied to a bundle on some seg= ment of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle E= ncapsulation Administrative Record that is the payload of a new bundle whos= e source is the security source of the path segment and whose destination i= s the security destination of the path segment. Apply the additional bundl= e transmission security measures to the encapsulating bundle: encrypt its p= ayload (the Administrative Record, containing the encapsulated bundle), enc= rypt extension blocks as copied from the encapsulated bundle, etc. Then fo= rward the encapsulating bundle. > > 4. When route service uncertainty forces a bundle to be routed over= multiple parallel additionally secured segments of its end-to-end path, en= capsulate it as above but within multiple different encapsulating bundles, = one for each of the parallel segments, and forward all of them. > > 5. At the destination of a bundle, apply all relevant bundle recept= ion security measures and then, if the payload is an encapsulation Administ= rative Record, extract the encapsulated bundle from the Administrative Reco= rd and simply forward it. > > I believe this would have the following impacts on DTN security: > > =B7 No EID references in BSP, simplifying canonicalization. > > =B7 PCBs only encrypt payloads, never PIBs or PCBs (encrypting th= e encapsulated bundle encrypts all three at once), so no correlators in BSP= . (Except for BABs, no bundle ever has more than one occurrence of any typ= e of BSP block. And there will never be more than two BABs, one immediatel= y following the primary block and one that is the final block in the bundle= , so that correlation is structural.) > > =B7 No delicate =93replacement=94 process for unraveling PCB nest= ing at the destination. > > =B7 No possible confusion about the correct order of application = of BSP blocks. > > =B7 No possible conflict among security destinations of different= BSP blocks. > > =B7 Security paths can never overlap. > > =B7 Any routing implementation can always accommodate any securit= y regime: routes that must be followed to ensure security are encoded into = routing information at the forwarding node, not into the bundle. (A little= like the late binding principle.) > > =B7 Any routing environment can always be made arbitrarily secure= =96 no need to require specially BSP-aware routing elements. > > =B7 Ciphersuite design is simplified, so a wider array of useful = ciphersuites can be developed without imposing bug-prone complexity. Minim= izes possible security problems. > > As an example of how I think this could work, see the attached diagram: > > 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are = within the low-risk =93W=94 security region; nodes C and G are gateways bet= ween region W and the more hazardous region X; node D is another node in X;= nodes E and F are gateways between region X and even more hazardous region= Y; nodes H and I are gateways between X and hazardous region Z. > > 2. At A the bundle is simply forwarded to B. > > 3. At B the routing element realizes that the bundle has to travers= e region X in order to get to K, so it forwards the bundle to C. > > 4. The routing element at C encapsulates the bundle in an Admin Rec= ord, creates a new bundle destined for G (the egress from region X) whose s= ource is C and whose payload is that Admin Record, encrypts the payload, at= taches a PCB, and forwards the bundle to D. > > 5. D realizes that the bundle has to traverse region Y in order to = get to G, so it forwards the bundle to E. > > 6. E encapsulates the bundle in an Admin Record, creates a new bund= le destined for F (the egress from region Y) whose source is E and whose pa= yload is that Admin Record, encrypts the payload, attaches a PCB, and forwa= rds the bundle to F. > > 7. The bundle protocol agent at F receives the bundle, decrypts it,= and passes the payload (an Admin Record) to the application agent. The ad= ministrative element of the application agent at F receives the Admin Recor= d, extracts the encapsulated bundle destined for G, and queues it to be for= warded. The routing element at F sees this bundle and forwards it to G. > > 8. The bundle protocol agent at G receives the bundle, decrypts it,= and passes the payload (an Admin Record) to the application agent. The ad= ministrative element of the application agent at G receives the Admin Recor= d, extracts the encapsulated bundle destined for K, and queues it to be for= warded. The routing element at G sees this bundle, realizes that the bundl= e has to traverse region Z in order to get to K, and therefore forwards the= bundle to H. > > 9. H encapsulates the bundle in an Admin Record, creates a new bund= le destined for I (the egress from region Z) whose source is H and whose pa= yload is that Admin Record, encrypts the payload, attaches a PCB, and forwa= rds the bundle to I. > > 10. The bundle protocol agent at I receives the bundle, decrypts it, an= d passes the payload (an Admin Record) to the application agent. The admin= istrative element of the application agent at I receives the Admin Record, = extracts the encapsulated bundle destined for K, and queues it to be forwar= ded. The routing element at I sees this bundle and forwards it to J. > > 11. At J the bundle is simply forwarded to K. > > 12. At K the bundle=92s payload is passed to the application. > > I think this approach would combine simplicity with quite a lot of operat= ional power, making everything cheaper and safer. > > So, having now stirred the hornet=92s nest, I will beat a hasty retreat f= or a week while I am on vacation. I=92ll try to follow up when I get back. > > Have a nice Thanksgiving, everybody. > > Scott > > > > -----Original Message----- > From: Peter Lovell [mailto:plovell@mac.com] > Sent: Monday, October 22, 2012 1:28 PM > To: Burleigh, Scott C (313B); ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell > Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN= 2 > > > > On Wed, Oct 24, 2012, Burleigh, Scott C (313B) wrote: > > > >> In view of which, I've now become a bigger fan of bundle-in-bundle > >>tunneling than I've been in the past. > > > > Hi Scott, > > > > I agree. I'm also a big fan, for a bunch of reasons. However, as I mentio= ned to Angela, the current [i.e. latest, expired] draft seems a bit "funky"= to me. There's no indication in the bundle that it's BiB and you need some= special EID to perform the decapsulation. Maybe that's just like an assign= ed port in TCP but we don't yet have such a mechanism. The multiple-bundle = thing is OK, I guess, but I don't see much use for it other than volume gat= eway-to-gateway traffic and I think that such heavy-duty tunnels could be s= pecially optimized. > > > > I need to go back and review all the discussions about BiB -- we worked i= t quite a bit but the spec never gained enough consensus to move forward. I= think it would be a good idea to revisit it now and get a solid draft that= has wider support. Maybe the email discussions will help us get there. > > > > Thanks.....Peter > > > > > > > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security > From scott.c.burleigh@jpl.nasa.gov Wed Jan 23 11:05:19 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFD121F8A4B for ; Wed, 23 Jan 2013 11:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfz9ZCGOu24N for ; Wed, 23 Jan 2013 11:05:17 -0800 (PST) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 23D1D21F871C for ; Wed, 23 Jan 2013 11:05:17 -0800 (PST) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0NJ5E4h002199 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Wed, 23 Jan 2013 11:05:15 -0800 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.60]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.02.0318.001; Wed, 23 Jan 2013 11:05:15 -0800 From: "Burleigh, Scott C (313B)" To: "dtn-security@irtf.org" Thread-Topic: [dtn-security] dtn-security Digest, Vol 9, Issue 4 Thread-Index: AQHN+ZPuFbqQaeuxFUeSJ76vVDa5BphXOFZQ Date: Wed, 23 Jan 2013 19:05:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:05:19 -0000 You're right, Angela, I definitely wouldn't want bundles to have to be enca= psulated every time any security block was added. The idea here would be t= hat you only encapsulate bundle Q whose source is A and whose destination i= s Z if you know -- at the time you are forwarding Q -- that in order for Q = to reach its destination safely it has got to traverse an additionally secu= red path segment from node X to node Y. In this case you'd create a new bu= ndle R whose source is X, whose destination is Y, and whose payload is Q, t= o which you would attach the required additional security blocks. That is, you'd encapsulate under exactly those conditions under which, in 6= 257 as written, you would annotate your additional BSP extension blocks wit= h security source and security destination other than the original source a= nd final destination. The reason to do this would be to delegate to Routin= g, in a straightforward and transparent manner, the job of ensuring that th= e bundle is forwarded to the security destination. If a node just wants to add a signature to a bundle, the question is whethe= r the node that will validate that signature (and therefore must know the c= orresponding key) is the final destination or some interim destination that= the bundle MUST be routed through. If the latter, then yes, you'd have to= encapsulate, because you're constraining the routing system. If the forme= r -- and if the validating destination node doesn't care which node attache= d the signature -- then no. You're right that encapsulation would eliminate non-destination nodes' abil= ity to peer into the original bundle's payload. Is that really a desirable= feature? I'm a little skeptical that we should rely on any node other tha= n the final destination having access to the payload; certainly if the payl= oad were encrypted this ought to be moot. Maybe there's still some desire = to be able to support deep packet/bundle inspection in firewall-like struct= ures, but I'd think that anything as intrusive as that wouldn't be deterred= by a bit of encapsulation. If a node wanted to sign and then encrypt a bundle, there would need to be = additional encapsulation if the node that must decrypt the bundle and/or th= e node that must validate the signature is other than the destination node.= Again, you'd have to encapsulate in order to cause the bundle to be route= d in the manner in which you require it to be routed. The same general principle would apply to extension security blocks. If th= e bundle has to be routed to a specific node in order for extension blocks = to be decrypted or validated -- and that node is different from the destina= tion node and from node to which it must be routed for the purpose of decry= pting/validating the payload -- then you'd have to encapsulate in order to = cause the bundle to be routed in the manner in which you require it to be r= outed. I think you could still encrypt different extension blocks with different k= eys without encapsulation, so long as the bundle's destination knew all of = the keys. Maybe you'd still want correlators to indicate which keys apply = to which blocks, but I would think that would be managed by policy rather t= han by instructions carried in the bundle. If not, though, then you're rig= ht, we wouldn't be able to get rid of correlators. One thing that this concept does is force the forwarding node to actually k= now what it's doing. It's no longer sufficient just to attach several secu= rity blocks and let the network try to figure out what you meant. You have= to have an actual plan for effecting all of the processing that you are go= ing to require, because that plan will drive the order of encapsulation and= security block attachment. I see that as an advantage rather than a drawb= ack, though. Scott -----Original Message----- From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] = On Behalf Of Angela Hennessy Sent: Wednesday, January 23, 2013 10:03 AM To: dtn-security@irtf.org Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 Hi Scott, I like how this approach simplifies the routing and gets rid of the securit= y src/dest and EID refs. I was a little confused though about how this woul= d work with some of the combinations of security blocks: If a node just wants to add a signature to a bundle, would this require the= bundle to be encapsulated? One of the advantages of BSP is that non securi= ty-aware nodes can still access the payload by just ignoring the PIB block.= Wouldn't we lose that feature if the bundle were encapsulated? If a node wants to sign and then encrypt the bundle, does this require the = bundle to be encapsulated twice? How would we handle signing/encrypting extension blocks? Would this require= a third encapsulation? Wouldn't we still need correlators in case multiple= extension blocks are encrypted with the same key, or would we not allow di= fferent extension blocks to be encrypted with different keys? Thanks, Angela On Tue, Jan 22, 2013 at 6:49 PM, wrote: > If you have received this digest without all the individual message=20 > attachments you will need to update your digest options in your list=20 > subscription. To do so, go to > > https://www.irtf.org/mailman/listinfo/dtn-security > > Click the 'Unsubscribe or edit options' button, log in, and set "Get=20 > MIME or Plain Text Digests?" to MIME. You can set this option=20 > globally for all the list digests you receive at this point. > > > > Send dtn-security mailing list submissions to > dtn-security@irtf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/dtn-security > or, via email, send a message with subject or body 'help' to > dtn-security-request@irtf.org > > You can reach the person managing the list at > dtn-security-owner@irtf.org > > When replying, please edit your Subject line so it is more specific=20 > than "Re: Contents of dtn-security digest..." > > Today's Topics: > > 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 > (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) > 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 > (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) > > > ---------- Forwarded message ---------- > From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]"=20 > > To: "Burleigh, Scott C" ,=20 > "dtn-security@irtf.org" > Cc: > Date: Tue, 22 Jan 2013 17:19:48 -0600 > Subject: Re: [dtn-security] FW: Re(19): Implementing Security=20 > Destinations inDTN2 It looks like basically a good idea to me. > > I recall sometime in 2006 or 2007ish pointing out that security destinati= ons needed to work more like IPsec tunnel-mode endpoints in order to make t= he routing work correctly, and I think what you're proposing here accomplis= hes that in a better way. > > Though I think cycles would be better spent on KMP issues that are actual= ly HARD, and *then* circling back to see what could be tweaked in the BSP, = I definitely think this proposed change is something that would improve the= BSP a bit in the meantime. > > I don't think it can be done in a way that's friendly to the existing cod= ebase like Stephen suggests shooting for. > > ________________________________ > From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On=20 > Behalf Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] > Sent: Tuesday, January 22, 2013 5:37 PM > To: dtn-security@irtf.org > Subject: [dtn-security] FW: Re(19): Implementing Security Destinations=20 > inDTN2 > > Hi. Late last September, several of us spun off a sub-thread talking abo= ut how the processing of bundles with multiple security destinations could = be handled in DTN implementations. I won't try to recreate all of the argu= ments on all sides, but I think we did converge on agreement that the curre= nt BSP mechanism for complex, multi-destination security could be difficult= to realize in coherent fashion across the network. After puzzling over th= is for a while, I came up with a concept (below) that I think would be simp= ler, safer, and even more powerful than the current protocol design. How d= o we all feel about this? Would it be worthwhile for DTNRG to invest in a = 6257bis RFC along these lines? > > Scott > _____________________________________________ > From: Burleigh, Scott C (313B) > Sent: Friday, November 16, 2012 5:05 PM > To: 'Peter Lovell'; ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss > Subject: RE: Re(19): [dtn-security] Implementing Security Destinations=20 > in DTN2 > > > Hi, Peter. At the risk (I know) of getting a lot of people severely tick= ed off at me, I am going to offer a modest proposal for improving the Bundl= e Security Protocol, inspired by this thread. > I propose to adopt a new design principle for Bundle Security Protocol: t= he routing element of a bundle protocol agent should never need to inspect = a bundle's BSP extension blocks in order to select the node(s) to forward t= he bundle to. > That is, BSP should provide security, not dictate routes. > My rationale for proposing this principle is that I believe it would: > > Simplify BSP, thereby reducing the incidence of bugs and making Bundle Se= curity significantly less expensive to implement and sustain. > Broaden the scope of BSP deployment by eliminating its dependence on spec= ific, BSP-aware routing implementations, thereby increasing the overall sec= urity of DTN. > Reduce the cost of developing and improving routing implementations by re= moving any requirement that they be BSP-aware, and broaden the scope of dep= loyment of non-BSP-aware routing implementations by enabling them to be use= d in environments requiring arbitrarily powerful security. Thereby, improv= e DTN operational performance. > > Here's how I would apply this principle: > > Eliminate security sources and security destinations from all BSP blocks.= The security source of a BSP block would always be the bundle's source. = The security destination of a BSP block would always be the bundle's destin= ation. > Add a new Administrative Record type for Bundle-in-Bundle encapsulation. > When additional security must be applied to a bundle on some segment of i= ts end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Encapsulat= ion Administrative Record that is the payload of a new bundle whose source = is the security source of the path segment and whose destination is the sec= urity destination of the path segment. Apply the additional bundle transmi= ssion security measures to the encapsulating bundle: encrypt its payload (t= he Administrative Record, containing the encapsulated bundle), encrypt exte= nsion blocks as copied from the encapsulated bundle, etc. Then forward the= encapsulating bundle. > When route service uncertainty forces a bundle to be routed over multiple= parallel additionally secured segments of its end-to-end path, encapsulate= it as above but within multiple different encapsulating bundles, one for e= ach of the parallel segments, and forward all of them. > At the destination of a bundle, apply all relevant bundle reception secur= ity measures and then, if the payload is an encapsulation Administrative Re= cord, extract the encapsulated bundle from the Administrative Record and si= mply forward it. > > I believe this would have the following impacts on DTN security: > > No EID references in BSP, simplifying canonicalization. > PCBs only encrypt payloads, never PIBs or PCBs (encrypting the=20 > encapsulated bundle encrypts all three at once), so no correlators in BSP= . (Except for BABs, no bundle ever has more than one occurrence of any typ= e of BSP block. And there will never be more than two BABs, one immediatel= y following the primary block and one that is the final block in the bundle= , so that correlation is structural.) No delicate "replacement" process for= unraveling PCB nesting at the destination. > No possible confusion about the correct order of application of BSP block= s. > No possible conflict among security destinations of different BSP blocks. > Security paths can never overlap. > Any routing implementation can always accommodate any security regime:=20 > routes that must be followed to ensure security are encoded into routing = information at the forwarding node, not into the bundle. (A little like th= e late binding principle.) Any routing environment can always be made arbit= rarily secure - no need to require specially BSP-aware routing elements. > Ciphersuite design is simplified, so a wider array of useful ciphersuites= can be developed without imposing bug-prone complexity. Minimizes possibl= e security problems. > > As an example of how I think this could work, see the attached diagram: > > Node A is sending a bundle to node K. Nodes A, B, J, and K are within th= e low-risk "W" security region; nodes C and G are gateways between region W= and the more hazardous region X; node D is another node in X; nodes E and = F are gateways between region X and even more hazardous region Y; nodes H a= nd I are gateways between X and hazardous region Z. > At A the bundle is simply forwarded to B. > At B the routing element realizes that the bundle has to traverse region = X in order to get to K, so it forwards the bundle to C. > The routing element at C encapsulates the bundle in an Admin Record, crea= tes a new bundle destined for G (the egress from region X) whose source is = C and whose payload is that Admin Record, encrypts the payload, attaches a = PCB, and forwards the bundle to D. > D realizes that the bundle has to traverse region Y in order to get to G,= so it forwards the bundle to E. > E encapsulates the bundle in an Admin Record, creates a new bundle destin= ed for F (the egress from region Y) whose source is E and whose payload is = that Admin Record, encrypts the payload, attaches a PCB, and forwards the b= undle to F. > The bundle protocol agent at F receives the bundle, decrypts it, and pass= es the payload (an Admin Record) to the application agent. The administrat= ive element of the application agent at F receives the Admin Record, extrac= ts the encapsulated bundle destined for G, and queues it to be forwarded. = The routing element at F sees this bundle and forwards it to G. > The bundle protocol agent at G receives the bundle, decrypts it, and pass= es the payload (an Admin Record) to the application agent. The administrat= ive element of the application agent at G receives the Admin Record, extrac= ts the encapsulated bundle destined for K, and queues it to be forwarded. = The routing element at G sees this bundle, realizes that the bundle has to = traverse region Z in order to get to K, and therefore forwards the bundle t= o H. > H encapsulates the bundle in an Admin Record, creates a new bundle destin= ed for I (the egress from region Z) whose source is H and whose payload is = that Admin Record, encrypts the payload, attaches a PCB, and forwards the b= undle to I. > The bundle protocol agent at I receives the bundle, decrypts it, and pass= es the payload (an Admin Record) to the application agent. The administrat= ive element of the application agent at I receives the Admin Record, extrac= ts the encapsulated bundle destined for K, and queues it to be forwarded. = The routing element at I sees this bundle and forwards it to J. > At J the bundle is simply forwarded to K. > At K the bundle's payload is passed to the application. > > I think this approach would combine simplicity with quite a lot of operat= ional power, making everything cheaper and safer. > So, having now stirred the hornet's nest, I will beat a hasty retreat for= a week while I am on vacation. I'll try to follow up when I get back. > Have a nice Thanksgiving, everybody. > Scott > > -----Original Message----- > From: Peter Lovell [mailto:plovell@mac.com] > Sent: Monday, October 22, 2012 1:28 PM > To: Burleigh, Scott C (313B); ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell > Subject: Re(19): [dtn-security] Implementing Security Destinations in=20 > DTN2 > > On Wed, Oct 24, 2012, Burleigh, Scott C (313B) wrote: > >> In view of which, I've now become a bigger fan of bundle-in-bundle=20 >>tunneling than I've been in the past. > > Hi Scott, > > I agree. I'm also a big fan, for a bunch of reasons. However, as I mentio= ned to Angela, the current [i.e. latest, expired] draft seems a bit "funky"= to me. There's no indication in the bundle that it's BiB and you need some= special EID to perform the decapsulation. Maybe that's just like an assign= ed port in TCP but we don't yet have such a mechanism. The multiple-bundle = thing is OK, I guess, but I don't see much use for it other than volume gat= eway-to-gateway traffic and I think that such heavy-duty tunnels could be s= pecially optimized. > > I need to go back and review all the discussions about BiB -- we worked i= t quite a bit but the spec never gained enough consensus to move forward. I= think it would be a good idea to revisit it now and get a solid draft that= has wider support. Maybe the email discussions will help us get there. > > Thanks.....Peter > > > > > ---------- Forwarded message ---------- > From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]"=20 > > To: "Burleigh, Scott C" ,=20 > "dtn-security@irtf.org" > Cc: > Date: Tue, 22 Jan 2013 17:47:47 -0600 > Subject: Re: [dtn-security] FW: Re(19): Implementing Security=20 > Destinations inDTN2 Agreed; that makes sense. > > ________________________________ > From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] > Sent: Tuesday, January 22, 2013 6:35 PM > To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.];=20 > dtn-security@irtf.org > Subject: RE: [dtn-security] FW: Re(19): Implementing Security=20 > Destinations inDTN2 > > Wes, I agree that some code change would be entailed in implementing this= proposal, but I think a large proportion of the code - the general flow of= processing the extension blocks, the canonicalization, the ciphersuites, r= eally almost everything that would have been implemented to handle the simp= le case of security source/destination being identical to bundle source/des= tination - would be preserved. I suspect that much of what I was proposing= here involves removing functionality that most developers haven't implemen= ted yet anyway, because of the potential pitfalls. > > > > Scott > > > > From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]=20 > [mailto:wesley.m.eddy@nasa.gov] > Sent: Tuesday, January 22, 2013 3:20 PM > To: Burleigh, Scott C (313B); dtn-security@irtf.org > Subject: RE: [dtn-security] FW: Re(19): Implementing Security=20 > Destinations inDTN2 > > > > It looks like basically a good idea to me. > > > > I recall sometime in 2006 or 2007ish pointing out that security destinati= ons needed to work more like IPsec tunnel-mode endpoints in order to make t= he routing work correctly, and I think what you're proposing here accomplis= hes that in a better way. > > > > Though I think cycles would be better spent on KMP issues that are actual= ly HARD, and *then* circling back to see what could be tweaked in the BSP, = I definitely think this proposed change is something that would improve the= BSP a bit in the meantime. > > > > I don't think it can be done in a way that's friendly to the existing cod= ebase like Stephen suggests shooting for. > > > > ________________________________ > > From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On=20 > Behalf Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] > Sent: Tuesday, January 22, 2013 5:37 PM > To: dtn-security@irtf.org > Subject: [dtn-security] FW: Re(19): Implementing Security Destinations=20 > inDTN2 > > Hi. Late last September, several of us spun off a sub-thread talking abo= ut how the processing of bundles with multiple security destinations could = be handled in DTN implementations. I won't try to recreate all of the argu= ments on all sides, but I think we did converge on agreement that the curre= nt BSP mechanism for complex, multi-destination security could be difficult= to realize in coherent fashion across the network. After puzzling over th= is for a while, I came up with a concept (below) that I think would be simp= ler, safer, and even more powerful than the current protocol design. How d= o we all feel about this? Would it be worthwhile for DTNRG to invest in a = 6257bis RFC along these lines? > > > > Scott > > _____________________________________________ > From: Burleigh, Scott C (313B) > Sent: Friday, November 16, 2012 5:05 PM > To: 'Peter Lovell'; ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss > Subject: RE: Re(19): [dtn-security] Implementing Security Destinations=20 > in DTN2 > > > > > > Hi, Peter. At the risk (I know) of getting a lot of people severely tick= ed off at me, I am going to offer a modest proposal for improving the Bundl= e Security Protocol, inspired by this thread. > > I propose to adopt a new design principle for Bundle Security Protocol: t= he routing element of a bundle protocol agent should never need to inspect = a bundle's BSP extension blocks in order to select the node(s) to forward t= he bundle to. > > That is, BSP should provide security, not dictate routes. > > My rationale for proposing this principle is that I believe it would: > > * Simplify BSP, thereby reducing the incidence of bugs and making= Bundle Security significantly less expensive to implement and sustain. > > * Broaden the scope of BSP deployment by eliminating its dependen= ce on specific, BSP-aware routing implementations, thereby increasing the o= verall security of DTN. > > * Reduce the cost of developing and improving routing implementat= ions by removing any requirement that they be BSP-aware, and broaden the sc= ope of deployment of non-BSP-aware routing implementations by enabling them= to be used in environments requiring arbitrarily powerful security. There= by, improve DTN operational performance. > > Here's how I would apply this principle: > > 1. Eliminate security sources and security destinations from all BS= P blocks. The security source of a BSP block would always be the bundle's = source. The security destination of a BSP block would always be the bundle= 's destination. > > 2. Add a new Administrative Record type for Bundle-in-Bundle encaps= ulation. > > 3. When additional security must be applied to a bundle on some seg= ment of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle E= ncapsulation Administrative Record that is the payload of a new bundle whos= e source is the security source of the path segment and whose destination i= s the security destination of the path segment. Apply the additional bundl= e transmission security measures to the encapsulating bundle: encrypt its p= ayload (the Administrative Record, containing the encapsulated bundle), enc= rypt extension blocks as copied from the encapsulated bundle, etc. Then fo= rward the encapsulating bundle. > > 4. When route service uncertainty forces a bundle to be routed over= multiple parallel additionally secured segments of its end-to-end path, en= capsulate it as above but within multiple different encapsulating bundles, = one for each of the parallel segments, and forward all of them. > > 5. At the destination of a bundle, apply all relevant bundle recept= ion security measures and then, if the payload is an encapsulation Administ= rative Record, extract the encapsulated bundle from the Administrative Reco= rd and simply forward it. > > I believe this would have the following impacts on DTN security: > > * No EID references in BSP, simplifying canonicalization. > > * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the = encapsulated bundle encrypts all three at once), so no correlators in BSP. = (Except for BABs, no bundle ever has more than one occurrence of any type = of BSP block. And there will never be more than two BABs, one immediately = following the primary block and one that is the final block in the bundle, = so that correlation is structural.) > > * No delicate "replacement" process for unraveling PCB nesting at= the destination. > > * No possible confusion about the correct order of application of= BSP blocks. > > * No possible conflict among security destinations of different B= SP blocks. > > * Security paths can never overlap. > > * Any routing implementation can always accommodate any security = regime: routes that must be followed to ensure security are encoded into ro= uting information at the forwarding node, not into the bundle. (A little l= ike the late binding principle.) > > * Any routing environment can always be made arbitrarily secure -= no need to require specially BSP-aware routing elements. > > * Ciphersuite design is simplified, so a wider array of useful ci= phersuites can be developed without imposing bug-prone complexity. Minimiz= es possible security problems. > > As an example of how I think this could work, see the attached diagram: > > 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are = within the low-risk "W" security region; nodes C and G are gateways between= region W and the more hazardous region X; node D is another node in X; nod= es E and F are gateways between region X and even more hazardous region Y; = nodes H and I are gateways between X and hazardous region Z. > > 2. At A the bundle is simply forwarded to B. > > 3. At B the routing element realizes that the bundle has to travers= e region X in order to get to K, so it forwards the bundle to C. > > 4. The routing element at C encapsulates the bundle in an Admin Rec= ord, creates a new bundle destined for G (the egress from region X) whose s= ource is C and whose payload is that Admin Record, encrypts the payload, at= taches a PCB, and forwards the bundle to D. > > 5. D realizes that the bundle has to traverse region Y in order to = get to G, so it forwards the bundle to E. > > 6. E encapsulates the bundle in an Admin Record, creates a new bund= le destined for F (the egress from region Y) whose source is E and whose pa= yload is that Admin Record, encrypts the payload, attaches a PCB, and forwa= rds the bundle to F. > > 7. The bundle protocol agent at F receives the bundle, decrypts it,= and passes the payload (an Admin Record) to the application agent. The ad= ministrative element of the application agent at F receives the Admin Recor= d, extracts the encapsulated bundle destined for G, and queues it to be for= warded. The routing element at F sees this bundle and forwards it to G. > > 8. The bundle protocol agent at G receives the bundle, decrypts it,= and passes the payload (an Admin Record) to the application agent. The ad= ministrative element of the application agent at G receives the Admin Recor= d, extracts the encapsulated bundle destined for K, and queues it to be for= warded. The routing element at G sees this bundle, realizes that the bundl= e has to traverse region Z in order to get to K, and therefore forwards the= bundle to H. > > 9. H encapsulates the bundle in an Admin Record, creates a new bund= le destined for I (the egress from region Z) whose source is H and whose pa= yload is that Admin Record, encrypts the payload, attaches a PCB, and forwa= rds the bundle to I. > > 10. The bundle protocol agent at I receives the bundle, decrypts it, an= d passes the payload (an Admin Record) to the application agent. The admin= istrative element of the application agent at I receives the Admin Record, = extracts the encapsulated bundle destined for K, and queues it to be forwar= ded. The routing element at I sees this bundle and forwards it to J. > > 11. At J the bundle is simply forwarded to K. > > 12. At K the bundle's payload is passed to the application. > > I think this approach would combine simplicity with quite a lot of operat= ional power, making everything cheaper and safer. > > So, having now stirred the hornet's nest, I will beat a hasty retreat for= a week while I am on vacation. I'll try to follow up when I get back. > > Have a nice Thanksgiving, everybody. > > Scott > > > > -----Original Message----- > From: Peter Lovell [mailto:plovell@mac.com] > Sent: Monday, October 22, 2012 1:28 PM > To: Burleigh, Scott C (313B); ahennes1@math.umd.edu > Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell > Subject: Re(19): [dtn-security] Implementing Security Destinations in=20 > DTN2 > > > > On Wed, Oct 24, 2012, Burleigh, Scott C (313B) wrote: > > > >> In view of which, I've now become a bigger fan of bundle-in-bundle > >>tunneling than I've been in the past. > > > > Hi Scott, > > > > I agree. I'm also a big fan, for a bunch of reasons. However, as I mentio= ned to Angela, the current [i.e. latest, expired] draft seems a bit "funky"= to me. There's no indication in the bundle that it's BiB and you need some= special EID to perform the decapsulation. Maybe that's just like an assign= ed port in TCP but we don't yet have such a mechanism. The multiple-bundle = thing is OK, I guess, but I don't see much use for it other than volume gat= eway-to-gateway traffic and I think that such heavy-duty tunnels could be s= pecially optimized. > > > > I need to go back and review all the discussions about BiB -- we worked i= t quite a bit but the spec never gained enough consensus to move forward. I= think it would be a good idea to revisit it now and get a solid draft that= has wider support. Maybe the email discussions will help us get there. > > > > Thanks.....Peter > > > > > > > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security > _______________________________________________ dtn-security mailing list dtn-security@irtf.org https://www.irtf.org/mailman/listinfo/dtn-security From robert.l.pitts@nasa.gov Thu Jan 24 05:52:29 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE7221F8518 for ; Thu, 24 Jan 2013 05:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUuAe6t5OZ+d for ; Thu, 24 Jan 2013 05:52:22 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 3A18A21F8A0D for ; Thu, 24 Jan 2013 05:52:19 -0800 (PST) Received: from ndmsppt02.ndc.nasa.gov (ndmsppt02.ndc.nasa.gov [198.117.0.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 50458260754; Thu, 24 Jan 2013 07:52:18 -0600 (CST) Received: from ndmshub05.ndc.nasa.gov (ndmshub05.ndc.nasa.gov [198.117.2.164]) by ndmsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r0ODqIFW027613; Thu, 24 Jan 2013 07:52:18 -0600 Received: from NDMSSCC04.ndc.nasa.gov ([198.117.2.172]) by ndmshub05.ndc.nasa.gov ([198.117.2.164]) with mapi; Thu, 24 Jan 2013 07:52:17 -0600 From: "Pitts, Robert L. (MSFC-EO60)[HOSC SERVICES CONTRACT]" To: "Birrane, Edward J." , "dtn-security@irtf.org" Date: Thu, 24 Jan 2013 07:52:17 -0600 Thread-Topic: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 Thread-Index: AQHN+PenH0ya9RV+Q02UlP2uaZf/xphV/v4wgAAB0cSAAPdeUIABiEmA Message-ID: <8A674285E0E0E344965DF27CCFEE30EC59B3709461@NDMSSCC04.ndc.nasa.gov> References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com><6af37e4869b76826d4d2108e3eef82b3.squirrel @webmail.math.umd.edu><20120923012212.319238544@smtp.mail.me.com><3c1f477d9 f6b104790e33e76236998e6.squirrel@webmail.math.umd.edu><20120926214742.2066794613@smtp. mail.me.com><20120927170104.253362480@smtp.mail.me.com><20120927172602.1763958833@smtp.mail.m e.com><20121002225237.520325524@smtp.mail.me.com><7249cc388d868cb16f14efe286351e37.squ irrel@webmail.math.umd.edu><20121004210719.1971171529@smtp.mail.me.com><20121004220537.1202245607 @smtp.mail.me.com><20121016220658.793339059@smtp.mail.me.com><20121022185905.200828573@smtp.mai l.me.com> <20121022202820.71123343@smtp.mail.me.com> , , <329D879C76FDD04AAAE84BB1D89B3970073C20BE1E@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B3970073C20BE1E@aplesfreedom.dom1.jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8A674285E0E0E344965DF27CCFEE30EC59B3709461NDMSSCC04ndcn_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-24_06:2013-01-24, 2013-01-24, 1970-01-01 signatures=0 Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 13:52:29 -0000 --_000_8A674285E0E0E344965DF27CCFEE30EC59B3709461NDMSSCC04ndcn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ed, I concur. Our work at the HOSC indicates that with the rou= ting and security coupling, we may well not have a comprehensive solution i= n a timely manner if at all. With the complex systems deployed in space an= d diverse communications links, a "GRE like" model would resolve many inter= face/boundary issues. Lee From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] = On Behalf Of Birrane, Edward J. Sent: Wednesday, January 23, 2013 11:51 AM To: dtn-security@irtf.org Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 Also agreed. Having worked through the spec to implement PIB/PCB/BAB in the ION codebase= , the core parts of the specification (canonicalization and extension block= s) are good, excepting minor changes that are emerging in the 6257 errata. = However, the tight coupling of routing and security imposes the difficult = requirement that we understand the topology and policy of portions of the n= etwork that may be unknowable. A simplified approach should remove this coupling and thus the need for tri= cky tasks like dictionary surgery, block nesting, path uniqueness, etc... T= he security use cases that I am aware of can be equally satisfied with a si= mplified BSP cooperating with some type of encapsulation approach (such as = Scott's bundle-in-bundle idea). A small group, in a small amount of time, could create a sample internet dr= aft based on 6257 that provides these simplifications, includes those appro= priate errata accumulated so far, and would serve as a good baseline for di= scussion going forward. -Ed --- Ed Birrane Senior Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: dtn-security-bounces@irtf.org [= mailto:dtn-security-bounces@irtf.org] On Behalf Of Eddy, Wesley M. (GRC-MS0= 0)[MTI SYSTEMS, INC.] Sent: Tuesday, January 22, 2013 6:48 PM To: Burleigh, Scott C; dtn-security@irtf.org Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 Agreed; that makes sense. ________________________________ From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] Sent: Tuesday, January 22, 2013 6:35 PM To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.org Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 Wes, I agree that some code change would be entailed in implementing this p= roposal, but I think a large proportion of the code - the general flow of p= rocessing the extension blocks, the canonicalization, the ciphersuites, rea= lly almost everything that would have been implemented to handle the simple= case of security source/destination being identical to bundle source/desti= nation - would be preserved. I suspect that much of what I was proposing h= ere involves removing functionality that most developers haven't implemente= d yet anyway, because of the potential pitfalls. Scott From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy@n= asa.gov] Sent: Tuesday, January 22, 2013 3:20 PM To: Burleigh, Scott C (313B); dtn-security@irtf.org Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinations = inDTN2 It looks like basically a good idea to me. I recall sometime in 2006 or 2007ish pointing out that security destination= s needed to work more like IPsec tunnel-mode endpoints in order to make the= routing work correctly, and I think what you're proposing here accomplishe= s that in a better way. Though I think cycles would be better spent on KMP issues that are actually= HARD, and *then* circling back to see what could be tweaked in the BSP, I = definitely think this proposed change is something that would improve the B= SP a bit in the meantime. I don't think it can be done in a way that's friendly to the existing codeb= ase like Stephen suggests shooting for. ________________________________ From: dtn-security-bounces@irtf.org [= dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B) [scott= .c.burleigh@jpl.nasa.gov] Sent: Tuesday, January 22, 2013 5:37 PM To: dtn-security@irtf.org Subject: [dtn-security] FW: Re(19): Implementing Security Destinations inDT= N2 Hi. Late last September, several of us spun off a sub-thread talking about= how the processing of bundles with multiple security destinations could be= handled in DTN implementations. I won't try to recreate all of the argume= nts on all sides, but I think we did converge on agreement that the current= BSP mechanism for complex, multi-destination security could be difficult t= o realize in coherent fashion across the network. After puzzling over this= for a while, I came up with a concept (below) that I think would be simple= r, safer, and even more powerful than the current protocol design. How do = we all feel about this? Would it be worthwhile for DTNRG to invest in a 62= 57bis RFC along these lines? Scott _____________________________________________ From: Burleigh, Scott C (313B) Sent: Friday, November 16, 2012 5:05 PM To: 'Peter Lovell'; ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in D= TN2 Hi, Peter. At the risk (I know) of getting a lot of people severely ticked= off at me, I am going to offer a modest proposal for improving the Bundle = Security Protocol, inspired by this thread. I propose to adopt a new design principle for Bundle Security Protocol: the= routing element of a bundle protocol agent should never need to inspect a = bundle's BSP extension blocks in order to select the node(s) to forward the= bundle to. That is, BSP should provide security, not dictate routes. My rationale for proposing this principle is that I believe it would: * Simplify BSP, thereby reducing the incidence of bugs and making B= undle Security significantly less expensive to implement and sustain. * Broaden the scope of BSP deployment by eliminating its dependence= on specific, BSP-aware routing implementations, thereby increasing the ove= rall security of DTN. * Reduce the cost of developing and improving routing implementatio= ns by removing any requirement that they be BSP-aware, and broaden the scop= e of deployment of non-BSP-aware routing implementations by enabling them t= o be used in environments requiring arbitrarily powerful security. Thereby= , improve DTN operational performance. Here's how I would apply this principle: 1. Eliminate security sources and security destinations from all BSP = blocks. The security source of a BSP block would always be the bundle's so= urce. The security destination of a BSP block would always be the bundle's= destination. 2. Add a new Administrative Record type for Bundle-in-Bundle encapsul= ation. 3. When additional security must be applied to a bundle on some segme= nt of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Enc= apsulation Administrative Record that is the payload of a new bundle whose = source is the security source of the path segment and whose destination is = the security destination of the path segment. Apply the additional bundle = transmission security measures to the encapsulating bundle: encrypt its pay= load (the Administrative Record, containing the encapsulated bundle), encry= pt extension blocks as copied from the encapsulated bundle, etc. Then forw= ard the encapsulating bundle. 4. When route service uncertainty forces a bundle to be routed over m= ultiple parallel additionally secured segments of its end-to-end path, enca= psulate it as above but within multiple different encapsulating bundles, on= e for each of the parallel segments, and forward all of them. 5. At the destination of a bundle, apply all relevant bundle receptio= n security measures and then, if the payload is an encapsulation Administra= tive Record, extract the encapsulated bundle from the Administrative Record= and simply forward it. I believe this would have the following impacts on DTN security: * No EID references in BSP, simplifying canonicalization. * PCBs only encrypt payloads, never PIBs or PCBs (encrypting the en= capsulated bundle encrypts all three at once), so no correlators in BSP. (= Except for BABs, no bundle ever has more than one occurrence of any type of= BSP block. And there will never be more than two BABs, one immediately fo= llowing the primary block and one that is the final block in the bundle, so= that correlation is structural.) * No delicate "replacement" process for unraveling PCB nesting at t= he destination. * No possible confusion about the correct order of application of B= SP blocks. * No possible conflict among security destinations of different BSP= blocks. * Security paths can never overlap. * Any routing implementation can always accommodate any security re= gime: routes that must be followed to ensure security are encoded into rout= ing information at the forwarding node, not into the bundle. (A little lik= e the late binding principle.) * Any routing environment can always be made arbitrarily secure - n= o need to require specially BSP-aware routing elements. * Ciphersuite design is simplified, so a wider array of useful ciph= ersuites can be developed without imposing bug-prone complexity. Minimizes= possible security problems. As an example of how I think this could work, see the attached diagram: 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are wi= thin the low-risk "W" security region; nodes C and G are gateways between r= egion W and the more hazardous region X; node D is another node in X; nodes= E and F are gateways between region X and even more hazardous region Y; no= des H and I are gateways between X and hazardous region Z. 2. At A the bundle is simply forwarded to B. 3. At B the routing element realizes that the bundle has to traverse = region X in order to get to K, so it forwards the bundle to C. 4. The routing element at C encapsulates the bundle in an Admin Recor= d, creates a new bundle destined for G (the egress from region X) whose sou= rce is C and whose payload is that Admin Record, encrypts the payload, atta= ches a PCB, and forwards the bundle to D. 5. D realizes that the bundle has to traverse region Y in order to ge= t to G, so it forwards the bundle to E. 6. E encapsulates the bundle in an Admin Record, creates a new bundle= destined for F (the egress from region Y) whose source is E and whose payl= oad is that Admin Record, encrypts the payload, attaches a PCB, and forward= s the bundle to F. 7. The bundle protocol agent at F receives the bundle, decrypts it, a= nd passes the payload (an Admin Record) to the application agent. The admi= nistrative element of the application agent at F receives the Admin Record,= extracts the encapsulated bundle destined for G, and queues it to be forwa= rded. The routing element at F sees this bundle and forwards it to G. 8. The bundle protocol agent at G receives the bundle, decrypts it, a= nd passes the payload (an Admin Record) to the application agent. The admi= nistrative element of the application agent at G receives the Admin Record,= extracts the encapsulated bundle destined for K, and queues it to be forwa= rded. The routing element at G sees this bundle, realizes that the bundle = has to traverse region Z in order to get to K, and therefore forwards the b= undle to H. 9. H encapsulates the bundle in an Admin Record, creates a new bundle= destined for I (the egress from region Z) whose source is H and whose payl= oad is that Admin Record, encrypts the payload, attaches a PCB, and forward= s the bundle to I. 10. The bundle protocol agent at I receives the bundle, decrypts it, and = passes the payload (an Admin Record) to the application agent. The adminis= trative element of the application agent at I receives the Admin Record, ex= tracts the encapsulated bundle destined for K, and queues it to be forwarde= d. The routing element at I sees this bundle and forwards it to J. 11. At J the bundle is simply forwarded to K. 12. At K the bundle's payload is passed to the application. I think this approach would combine simplicity with quite a lot of operatio= nal power, making everything cheaper and safer. So, having now stirred the hornet's nest, I will beat a hasty retreat for a= week while I am on vacation. I'll try to follow up when I get back. Have a nice Thanksgiving, everybody. Scott -----Original Message----- From: Peter Lovell [mailto:plovell@mac.com] Sent: Monday, October 22, 2012 1:28 PM To: Burleigh, Scott C (313B); ahennes1@math.umd.edu Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2 On Wed, Oct 24, 2012, Burleigh, Scott C (313B) > wrote: > In view of which, I've now become a bigger fan of bundle-in-bundle >tunneling than I've been in the past. Hi Scott, I agree. I'm also a big fan, for a bunch of reasons. However, as I mentione= d to Angela, the current [i.e. latest, expired] draft seems a bit "funky" t= o me. There's no indication in the bundle that it's BiB and you need some s= pecial EID to perform the decapsulation. Maybe that's just like an assigned= port in TCP but we don't yet have such a mechanism. The multiple-bundle th= ing is OK, I guess, but I don't see much use for it other than volume gatew= ay-to-gateway traffic and I think that such heavy-duty tunnels could be spe= cially optimized. I need to go back and review all the discussions about BiB -- we worked it = quite a bit but the spec never gained enough consensus to move forward. I t= hink it would be a good idea to revisit it now and get a solid draft that h= as wider support. Maybe the email discussions will help us get there. Thanks.....Peter --_000_8A674285E0E0E344965DF27CCFEE30EC59B3709461NDMSSCC04ndcn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ed,<= /o:p>

 

        &n= bsp;       I concur.  Our work at the HO= SC indicates that with the routing and security coupling, we may well not h= ave a comprehensive solution in a timely manner if at all.  With the c= omplex systems deployed in space and diverse communications links, a “= ;GRE like” model would resolve many interface/boundary issues.

 

Lee

 

From: dtn-se= curity-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] On Behalf= Of Birrane, Edward J.
Sent: Wednesday, January 23, 2013 11:5= 1 AM
To: dtn-security@irtf.org
Subject: Re: [dtn-securi= ty] FW: Re(19): Implementing Security Destinations inDTN2=

 

Also agreed.

<= o:p> 

Having worked throug= h the spec to implement PIB/PCB/BAB in the ION codebase, the core parts of = the specification (canonicalization and extension blocks) are good, excepti= ng minor changes that are emerging in the 6257 errata.  However, the t= ight coupling of routing and security imposes the difficult requirement tha= t we understand the topology and policy of portions of the network that may= be unknowable.

&nbs= p;

A simplified approach should= remove this coupling and thus the need for tricky tasks like dictionary su= rgery, block nesting, path uniqueness, etc... The security use cases that I= am aware of can be equally satisfied with a simplified BSP cooperating wit= h some type of encapsulation approach (such as Scott’s bundle-in-bund= le idea).

 

A small group, in a small amount o= f time, could create a sample internet draft based on 6257 that provides th= ese simplifications, includes those appropriate errata accumulated so far, = and would serve as a good baseline for discussion going forward.=

 

-Ed

 

---
Ed Birrane
Senior Professional Staff, Space De= partment
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / = (F) 443-228-3839
 

From:<= /b> dtn-security-bounces@irtf.org<= /a> [mailto:dtn-security-b= ounces@irtf.org] On Behalf Of Eddy, Wesley M. (GRC-MS00)[MTI SYS= TEMS, INC.]
Sent: Tuesday, January 22, 2013 6:48 PM
To:= Burleigh, Scott C; dtn-security@i= rtf.org
Subject: Re: [dtn-security] FW: Re(19): Implementing = Security Destinations inDTN2

 

Agreed; that make= s sense.

 

From:<= /b> Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov]
Sent= : Tuesday, January 22, 2013 6:35 PM
To: Eddy, Wesley M. (GRC-= MS00)[MTI SYSTEMS, INC.]; dtn-secu= rity@irtf.org
Subject: RE: [dtn-security] FW: Re(19): Impleme= nting Security Destinations inDTN2

Wes, I agree that some code change would be entail= ed in implementing this proposal, but I think a large proportion of the cod= e – the general flow of processing the extension blocks, the canonica= lization, the ciphersuites, really almost everything that would have been i= mplemented to handle the simple case of security source/destination being i= dentical to bundle source/destination – would be preserved.  I s= uspect that much of what I was proposing here involves removing functionali= ty that most developers haven’t implemented yet anyway, because of th= e potential pitfalls.

 =

Scott

 

From: Ed= dy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy@nasa.gov]
Sent: Tuesday, Ja= nuary 22, 2013 3:20 PM
To: Burleigh, Scott C (313B); dtn-security@irtf.org
Subject: R= E: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2

 

It looks like basically a good idea to me.

 

I recall sometime in 2006 or 2007ish point= ing out that security destinations needed to work more like IPsec tunnel-mo= de endpoints in order to make the routing work correctly, and I think what = you're proposing here accomplishes that in a better way.<= /p>

 

Though I think cycles would be better spent on KMP issues t= hat are actually HARD, and *then* circling back to see what could be tweake= d in the BSP, I definitely think this proposed change is som= ething that would improve the BSP a bit in the meantime.

 

I don't think it can be done in a way that's friendly = to the existing codebase like Stephen suggests shooting for.

 

From: dtn-security-bounces@irtf.org= [dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B) = [scott.c.burleigh@jpl.nasa.gov]
Sent: Tuesday, January 22, 2013 5= :37 PM
To: dtn-security@= irtf.org
Subject: [dtn-security] FW: Re(19): Implementing Sec= urity Destinations inDTN2

Hi.  Late last September, several of us spun off a sub= -thread talking about how the processing of bundles with multiple security = destinations could be handled in DTN implementations.  I won’t t= ry to recreate all of the arguments on all sides, but I think we did conver= ge on agreement that the current BSP mechanism for complex, multi-destinati= on security could be difficult to realize in coherent fashion across the ne= twork.  After puzzling over this for a while, I came up with a concept= (below) that I think would be simpler, safer, and even more powerful than = the current protocol design.  How do we all feel about this?  Wou= ld it be worthwhile for DTNRG to invest in a 6257bis RFC along these lines?=

 

=

Scott

_____________________________________________From: Burleigh, Scott C (313B)
Sent: Friday, November 16= , 2012 5:05 PM
To: 'Peter Lovell'; ahennes1@math.umd.edu
Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard We= iss
Subject: RE: Re(19): [dtn-security] Implementing Security Des= tinations in DTN2

&nbs= p;

 

Hi, Peter.&nb= sp; At the risk (I know) of getting a lot of people severely ticked off at = me, I am going to offer a modest proposal for improving the Bundle Security= Protocol, inspired by this thread.

I propose to adopt a new= design principle for Bundle Security Protocol: the routing element of a bu= ndle protocol agent should never need to inspect a bundle’s BSP exten= sion blocks in order to select the node(s) to forward the bundle to.=

That is, BSP should provide security, not dictate routes.

My rationale for proposing this principle is that I believe it wo= uld:

·=          Simplify BSP, = thereby reducing the incidence of bugs and making Bundle Security significa= ntly less expensive to implement and sustain.

·      &n= bsp;  Broaden the scope of BSP deployment by eliminating i= ts dependence on specific, BSP-aware routing implementations, thereby incre= asing the overall security of DTN.

·         <= /span>Reduce the cost of developing and improving routing implementati= ons by removing any requirement that they be BSP-aware, and broaden the sco= pe of deployment of non-BSP-aware routing implementations by enabling them = to be used in environments requiring arbitrarily powerful security.  T= hereby, improve DTN operational performance.

Here's how I would appl= y this principle:

1.       Eli= minate security sources and security destinations from all BSP blocks. = ; The security source of a BSP block would always be the bundle’s sou= rce.  The security destination of a BSP block would always be the bund= le’s destination.

2.       Ad= d a new Administrative Record type for Bundle-in-Bundle encapsulation.

3.&nbs= p;      When additional security must = be applied to a bundle on some segment of its end-to-end path, encapsulate = the bundle in a Bundle-in-Bundle Encapsulation Administrative Record that i= s the payload of a new bundle whose source is the security source of the pa= th segment and whose destination is the security destination of the path se= gment.  Apply the additional bundle transmission security measures to = the encapsulating bundle: encrypt its payload (the Administrative Record, c= ontaining the encapsulated bundle), encrypt extension blocks as copied from= the encapsulated bundle, etc.  Then forward the encapsulating bundle.=

4.       When route service uncert= ainty forces a bundle to be routed over multiple parallel additionally secu= red segments of its end-to-end path, encapsulate it as above but within mul= tiple different encapsulating bundles, one for each of the parallel segment= s, and forward all of them.

5.       At the destination of a bundle, apply all relevant bundle reception secur= ity measures and then, if the payload is an encapsulation Administrative Re= cord, extract the encapsulated bundle from the Administrative Record and si= mply forward it.

I believe this would have the following impacts on = DTN security:

·         No EI= D references in BSP, simplifying canonicalization.

·     &nbs= p;   PCBs only encrypt payloads, never PIBs or PCBs (= encrypting the encapsulated bundle encrypts all three at once), so no corre= lators in BSP.  (Except for BABs, no bundle ever has more than one occ= urrence of any type of BSP block.  And there will never be more than t= wo BABs, one immediately following the primary block and one that is the fi= nal block in the bundle, so that correlation is structural.)

·=     =      No delicate “replacement” = process for unraveling PCB nesting at the destination.

·     =     No possible confusion about the correct orde= r of application of BSP blocks.

·         No possible conflict among security destinations of different BSP b= locks.

·&nb= sp;        Security paths ca= n never overlap.

·         Any ro= uting implementation can always accommodate any security regime: routes tha= t must be followed to ensure security are encoded into routing information = at the forwarding node, not into the bundle.  (A little like the late = binding principle.)

·         Any = routing environment can always be made arbitrarily secure – no need t= o require specially BSP-aware routing elements.

·      &= nbsp;  Ciphersuite design is simplified, so a wider array = of useful ciphersuites can be developed without imposing bug-prone complexi= ty.  Minimizes possible security problems.

As an example of how= I think this could work, see the attached diagram:

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:bla= ck'>1.   =     Node A is sending a bundle to node K.  = Nodes A, B, J, and K are within the low-risk “W” security regio= n; nodes C and G are gateways between region W and the more hazardous regio= n X; node D is another node in X; nodes E and F are gateways between region= X and even more hazardous region Y; nodes H and I are gateways between X a= nd hazardous region Z.

2.       At = A the bundle is simply forwarded to B.

3.      = At B the routing element realizes that the bundle has to trave= rse region X in order to get to K, so it forwards the bundle to C. <= o:p>

4. &n= bsp;     The routing element at C encapsula= tes the bundle in an Admin Record, creates a new bundle destined for G (the= egress from region X) whose source is C and whose payload is that Admin Re= cord, encrypts the payload, attaches a PCB, and forwards the bundle to D. <= /span>

5.&= nbsp;      D realizes that the bundle = has to traverse region Y in order to get to G, so it forwards the bundle to= E.

6.       E encapsulates the bun= dle in an Admin Record, creates a new bundle destined for F (the egress fro= m region Y) whose source is E and whose payload is that Admin Record, encry= pts the payload, attaches a PCB, and forwards the bundle to F. =

7.  =      The bundle protocol agent at F receive= s the bundle, decrypts it, and passes the payload (an Admin Record) to the = application agent.  The administrative element of the application agen= t at F receives the Admin Record, extracts the encapsulated bundle destined= for G, and queues it to be forwarded.  The routing element at F sees = this bundle and forwards it to G.

8.       The bundle protocol agent at G receives the bundle, decrypts it, an= d passes the payload (an Admin Record) to the application agent.  The = administrative element of the application agent at G receives the Admin Rec= ord, extracts the encapsulated bundle destined for K, and queues it to be f= orwarded.  The routing element at G sees this bundle, realizes that th= e bundle has to traverse region Z in order to get to K, and therefore forwa= rds the bundle to H.

9.       H enc= apsulates the bundle in an Admin Record, creates a new bundle destined for = I (the egress from region Z) whose source is H and whose payload is that Ad= min Record, encrypts the payload, attaches a PCB, and forwards the bundle t= o I.

10.   The bundle protocol agent at I receives the = bundle, decrypts it, and passes the payload (an Admin Record) to the applic= ation agent.  The administrative element of the application agent at I= receives the Admin Record, extracts the encapsulated bundle destined for K= , and queues it to be forwarded.  The routing element at I sees this b= undle and forwards it to J.

11.   At J the bundle is si= mply forwarded to K.

12.   At K the bundle’s payl= oad is passed to the application.

I think this approach would combin= e simplicity with quite a lot of operational power, making everything cheap= er and safer.

So, having now stirred the hornet’s nest, = I will beat a hasty retreat for a week while I am on vacation.  I̵= 7;ll try to follow up when I get back.

Have a nice Thanksgivin= g, everybody.

Scott

 

----= -Original Message-----
From: Peter Lovell [mailto:plovell@mac.com]
Sent: Monday, October 22, 2012 1:28 P= M
To: Burleigh, Scott C (313B); ahennes1@math.umd.edu
Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell=
Subject: Re(19): [dtn-security] Implementing Security Destinations in D= TN2

 <= /p>

On Wed, Oct 24, 2012, Burleigh, Sco= tt C (313B) <scott.c.bu= rleigh@jpl.nasa.gov> wrote:

 

>= In view of which, I've now become a bigger fan of bundle-in-bundle =

>tunneling than I've= been in the past.

&nb= sp;

Hi Scott,

 

=

I agree. I'm also a big fan, for a bunch of reaso= ns. However, as I mentioned to Angela, the current [i.e. latest, expired] d= raft seems a bit "funky" to me. There's no indication in the bund= le that it's BiB and you need some special EID to perform the decapsulation= . Maybe that's just like an assigned port in TCP but we don't yet have such= a mechanism. The multiple-bundle thing is OK, I guess, but I don't see muc= h use for it other than volume gateway-to-gateway traffic and I think that = such heavy-duty tunnels could be specially optimized.

=

 

I need to go back and review all the discussions about BiB -= - we worked it quite a bit but the spec never gained enough consensus to mo= ve forward. I think it would be a good idea to revisit it now and get a sol= id draft that has wider support. Maybe the email discussions will help us g= et there.

 <= /o:p>

Thanks.....Peter<= /o:p>

 

 

= --_000_8A674285E0E0E344965DF27CCFEE30EC59B3709461NDMSSCC04ndcn_-- From Edward.Birrane@jhuapl.edu Sat Jan 26 17:19:01 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F98C21F8B88 for ; Sat, 26 Jan 2013 17:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i88dv3XMLpTH for ; Sat, 26 Jan 2013 17:18:59 -0800 (PST) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) by ietfa.amsl.com (Postfix) with ESMTP id B20A821F8497 for ; Sat, 26 Jan 2013 17:18:55 -0800 (PST) Received: from aplexcas2.dom1.jhuapl.edu (unknown [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 72ea_ad87_4698a575_6ef9_4c77_aa17_38eee19fdeb2; Sat, 26 Jan 2013 20:18:54 -0500 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Sat, 26 Jan 2013 20:18:54 -0500 From: "Birrane, Edward J." To: "dtn-security@irtf.org" Date: Sat, 26 Jan 2013 20:18:51 -0500 Thread-Topic: [dtn-security] dtn-security Digest, Vol 9, Issue 4 Thread-Index: Ac35k+7Npp50lx3kRuSRThQdx4WHbgCmFUAi Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.15.0.121009 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 01:19:01 -0000 Angela, I see (at least) two issues independent enough that they should not be conflated. The first is whether simplifying the BSP specification, to omi= t tight routing coupling, is beneficial. The second is the utility of the bundle-in-bundle encapsulation mechanism in a security context. 1. Simplifying BSP What we have found is that the concept of a security destination, separate from a bundle destination, places a burden on any routing mechanis= m to guarantee delivery through one or more "waypoints" before the bundle reaches its destination. Since routing mechanisms cannot make this guarantee in any type of opportunistic network (and may struggle to make this guarantee in structured networks) we need to find a way to relax this language and the implementation hurdles it imposes. Removing security sources and destinations from the specification and deferring tunneling and multi-point behavior to some other mechanism (or mechanisms) seems like a promising way to go for BSP. I think most folks on this list agree with the above, but before we get too deeply into specifics surrounding encapsulation, it is probably a good idea to check that assumption. ---> Do we agree that (provided we can meet necessary use cases) this is a desired simplification of BSP? 2. Bundle-in-Bundle (BiB) encapsulation BiB is a useful way to create a tunnel in a network at the BP layer. With any tunneled packet, it should be protected from misuse while in the tunnel= , and encapsulation is a way to do that. IMO, it should be used exactly in those situations where we need a security destination that is different tha= n the bundle destination; i.e. When we need to make a security tunnel. Actions such as adding a signature to a bundle or encrypting a bundle, would not require encapsulation if the security destinations remain the bundle destinations. The only exception here would be BAB, which is the special case of next-hop neighbors, which would still not require an encapsulation, but the security destination would be understood to be the next immediate BP hop which is knowable by the routing subsystem (arguably the only thing knowable by the routing subsystem). If we have extension blocks that have security destinations different fro= m the payload security destinations, then it sounds like we are treating extension blocks as "extra" independent payloads and that may cause identit= y problems beyond these BSP issues. It would probably be helpful to specify a concrete use-case surrounding the signing and encrypting of payloads and extension blocks along the traversed path of a bundle. Could you propose such a use case? -Ed On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" wrote: > Hi Scott, > > I like how this approach simplifies the routing and gets rid of the > security src/dest and EID refs. I was a little confused though about > how this would work with some of the combinations of security blocks: > > If a node just wants to add a signature to a bundle, would this > require the bundle to be encapsulated? One of the advantages of BSP is > that non security-aware nodes can still access the payload by just > ignoring the PIB block. Wouldn't we lose that feature if the bundle > were encapsulated? > > If a node wants to sign and then encrypt the bundle, does this require > the bundle to be encapsulated twice? > > How would we handle signing/encrypting extension blocks? Would this > require a third encapsulation? Wouldn't we still need correlators in > case multiple extension blocks are encrypted with the same key, or > would we not allow different extension blocks to be encrypted with > different keys? > > > Thanks, > Angela > > > > On Tue, Jan 22, 2013 at 6:49 PM, wrote: >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.irtf.org/mailman/listinfo/dtn-security >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send dtn-security mailing list submissions to >> dtn-security@irtf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.irtf.org/mailman/listinfo/dtn-security >> or, via email, send a message with subject or body 'help' to >> dtn-security-request@irtf.org >> >> You can reach the person managing the list at >> dtn-security-owner@irtf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of dtn-security digest..." >> >> Today's Topics: >> >> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >> >> >> ---------- Forwarded message ---------- >> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >> >> To: "Burleigh, Scott C" , >> "dtn-security@irtf.org" >> Cc: >> Date: Tue, 22 Jan 2013 17:19:48 -0600 >> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >> inDTN2 >> It looks like basically a good idea to me. >> >> I recall sometime in 2006 or 2007ish pointing out that security destinat= ions >> needed to work more like IPsec tunnel-mode endpoints in order to make th= e >> routing work correctly, and I think what you're proposing here accomplis= hes >> that in a better way. >> >> Though I think cycles would be better spent on KMP issues that are actua= lly >> HARD, and *then* circling back to see what could be tweaked in the BSP, = I >> definitely think this proposed change is something that would improve th= e BSP >> a bit in the meantime. >> >> I don't think it can be done in a way that's friendly to the existing >> codebase like Stephen suggests shooting for. >> >> ________________________________ >> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On B= ehalf >> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >> Sent: Tuesday, January 22, 2013 5:37 PM >> To: dtn-security@irtf.org >> Subject: [dtn-security] FW: Re(19): Implementing Security Destinations i= nDTN2 >> >> Hi. Late last September, several of us spun off a sub-thread talking ab= out >> how the processing of bundles with multiple security destinations could = be >> handled in DTN implementations. I won=B9t try to recreate all of the ar= guments >> on all sides, but I think we did converge on agreement that the current = BSP >> mechanism for complex, multi-destination security could be difficult to >> realize in coherent fashion across the network. After puzzling over thi= s for >> a while, I came up with a concept (below) that I think would be simpler, >> safer, and even more powerful than the current protocol design. How do = we >> all feel about this? Would it be worthwhile for DTNRG to invest in a 62= 57bis >> RFC along these lines? >> >> Scott >> _____________________________________________ >> From: Burleigh, Scott C (313B) >> Sent: Friday, November 16, 2012 5:05 PM >> To: 'Peter Lovell'; ahennes1@math.umd.edu >> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations i= n >> DTN2 >> >> >> Hi, Peter. At the risk (I know) of getting a lot of people severely tic= ked >> off at me, I am going to offer a modest proposal for improving the Bundl= e >> Security Protocol, inspired by this thread. >> I propose to adopt a new design principle for Bundle Security Protocol: = the >> routing element of a bundle protocol agent should never need to inspect = a >> bundle=B9s BSP extension blocks in order to select the node(s) to forwar= d the >> bundle to. >> That is, BSP should provide security, not dictate routes. >> My rationale for proposing this principle is that I believe it would: >> >> Simplify BSP, thereby reducing the incidence of bugs and making Bundle >> Security significantly less expensive to implement and sustain. >> Broaden the scope of BSP deployment by eliminating its dependence on >> specific, BSP-aware routing implementations, thereby increasing the over= all >> security of DTN. >> Reduce the cost of developing and improving routing implementations by >> removing any requirement that they be BSP-aware, and broaden the scope o= f >> deployment of non-BSP-aware routing implementations by enabling them to = be >> used in environments requiring arbitrarily powerful security. Thereby, >> improve DTN operational performance. >> >> Here's how I would apply this principle: >> >> Eliminate security sources and security destinations from all BSP blocks= . >> The security source of a BSP block would always be the bundle=B9s source= . The >> security destination of a BSP block would always be the bundle=B9s desti= nation. >> Add a new Administrative Record type for Bundle-in-Bundle encapsulation. >> When additional security must be applied to a bundle on some segment of = its >> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Encapsulat= ion >> Administrative Record that is the payload of a new bundle whose source i= s the >> security source of the path segment and whose destination is the securit= y >> destination of the path segment. Apply the additional bundle transmissi= on >> security measures to the encapsulating bundle: encrypt its payload (the >> Administrative Record, containing the encapsulated bundle), encrypt exte= nsion >> blocks as copied from the encapsulated bundle, etc. Then forward the >> encapsulating bundle. >> When route service uncertainty forces a bundle to be routed over multipl= e >> parallel additionally secured segments of its end-to-end path, encapsula= te it >> as above but within multiple different encapsulating bundles, one for ea= ch of >> the parallel segments, and forward all of them. >> At the destination of a bundle, apply all relevant bundle reception secu= rity >> measures and then, if the payload is an encapsulation Administrative Rec= ord, >> extract the encapsulated bundle from the Administrative Record and simpl= y >> forward it. >> >> I believe this would have the following impacts on DTN security: >> >> No EID references in BSP, simplifying canonicalization. >> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the encapsula= ted >> bundle encrypts all three at once), so no correlators in BSP. (Except f= or >> BABs, no bundle ever has more than one occurrence of any type of BSP blo= ck. >> And there will never be more than two BABs, one immediately following th= e >> primary block and one that is the final block in the bundle, so that >> correlation is structural.) >> No delicate =B3replacement=B2 process for unraveling PCB nesting at the >> destination. >> No possible confusion about the correct order of application of BSP bloc= ks. >> No possible conflict among security destinations of different BSP blocks= . >> Security paths can never overlap. >> Any routing implementation can always accommodate any security regime: r= outes >> that must be followed to ensure security are encoded into routing inform= ation >> at the forwarding node, not into the bundle. (A little like the late bi= nding >> principle.) >> Any routing environment can always be made arbitrarily secure =AD no nee= d to >> require specially BSP-aware routing elements. >> Ciphersuite design is simplified, so a wider array of useful ciphersuite= s can >> be developed without imposing bug-prone complexity. Minimizes possible >> security problems. >> >> As an example of how I think this could work, see the attached diagram: >> >> Node A is sending a bundle to node K. Nodes A, B, J, and K are within t= he >> low-risk =B3W=B2 security region; nodes C and G are gateways between reg= ion W and >> the more hazardous region X; node D is another node in X; nodes E and F = are >> gateways between region X and even more hazardous region Y; nodes H and = I are >> gateways between X and hazardous region Z. >> At A the bundle is simply forwarded to B. >> At B the routing element realizes that the bundle has to traverse region= X in >> order to get to K, so it forwards the bundle to C. >> The routing element at C encapsulates the bundle in an Admin Record, cre= ates >> a new bundle destined for G (the egress from region X) whose source is C= and >> whose payload is that Admin Record, encrypts the payload, attaches a PCB= , and >> forwards the bundle to D. >> D realizes that the bundle has to traverse region Y in order to get to G= , so >> it forwards the bundle to E. >> E encapsulates the bundle in an Admin Record, creates a new bundle desti= ned >> for F (the egress from region Y) whose source is E and whose payload is = that >> Admin Record, encrypts the payload, attaches a PCB, and forwards the bun= dle >> to F. >> The bundle protocol agent at F receives the bundle, decrypts it, and pas= ses >> the payload (an Admin Record) to the application agent. The administrat= ive >> element of the application agent at F receives the Admin Record, extract= s the >> encapsulated bundle destined for G, and queues it to be forwarded. The >> routing element at F sees this bundle and forwards it to G. >> The bundle protocol agent at G receives the bundle, decrypts it, and pas= ses >> the payload (an Admin Record) to the application agent. The administrat= ive >> element of the application agent at G receives the Admin Record, extract= s the >> encapsulated bundle destined for K, and queues it to be forwarded. The >> routing element at G sees this bundle, realizes that the bundle has to >> traverse region Z in order to get to K, and therefore forwards the bundl= e to >> H. >> H encapsulates the bundle in an Admin Record, creates a new bundle desti= ned >> for I (the egress from region Z) whose source is H and whose payload is = that >> Admin Record, encrypts the payload, attaches a PCB, and forwards the bun= dle >> to I. >> The bundle protocol agent at I receives the bundle, decrypts it, and pas= ses >> the payload (an Admin Record) to the application agent. The administrat= ive >> element of the application agent at I receives the Admin Record, extract= s the >> encapsulated bundle destined for K, and queues it to be forwarded. The >> routing element at I sees this bundle and forwards it to J. >> At J the bundle is simply forwarded to K. >> At K the bundle=B9s payload is passed to the application. >> >> I think this approach would combine simplicity with quite a lot of >> operational power, making everything cheaper and safer. >> So, having now stirred the hornet=B9s nest, I will beat a hasty retreat = for a >> week while I am on vacation. I=B9ll try to follow up when I get back. >> Have a nice Thanksgiving, everybody. >> Scott >> >> -----Original Message----- >> From: Peter Lovell [mailto:plovell@mac.com] >> Sent: Monday, October 22, 2012 1:28 PM >> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell >> Subject: Re(19): [dtn-security] Implementing Security Destinations in DT= N2 >> >> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >> wrote: >> >>> In view of which, I've now become a bigger fan of bundle-in-bundle >>> tunneling than I've been in the past. >> >> Hi Scott, >> >> I agree. I'm also a big fan, for a bunch of reasons. However, as I menti= oned >> to Angela, the current [i.e. latest, expired] draft seems a bit "funky" = to >> me. There's no indication in the bundle that it's BiB and you need some >> special EID to perform the decapsulation. Maybe that's just like an assi= gned >> port in TCP but we don't yet have such a mechanism. The multiple-bundle = thing >> is OK, I guess, but I don't see much use for it other than volume >> gateway-to-gateway traffic and I think that such heavy-duty tunnels coul= d be >> specially optimized. >> >> I need to go back and review all the discussions about BiB -- we worked = it >> quite a bit but the spec never gained enough consensus to move forward. = I >> think it would be a good idea to revisit it now and get a solid draft th= at >> has wider support. Maybe the email discussions will help us get there. >> >> Thanks.....Peter >> >> >> >> >> ---------- Forwarded message ---------- >> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >> >> To: "Burleigh, Scott C" , >> "dtn-security@irtf.org" >> Cc: >> Date: Tue, 22 Jan 2013 17:47:47 -0600 >> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >> inDTN2 >> Agreed; that makes sense. >> >> ________________________________ >> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >> Sent: Tuesday, January 22, 2013 6:35 PM >> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.org >> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >> inDTN2 >> >> Wes, I agree that some code change would be entailed in implementing thi= s >> proposal, but I think a large proportion of the code =AD the general flo= w of >> processing the extension blocks, the canonicalization, the ciphersuites, >> really almost everything that would have been implemented to handle the >> simple case of security source/destination being identical to bundle >> source/destination =AD would be preserved. I suspect that much of what = I was >> proposing here involves removing functionality that most developers have= n=B9t >> implemented yet anyway, because of the potential pitfalls. >> >> >> >> Scott >> >> >> >> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >> [mailto:wesley.m.eddy@nasa.gov] >> Sent: Tuesday, January 22, 2013 3:20 PM >> To: Burleigh, Scott C (313B); dtn-security@irtf.org >> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >> inDTN2 >> >> >> >> It looks like basically a good idea to me. >> >> >> >> I recall sometime in 2006 or 2007ish pointing out that security destinat= ions >> needed to work more like IPsec tunnel-mode endpoints in order to make th= e >> routing work correctly, and I think what you're proposing here accomplis= hes >> that in a better way. >> >> >> >> Though I think cycles would be better spent on KMP issues that are actua= lly >> HARD, and *then* circling back to see what could be tweaked in the BSP, = I >> definitely think this proposed change is something that would improve th= e BSP >> a bit in the meantime. >> >> >> >> I don't think it can be done in a way that's friendly to the existing >> codebase like Stephen suggests shooting for. >> >> >> >> ________________________________ >> >> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On B= ehalf >> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >> Sent: Tuesday, January 22, 2013 5:37 PM >> To: dtn-security@irtf.org >> Subject: [dtn-security] FW: Re(19): Implementing Security Destinations i= nDTN2 >> >> Hi. Late last September, several of us spun off a sub-thread talking ab= out >> how the processing of bundles with multiple security destinations could = be >> handled in DTN implementations. I won=B9t try to recreate all of the ar= guments >> on all sides, but I think we did converge on agreement that the current = BSP >> mechanism for complex, multi-destination security could be difficult to >> realize in coherent fashion across the network. After puzzling over thi= s for >> a while, I came up with a concept (below) that I think would be simpler, >> safer, and even more powerful than the current protocol design. How do = we >> all feel about this? Would it be worthwhile for DTNRG to invest in a 62= 57bis >> RFC along these lines? >> >> >> >> Scott >> >> _____________________________________________ >> From: Burleigh, Scott C (313B) >> Sent: Friday, November 16, 2012 5:05 PM >> To: 'Peter Lovell'; ahennes1@math.umd.edu >> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations i= n >> DTN2 >> >> >> >> >> >> Hi, Peter. At the risk (I know) of getting a lot of people severely tic= ked >> off at me, I am going to offer a modest proposal for improving the Bundl= e >> Security Protocol, inspired by this thread. >> >> I propose to adopt a new design principle for Bundle Security Protocol: = the >> routing element of a bundle protocol agent should never need to inspect = a >> bundle=B9s BSP extension blocks in order to select the node(s) to forwar= d the >> bundle to. >> >> That is, BSP should provide security, not dictate routes. >> >> My rationale for proposing this principle is that I believe it would: >> >> =B7 Simplify BSP, thereby reducing the incidence of bugs and mak= ing >> Bundle Security significantly less expensive to implement and sustain. >> >> =B7 Broaden the scope of BSP deployment by eliminating its depen= dence >> on specific, BSP-aware routing implementations, thereby increasing the >> overall security of DTN. >> >> =B7 Reduce the cost of developing and improving routing implemen= tations >> by removing any requirement that they be BSP-aware, and broaden the scop= e of >> deployment of non-BSP-aware routing implementations by enabling them to = be >> used in environments requiring arbitrarily powerful security. Thereby, >> improve DTN operational performance. >> >> Here's how I would apply this principle: >> >> 1. Eliminate security sources and security destinations from all B= SP >> blocks. The security source of a BSP block would always be the bundle= =B9s >> source. The security destination of a BSP block would always be the bun= dle=B9s >> destination. >> >> 2. Add a new Administrative Record type for Bundle-in-Bundle >> encapsulation. >> >> 3. When additional security must be applied to a bundle on some se= gment >> of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >> Encapsulation Administrative Record that is the payload of a new bundle = whose >> source is the security source of the path segment and whose destination = is >> the security destination of the path segment. Apply the additional bund= le >> transmission security measures to the encapsulating bundle: encrypt its >> payload (the Administrative Record, containing the encapsulated bundle), >> encrypt extension blocks as copied from the encapsulated bundle, etc. T= hen >> forward the encapsulating bundle. >> >> 4. When route service uncertainty forces a bundle to be routed ove= r >> multiple parallel additionally secured segments of its end-to-end path, >> encapsulate it as above but within multiple different encapsulating bund= les, >> one for each of the parallel segments, and forward all of them. >> >> 5. At the destination of a bundle, apply all relevant bundle recep= tion >> security measures and then, if the payload is an encapsulation Administr= ative >> Record, extract the encapsulated bundle from the Administrative Record a= nd >> simply forward it. >> >> I believe this would have the following impacts on DTN security: >> >> =B7 No EID references in BSP, simplifying canonicalization. >> >> =B7 PCBs only encrypt payloads, never PIBs or PCBs (encrypting t= he >> encapsulated bundle encrypts all three at once), so no correlators in BS= P. >> (Except for BABs, no bundle ever has more than one occurrence of any typ= e of >> BSP block. And there will never be more than two BABs, one immediately >> following the primary block and one that is the final block in the bundl= e, so >> that correlation is structural.) >> >> =B7 No delicate =B3replacement=B2 process for unraveling PCB nes= ting at the >> destination. >> >> =B7 No possible confusion about the correct order of application= of BSP >> blocks. >> >> =B7 No possible conflict among security destinations of differen= t BSP >> blocks. >> >> =B7 Security paths can never overlap. >> >> =B7 Any routing implementation can always accommodate any securi= ty >> regime: routes that must be followed to ensure security are encoded into >> routing information at the forwarding node, not into the bundle. (A lit= tle >> like the late binding principle.) >> >> =B7 Any routing environment can always be made arbitrarily secur= e =AD no >> need to require specially BSP-aware routing elements. >> >> =B7 Ciphersuite design is simplified, so a wider array of useful >> ciphersuites can be developed without imposing bug-prone complexity. >> Minimizes possible security problems. >> >> As an example of how I think this could work, see the attached diagram: >> >> 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are >> within the low-risk =B3W=B2 security region; nodes C and G are gateways = between >> region W and the more hazardous region X; node D is another node in X; n= odes >> E and F are gateways between region X and even more hazardous region Y; = nodes >> H and I are gateways between X and hazardous region Z. >> >> 2. At A the bundle is simply forwarded to B. >> >> 3. At B the routing element realizes that the bundle has to traver= se >> region X in order to get to K, so it forwards the bundle to C. >> >> 4. The routing element at C encapsulates the bundle in an Admin Re= cord, >> creates a new bundle destined for G (the egress from region X) whose sou= rce >> is C and whose payload is that Admin Record, encrypts the payload, attac= hes a >> PCB, and forwards the bundle to D. >> >> 5. D realizes that the bundle has to traverse region Y in order to= get >> to G, so it forwards the bundle to E. >> >> 6. E encapsulates the bundle in an Admin Record, creates a new bun= dle >> destined for F (the egress from region Y) whose source is E and whose pa= yload >> is that Admin Record, encrypts the payload, attaches a PCB, and forwards= the >> bundle to F. >> >> 7. The bundle protocol agent at F receives the bundle, decrypts it= , and >> passes the payload (an Admin Record) to the application agent. The >> administrative element of the application agent at F receives the Admin >> Record, extracts the encapsulated bundle destined for G, and queues it t= o be >> forwarded. The routing element at F sees this bundle and forwards it to= G. >> >> 8. The bundle protocol agent at G receives the bundle, decrypts it= , and >> passes the payload (an Admin Record) to the application agent. The >> administrative element of the application agent at G receives the Admin >> Record, extracts the encapsulated bundle destined for K, and queues it t= o be >> forwarded. The routing element at G sees this bundle, realizes that the >> bundle has to traverse region Z in order to get to K, and therefore forw= ards >> the bundle to H. >> >> 9. H encapsulates the bundle in an Admin Record, creates a new bun= dle >> destined for I (the egress from region Z) whose source is H and whose pa= yload >> is that Admin Record, encrypts the payload, attaches a PCB, and forwards= the >> bundle to I. >> >> 10. The bundle protocol agent at I receives the bundle, decrypts it, a= nd >> passes the payload (an Admin Record) to the application agent. The >> administrative element of the application agent at I receives the Admin >> Record, extracts the encapsulated bundle destined for K, and queues it t= o be >> forwarded. The routing element at I sees this bundle and forwards it to= J. >> >> 11. At J the bundle is simply forwarded to K. >> >> 12. At K the bundle=B9s payload is passed to the application. >> >> I think this approach would combine simplicity with quite a lot of >> operational power, making everything cheaper and safer. >> >> So, having now stirred the hornet=B9s nest, I will beat a hasty retreat = for a >> week while I am on vacation. I=B9ll try to follow up when I get back. >> >> Have a nice Thanksgiving, everybody. >> >> Scott >> >> >> >> -----Original Message----- >> From: Peter Lovell [mailto:plovell@mac.com] >> Sent: Monday, October 22, 2012 1:28 PM >> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell >> Subject: Re(19): [dtn-security] Implementing Security Destinations in DT= N2 >> >> >> >> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >> wrote: >> >> >> >>> In view of which, I've now become a bigger fan of bundle-in-bundle >> >>> tunneling than I've been in the past. >> >> >> >> Hi Scott, >> >> >> >> I agree. I'm also a big fan, for a bunch of reasons. However, as I menti= oned >> to Angela, the current [i.e. latest, expired] draft seems a bit "funky" = to >> me. There's no indication in the bundle that it's BiB and you need some >> special EID to perform the decapsulation. Maybe that's just like an assi= gned >> port in TCP but we don't yet have such a mechanism. The multiple-bundle = thing >> is OK, I guess, but I don't see much use for it other than volume >> gateway-to-gateway traffic and I think that such heavy-duty tunnels coul= d be >> specially optimized. >> >> >> >> I need to go back and review all the discussions about BiB -- we worked = it >> quite a bit but the spec never gained enough consensus to move forward. = I >> think it would be a good idea to revisit it now and get a solid draft th= at >> has wider support. Maybe the email discussions will help us get there. >> >> >> >> Thanks.....Peter >> >> >> >> >> >> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security >> > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security From stephen.farrell@cs.tcd.ie Sat Jan 26 18:09:04 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C259921F8626 for ; Sat, 26 Jan 2013 18:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tqmp-OTusts for ; Sat, 26 Jan 2013 18:09:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 37ED721F8619 for ; Sat, 26 Jan 2013 18:09:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7218DBE62; Sun, 27 Jan 2013 02:08:37 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roZBCsT9dhM6; Sun, 27 Jan 2013 02:08:31 +0000 (GMT) Received: from [10.87.48.7] (unknown [86.45.57.26]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0B138BE60; Sun, 27 Jan 2013 02:08:31 +0000 (GMT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Stephen Farrell Date: Sun, 27 Jan 2013 02:08:27 +0000 To: "Birrane, Edward J." Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 02:09:04 -0000 On 27 Jan 2013, at 01:18, "Birrane, Edward J." w= rote: > Angela, >=20 > I see (at least) two issues independent enough that they should not be > conflated. The first is whether simplifying the BSP specification, to om= it > tight routing coupling, is beneficial. The second is the utility of the > bundle-in-bundle encapsulation mechanism in a security context. >=20 > 1. Simplifying BSP > What we have found is that the concept of a security destination, > separate from a bundle destination, places a burden on any routing mechani= sm > to guarantee delivery through one or more "waypoints" before the bundle > reaches its destination. Since routing mechanisms cannot make this > guarantee in any type of opportunistic network (and may struggle to make > this guarantee in structured networks) we need to find a way to relax this= > language and the implementation hurdles it imposes. Removing security > sources and destinations from the specification and deferring tunneling an= d > multi-point behavior to some other mechanism (or mechanisms) seems like a > promising way to go for BSP. >=20 > I think most folks on this list agree with the above, but before we get > too deeply into specifics surrounding encapsulation, it is probably a good= > idea to check that assumption. >=20 > ---> Do we agree that (provided we can meet necessary use cases) this is a= > desired simplification of BSP? That's neither needed nor necessarily desirable. Just write the draft that s= ays how to do it, then ask if people like it. Abstract argument in advance d= oesn't seem useful. S >=20 >=20 > 2. Bundle-in-Bundle (BiB) encapsulation >=20 > BiB is a useful way to create a tunnel in a network at the BP layer. With= > any tunneled packet, it should be protected from misuse while in the tunne= l, > and encapsulation is a way to do that. IMO, it should be used exactly in > those situations where we need a security destination that is different th= an > the bundle destination; i.e. When we need to make a security tunnel. >=20 > Actions such as adding a signature to a bundle or encrypting a bundle, > would not require encapsulation if the security destinations remain the > bundle destinations. The only exception here would be BAB, which is the > special case of next-hop neighbors, which would still not require an > encapsulation, but the security destination would be understood to be the > next immediate BP hop which is knowable by the routing subsystem (arguably= > the only thing knowable by the routing subsystem). >=20 > If we have extension blocks that have security destinations different fro= m > the payload security destinations, then it sounds like we are treating > extension blocks as "extra" independent payloads and that may cause identi= ty > problems beyond these BSP issues. >=20 > It would probably be helpful to specify a concrete use-case surrounding > the signing and encrypting of payloads and extension blocks along the > traversed path of a bundle. Could you propose such a use case? >=20 > -Ed >=20 > On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" wrote:= >=20 >> Hi Scott, >>=20 >> I like how this approach simplifies the routing and gets rid of the >> security src/dest and EID refs. I was a little confused though about >> how this would work with some of the combinations of security blocks: >>=20 >> If a node just wants to add a signature to a bundle, would this >> require the bundle to be encapsulated? One of the advantages of BSP is >> that non security-aware nodes can still access the payload by just >> ignoring the PIB block. Wouldn't we lose that feature if the bundle >> were encapsulated? >>=20 >> If a node wants to sign and then encrypt the bundle, does this require >> the bundle to be encapsulated twice? >>=20 >> How would we handle signing/encrypting extension blocks? Would this >> require a third encapsulation? Wouldn't we still need correlators in >> case multiple extension blocks are encrypted with the same key, or >> would we not allow different extension blocks to be encrypted with >> different keys? >>=20 >>=20 >> Thanks, >> Angela >>=20 >>=20 >>=20 >> On Tue, Jan 22, 2013 at 6:49 PM, wrote: >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>>=20 >>> https://www.irtf.org/mailman/listinfo/dtn-security >>>=20 >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>>=20 >>>=20 >>>=20 >>> Send dtn-security mailing list submissions to >>> dtn-security@irtf.org >>>=20 >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.irtf.org/mailman/listinfo/dtn-security >>> or, via email, send a message with subject or body 'help' to >>> dtn-security-request@irtf.org >>>=20 >>> You can reach the person managing the list at >>> dtn-security-owner@irtf.org >>>=20 >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of dtn-security digest..." >>>=20 >>> Today's Topics: >>>=20 >>> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>=20 >>>=20 >>> ---------- Forwarded message ---------- >>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>> >>> To: "Burleigh, Scott C" , >>> "dtn-security@irtf.org" >>> Cc: >>> Date: Tue, 22 Jan 2013 17:19:48 -0600 >>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >>> inDTN2 >>> It looks like basically a good idea to me. >>>=20 >>> I recall sometime in 2006 or 2007ish pointing out that security destinat= ions >>> needed to work more like IPsec tunnel-mode endpoints in order to make th= e >>> routing work correctly, and I think what you're proposing here accomplis= hes >>> that in a better way. >>>=20 >>> Though I think cycles would be better spent on KMP issues that are actua= lly >>> HARD, and *then* circling back to see what could be tweaked in the BSP, I= >>> definitely think this proposed change is something that would improve th= e BSP >>> a bit in the meantime. >>>=20 >>> I don't think it can be done in a way that's friendly to the existing >>> codebase like Stephen suggests shooting for. >>>=20 >>> ________________________________ >>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On B= ehalf >>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>> Sent: Tuesday, January 22, 2013 5:37 PM >>> To: dtn-security@irtf.org >>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinations i= nDTN2 >>>=20 >>> Hi. Late last September, several of us spun off a sub-thread talking ab= out >>> how the processing of bundles with multiple security destinations could b= e >>> handled in DTN implementations. I won=C2=B9t try to recreate all of the= arguments >>> on all sides, but I think we did converge on agreement that the current B= SP >>> mechanism for complex, multi-destination security could be difficult to >>> realize in coherent fashion across the network. After puzzling over thi= s for >>> a while, I came up with a concept (below) that I think would be simpler,= >>> safer, and even more powerful than the current protocol design. How do w= e >>> all feel about this? Would it be worthwhile for DTNRG to invest in a 62= 57bis >>> RFC along these lines? >>>=20 >>> Scott >>> _____________________________________________ >>> From: Burleigh, Scott C (313B) >>> Sent: Friday, November 16, 2012 5:05 PM >>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations i= n >>> DTN2 >>>=20 >>>=20 >>> Hi, Peter. At the risk (I know) of getting a lot of people severely tic= ked >>> off at me, I am going to offer a modest proposal for improving the Bundl= e >>> Security Protocol, inspired by this thread. >>> I propose to adopt a new design principle for Bundle Security Protocol: t= he >>> routing element of a bundle protocol agent should never need to inspect a= >>> bundle=C2=B9s BSP extension blocks in order to select the node(s) to for= ward the >>> bundle to. >>> That is, BSP should provide security, not dictate routes. >>> My rationale for proposing this principle is that I believe it would: >>>=20 >>> Simplify BSP, thereby reducing the incidence of bugs and making Bundle >>> Security significantly less expensive to implement and sustain. >>> Broaden the scope of BSP deployment by eliminating its dependence on >>> specific, BSP-aware routing implementations, thereby increasing the over= all >>> security of DTN. >>> Reduce the cost of developing and improving routing implementations by >>> removing any requirement that they be BSP-aware, and broaden the scope o= f >>> deployment of non-BSP-aware routing implementations by enabling them to b= e >>> used in environments requiring arbitrarily powerful security. Thereby, >>> improve DTN operational performance. >>>=20 >>> Here's how I would apply this principle: >>>=20 >>> Eliminate security sources and security destinations from all BSP blocks= . >>> The security source of a BSP block would always be the bundle=C2=B9s sou= rce. The >>> security destination of a BSP block would always be the bundle=C2=B9s de= stination. >>> Add a new Administrative Record type for Bundle-in-Bundle encapsulation.= >>> When additional security must be applied to a bundle on some segment of i= ts >>> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Encapsulat= ion >>> Administrative Record that is the payload of a new bundle whose source i= s the >>> security source of the path segment and whose destination is the securit= y >>> destination of the path segment. Apply the additional bundle transmissi= on >>> security measures to the encapsulating bundle: encrypt its payload (the >>> Administrative Record, containing the encapsulated bundle), encrypt exte= nsion >>> blocks as copied from the encapsulated bundle, etc. Then forward the >>> encapsulating bundle. >>> When route service uncertainty forces a bundle to be routed over multipl= e >>> parallel additionally secured segments of its end-to-end path, encapsula= te it >>> as above but within multiple different encapsulating bundles, one for ea= ch of >>> the parallel segments, and forward all of them. >>> At the destination of a bundle, apply all relevant bundle reception secu= rity >>> measures and then, if the payload is an encapsulation Administrative Rec= ord, >>> extract the encapsulated bundle from the Administrative Record and simpl= y >>> forward it. >>>=20 >>> I believe this would have the following impacts on DTN security: >>>=20 >>> No EID references in BSP, simplifying canonicalization. >>> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the encapsula= ted >>> bundle encrypts all three at once), so no correlators in BSP. (Except f= or >>> BABs, no bundle ever has more than one occurrence of any type of BSP blo= ck. >>> And there will never be more than two BABs, one immediately following th= e >>> primary block and one that is the final block in the bundle, so that >>> correlation is structural.) >>> No delicate =C2=B3replacement=C2=B2 process for unraveling PCB nesting a= t the >>> destination. >>> No possible confusion about the correct order of application of BSP bloc= ks. >>> No possible conflict among security destinations of different BSP blocks= . >>> Security paths can never overlap. >>> Any routing implementation can always accommodate any security regime: r= outes >>> that must be followed to ensure security are encoded into routing inform= ation >>> at the forwarding node, not into the bundle. (A little like the late bi= nding >>> principle.) >>> Any routing environment can always be made arbitrarily secure =C2=AD no n= eed to >>> require specially BSP-aware routing elements. >>> Ciphersuite design is simplified, so a wider array of useful ciphersuite= s can >>> be developed without imposing bug-prone complexity. Minimizes possible >>> security problems. >>>=20 >>> As an example of how I think this could work, see the attached diagram: >>>=20 >>> Node A is sending a bundle to node K. Nodes A, B, J, and K are within t= he >>> low-risk =C2=B3W=C2=B2 security region; nodes C and G are gateways betwe= en region W and >>> the more hazardous region X; node D is another node in X; nodes E and F a= re >>> gateways between region X and even more hazardous region Y; nodes H and I= are >>> gateways between X and hazardous region Z. >>> At A the bundle is simply forwarded to B. >>> At B the routing element realizes that the bundle has to traverse region= X in >>> order to get to K, so it forwards the bundle to C. >>> The routing element at C encapsulates the bundle in an Admin Record, cre= ates >>> a new bundle destined for G (the egress from region X) whose source is C= and >>> whose payload is that Admin Record, encrypts the payload, attaches a PCB= , and >>> forwards the bundle to D. >>> D realizes that the bundle has to traverse region Y in order to get to G= , so >>> it forwards the bundle to E. >>> E encapsulates the bundle in an Admin Record, creates a new bundle desti= ned >>> for F (the egress from region Y) whose source is E and whose payload is t= hat >>> Admin Record, encrypts the payload, attaches a PCB, and forwards the bun= dle >>> to F. >>> The bundle protocol agent at F receives the bundle, decrypts it, and pas= ses >>> the payload (an Admin Record) to the application agent. The administrat= ive >>> element of the application agent at F receives the Admin Record, extract= s the >>> encapsulated bundle destined for G, and queues it to be forwarded. The >>> routing element at F sees this bundle and forwards it to G. >>> The bundle protocol agent at G receives the bundle, decrypts it, and pas= ses >>> the payload (an Admin Record) to the application agent. The administrat= ive >>> element of the application agent at G receives the Admin Record, extract= s the >>> encapsulated bundle destined for K, and queues it to be forwarded. The >>> routing element at G sees this bundle, realizes that the bundle has to >>> traverse region Z in order to get to K, and therefore forwards the bundl= e to >>> H. >>> H encapsulates the bundle in an Admin Record, creates a new bundle desti= ned >>> for I (the egress from region Z) whose source is H and whose payload is t= hat >>> Admin Record, encrypts the payload, attaches a PCB, and forwards the bun= dle >>> to I. >>> The bundle protocol agent at I receives the bundle, decrypts it, and pas= ses >>> the payload (an Admin Record) to the application agent. The administrat= ive >>> element of the application agent at I receives the Admin Record, extract= s the >>> encapsulated bundle destined for K, and queues it to be forwarded. The >>> routing element at I sees this bundle and forwards it to J. >>> At J the bundle is simply forwarded to K. >>> At K the bundle=C2=B9s payload is passed to the application. >>>=20 >>> I think this approach would combine simplicity with quite a lot of >>> operational power, making everything cheaper and safer. >>> So, having now stirred the hornet=C2=B9s nest, I will beat a hasty retre= at for a >>> week while I am on vacation. I=C2=B9ll try to follow up when I get back= . >>> Have a nice Thanksgiving, everybody. >>> Scott >>>=20 >>> -----Original Message----- >>> From: Peter Lovell [mailto:plovell@mac.com] >>> Sent: Monday, October 22, 2012 1:28 PM >>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell >>> Subject: Re(19): [dtn-security] Implementing Security Destinations in DT= N2 >>>=20 >>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>> wrote: >>>=20 >>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>> tunneling than I've been in the past. >>>=20 >>> Hi Scott, >>>=20 >>> I agree. I'm also a big fan, for a bunch of reasons. However, as I menti= oned >>> to Angela, the current [i.e. latest, expired] draft seems a bit "funky" t= o >>> me. There's no indication in the bundle that it's BiB and you need some >>> special EID to perform the decapsulation. Maybe that's just like an assi= gned >>> port in TCP but we don't yet have such a mechanism. The multiple-bundle t= hing >>> is OK, I guess, but I don't see much use for it other than volume >>> gateway-to-gateway traffic and I think that such heavy-duty tunnels coul= d be >>> specially optimized. >>>=20 >>> I need to go back and review all the discussions about BiB -- we worked i= t >>> quite a bit but the spec never gained enough consensus to move forward. I= >>> think it would be a good idea to revisit it now and get a solid draft th= at >>> has wider support. Maybe the email discussions will help us get there. >>>=20 >>> Thanks.....Peter >>>=20 >>>=20 >>>=20 >>>=20 >>> ---------- Forwarded message ---------- >>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>> >>> To: "Burleigh, Scott C" , >>> "dtn-security@irtf.org" >>> Cc: >>> Date: Tue, 22 Jan 2013 17:47:47 -0600 >>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >>> inDTN2 >>> Agreed; that makes sense. >>>=20 >>> ________________________________ >>> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>> Sent: Tuesday, January 22, 2013 6:35 PM >>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.org= >>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >>> inDTN2 >>>=20 >>> Wes, I agree that some code change would be entailed in implementing thi= s >>> proposal, but I think a large proportion of the code =C2=AD the general f= low of >>> processing the extension blocks, the canonicalization, the ciphersuites,= >>> really almost everything that would have been implemented to handle the >>> simple case of security source/destination being identical to bundle >>> source/destination =C2=AD would be preserved. I suspect that much of wh= at I was >>> proposing here involves removing functionality that most developers have= n=C2=B9t >>> implemented yet anyway, because of the potential pitfalls. >>>=20 >>>=20 >>>=20 >>> Scott >>>=20 >>>=20 >>>=20 >>> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >>> [mailto:wesley.m.eddy@nasa.gov] >>> Sent: Tuesday, January 22, 2013 3:20 PM >>> To: Burleigh, Scott C (313B); dtn-security@irtf.org >>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >>> inDTN2 >>>=20 >>>=20 >>>=20 >>> It looks like basically a good idea to me. >>>=20 >>>=20 >>>=20 >>> I recall sometime in 2006 or 2007ish pointing out that security destinat= ions >>> needed to work more like IPsec tunnel-mode endpoints in order to make th= e >>> routing work correctly, and I think what you're proposing here accomplis= hes >>> that in a better way. >>>=20 >>>=20 >>>=20 >>> Though I think cycles would be better spent on KMP issues that are actua= lly >>> HARD, and *then* circling back to see what could be tweaked in the BSP, I= >>> definitely think this proposed change is something that would improve th= e BSP >>> a bit in the meantime. >>>=20 >>>=20 >>>=20 >>> I don't think it can be done in a way that's friendly to the existing >>> codebase like Stephen suggests shooting for. >>>=20 >>>=20 >>>=20 >>> ________________________________ >>>=20 >>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On B= ehalf >>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>> Sent: Tuesday, January 22, 2013 5:37 PM >>> To: dtn-security@irtf.org >>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinations i= nDTN2 >>>=20 >>> Hi. Late last September, several of us spun off a sub-thread talking ab= out >>> how the processing of bundles with multiple security destinations could b= e >>> handled in DTN implementations. I won=C2=B9t try to recreate all of the= arguments >>> on all sides, but I think we did converge on agreement that the current B= SP >>> mechanism for complex, multi-destination security could be difficult to >>> realize in coherent fashion across the network. After puzzling over thi= s for >>> a while, I came up with a concept (below) that I think would be simpler,= >>> safer, and even more powerful than the current protocol design. How do w= e >>> all feel about this? Would it be worthwhile for DTNRG to invest in a 62= 57bis >>> RFC along these lines? >>>=20 >>>=20 >>>=20 >>> Scott >>>=20 >>> _____________________________________________ >>> From: Burleigh, Scott C (313B) >>> Sent: Friday, November 16, 2012 5:05 PM >>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations i= n >>> DTN2 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Hi, Peter. At the risk (I know) of getting a lot of people severely tic= ked >>> off at me, I am going to offer a modest proposal for improving the Bundl= e >>> Security Protocol, inspired by this thread. >>>=20 >>> I propose to adopt a new design principle for Bundle Security Protocol: t= he >>> routing element of a bundle protocol agent should never need to inspect a= >>> bundle=C2=B9s BSP extension blocks in order to select the node(s) to for= ward the >>> bundle to. >>>=20 >>> That is, BSP should provide security, not dictate routes. >>>=20 >>> My rationale for proposing this principle is that I believe it would: >>>=20 >>> =C2=B7 Simplify BSP, thereby reducing the incidence of bugs and m= aking >>> Bundle Security significantly less expensive to implement and sustain. >>>=20 >>> =C2=B7 Broaden the scope of BSP deployment by eliminating its de= pendence >>> on specific, BSP-aware routing implementations, thereby increasing the >>> overall security of DTN. >>>=20 >>> =C2=B7 Reduce the cost of developing and improving routing imple= mentations >>> by removing any requirement that they be BSP-aware, and broaden the scop= e of >>> deployment of non-BSP-aware routing implementations by enabling them to b= e >>> used in environments requiring arbitrarily powerful security. Thereby, >>> improve DTN operational performance. >>>=20 >>> Here's how I would apply this principle: >>>=20 >>> 1. Eliminate security sources and security destinations from all B= SP >>> blocks. The security source of a BSP block would always be the bundle=C2= =B9s >>> source. The security destination of a BSP block would always be the bun= dle=C2=B9s >>> destination. >>>=20 >>> 2. Add a new Administrative Record type for Bundle-in-Bundle >>> encapsulation. >>>=20 >>> 3. When additional security must be applied to a bundle on some se= gment >>> of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>> Encapsulation Administrative Record that is the payload of a new bundle w= hose >>> source is the security source of the path segment and whose destination i= s >>> the security destination of the path segment. Apply the additional bund= le >>> transmission security measures to the encapsulating bundle: encrypt its >>> payload (the Administrative Record, containing the encapsulated bundle),= >>> encrypt extension blocks as copied from the encapsulated bundle, etc. T= hen >>> forward the encapsulating bundle. >>>=20 >>> 4. When route service uncertainty forces a bundle to be routed ove= r >>> multiple parallel additionally secured segments of its end-to-end path, >>> encapsulate it as above but within multiple different encapsulating bund= les, >>> one for each of the parallel segments, and forward all of them. >>>=20 >>> 5. At the destination of a bundle, apply all relevant bundle recep= tion >>> security measures and then, if the payload is an encapsulation Administr= ative >>> Record, extract the encapsulated bundle from the Administrative Record a= nd >>> simply forward it. >>>=20 >>> I believe this would have the following impacts on DTN security: >>>=20 >>> =C2=B7 No EID references in BSP, simplifying canonicalization. >>>=20 >>> =C2=B7 PCBs only encrypt payloads, never PIBs or PCBs (encryptin= g the >>> encapsulated bundle encrypts all three at once), so no correlators in BS= P. >>> (Except for BABs, no bundle ever has more than one occurrence of any typ= e of >>> BSP block. And there will never be more than two BABs, one immediately >>> following the primary block and one that is the final block in the bundl= e, so >>> that correlation is structural.) >>>=20 >>> =C2=B7 No delicate =C2=B3replacement=C2=B2 process for unravelin= g PCB nesting at the >>> destination. >>>=20 >>> =C2=B7 No possible confusion about the correct order of applicat= ion of BSP >>> blocks. >>>=20 >>> =C2=B7 No possible conflict among security destinations of diffe= rent BSP >>> blocks. >>>=20 >>> =C2=B7 Security paths can never overlap. >>>=20 >>> =C2=B7 Any routing implementation can always accommodate any sec= urity >>> regime: routes that must be followed to ensure security are encoded into= >>> routing information at the forwarding node, not into the bundle. (A lit= tle >>> like the late binding principle.) >>>=20 >>> =C2=B7 Any routing environment can always be made arbitrarily se= cure =C2=AD no >>> need to require specially BSP-aware routing elements. >>>=20 >>> =C2=B7 Ciphersuite design is simplified, so a wider array of use= ful >>> ciphersuites can be developed without imposing bug-prone complexity. >>> Minimizes possible security problems. >>>=20 >>> As an example of how I think this could work, see the attached diagram: >>>=20 >>> 1. Node A is sending a bundle to node K. Nodes A, B, J, and K are= >>> within the low-risk =C2=B3W=C2=B2 security region; nodes C and G are gat= eways between >>> region W and the more hazardous region X; node D is another node in X; n= odes >>> E and F are gateways between region X and even more hazardous region Y; n= odes >>> H and I are gateways between X and hazardous region Z. >>>=20 >>> 2. At A the bundle is simply forwarded to B. >>>=20 >>> 3. At B the routing element realizes that the bundle has to traver= se >>> region X in order to get to K, so it forwards the bundle to C. >>>=20 >>> 4. The routing element at C encapsulates the bundle in an Admin Re= cord, >>> creates a new bundle destined for G (the egress from region X) whose sou= rce >>> is C and whose payload is that Admin Record, encrypts the payload, attac= hes a >>> PCB, and forwards the bundle to D. >>>=20 >>> 5. D realizes that the bundle has to traverse region Y in order to= get >>> to G, so it forwards the bundle to E. >>>=20 >>> 6. E encapsulates the bundle in an Admin Record, creates a new bun= dle >>> destined for F (the egress from region Y) whose source is E and whose pa= yload >>> is that Admin Record, encrypts the payload, attaches a PCB, and forwards= the >>> bundle to F. >>>=20 >>> 7. The bundle protocol agent at F receives the bundle, decrypts it= , and >>> passes the payload (an Admin Record) to the application agent. The >>> administrative element of the application agent at F receives the Admin >>> Record, extracts the encapsulated bundle destined for G, and queues it t= o be >>> forwarded. The routing element at F sees this bundle and forwards it to= G. >>>=20 >>> 8. The bundle protocol agent at G receives the bundle, decrypts it= , and >>> passes the payload (an Admin Record) to the application agent. The >>> administrative element of the application agent at G receives the Admin >>> Record, extracts the encapsulated bundle destined for K, and queues it t= o be >>> forwarded. The routing element at G sees this bundle, realizes that the= >>> bundle has to traverse region Z in order to get to K, and therefore forw= ards >>> the bundle to H. >>>=20 >>> 9. H encapsulates the bundle in an Admin Record, creates a new bun= dle >>> destined for I (the egress from region Z) whose source is H and whose pa= yload >>> is that Admin Record, encrypts the payload, attaches a PCB, and forwards= the >>> bundle to I. >>>=20 >>> 10. The bundle protocol agent at I receives the bundle, decrypts it, a= nd >>> passes the payload (an Admin Record) to the application agent. The >>> administrative element of the application agent at I receives the Admin >>> Record, extracts the encapsulated bundle destined for K, and queues it t= o be >>> forwarded. The routing element at I sees this bundle and forwards it to= J. >>>=20 >>> 11. At J the bundle is simply forwarded to K. >>>=20 >>> 12. At K the bundle=C2=B9s payload is passed to the application. >>>=20 >>> I think this approach would combine simplicity with quite a lot of >>> operational power, making everything cheaper and safer. >>>=20 >>> So, having now stirred the hornet=C2=B9s nest, I will beat a hasty retre= at for a >>> week while I am on vacation. I=C2=B9ll try to follow up when I get back= . >>>=20 >>> Have a nice Thanksgiving, everybody. >>>=20 >>> Scott >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Peter Lovell [mailto:plovell@mac.com] >>> Sent: Monday, October 22, 2012 1:28 PM >>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell >>> Subject: Re(19): [dtn-security] Implementing Security Destinations in DT= N2 >>>=20 >>>=20 >>>=20 >>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>> wrote: >>>=20 >>>=20 >>>=20 >>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>=20 >>>> tunneling than I've been in the past. >>>=20 >>>=20 >>>=20 >>> Hi Scott, >>>=20 >>>=20 >>>=20 >>> I agree. I'm also a big fan, for a bunch of reasons. However, as I menti= oned >>> to Angela, the current [i.e. latest, expired] draft seems a bit "funky" t= o >>> me. There's no indication in the bundle that it's BiB and you need some >>> special EID to perform the decapsulation. Maybe that's just like an assi= gned >>> port in TCP but we don't yet have such a mechanism. The multiple-bundle t= hing >>> is OK, I guess, but I don't see much use for it other than volume >>> gateway-to-gateway traffic and I think that such heavy-duty tunnels coul= d be >>> specially optimized. >>>=20 >>>=20 >>>=20 >>> I need to go back and review all the discussions about BiB -- we worked i= t >>> quite a bit but the spec never gained enough consensus to move forward. I= >>> think it would be a good idea to revisit it now and get a solid draft th= at >>> has wider support. Maybe the email discussions will help us get there. >>>=20 >>>=20 >>>=20 >>> Thanks.....Peter >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dtn-security mailing list >>> dtn-security@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-security >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security >=20 > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security From ahennes1@gmail.com Sun Jan 27 13:42:22 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF6E21F84D1 for ; Sun, 27 Jan 2013 13:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pCMJnS9rjUd for ; Sun, 27 Jan 2013 13:42:20 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id D76A121F8487 for ; Sun, 27 Jan 2013 13:42:19 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id j14so3119938lbo.10 for ; Sun, 27 Jan 2013 13:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=5gJWcjyxIJj3C3EzbI0mSxAPYlXFggN79qrb+EwFC7Q=; b=0iKIVSaeGhIr1LSzmjlwYTXekwXmKdCzmx4w+0b9ySj0ACjU1y9i8QYjVrnP7/nGb0 Bj4+j/kQAvlh+JFtXnc6wLPqAw42+dju2wMOqy9yfsSnS948hUiUISBnUts1hz+ss7Hl P7Z5wC6XLauJwv+4DF4qM/IX160qYIzhCfqPW5rDqCQLEBIHLTeHjplbSlSS9jV+uMgm hgjOCk9Q8W4hpSdgP6eUA0u09v1pqEo/rctWhXUyAkHsXa2BsYxMChqsFQzpqBx92mCw EGaegRJpSJZ9sdhEl8NTrAKLP1Gm4ASxL+pdG8wtTUa3aJQnbND0lRYuAW+GzCpORyhY lkEg== MIME-Version: 1.0 X-Received: by 10.152.46.17 with SMTP id r17mr11262007lam.47.1359322938600; Sun, 27 Jan 2013 13:42:18 -0800 (PST) Sender: ahennes1@gmail.com Received: by 10.112.150.39 with HTTP; Sun, 27 Jan 2013 13:42:18 -0800 (PST) In-Reply-To: References: Date: Sun, 27 Jan 2013 16:42:18 -0500 X-Google-Sender-Auth: 4isTES3hMawtmmyJt1nZ0Rq5i0c Message-ID: From: Angela Hennessy To: dtn-security@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 21:42:23 -0000 Hi Ed, I definitely agree that things can get pretty complicated dealing with the security src/dest, and we've run into some issues when implementing them. I think the idea of using bundle-in-bundle encapsulation is an interesting alternative, and I'll be interested to read all the details. thanks, Angela On Sat, Jan 26, 2013 at 9:09 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.irtf.org/mailman/listinfo/dtn-security > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send dtn-security mailing list submissions to > dtn-security@irtf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/dtn-security > or, via email, send a message with subject or body 'help' to > dtn-security-request@irtf.org > > You can reach the person managing the list at > dtn-security-owner@irtf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dtn-security digest..." > > Today's Topics: > > 1. Re: dtn-security Digest, Vol 9, Issue 4 (Stephen Farrell) > > > ---------- Forwarded message ---------- > From: Stephen Farrell > To: "Birrane, Edward J." > Cc: "dtn-security@irtf.org" > Date: Sun, 27 Jan 2013 02:08:27 +0000 > Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 > > > On 27 Jan 2013, at 01:18, "Birrane, Edward J." wrote: > >> Angela, >> >> I see (at least) two issues independent enough that they should not be >> conflated. The first is whether simplifying the BSP specification, to = omit >> tight routing coupling, is beneficial. The second is the utility of the >> bundle-in-bundle encapsulation mechanism in a security context. >> >> 1. Simplifying BSP >> What we have found is that the concept of a security destination, >> separate from a bundle destination, places a burden on any routing mecha= nism >> to guarantee delivery through one or more "waypoints" before the bundle >> reaches its destination. Since routing mechanisms cannot make this >> guarantee in any type of opportunistic network (and may struggle to make >> this guarantee in structured networks) we need to find a way to relax th= is >> language and the implementation hurdles it imposes. Removing security >> sources and destinations from the specification and deferring tunneling = and >> multi-point behavior to some other mechanism (or mechanisms) seems like = a >> promising way to go for BSP. >> >> I think most folks on this list agree with the above, but before we get >> too deeply into specifics surrounding encapsulation, it is probably a go= od >> idea to check that assumption. >> >> ---> Do we agree that (provided we can meet necessary use cases) this is= a >> desired simplification of BSP? > > That's neither needed nor necessarily desirable. Just write the draft tha= t says how to do it, then ask if people like it. Abstract argument in advan= ce doesn't seem useful. > > S > >> >> >> 2. Bundle-in-Bundle (BiB) encapsulation >> >> BiB is a useful way to create a tunnel in a network at the BP layer. Wi= th >> any tunneled packet, it should be protected from misuse while in the tun= nel, >> and encapsulation is a way to do that. IMO, it should be used exactly i= n >> those situations where we need a security destination that is different = than >> the bundle destination; i.e. When we need to make a security tunnel. >> >> Actions such as adding a signature to a bundle or encrypting a bundle, >> would not require encapsulation if the security destinations remain the >> bundle destinations. The only exception here would be BAB, which is the >> special case of next-hop neighbors, which would still not require an >> encapsulation, but the security destination would be understood to be th= e >> next immediate BP hop which is knowable by the routing subsystem (arguab= ly >> the only thing knowable by the routing subsystem). >> >> If we have extension blocks that have security destinations different f= rom >> the payload security destinations, then it sounds like we are treating >> extension blocks as "extra" independent payloads and that may cause iden= tity >> problems beyond these BSP issues. >> >> It would probably be helpful to specify a concrete use-case surrounding >> the signing and encrypting of payloads and extension blocks along the >> traversed path of a bundle. Could you propose such a use case? >> >> -Ed >> >> On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" wrot= e: >> >>> Hi Scott, >>> >>> I like how this approach simplifies the routing and gets rid of the >>> security src/dest and EID refs. I was a little confused though about >>> how this would work with some of the combinations of security blocks: >>> >>> If a node just wants to add a signature to a bundle, would this >>> require the bundle to be encapsulated? One of the advantages of BSP is >>> that non security-aware nodes can still access the payload by just >>> ignoring the PIB block. Wouldn't we lose that feature if the bundle >>> were encapsulated? >>> >>> If a node wants to sign and then encrypt the bundle, does this require >>> the bundle to be encapsulated twice? >>> >>> How would we handle signing/encrypting extension blocks? Would this >>> require a third encapsulation? Wouldn't we still need correlators in >>> case multiple extension blocks are encrypted with the same key, or >>> would we not allow different extension blocks to be encrypted with >>> different keys? >>> >>> >>> Thanks, >>> Angela >>> >>> >>> >>> On Tue, Jan 22, 2013 at 6:49 PM, wrote= : >>>> If you have received this digest without all the individual message >>>> attachments you will need to update your digest options in your list >>>> subscription. To do so, go to >>>> >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> >>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>> globally for all the list digests you receive at this point. >>>> >>>> >>>> >>>> Send dtn-security mailing list submissions to >>>> dtn-security@irtf.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> or, via email, send a message with subject or body 'help' to >>>> dtn-security-request@irtf.org >>>> >>>> You can reach the person managing the list at >>>> dtn-security-owner@irtf.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of dtn-security digest..." >>>> >>>> Today's Topics: >>>> >>>> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>> >>>> To: "Burleigh, Scott C" , >>>> "dtn-security@irtf.org" >>>> Cc: >>>> Date: Tue, 22 Jan 2013 17:19:48 -0600 >>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinat= ions >>>> inDTN2 >>>> It looks like basically a good idea to me. >>>> >>>> I recall sometime in 2006 or 2007ish pointing out that security destin= ations >>>> needed to work more like IPsec tunnel-mode endpoints in order to make = the >>>> routing work correctly, and I think what you're proposing here accompl= ishes >>>> that in a better way. >>>> >>>> Though I think cycles would be better spent on KMP issues that are act= ually >>>> HARD, and *then* circling back to see what could be tweaked in the BSP= , I >>>> definitely think this proposed change is something that would improve = the BSP >>>> a bit in the meantime. >>>> >>>> I don't think it can be done in a way that's friendly to the existing >>>> codebase like Stephen suggests shooting for. >>>> >>>> ________________________________ >>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On= Behalf >>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>> To: dtn-security@irtf.org >>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinations= inDTN2 >>>> >>>> Hi. Late last September, several of us spun off a sub-thread talking = about >>>> how the processing of bundles with multiple security destinations coul= d be >>>> handled in DTN implementations. I won=B9t try to recreate all of the = arguments >>>> on all sides, but I think we did converge on agreement that the curren= t BSP >>>> mechanism for complex, multi-destination security could be difficult t= o >>>> realize in coherent fashion across the network. After puzzling over t= his for >>>> a while, I came up with a concept (below) that I think would be simple= r, >>>> safer, and even more powerful than the current protocol design. How d= o we >>>> all feel about this? Would it be worthwhile for DTNRG to invest in a = 6257bis >>>> RFC along these lines? >>>> >>>> Scott >>>> _____________________________________________ >>>> From: Burleigh, Scott C (313B) >>>> Sent: Friday, November 16, 2012 5:05 PM >>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations= in >>>> DTN2 >>>> >>>> >>>> Hi, Peter. At the risk (I know) of getting a lot of people severely t= icked >>>> off at me, I am going to offer a modest proposal for improving the Bun= dle >>>> Security Protocol, inspired by this thread. >>>> I propose to adopt a new design principle for Bundle Security Protocol= : the >>>> routing element of a bundle protocol agent should never need to inspec= t a >>>> bundle=B9s BSP extension blocks in order to select the node(s) to forw= ard the >>>> bundle to. >>>> That is, BSP should provide security, not dictate routes. >>>> My rationale for proposing this principle is that I believe it would: >>>> >>>> Simplify BSP, thereby reducing the incidence of bugs and making Bundle >>>> Security significantly less expensive to implement and sustain. >>>> Broaden the scope of BSP deployment by eliminating its dependence on >>>> specific, BSP-aware routing implementations, thereby increasing the ov= erall >>>> security of DTN. >>>> Reduce the cost of developing and improving routing implementations by >>>> removing any requirement that they be BSP-aware, and broaden the scope= of >>>> deployment of non-BSP-aware routing implementations by enabling them t= o be >>>> used in environments requiring arbitrarily powerful security. Thereby= , >>>> improve DTN operational performance. >>>> >>>> Here's how I would apply this principle: >>>> >>>> Eliminate security sources and security destinations from all BSP bloc= ks. >>>> The security source of a BSP block would always be the bundle=B9s sour= ce. The >>>> security destination of a BSP block would always be the bundle=B9s des= tination. >>>> Add a new Administrative Record type for Bundle-in-Bundle encapsulatio= n. >>>> When additional security must be applied to a bundle on some segment o= f its >>>> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle Encapsul= ation >>>> Administrative Record that is the payload of a new bundle whose source= is the >>>> security source of the path segment and whose destination is the secur= ity >>>> destination of the path segment. Apply the additional bundle transmis= sion >>>> security measures to the encapsulating bundle: encrypt its payload (th= e >>>> Administrative Record, containing the encapsulated bundle), encrypt ex= tension >>>> blocks as copied from the encapsulated bundle, etc. Then forward the >>>> encapsulating bundle. >>>> When route service uncertainty forces a bundle to be routed over multi= ple >>>> parallel additionally secured segments of its end-to-end path, encapsu= late it >>>> as above but within multiple different encapsulating bundles, one for = each of >>>> the parallel segments, and forward all of them. >>>> At the destination of a bundle, apply all relevant bundle reception se= curity >>>> measures and then, if the payload is an encapsulation Administrative R= ecord, >>>> extract the encapsulated bundle from the Administrative Record and sim= ply >>>> forward it. >>>> >>>> I believe this would have the following impacts on DTN security: >>>> >>>> No EID references in BSP, simplifying canonicalization. >>>> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the encapsu= lated >>>> bundle encrypts all three at once), so no correlators in BSP. (Except= for >>>> BABs, no bundle ever has more than one occurrence of any type of BSP b= lock. >>>> And there will never be more than two BABs, one immediately following = the >>>> primary block and one that is the final block in the bundle, so that >>>> correlation is structural.) >>>> No delicate =B3replacement=B2 process for unraveling PCB nesting at th= e >>>> destination. >>>> No possible confusion about the correct order of application of BSP bl= ocks. >>>> No possible conflict among security destinations of different BSP bloc= ks. >>>> Security paths can never overlap. >>>> Any routing implementation can always accommodate any security regime:= routes >>>> that must be followed to ensure security are encoded into routing info= rmation >>>> at the forwarding node, not into the bundle. (A little like the late = binding >>>> principle.) >>>> Any routing environment can always be made arbitrarily secure =AD no n= eed to >>>> require specially BSP-aware routing elements. >>>> Ciphersuite design is simplified, so a wider array of useful ciphersui= tes can >>>> be developed without imposing bug-prone complexity. Minimizes possibl= e >>>> security problems. >>>> >>>> As an example of how I think this could work, see the attached diagram= : >>>> >>>> Node A is sending a bundle to node K. Nodes A, B, J, and K are within= the >>>> low-risk =B3W=B2 security region; nodes C and G are gateways between r= egion W and >>>> the more hazardous region X; node D is another node in X; nodes E and = F are >>>> gateways between region X and even more hazardous region Y; nodes H an= d I are >>>> gateways between X and hazardous region Z. >>>> At A the bundle is simply forwarded to B. >>>> At B the routing element realizes that the bundle has to traverse regi= on X in >>>> order to get to K, so it forwards the bundle to C. >>>> The routing element at C encapsulates the bundle in an Admin Record, c= reates >>>> a new bundle destined for G (the egress from region X) whose source is= C and >>>> whose payload is that Admin Record, encrypts the payload, attaches a P= CB, and >>>> forwards the bundle to D. >>>> D realizes that the bundle has to traverse region Y in order to get to= G, so >>>> it forwards the bundle to E. >>>> E encapsulates the bundle in an Admin Record, creates a new bundle des= tined >>>> for F (the egress from region Y) whose source is E and whose payload i= s that >>>> Admin Record, encrypts the payload, attaches a PCB, and forwards the b= undle >>>> to F. >>>> The bundle protocol agent at F receives the bundle, decrypts it, and p= asses >>>> the payload (an Admin Record) to the application agent. The administr= ative >>>> element of the application agent at F receives the Admin Record, extra= cts the >>>> encapsulated bundle destined for G, and queues it to be forwarded. Th= e >>>> routing element at F sees this bundle and forwards it to G. >>>> The bundle protocol agent at G receives the bundle, decrypts it, and p= asses >>>> the payload (an Admin Record) to the application agent. The administr= ative >>>> element of the application agent at G receives the Admin Record, extra= cts the >>>> encapsulated bundle destined for K, and queues it to be forwarded. Th= e >>>> routing element at G sees this bundle, realizes that the bundle has to >>>> traverse region Z in order to get to K, and therefore forwards the bun= dle to >>>> H. >>>> H encapsulates the bundle in an Admin Record, creates a new bundle des= tined >>>> for I (the egress from region Z) whose source is H and whose payload i= s that >>>> Admin Record, encrypts the payload, attaches a PCB, and forwards the b= undle >>>> to I. >>>> The bundle protocol agent at I receives the bundle, decrypts it, and p= asses >>>> the payload (an Admin Record) to the application agent. The administr= ative >>>> element of the application agent at I receives the Admin Record, extra= cts the >>>> encapsulated bundle destined for K, and queues it to be forwarded. Th= e >>>> routing element at I sees this bundle and forwards it to J. >>>> At J the bundle is simply forwarded to K. >>>> At K the bundle=B9s payload is passed to the application. >>>> >>>> I think this approach would combine simplicity with quite a lot of >>>> operational power, making everything cheaper and safer. >>>> So, having now stirred the hornet=B9s nest, I will beat a hasty retrea= t for a >>>> week while I am on vacation. I=B9ll try to follow up when I get back. >>>> Have a nice Thanksgiving, everybody. >>>> Scott >>>> >>>> -----Original Message----- >>>> From: Peter Lovell [mailto:plovell@mac.com] >>>> Sent: Monday, October 22, 2012 1:28 PM >>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell >>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in = DTN2 >>>> >>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>> wrote: >>>> >>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>> tunneling than I've been in the past. >>>> >>>> Hi Scott, >>>> >>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I men= tioned >>>> to Angela, the current [i.e. latest, expired] draft seems a bit "funky= " to >>>> me. There's no indication in the bundle that it's BiB and you need som= e >>>> special EID to perform the decapsulation. Maybe that's just like an as= signed >>>> port in TCP but we don't yet have such a mechanism. The multiple-bundl= e thing >>>> is OK, I guess, but I don't see much use for it other than volume >>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels co= uld be >>>> specially optimized. >>>> >>>> I need to go back and review all the discussions about BiB -- we worke= d it >>>> quite a bit but the spec never gained enough consensus to move forward= . I >>>> think it would be a good idea to revisit it now and get a solid draft = that >>>> has wider support. Maybe the email discussions will help us get there. >>>> >>>> Thanks.....Peter >>>> >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>> >>>> To: "Burleigh, Scott C" , >>>> "dtn-security@irtf.org" >>>> Cc: >>>> Date: Tue, 22 Jan 2013 17:47:47 -0600 >>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinat= ions >>>> inDTN2 >>>> Agreed; that makes sense. >>>> >>>> ________________________________ >>>> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>> Sent: Tuesday, January 22, 2013 6:35 PM >>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.o= rg >>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinat= ions >>>> inDTN2 >>>> >>>> Wes, I agree that some code change would be entailed in implementing t= his >>>> proposal, but I think a large proportion of the code =AD the general f= low of >>>> processing the extension blocks, the canonicalization, the ciphersuite= s, >>>> really almost everything that would have been implemented to handle th= e >>>> simple case of security source/destination being identical to bundle >>>> source/destination =AD would be preserved. I suspect that much of wha= t I was >>>> proposing here involves removing functionality that most developers ha= ven=B9t >>>> implemented yet anyway, because of the potential pitfalls. >>>> >>>> >>>> >>>> Scott >>>> >>>> >>>> >>>> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >>>> [mailto:wesley.m.eddy@nasa.gov] >>>> Sent: Tuesday, January 22, 2013 3:20 PM >>>> To: Burleigh, Scott C (313B); dtn-security@irtf.org >>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinat= ions >>>> inDTN2 >>>> >>>> >>>> >>>> It looks like basically a good idea to me. >>>> >>>> >>>> >>>> I recall sometime in 2006 or 2007ish pointing out that security destin= ations >>>> needed to work more like IPsec tunnel-mode endpoints in order to make = the >>>> routing work correctly, and I think what you're proposing here accompl= ishes >>>> that in a better way. >>>> >>>> >>>> >>>> Though I think cycles would be better spent on KMP issues that are act= ually >>>> HARD, and *then* circling back to see what could be tweaked in the BSP= , I >>>> definitely think this proposed change is something that would improve = the BSP >>>> a bit in the meantime. >>>> >>>> >>>> >>>> I don't think it can be done in a way that's friendly to the existing >>>> codebase like Stephen suggests shooting for. >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] On= Behalf >>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>> To: dtn-security@irtf.org >>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinations= inDTN2 >>>> >>>> Hi. Late last September, several of us spun off a sub-thread talking = about >>>> how the processing of bundles with multiple security destinations coul= d be >>>> handled in DTN implementations. I won=B9t try to recreate all of the = arguments >>>> on all sides, but I think we did converge on agreement that the curren= t BSP >>>> mechanism for complex, multi-destination security could be difficult t= o >>>> realize in coherent fashion across the network. After puzzling over t= his for >>>> a while, I came up with a concept (below) that I think would be simple= r, >>>> safer, and even more powerful than the current protocol design. How d= o we >>>> all feel about this? Would it be worthwhile for DTNRG to invest in a = 6257bis >>>> RFC along these lines? >>>> >>>> >>>> >>>> Scott >>>> >>>> _____________________________________________ >>>> From: Burleigh, Scott C (313B) >>>> Sent: Friday, November 16, 2012 5:05 PM >>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinations= in >>>> DTN2 >>>> >>>> >>>> >>>> >>>> >>>> Hi, Peter. At the risk (I know) of getting a lot of people severely t= icked >>>> off at me, I am going to offer a modest proposal for improving the Bun= dle >>>> Security Protocol, inspired by this thread. >>>> >>>> I propose to adopt a new design principle for Bundle Security Protocol= : the >>>> routing element of a bundle protocol agent should never need to inspec= t a >>>> bundle=B9s BSP extension blocks in order to select the node(s) to forw= ard the >>>> bundle to. >>>> >>>> That is, BSP should provide security, not dictate routes. >>>> >>>> My rationale for proposing this principle is that I believe it would: >>>> >>>> =B7 Simplify BSP, thereby reducing the incidence of bugs and m= aking >>>> Bundle Security significantly less expensive to implement and sustain. >>>> >>>> =B7 Broaden the scope of BSP deployment by eliminating its dep= endence >>>> on specific, BSP-aware routing implementations, thereby increasing the >>>> overall security of DTN. >>>> >>>> =B7 Reduce the cost of developing and improving routing implem= entations >>>> by removing any requirement that they be BSP-aware, and broaden the sc= ope of >>>> deployment of non-BSP-aware routing implementations by enabling them t= o be >>>> used in environments requiring arbitrarily powerful security. Thereby= , >>>> improve DTN operational performance. >>>> >>>> Here's how I would apply this principle: >>>> >>>> 1. Eliminate security sources and security destinations from all= BSP >>>> blocks. The security source of a BSP block would always be the bundle= =B9s >>>> source. The security destination of a BSP block would always be the b= undle=B9s >>>> destination. >>>> >>>> 2. Add a new Administrative Record type for Bundle-in-Bundle >>>> encapsulation. >>>> >>>> 3. When additional security must be applied to a bundle on some = segment >>>> of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>> Encapsulation Administrative Record that is the payload of a new bundl= e whose >>>> source is the security source of the path segment and whose destinatio= n is >>>> the security destination of the path segment. Apply the additional bu= ndle >>>> transmission security measures to the encapsulating bundle: encrypt it= s >>>> payload (the Administrative Record, containing the encapsulated bundle= ), >>>> encrypt extension blocks as copied from the encapsulated bundle, etc. = Then >>>> forward the encapsulating bundle. >>>> >>>> 4. When route service uncertainty forces a bundle to be routed o= ver >>>> multiple parallel additionally secured segments of its end-to-end path= , >>>> encapsulate it as above but within multiple different encapsulating bu= ndles, >>>> one for each of the parallel segments, and forward all of them. >>>> >>>> 5. At the destination of a bundle, apply all relevant bundle rec= eption >>>> security measures and then, if the payload is an encapsulation Adminis= trative >>>> Record, extract the encapsulated bundle from the Administrative Record= and >>>> simply forward it. >>>> >>>> I believe this would have the following impacts on DTN security: >>>> >>>> =B7 No EID references in BSP, simplifying canonicalization. >>>> >>>> =B7 PCBs only encrypt payloads, never PIBs or PCBs (encrypting= the >>>> encapsulated bundle encrypts all three at once), so no correlators in = BSP. >>>> (Except for BABs, no bundle ever has more than one occurrence of any t= ype of >>>> BSP block. And there will never be more than two BABs, one immediatel= y >>>> following the primary block and one that is the final block in the bun= dle, so >>>> that correlation is structural.) >>>> >>>> =B7 No delicate =B3replacement=B2 process for unraveling PCB n= esting at the >>>> destination. >>>> >>>> =B7 No possible confusion about the correct order of applicati= on of BSP >>>> blocks. >>>> >>>> =B7 No possible conflict among security destinations of differ= ent BSP >>>> blocks. >>>> >>>> =B7 Security paths can never overlap. >>>> >>>> =B7 Any routing implementation can always accommodate any secu= rity >>>> regime: routes that must be followed to ensure security are encoded in= to >>>> routing information at the forwarding node, not into the bundle. (A l= ittle >>>> like the late binding principle.) >>>> >>>> =B7 Any routing environment can always be made arbitrarily sec= ure =AD no >>>> need to require specially BSP-aware routing elements. >>>> >>>> =B7 Ciphersuite design is simplified, so a wider array of usef= ul >>>> ciphersuites can be developed without imposing bug-prone complexity. >>>> Minimizes possible security problems. >>>> >>>> As an example of how I think this could work, see the attached diagram= : >>>> >>>> 1. Node A is sending a bundle to node K. Nodes A, B, J, and K a= re >>>> within the low-risk =B3W=B2 security region; nodes C and G are gateway= s between >>>> region W and the more hazardous region X; node D is another node in X;= nodes >>>> E and F are gateways between region X and even more hazardous region Y= ; nodes >>>> H and I are gateways between X and hazardous region Z. >>>> >>>> 2. At A the bundle is simply forwarded to B. >>>> >>>> 3. At B the routing element realizes that the bundle has to trav= erse >>>> region X in order to get to K, so it forwards the bundle to C. >>>> >>>> 4. The routing element at C encapsulates the bundle in an Admin = Record, >>>> creates a new bundle destined for G (the egress from region X) whose s= ource >>>> is C and whose payload is that Admin Record, encrypts the payload, att= aches a >>>> PCB, and forwards the bundle to D. >>>> >>>> 5. D realizes that the bundle has to traverse region Y in order = to get >>>> to G, so it forwards the bundle to E. >>>> >>>> 6. E encapsulates the bundle in an Admin Record, creates a new b= undle >>>> destined for F (the egress from region Y) whose source is E and whose = payload >>>> is that Admin Record, encrypts the payload, attaches a PCB, and forwar= ds the >>>> bundle to F. >>>> >>>> 7. The bundle protocol agent at F receives the bundle, decrypts = it, and >>>> passes the payload (an Admin Record) to the application agent. The >>>> administrative element of the application agent at F receives the Admi= n >>>> Record, extracts the encapsulated bundle destined for G, and queues it= to be >>>> forwarded. The routing element at F sees this bundle and forwards it = to G. >>>> >>>> 8. The bundle protocol agent at G receives the bundle, decrypts = it, and >>>> passes the payload (an Admin Record) to the application agent. The >>>> administrative element of the application agent at G receives the Admi= n >>>> Record, extracts the encapsulated bundle destined for K, and queues it= to be >>>> forwarded. The routing element at G sees this bundle, realizes that t= he >>>> bundle has to traverse region Z in order to get to K, and therefore fo= rwards >>>> the bundle to H. >>>> >>>> 9. H encapsulates the bundle in an Admin Record, creates a new b= undle >>>> destined for I (the egress from region Z) whose source is H and whose = payload >>>> is that Admin Record, encrypts the payload, attaches a PCB, and forwar= ds the >>>> bundle to I. >>>> >>>> 10. The bundle protocol agent at I receives the bundle, decrypts it,= and >>>> passes the payload (an Admin Record) to the application agent. The >>>> administrative element of the application agent at I receives the Admi= n >>>> Record, extracts the encapsulated bundle destined for K, and queues it= to be >>>> forwarded. The routing element at I sees this bundle and forwards it = to J. >>>> >>>> 11. At J the bundle is simply forwarded to K. >>>> >>>> 12. At K the bundle=B9s payload is passed to the application. >>>> >>>> I think this approach would combine simplicity with quite a lot of >>>> operational power, making everything cheaper and safer. >>>> >>>> So, having now stirred the hornet=B9s nest, I will beat a hasty retrea= t for a >>>> week while I am on vacation. I=B9ll try to follow up when I get back. >>>> >>>> Have a nice Thanksgiving, everybody. >>>> >>>> Scott >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Peter Lovell [mailto:plovell@mac.com] >>>> Sent: Monday, October 22, 2012 1:28 PM >>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovell >>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in = DTN2 >>>> >>>> >>>> >>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>> wrote: >>>> >>>> >>>> >>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>> >>>>> tunneling than I've been in the past. >>>> >>>> >>>> >>>> Hi Scott, >>>> >>>> >>>> >>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I men= tioned >>>> to Angela, the current [i.e. latest, expired] draft seems a bit "funky= " to >>>> me. There's no indication in the bundle that it's BiB and you need som= e >>>> special EID to perform the decapsulation. Maybe that's just like an as= signed >>>> port in TCP but we don't yet have such a mechanism. The multiple-bundl= e thing >>>> is OK, I guess, but I don't see much use for it other than volume >>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels co= uld be >>>> specially optimized. >>>> >>>> >>>> >>>> I need to go back and review all the discussions about BiB -- we worke= d it >>>> quite a bit but the spec never gained enough consensus to move forward= . I >>>> think it would be a good idea to revisit it now and get a solid draft = that >>>> has wider support. Maybe the email discussions will help us get there. >>>> >>>> >>>> >>>> Thanks.....Peter >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> dtn-security mailing list >>>> dtn-security@irtf.org >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>> _______________________________________________ >>> dtn-security mailing list >>> dtn-security@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-security >> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security > > > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security > From william.d.ivancic@nasa.gov Mon Jan 28 07:46:33 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8D221F892C for ; Mon, 28 Jan 2013 07:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqmR73G3Wwxq for ; Mon, 28 Jan 2013 07:46:31 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 237EF21F8930 for ; Mon, 28 Jan 2013 07:46:31 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 3AC9B1081D6; Mon, 28 Jan 2013 09:46:30 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r0SFkTGZ008429; Mon, 28 Jan 2013 09:46:29 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Mon, 28 Jan 2013 09:46:29 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: Angela Hennessy , "dtn-security@irtf.org" Date: Mon, 28 Jan 2013 09:46:57 -0600 Thread-Topic: [dtn-security] dtn-security Digest, Vol 9, Issue 9 Thread-Index: Ac381zRjdU3YxMZfTICH6878mn8fqwAl3+C4 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-28_02:2013-01-27, 2013-01-28, 1970-01-01 signatures=0 Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:46:34 -0000 Angela, I believe your group was performing interoperability testing between variou= s DTN implementations. If so, Can you summarize the results and perhaps point to the test plan or any reports. IMHO, as is, the BSP would be very difficult to achieve full interoperability over all option and parameters due to the complexity. Simplifying would be a good thing, but perhaps premature if the overall protocol is to be revised. In other words, is this still research or will there be a move to operational deployment (a minimum of 1000s of agents). Will ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic > From: Angela Hennessy > Date: Sun, 27 Jan 2013 15:42:18 -0600 > To: "dtn-security@irtf.org" > Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 > > Hi Ed, > > I definitely agree that things can get pretty complicated dealing with > the security src/dest, and we've run into some issues when > implementing them. I think the idea of using bundle-in-bundle > encapsulation is an interesting alternative, and I'll be interested to > read all the details. > > > thanks, > Angela > > On Sat, Jan 26, 2013 at 9:09 PM, wrote: >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.irtf.org/mailman/listinfo/dtn-security >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send dtn-security mailing list submissions to >> dtn-security@irtf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.irtf.org/mailman/listinfo/dtn-security >> or, via email, send a message with subject or body 'help' to >> dtn-security-request@irtf.org >> >> You can reach the person managing the list at >> dtn-security-owner@irtf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of dtn-security digest..." >> >> Today's Topics: >> >> 1. Re: dtn-security Digest, Vol 9, Issue 4 (Stephen Farrell) >> >> >> ---------- Forwarded message ---------- >> From: Stephen Farrell >> To: "Birrane, Edward J." >> Cc: "dtn-security@irtf.org" >> Date: Sun, 27 Jan 2013 02:08:27 +0000 >> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 >> >> >> On 27 Jan 2013, at 01:18, "Birrane, Edward J." >> wrote: >> >>> Angela, >>> >>> I see (at least) two issues independent enough that they should not b= e >>> conflated. The first is whether simplifying the BSP specification, to= omit >>> tight routing coupling, is beneficial. The second is the utility of th= e >>> bundle-in-bundle encapsulation mechanism in a security context. >>> >>> 1. Simplifying BSP >>> What we have found is that the concept of a security destination, >>> separate from a bundle destination, places a burden on any routing mech= anism >>> to guarantee delivery through one or more "waypoints" before the bundle >>> reaches its destination. Since routing mechanisms cannot make this >>> guarantee in any type of opportunistic network (and may struggle to mak= e >>> this guarantee in structured networks) we need to find a way to relax t= his >>> language and the implementation hurdles it imposes. Removing security >>> sources and destinations from the specification and deferring tunneling= and >>> multi-point behavior to some other mechanism (or mechanisms) seems like= a >>> promising way to go for BSP. >>> >>> I think most folks on this list agree with the above, but before we ge= t >>> too deeply into specifics surrounding encapsulation, it is probably a g= ood >>> idea to check that assumption. >>> >>> ---> Do we agree that (provided we can meet necessary use cases) this i= s a >>> desired simplification of BSP? >> >> That's neither needed nor necessarily desirable. Just write the draft th= at >> says how to do it, then ask if people like it. Abstract argument in adva= nce >> doesn't seem useful. >> >> S >> >>> >>> >>> 2. Bundle-in-Bundle (BiB) encapsulation >>> >>> BiB is a useful way to create a tunnel in a network at the BP layer. W= ith >>> any tunneled packet, it should be protected from misuse while in the tu= nnel, >>> and encapsulation is a way to do that. IMO, it should be used exactly = in >>> those situations where we need a security destination that is different= than >>> the bundle destination; i.e. When we need to make a security tunnel. >>> >>> Actions such as adding a signature to a bundle or encrypting a bundle, >>> would not require encapsulation if the security destinations remain the >>> bundle destinations. The only exception here would be BAB, which is the >>> special case of next-hop neighbors, which would still not require an >>> encapsulation, but the security destination would be understood to be t= he >>> next immediate BP hop which is knowable by the routing subsystem (argua= bly >>> the only thing knowable by the routing subsystem). >>> >>> If we have extension blocks that have security destinations different = from >>> the payload security destinations, then it sounds like we are treating >>> extension blocks as "extra" independent payloads and that may cause ide= ntity >>> problems beyond these BSP issues. >>> >>> It would probably be helpful to specify a concrete use-case surroundin= g >>> the signing and encrypting of payloads and extension blocks along the >>> traversed path of a bundle. Could you propose such a use case? >>> >>> -Ed >>> >>> On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" wro= te: >>> >>>> Hi Scott, >>>> >>>> I like how this approach simplifies the routing and gets rid of the >>>> security src/dest and EID refs. I was a little confused though about >>>> how this would work with some of the combinations of security blocks: >>>> >>>> If a node just wants to add a signature to a bundle, would this >>>> require the bundle to be encapsulated? One of the advantages of BSP is >>>> that non security-aware nodes can still access the payload by just >>>> ignoring the PIB block. Wouldn't we lose that feature if the bundle >>>> were encapsulated? >>>> >>>> If a node wants to sign and then encrypt the bundle, does this require >>>> the bundle to be encapsulated twice? >>>> >>>> How would we handle signing/encrypting extension blocks? Would this >>>> require a third encapsulation? Wouldn't we still need correlators in >>>> case multiple extension blocks are encrypted with the same key, or >>>> would we not allow different extension blocks to be encrypted with >>>> different keys? >>>> >>>> >>>> Thanks, >>>> Angela >>>> >>>> >>>> >>>> On Tue, Jan 22, 2013 at 6:49 PM, wrot= e: >>>>> If you have received this digest without all the individual message >>>>> attachments you will need to update your digest options in your list >>>>> subscription. To do so, go to >>>>> >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>> globally for all the list digests you receive at this point. >>>>> >>>>> >>>>> >>>>> Send dtn-security mailing list submissions to >>>>> dtn-security@irtf.org >>>>> >>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> or, via email, send a message with subject or body 'help' to >>>>> dtn-security-request@irtf.org >>>>> >>>>> You can reach the person managing the list at >>>>> dtn-security-owner@irtf.org >>>>> >>>>> When replying, please edit your Subject line so it is more specific >>>>> than "Re: Contents of dtn-security digest..." >>>>> >>>>> Today's Topics: >>>>> >>>>> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>> >>>>> To: "Burleigh, Scott C" , >>>>> "dtn-security@irtf.org" >>>>> Cc: >>>>> Date: Tue, 22 Jan 2013 17:19:48 -0600 >>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destina= tions >>>>> inDTN2 >>>>> It looks like basically a good idea to me. >>>>> >>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>> destinations >>>>> needed to work more like IPsec tunnel-mode endpoints in order to make= the >>>>> routing work correctly, and I think what you're proposing here >>>>> accomplishes >>>>> that in a better way. >>>>> >>>>> Though I think cycles would be better spent on KMP issues that are >>>>> actually >>>>> HARD, and *then* circling back to see what could be tweaked in the BS= P, I >>>>> definitely think this proposed change is something that would improve= the >>>>> BSP >>>>> a bit in the meantime. >>>>> >>>>> I don't think it can be done in a way that's friendly to the existing >>>>> codebase like Stephen suggests shooting for. >>>>> >>>>> ________________________________ >>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] O= n >>>>> Behalf >>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>> To: dtn-security@irtf.org >>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destination= s >>>>> inDTN2 >>>>> >>>>> Hi. Late last September, several of us spun off a sub-thread talking >>>>> about >>>>> how the processing of bundles with multiple security destinations cou= ld be >>>>> handled in DTN implementations. I won=B9t try to recreate all of the >>>>> arguments >>>>> on all sides, but I think we did converge on agreement that the curre= nt >>>>> BSP >>>>> mechanism for complex, multi-destination security could be difficult = to >>>>> realize in coherent fashion across the network. After puzzling over = this >>>>> for >>>>> a while, I came up with a concept (below) that I think would be simpl= er, >>>>> safer, and even more powerful than the current protocol design. How = do we >>>>> all feel about this? Would it be worthwhile for DTNRG to invest in a >>>>> 6257bis >>>>> RFC along these lines? >>>>> >>>>> Scott >>>>> _____________________________________________ >>>>> From: Burleigh, Scott C (313B) >>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destination= s in >>>>> DTN2 >>>>> >>>>> >>>>> Hi, Peter. At the risk (I know) of getting a lot of people severely >>>>> ticked >>>>> off at me, I am going to offer a modest proposal for improving the Bu= ndle >>>>> Security Protocol, inspired by this thread. >>>>> I propose to adopt a new design principle for Bundle Security Protoco= l: >>>>> the >>>>> routing element of a bundle protocol agent should never need to inspe= ct a >>>>> bundle=B9s BSP extension blocks in order to select the node(s) to for= ward >>>>> the >>>>> bundle to. >>>>> That is, BSP should provide security, not dictate routes. >>>>> My rationale for proposing this principle is that I believe it would: >>>>> >>>>> Simplify BSP, thereby reducing the incidence of bugs and making Bundl= e >>>>> Security significantly less expensive to implement and sustain. >>>>> Broaden the scope of BSP deployment by eliminating its dependence on >>>>> specific, BSP-aware routing implementations, thereby increasing the >>>>> overall >>>>> security of DTN. >>>>> Reduce the cost of developing and improving routing implementations b= y >>>>> removing any requirement that they be BSP-aware, and broaden the scop= e of >>>>> deployment of non-BSP-aware routing implementations by enabling them = to be >>>>> used in environments requiring arbitrarily powerful security. Thereb= y, >>>>> improve DTN operational performance. >>>>> >>>>> Here's how I would apply this principle: >>>>> >>>>> Eliminate security sources and security destinations from all BSP blo= cks. >>>>> The security source of a BSP block would always be the bundle=B9s sou= rce. >>>>> The >>>>> security destination of a BSP block would always be the bundle=B9s >>>>> destination. >>>>> Add a new Administrative Record type for Bundle-in-Bundle encapsulati= on. >>>>> When additional security must be applied to a bundle on some segment = of >>>>> its >>>>> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>> Encapsulation >>>>> Administrative Record that is the payload of a new bundle whose sourc= e is >>>>> the >>>>> security source of the path segment and whose destination is the secu= rity >>>>> destination of the path segment. Apply the additional bundle transmi= ssion >>>>> security measures to the encapsulating bundle: encrypt its payload (t= he >>>>> Administrative Record, containing the encapsulated bundle), encrypt >>>>> extension >>>>> blocks as copied from the encapsulated bundle, etc. Then forward the >>>>> encapsulating bundle. >>>>> When route service uncertainty forces a bundle to be routed over mult= iple >>>>> parallel additionally secured segments of its end-to-end path, encaps= ulate >>>>> it >>>>> as above but within multiple different encapsulating bundles, one for= each >>>>> of >>>>> the parallel segments, and forward all of them. >>>>> At the destination of a bundle, apply all relevant bundle reception >>>>> security >>>>> measures and then, if the payload is an encapsulation Administrative >>>>> Record, >>>>> extract the encapsulated bundle from the Administrative Record and si= mply >>>>> forward it. >>>>> >>>>> I believe this would have the following impacts on DTN security: >>>>> >>>>> No EID references in BSP, simplifying canonicalization. >>>>> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the >>>>> encapsulated >>>>> bundle encrypts all three at once), so no correlators in BSP. (Excep= t for >>>>> BABs, no bundle ever has more than one occurrence of any type of BSP >>>>> block. >>>>> And there will never be more than two BABs, one immediately following= the >>>>> primary block and one that is the final block in the bundle, so that >>>>> correlation is structural.) >>>>> No delicate =B3replacement=B2 process for unraveling PCB nesting at t= he >>>>> destination. >>>>> No possible confusion about the correct order of application of BSP >>>>> blocks. >>>>> No possible conflict among security destinations of different BSP blo= cks. >>>>> Security paths can never overlap. >>>>> Any routing implementation can always accommodate any security regime= : >>>>> routes >>>>> that must be followed to ensure security are encoded into routing >>>>> information >>>>> at the forwarding node, not into the bundle. (A little like the late >>>>> binding >>>>> principle.) >>>>> Any routing environment can always be made arbitrarily secure =AD no = need to >>>>> require specially BSP-aware routing elements. >>>>> Ciphersuite design is simplified, so a wider array of useful ciphersu= ites >>>>> can >>>>> be developed without imposing bug-prone complexity. Minimizes possib= le >>>>> security problems. >>>>> >>>>> As an example of how I think this could work, see the attached diagra= m: >>>>> >>>>> Node A is sending a bundle to node K. Nodes A, B, J, and K are withi= n the >>>>> low-risk =B3W=B2 security region; nodes C and G are gateways between = region W >>>>> and >>>>> the more hazardous region X; node D is another node in X; nodes E and= F >>>>> are >>>>> gateways between region X and even more hazardous region Y; nodes H a= nd I >>>>> are >>>>> gateways between X and hazardous region Z. >>>>> At A the bundle is simply forwarded to B. >>>>> At B the routing element realizes that the bundle has to traverse reg= ion X >>>>> in >>>>> order to get to K, so it forwards the bundle to C. >>>>> The routing element at C encapsulates the bundle in an Admin Record, >>>>> creates >>>>> a new bundle destined for G (the egress from region X) whose source i= s C >>>>> and >>>>> whose payload is that Admin Record, encrypts the payload, attaches a = PCB, >>>>> and >>>>> forwards the bundle to D. >>>>> D realizes that the bundle has to traverse region Y in order to get t= o G, >>>>> so >>>>> it forwards the bundle to E. >>>>> E encapsulates the bundle in an Admin Record, creates a new bundle >>>>> destined >>>>> for F (the egress from region Y) whose source is E and whose payload = is >>>>> that >>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards the >>>>> bundle >>>>> to F. >>>>> The bundle protocol agent at F receives the bundle, decrypts it, and >>>>> passes >>>>> the payload (an Admin Record) to the application agent. The >>>>> administrative >>>>> element of the application agent at F receives the Admin Record, extr= acts >>>>> the >>>>> encapsulated bundle destined for G, and queues it to be forwarded. T= he >>>>> routing element at F sees this bundle and forwards it to G. >>>>> The bundle protocol agent at G receives the bundle, decrypts it, and >>>>> passes >>>>> the payload (an Admin Record) to the application agent. The >>>>> administrative >>>>> element of the application agent at G receives the Admin Record, extr= acts >>>>> the >>>>> encapsulated bundle destined for K, and queues it to be forwarded. T= he >>>>> routing element at G sees this bundle, realizes that the bundle has t= o >>>>> traverse region Z in order to get to K, and therefore forwards the bu= ndle >>>>> to >>>>> H. >>>>> H encapsulates the bundle in an Admin Record, creates a new bundle >>>>> destined >>>>> for I (the egress from region Z) whose source is H and whose payload = is >>>>> that >>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards the >>>>> bundle >>>>> to I. >>>>> The bundle protocol agent at I receives the bundle, decrypts it, and >>>>> passes >>>>> the payload (an Admin Record) to the application agent. The >>>>> administrative >>>>> element of the application agent at I receives the Admin Record, extr= acts >>>>> the >>>>> encapsulated bundle destined for K, and queues it to be forwarded. T= he >>>>> routing element at I sees this bundle and forwards it to J. >>>>> At J the bundle is simply forwarded to K. >>>>> At K the bundle=B9s payload is passed to the application. >>>>> >>>>> I think this approach would combine simplicity with quite a lot of >>>>> operational power, making everything cheaper and safer. >>>>> So, having now stirred the hornet=B9s nest, I will beat a hasty retre= at for >>>>> a >>>>> week while I am on vacation. I=B9ll try to follow up when I get back= . >>>>> Have a nice Thanksgiving, everybody. >>>>> Scott >>>>> >>>>> -----Original Message----- >>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovel= l >>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in= DTN2 >>>>> >>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>> wrote: >>>>> >>>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>>> tunneling than I've been in the past. >>>>> >>>>> Hi Scott, >>>>> >>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>> mentioned >>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "funk= y" to >>>>> me. There's no indication in the bundle that it's BiB and you need so= me >>>>> special EID to perform the decapsulation. Maybe that's just like an >>>>> assigned >>>>> port in TCP but we don't yet have such a mechanism. The multiple-bund= le >>>>> thing >>>>> is OK, I guess, but I don't see much use for it other than volume >>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels c= ould >>>>> be >>>>> specially optimized. >>>>> >>>>> I need to go back and review all the discussions about BiB -- we work= ed it >>>>> quite a bit but the spec never gained enough consensus to move forwar= d. I >>>>> think it would be a good idea to revisit it now and get a solid draft= that >>>>> has wider support. Maybe the email discussions will help us get there= . >>>>> >>>>> Thanks.....Peter >>>>> >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>> >>>>> To: "Burleigh, Scott C" , >>>>> "dtn-security@irtf.org" >>>>> Cc: >>>>> Date: Tue, 22 Jan 2013 17:47:47 -0600 >>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destina= tions >>>>> inDTN2 >>>>> Agreed; that makes sense. >>>>> >>>>> ________________________________ >>>>> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>> Sent: Tuesday, January 22, 2013 6:35 PM >>>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf.= org >>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destina= tions >>>>> inDTN2 >>>>> >>>>> Wes, I agree that some code change would be entailed in implementing = this >>>>> proposal, but I think a large proportion of the code =AD the general = flow of >>>>> processing the extension blocks, the canonicalization, the ciphersuit= es, >>>>> really almost everything that would have been implemented to handle t= he >>>>> simple case of security source/destination being identical to bundle >>>>> source/destination =AD would be preserved. I suspect that much of wh= at I >>>>> was >>>>> proposing here involves removing functionality that most developers >>>>> haven=B9t >>>>> implemented yet anyway, because of the potential pitfalls. >>>>> >>>>> >>>>> >>>>> Scott >>>>> >>>>> >>>>> >>>>> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >>>>> [mailto:wesley.m.eddy@nasa.gov] >>>>> Sent: Tuesday, January 22, 2013 3:20 PM >>>>> To: Burleigh, Scott C (313B); dtn-security@irtf.org >>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destina= tions >>>>> inDTN2 >>>>> >>>>> >>>>> >>>>> It looks like basically a good idea to me. >>>>> >>>>> >>>>> >>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>> destinations >>>>> needed to work more like IPsec tunnel-mode endpoints in order to make= the >>>>> routing work correctly, and I think what you're proposing here >>>>> accomplishes >>>>> that in a better way. >>>>> >>>>> >>>>> >>>>> Though I think cycles would be better spent on KMP issues that are >>>>> actually >>>>> HARD, and *then* circling back to see what could be tweaked in the BS= P, I >>>>> definitely think this proposed change is something that would improve= the >>>>> BSP >>>>> a bit in the meantime. >>>>> >>>>> >>>>> >>>>> I don't think it can be done in a way that's friendly to the existing >>>>> codebase like Stephen suggests shooting for. >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> >>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] O= n >>>>> Behalf >>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>> To: dtn-security@irtf.org >>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destination= s >>>>> inDTN2 >>>>> >>>>> Hi. Late last September, several of us spun off a sub-thread talking >>>>> about >>>>> how the processing of bundles with multiple security destinations cou= ld be >>>>> handled in DTN implementations. I won=B9t try to recreate all of the >>>>> arguments >>>>> on all sides, but I think we did converge on agreement that the curre= nt >>>>> BSP >>>>> mechanism for complex, multi-destination security could be difficult = to >>>>> realize in coherent fashion across the network. After puzzling over = this >>>>> for >>>>> a while, I came up with a concept (below) that I think would be simpl= er, >>>>> safer, and even more powerful than the current protocol design. How = do we >>>>> all feel about this? Would it be worthwhile for DTNRG to invest in a >>>>> 6257bis >>>>> RFC along these lines? >>>>> >>>>> >>>>> >>>>> Scott >>>>> >>>>> _____________________________________________ >>>>> From: Burleigh, Scott C (313B) >>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destination= s in >>>>> DTN2 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi, Peter. At the risk (I know) of getting a lot of people severely >>>>> ticked >>>>> off at me, I am going to offer a modest proposal for improving the Bu= ndle >>>>> Security Protocol, inspired by this thread. >>>>> >>>>> I propose to adopt a new design principle for Bundle Security Protoco= l: >>>>> the >>>>> routing element of a bundle protocol agent should never need to inspe= ct a >>>>> bundle=B9s BSP extension blocks in order to select the node(s) to for= ward >>>>> the >>>>> bundle to. >>>>> >>>>> That is, BSP should provide security, not dictate routes. >>>>> >>>>> My rationale for proposing this principle is that I believe it would: >>>>> >>>>> =B7 Simplify BSP, thereby reducing the incidence of bugs and = making >>>>> Bundle Security significantly less expensive to implement and sustain= . >>>>> >>>>> =B7 Broaden the scope of BSP deployment by eliminating its >>>>> dependence >>>>> on specific, BSP-aware routing implementations, thereby increasing th= e >>>>> overall security of DTN. >>>>> >>>>> =B7 Reduce the cost of developing and improving routing >>>>> implementations >>>>> by removing any requirement that they be BSP-aware, and broaden the s= cope >>>>> of >>>>> deployment of non-BSP-aware routing implementations by enabling them = to be >>>>> used in environments requiring arbitrarily powerful security. Thereb= y, >>>>> improve DTN operational performance. >>>>> >>>>> Here's how I would apply this principle: >>>>> >>>>> 1. Eliminate security sources and security destinations from al= l BSP >>>>> blocks. The security source of a BSP block would always be the bundl= e=B9s >>>>> source. The security destination of a BSP block would always be the >>>>> bundle=B9s >>>>> destination. >>>>> >>>>> 2. Add a new Administrative Record type for Bundle-in-Bundle >>>>> encapsulation. >>>>> >>>>> 3. When additional security must be applied to a bundle on some >>>>> segment >>>>> of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>> Encapsulation Administrative Record that is the payload of a new bund= le >>>>> whose >>>>> source is the security source of the path segment and whose destinati= on is >>>>> the security destination of the path segment. Apply the additional b= undle >>>>> transmission security measures to the encapsulating bundle: encrypt i= ts >>>>> payload (the Administrative Record, containing the encapsulated bundl= e), >>>>> encrypt extension blocks as copied from the encapsulated bundle, etc. >>>>> Then >>>>> forward the encapsulating bundle. >>>>> >>>>> 4. When route service uncertainty forces a bundle to be routed = over >>>>> multiple parallel additionally secured segments of its end-to-end pat= h, >>>>> encapsulate it as above but within multiple different encapsulating >>>>> bundles, >>>>> one for each of the parallel segments, and forward all of them. >>>>> >>>>> 5. At the destination of a bundle, apply all relevant bundle >>>>> reception >>>>> security measures and then, if the payload is an encapsulation >>>>> Administrative >>>>> Record, extract the encapsulated bundle from the Administrative Recor= d and >>>>> simply forward it. >>>>> >>>>> I believe this would have the following impacts on DTN security: >>>>> >>>>> =B7 No EID references in BSP, simplifying canonicalization. >>>>> >>>>> =B7 PCBs only encrypt payloads, never PIBs or PCBs (encryptin= g the >>>>> encapsulated bundle encrypts all three at once), so no correlators in= BSP. >>>>> (Except for BABs, no bundle ever has more than one occurrence of any = type >>>>> of >>>>> BSP block. And there will never be more than two BABs, one immediate= ly >>>>> following the primary block and one that is the final block in the bu= ndle, >>>>> so >>>>> that correlation is structural.) >>>>> >>>>> =B7 No delicate =B3replacement=B2 process for unraveling PCB = nesting at >>>>> the >>>>> destination. >>>>> >>>>> =B7 No possible confusion about the correct order of applicat= ion of >>>>> BSP >>>>> blocks. >>>>> >>>>> =B7 No possible conflict among security destinations of diffe= rent >>>>> BSP >>>>> blocks. >>>>> >>>>> =B7 Security paths can never overlap. >>>>> >>>>> =B7 Any routing implementation can always accommodate any sec= urity >>>>> regime: routes that must be followed to ensure security are encoded i= nto >>>>> routing information at the forwarding node, not into the bundle. (A >>>>> little >>>>> like the late binding principle.) >>>>> >>>>> =B7 Any routing environment can always be made arbitrarily se= cure =AD >>>>> no >>>>> need to require specially BSP-aware routing elements. >>>>> >>>>> =B7 Ciphersuite design is simplified, so a wider array of use= ful >>>>> ciphersuites can be developed without imposing bug-prone complexity. >>>>> Minimizes possible security problems. >>>>> >>>>> As an example of how I think this could work, see the attached diagra= m: >>>>> >>>>> 1. Node A is sending a bundle to node K. Nodes A, B, J, and K = are >>>>> within the low-risk =B3W=B2 security region; nodes C and G are gatewa= ys >>>>> between >>>>> region W and the more hazardous region X; node D is another node in X= ; >>>>> nodes >>>>> E and F are gateways between region X and even more hazardous region = Y; >>>>> nodes >>>>> H and I are gateways between X and hazardous region Z. >>>>> >>>>> 2. At A the bundle is simply forwarded to B. >>>>> >>>>> 3. At B the routing element realizes that the bundle has to tra= verse >>>>> region X in order to get to K, so it forwards the bundle to C. >>>>> >>>>> 4. The routing element at C encapsulates the bundle in an Admin >>>>> Record, >>>>> creates a new bundle destined for G (the egress from region X) whose >>>>> source >>>>> is C and whose payload is that Admin Record, encrypts the payload, >>>>> attaches a >>>>> PCB, and forwards the bundle to D. >>>>> >>>>> 5. D realizes that the bundle has to traverse region Y in order= to >>>>> get >>>>> to G, so it forwards the bundle to E. >>>>> >>>>> 6. E encapsulates the bundle in an Admin Record, creates a new >>>>> bundle >>>>> destined for F (the egress from region Y) whose source is E and whose >>>>> payload >>>>> is that Admin Record, encrypts the payload, attaches a PCB, and forwa= rds >>>>> the >>>>> bundle to F. >>>>> >>>>> 7. The bundle protocol agent at F receives the bundle, decrypts= it, >>>>> and >>>>> passes the payload (an Admin Record) to the application agent. The >>>>> administrative element of the application agent at F receives the Adm= in >>>>> Record, extracts the encapsulated bundle destined for G, and queues i= t to >>>>> be >>>>> forwarded. The routing element at F sees this bundle and forwards it= to >>>>> G. >>>>> >>>>> 8. The bundle protocol agent at G receives the bundle, decrypts= it, >>>>> and >>>>> passes the payload (an Admin Record) to the application agent. The >>>>> administrative element of the application agent at G receives the Adm= in >>>>> Record, extracts the encapsulated bundle destined for K, and queues i= t to >>>>> be >>>>> forwarded. The routing element at G sees this bundle, realizes that = the >>>>> bundle has to traverse region Z in order to get to K, and therefore >>>>> forwards >>>>> the bundle to H. >>>>> >>>>> 9. H encapsulates the bundle in an Admin Record, creates a new >>>>> bundle >>>>> destined for I (the egress from region Z) whose source is H and whose >>>>> payload >>>>> is that Admin Record, encrypts the payload, attaches a PCB, and forwa= rds >>>>> the >>>>> bundle to I. >>>>> >>>>> 10. The bundle protocol agent at I receives the bundle, decrypts it= , and >>>>> passes the payload (an Admin Record) to the application agent. The >>>>> administrative element of the application agent at I receives the Adm= in >>>>> Record, extracts the encapsulated bundle destined for K, and queues i= t to >>>>> be >>>>> forwarded. The routing element at I sees this bundle and forwards it= to >>>>> J. >>>>> >>>>> 11. At J the bundle is simply forwarded to K. >>>>> >>>>> 12. At K the bundle=B9s payload is passed to the application. >>>>> >>>>> I think this approach would combine simplicity with quite a lot of >>>>> operational power, making everything cheaper and safer. >>>>> >>>>> So, having now stirred the hornet=B9s nest, I will beat a hasty retre= at for >>>>> a >>>>> week while I am on vacation. I=B9ll try to follow up when I get back= . >>>>> >>>>> Have a nice Thanksgiving, everybody. >>>>> >>>>> Scott >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lovel= l >>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations in= DTN2 >>>>> >>>>> >>>>> >>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>> >>>>>> tunneling than I've been in the past. >>>>> >>>>> >>>>> >>>>> Hi Scott, >>>>> >>>>> >>>>> >>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>> mentioned >>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "funk= y" to >>>>> me. There's no indication in the bundle that it's BiB and you need so= me >>>>> special EID to perform the decapsulation. Maybe that's just like an >>>>> assigned >>>>> port in TCP but we don't yet have such a mechanism. The multiple-bund= le >>>>> thing >>>>> is OK, I guess, but I don't see much use for it other than volume >>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels c= ould >>>>> be >>>>> specially optimized. >>>>> >>>>> >>>>> >>>>> I need to go back and review all the discussions about BiB -- we work= ed it >>>>> quite a bit but the spec never gained enough consensus to move forwar= d. I >>>>> think it would be a good idea to revisit it now and get a solid draft= that >>>>> has wider support. Maybe the email discussions will help us get there= . >>>>> >>>>> >>>>> >>>>> Thanks.....Peter >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dtn-security mailing list >>>>> dtn-security@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> _______________________________________________ >>>> dtn-security mailing list >>>> dtn-security@irtf.org >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>> >>> _______________________________________________ >>> dtn-security mailing list >>> dtn-security@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-security >> >> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security >> > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security From ahennes1@gmail.com Mon Jan 28 11:25:48 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E96721F86F6 for ; Mon, 28 Jan 2013 11:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUs2j7s2FPJR for ; Mon, 28 Jan 2013 11:25:46 -0800 (PST) Received: from mail-la0-x22e.google.com (la-in-x022e.1e100.net [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9C92F21F86CE for ; Mon, 28 Jan 2013 11:25:40 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq12so1050603lab.19 for ; Mon, 28 Jan 2013 11:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/WjYYe/qyZCvTPgPug3WJd2tZEsyEb6TS4AXkULlDLg=; b=RUVVEtroE7Y7ftrV/e1+eN6rrx/mfjTgmBEpcwMQydk8y49WHBufUGmRNPCbpw3Rzp ocevBySLzXF/s1pF6cjub5BEoix0ybokJPmjDhR1aylN9H3X+61VEzVk6xJVrnk+vsb9 ovQRDMmkJBr67hD2KGIge9+NII3TpWMBz8tiABXuwZuZi0RCnXUq3pJJnYjwNil484Ub BlaMLu5nUx4RWJg7oCNI7Eo1MZRyqEEMQtXiv5IpDKwsNFF9Tw7JDrPTLWLyIeAzKl3R ni2smSluF6pOzVXpak7VltZb8XsXRBYfdOqXINKBZYfOM8J1ZR/3hyRYoKe8HJGQSsKX uiOQ== MIME-Version: 1.0 X-Received: by 10.112.82.166 with SMTP id j6mr6052538lby.25.1359401139426; Mon, 28 Jan 2013 11:25:39 -0800 (PST) Sender: ahennes1@gmail.com Received: by 10.112.150.39 with HTTP; Mon, 28 Jan 2013 11:25:39 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 14:25:39 -0500 X-Google-Sender-Auth: A-Ap-k_nAtUkRBAXyM8bssune1g Message-ID: From: Angela Hennessy To: "Ivancic, William D. (GRC-RHN0)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 19:25:49 -0000 Hi Will, We had done some work on interoperability testing between DTN2 and IBR-DTN, which turned up some places where the BSP spec was somewhat vague (and as a result was implemented differently in DTN2 and IBR-DTN). I believe we addressed most of these in the proposed errata list for BSP. We haven't done any interoperability testing with the ION implementation, since this uses different cryptographic algorithms for the PIB and PCB ciphersuites. thanks, Angela On Mon, Jan 28, 2013 at 10:46 AM, Ivancic, William D. (GRC-RHN0) wrote: > Angela, > > I believe your group was performing interoperability testing between vari= ous > DTN implementations. If so, Can you summarize the results and perhaps poi= nt > to the test plan or any reports. > > IMHO, as is, the BSP would be very difficult to achieve full > interoperability over all option and parameters due to the complexity. > > Simplifying would be a good thing, but perhaps premature if the overall > protocol is to be revised. In other words, is this still research or wil= l > there be a move to operational deployment (a minimum of 1000s of agents)= . > > Will > > ****************************** > William D. Ivancic > Phone 216-433-3494 > Fax 216-433-8705 > Networking Lab 216-433-2620 > Mobile 440-503-4892 > http://roland.grc.nasa.gov/~ivancic > > > >> From: Angela Hennessy >> Date: Sun, 27 Jan 2013 15:42:18 -0600 >> To: "dtn-security@irtf.org" >> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 >> >> Hi Ed, >> >> I definitely agree that things can get pretty complicated dealing with >> the security src/dest, and we've run into some issues when >> implementing them. I think the idea of using bundle-in-bundle >> encapsulation is an interesting alternative, and I'll be interested to >> read all the details. >> >> >> thanks, >> Angela >> >> On Sat, Jan 26, 2013 at 9:09 PM, wrote: >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>> >>> https://www.irtf.org/mailman/listinfo/dtn-security >>> >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>> >>> >>> >>> Send dtn-security mailing list submissions to >>> dtn-security@irtf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.irtf.org/mailman/listinfo/dtn-security >>> or, via email, send a message with subject or body 'help' to >>> dtn-security-request@irtf.org >>> >>> You can reach the person managing the list at >>> dtn-security-owner@irtf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of dtn-security digest..." >>> >>> Today's Topics: >>> >>> 1. Re: dtn-security Digest, Vol 9, Issue 4 (Stephen Farrell) >>> >>> >>> ---------- Forwarded message ---------- >>> From: Stephen Farrell >>> To: "Birrane, Edward J." >>> Cc: "dtn-security@irtf.org" >>> Date: Sun, 27 Jan 2013 02:08:27 +0000 >>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 >>> >>> >>> On 27 Jan 2013, at 01:18, "Birrane, Edward J." >>> wrote: >>> >>>> Angela, >>>> >>>> I see (at least) two issues independent enough that they should not = be >>>> conflated. The first is whether simplifying the BSP specification, t= o omit >>>> tight routing coupling, is beneficial. The second is the utility of t= he >>>> bundle-in-bundle encapsulation mechanism in a security context. >>>> >>>> 1. Simplifying BSP >>>> What we have found is that the concept of a security destination, >>>> separate from a bundle destination, places a burden on any routing mec= hanism >>>> to guarantee delivery through one or more "waypoints" before the bundl= e >>>> reaches its destination. Since routing mechanisms cannot make this >>>> guarantee in any type of opportunistic network (and may struggle to ma= ke >>>> this guarantee in structured networks) we need to find a way to relax = this >>>> language and the implementation hurdles it imposes. Removing security >>>> sources and destinations from the specification and deferring tunnelin= g and >>>> multi-point behavior to some other mechanism (or mechanisms) seems lik= e a >>>> promising way to go for BSP. >>>> >>>> I think most folks on this list agree with the above, but before we g= et >>>> too deeply into specifics surrounding encapsulation, it is probably a = good >>>> idea to check that assumption. >>>> >>>> ---> Do we agree that (provided we can meet necessary use cases) this = is a >>>> desired simplification of BSP? >>> >>> That's neither needed nor necessarily desirable. Just write the draft t= hat >>> says how to do it, then ask if people like it. Abstract argument in adv= ance >>> doesn't seem useful. >>> >>> S >>> >>>> >>>> >>>> 2. Bundle-in-Bundle (BiB) encapsulation >>>> >>>> BiB is a useful way to create a tunnel in a network at the BP layer. = With >>>> any tunneled packet, it should be protected from misuse while in the t= unnel, >>>> and encapsulation is a way to do that. IMO, it should be used exactly= in >>>> those situations where we need a security destination that is differen= t than >>>> the bundle destination; i.e. When we need to make a security tunnel. >>>> >>>> Actions such as adding a signature to a bundle or encrypting a bundle= , >>>> would not require encapsulation if the security destinations remain th= e >>>> bundle destinations. The only exception here would be BAB, which is th= e >>>> special case of next-hop neighbors, which would still not require an >>>> encapsulation, but the security destination would be understood to be = the >>>> next immediate BP hop which is knowable by the routing subsystem (argu= ably >>>> the only thing knowable by the routing subsystem). >>>> >>>> If we have extension blocks that have security destinations different= from >>>> the payload security destinations, then it sounds like we are treating >>>> extension blocks as "extra" independent payloads and that may cause id= entity >>>> problems beyond these BSP issues. >>>> >>>> It would probably be helpful to specify a concrete use-case surroundi= ng >>>> the signing and encrypting of payloads and extension blocks along the >>>> traversed path of a bundle. Could you propose such a use case? >>>> >>>> -Ed >>>> >>>> On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" wr= ote: >>>> >>>>> Hi Scott, >>>>> >>>>> I like how this approach simplifies the routing and gets rid of the >>>>> security src/dest and EID refs. I was a little confused though about >>>>> how this would work with some of the combinations of security blocks: >>>>> >>>>> If a node just wants to add a signature to a bundle, would this >>>>> require the bundle to be encapsulated? One of the advantages of BSP i= s >>>>> that non security-aware nodes can still access the payload by just >>>>> ignoring the PIB block. Wouldn't we lose that feature if the bundle >>>>> were encapsulated? >>>>> >>>>> If a node wants to sign and then encrypt the bundle, does this requir= e >>>>> the bundle to be encapsulated twice? >>>>> >>>>> How would we handle signing/encrypting extension blocks? Would this >>>>> require a third encapsulation? Wouldn't we still need correlators in >>>>> case multiple extension blocks are encrypted with the same key, or >>>>> would we not allow different extension blocks to be encrypted with >>>>> different keys? >>>>> >>>>> >>>>> Thanks, >>>>> Angela >>>>> >>>>> >>>>> >>>>> On Tue, Jan 22, 2013 at 6:49 PM, wro= te: >>>>>> If you have received this digest without all the individual message >>>>>> attachments you will need to update your digest options in your list >>>>>> subscription. To do so, go to >>>>>> >>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>> >>>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>>> globally for all the list digests you receive at this point. >>>>>> >>>>>> >>>>>> >>>>>> Send dtn-security mailing list submissions to >>>>>> dtn-security@irtf.org >>>>>> >>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>> or, via email, send a message with subject or body 'help' to >>>>>> dtn-security-request@irtf.org >>>>>> >>>>>> You can reach the person managing the list at >>>>>> dtn-security-owner@irtf.org >>>>>> >>>>>> When replying, please edit your Subject line so it is more specific >>>>>> than "Re: Contents of dtn-security digest..." >>>>>> >>>>>> Today's Topics: >>>>>> >>>>>> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>> >>>>>> To: "Burleigh, Scott C" , >>>>>> "dtn-security@irtf.org" >>>>>> Cc: >>>>>> Date: Tue, 22 Jan 2013 17:19:48 -0600 >>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destin= ations >>>>>> inDTN2 >>>>>> It looks like basically a good idea to me. >>>>>> >>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>> destinations >>>>>> needed to work more like IPsec tunnel-mode endpoints in order to mak= e the >>>>>> routing work correctly, and I think what you're proposing here >>>>>> accomplishes >>>>>> that in a better way. >>>>>> >>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>> actually >>>>>> HARD, and *then* circling back to see what could be tweaked in the B= SP, I >>>>>> definitely think this proposed change is something that would improv= e the >>>>>> BSP >>>>>> a bit in the meantime. >>>>>> >>>>>> I don't think it can be done in a way that's friendly to the existin= g >>>>>> codebase like Stephen suggests shooting for. >>>>>> >>>>>> ________________________________ >>>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] = On >>>>>> Behalf >>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>> To: dtn-security@irtf.org >>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >>>>>> inDTN2 >>>>>> >>>>>> Hi. Late last September, several of us spun off a sub-thread talkin= g >>>>>> about >>>>>> how the processing of bundles with multiple security destinations co= uld be >>>>>> handled in DTN implementations. I won=B9t try to recreate all of th= e >>>>>> arguments >>>>>> on all sides, but I think we did converge on agreement that the curr= ent >>>>>> BSP >>>>>> mechanism for complex, multi-destination security could be difficult= to >>>>>> realize in coherent fashion across the network. After puzzling over= this >>>>>> for >>>>>> a while, I came up with a concept (below) that I think would be simp= ler, >>>>>> safer, and even more powerful than the current protocol design. How= do we >>>>>> all feel about this? Would it be worthwhile for DTNRG to invest in = a >>>>>> 6257bis >>>>>> RFC along these lines? >>>>>> >>>>>> Scott >>>>>> _____________________________________________ >>>>>> From: Burleigh, Scott C (313B) >>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinatio= ns in >>>>>> DTN2 >>>>>> >>>>>> >>>>>> Hi, Peter. At the risk (I know) of getting a lot of people severely >>>>>> ticked >>>>>> off at me, I am going to offer a modest proposal for improving the B= undle >>>>>> Security Protocol, inspired by this thread. >>>>>> I propose to adopt a new design principle for Bundle Security Protoc= ol: >>>>>> the >>>>>> routing element of a bundle protocol agent should never need to insp= ect a >>>>>> bundle=B9s BSP extension blocks in order to select the node(s) to fo= rward >>>>>> the >>>>>> bundle to. >>>>>> That is, BSP should provide security, not dictate routes. >>>>>> My rationale for proposing this principle is that I believe it would= : >>>>>> >>>>>> Simplify BSP, thereby reducing the incidence of bugs and making Bund= le >>>>>> Security significantly less expensive to implement and sustain. >>>>>> Broaden the scope of BSP deployment by eliminating its dependence on >>>>>> specific, BSP-aware routing implementations, thereby increasing the >>>>>> overall >>>>>> security of DTN. >>>>>> Reduce the cost of developing and improving routing implementations = by >>>>>> removing any requirement that they be BSP-aware, and broaden the sco= pe of >>>>>> deployment of non-BSP-aware routing implementations by enabling them= to be >>>>>> used in environments requiring arbitrarily powerful security. There= by, >>>>>> improve DTN operational performance. >>>>>> >>>>>> Here's how I would apply this principle: >>>>>> >>>>>> Eliminate security sources and security destinations from all BSP bl= ocks. >>>>>> The security source of a BSP block would always be the bundle=B9s so= urce. >>>>>> The >>>>>> security destination of a BSP block would always be the bundle=B9s >>>>>> destination. >>>>>> Add a new Administrative Record type for Bundle-in-Bundle encapsulat= ion. >>>>>> When additional security must be applied to a bundle on some segment= of >>>>>> its >>>>>> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>>> Encapsulation >>>>>> Administrative Record that is the payload of a new bundle whose sour= ce is >>>>>> the >>>>>> security source of the path segment and whose destination is the sec= urity >>>>>> destination of the path segment. Apply the additional bundle transm= ission >>>>>> security measures to the encapsulating bundle: encrypt its payload (= the >>>>>> Administrative Record, containing the encapsulated bundle), encrypt >>>>>> extension >>>>>> blocks as copied from the encapsulated bundle, etc. Then forward th= e >>>>>> encapsulating bundle. >>>>>> When route service uncertainty forces a bundle to be routed over mul= tiple >>>>>> parallel additionally secured segments of its end-to-end path, encap= sulate >>>>>> it >>>>>> as above but within multiple different encapsulating bundles, one fo= r each >>>>>> of >>>>>> the parallel segments, and forward all of them. >>>>>> At the destination of a bundle, apply all relevant bundle reception >>>>>> security >>>>>> measures and then, if the payload is an encapsulation Administrative >>>>>> Record, >>>>>> extract the encapsulated bundle from the Administrative Record and s= imply >>>>>> forward it. >>>>>> >>>>>> I believe this would have the following impacts on DTN security: >>>>>> >>>>>> No EID references in BSP, simplifying canonicalization. >>>>>> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the >>>>>> encapsulated >>>>>> bundle encrypts all three at once), so no correlators in BSP. (Exce= pt for >>>>>> BABs, no bundle ever has more than one occurrence of any type of BSP >>>>>> block. >>>>>> And there will never be more than two BABs, one immediately followin= g the >>>>>> primary block and one that is the final block in the bundle, so that >>>>>> correlation is structural.) >>>>>> No delicate =B3replacement=B2 process for unraveling PCB nesting at = the >>>>>> destination. >>>>>> No possible confusion about the correct order of application of BSP >>>>>> blocks. >>>>>> No possible conflict among security destinations of different BSP bl= ocks. >>>>>> Security paths can never overlap. >>>>>> Any routing implementation can always accommodate any security regim= e: >>>>>> routes >>>>>> that must be followed to ensure security are encoded into routing >>>>>> information >>>>>> at the forwarding node, not into the bundle. (A little like the lat= e >>>>>> binding >>>>>> principle.) >>>>>> Any routing environment can always be made arbitrarily secure =AD no= need to >>>>>> require specially BSP-aware routing elements. >>>>>> Ciphersuite design is simplified, so a wider array of useful ciphers= uites >>>>>> can >>>>>> be developed without imposing bug-prone complexity. Minimizes possi= ble >>>>>> security problems. >>>>>> >>>>>> As an example of how I think this could work, see the attached diagr= am: >>>>>> >>>>>> Node A is sending a bundle to node K. Nodes A, B, J, and K are with= in the >>>>>> low-risk =B3W=B2 security region; nodes C and G are gateways between= region W >>>>>> and >>>>>> the more hazardous region X; node D is another node in X; nodes E an= d F >>>>>> are >>>>>> gateways between region X and even more hazardous region Y; nodes H = and I >>>>>> are >>>>>> gateways between X and hazardous region Z. >>>>>> At A the bundle is simply forwarded to B. >>>>>> At B the routing element realizes that the bundle has to traverse re= gion X >>>>>> in >>>>>> order to get to K, so it forwards the bundle to C. >>>>>> The routing element at C encapsulates the bundle in an Admin Record, >>>>>> creates >>>>>> a new bundle destined for G (the egress from region X) whose source = is C >>>>>> and >>>>>> whose payload is that Admin Record, encrypts the payload, attaches a= PCB, >>>>>> and >>>>>> forwards the bundle to D. >>>>>> D realizes that the bundle has to traverse region Y in order to get = to G, >>>>>> so >>>>>> it forwards the bundle to E. >>>>>> E encapsulates the bundle in an Admin Record, creates a new bundle >>>>>> destined >>>>>> for F (the egress from region Y) whose source is E and whose payload= is >>>>>> that >>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards the >>>>>> bundle >>>>>> to F. >>>>>> The bundle protocol agent at F receives the bundle, decrypts it, and >>>>>> passes >>>>>> the payload (an Admin Record) to the application agent. The >>>>>> administrative >>>>>> element of the application agent at F receives the Admin Record, ext= racts >>>>>> the >>>>>> encapsulated bundle destined for G, and queues it to be forwarded. = The >>>>>> routing element at F sees this bundle and forwards it to G. >>>>>> The bundle protocol agent at G receives the bundle, decrypts it, and >>>>>> passes >>>>>> the payload (an Admin Record) to the application agent. The >>>>>> administrative >>>>>> element of the application agent at G receives the Admin Record, ext= racts >>>>>> the >>>>>> encapsulated bundle destined for K, and queues it to be forwarded. = The >>>>>> routing element at G sees this bundle, realizes that the bundle has = to >>>>>> traverse region Z in order to get to K, and therefore forwards the b= undle >>>>>> to >>>>>> H. >>>>>> H encapsulates the bundle in an Admin Record, creates a new bundle >>>>>> destined >>>>>> for I (the egress from region Z) whose source is H and whose payload= is >>>>>> that >>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards the >>>>>> bundle >>>>>> to I. >>>>>> The bundle protocol agent at I receives the bundle, decrypts it, and >>>>>> passes >>>>>> the payload (an Admin Record) to the application agent. The >>>>>> administrative >>>>>> element of the application agent at I receives the Admin Record, ext= racts >>>>>> the >>>>>> encapsulated bundle destined for K, and queues it to be forwarded. = The >>>>>> routing element at I sees this bundle and forwards it to J. >>>>>> At J the bundle is simply forwarded to K. >>>>>> At K the bundle=B9s payload is passed to the application. >>>>>> >>>>>> I think this approach would combine simplicity with quite a lot of >>>>>> operational power, making everything cheaper and safer. >>>>>> So, having now stirred the hornet=B9s nest, I will beat a hasty retr= eat for >>>>>> a >>>>>> week while I am on vacation. I=B9ll try to follow up when I get bac= k. >>>>>> Have a nice Thanksgiving, everybody. >>>>>> Scott >>>>>> >>>>>> -----Original Message----- >>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Love= ll >>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations i= n DTN2 >>>>>> >>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>> wrote: >>>>>> >>>>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>>>> tunneling than I've been in the past. >>>>>> >>>>>> Hi Scott, >>>>>> >>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>> mentioned >>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "fun= ky" to >>>>>> me. There's no indication in the bundle that it's BiB and you need s= ome >>>>>> special EID to perform the decapsulation. Maybe that's just like an >>>>>> assigned >>>>>> port in TCP but we don't yet have such a mechanism. The multiple-bun= dle >>>>>> thing >>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels = could >>>>>> be >>>>>> specially optimized. >>>>>> >>>>>> I need to go back and review all the discussions about BiB -- we wor= ked it >>>>>> quite a bit but the spec never gained enough consensus to move forwa= rd. I >>>>>> think it would be a good idea to revisit it now and get a solid draf= t that >>>>>> has wider support. Maybe the email discussions will help us get ther= e. >>>>>> >>>>>> Thanks.....Peter >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>> >>>>>> To: "Burleigh, Scott C" , >>>>>> "dtn-security@irtf.org" >>>>>> Cc: >>>>>> Date: Tue, 22 Jan 2013 17:47:47 -0600 >>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destin= ations >>>>>> inDTN2 >>>>>> Agreed; that makes sense. >>>>>> >>>>>> ________________________________ >>>>>> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>> Sent: Tuesday, January 22, 2013 6:35 PM >>>>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irtf= .org >>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destin= ations >>>>>> inDTN2 >>>>>> >>>>>> Wes, I agree that some code change would be entailed in implementing= this >>>>>> proposal, but I think a large proportion of the code =AD the general= flow of >>>>>> processing the extension blocks, the canonicalization, the ciphersui= tes, >>>>>> really almost everything that would have been implemented to handle = the >>>>>> simple case of security source/destination being identical to bundle >>>>>> source/destination =AD would be preserved. I suspect that much of w= hat I >>>>>> was >>>>>> proposing here involves removing functionality that most developers >>>>>> haven=B9t >>>>>> implemented yet anyway, because of the potential pitfalls. >>>>>> >>>>>> >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>> >>>>>> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >>>>>> [mailto:wesley.m.eddy@nasa.gov] >>>>>> Sent: Tuesday, January 22, 2013 3:20 PM >>>>>> To: Burleigh, Scott C (313B); dtn-security@irtf.org >>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destin= ations >>>>>> inDTN2 >>>>>> >>>>>> >>>>>> >>>>>> It looks like basically a good idea to me. >>>>>> >>>>>> >>>>>> >>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>> destinations >>>>>> needed to work more like IPsec tunnel-mode endpoints in order to mak= e the >>>>>> routing work correctly, and I think what you're proposing here >>>>>> accomplishes >>>>>> that in a better way. >>>>>> >>>>>> >>>>>> >>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>> actually >>>>>> HARD, and *then* circling back to see what could be tweaked in the B= SP, I >>>>>> definitely think this proposed change is something that would improv= e the >>>>>> BSP >>>>>> a bit in the meantime. >>>>>> >>>>>> >>>>>> >>>>>> I don't think it can be done in a way that's friendly to the existin= g >>>>>> codebase like Stephen suggests shooting for. >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org] = On >>>>>> Behalf >>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>> To: dtn-security@irtf.org >>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinatio= ns >>>>>> inDTN2 >>>>>> >>>>>> Hi. Late last September, several of us spun off a sub-thread talkin= g >>>>>> about >>>>>> how the processing of bundles with multiple security destinations co= uld be >>>>>> handled in DTN implementations. I won=B9t try to recreate all of th= e >>>>>> arguments >>>>>> on all sides, but I think we did converge on agreement that the curr= ent >>>>>> BSP >>>>>> mechanism for complex, multi-destination security could be difficult= to >>>>>> realize in coherent fashion across the network. After puzzling over= this >>>>>> for >>>>>> a while, I came up with a concept (below) that I think would be simp= ler, >>>>>> safer, and even more powerful than the current protocol design. How= do we >>>>>> all feel about this? Would it be worthwhile for DTNRG to invest in = a >>>>>> 6257bis >>>>>> RFC along these lines? >>>>>> >>>>>> >>>>>> >>>>>> Scott >>>>>> >>>>>> _____________________________________________ >>>>>> From: Burleigh, Scott C (313B) >>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinatio= ns in >>>>>> DTN2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi, Peter. At the risk (I know) of getting a lot of people severely >>>>>> ticked >>>>>> off at me, I am going to offer a modest proposal for improving the B= undle >>>>>> Security Protocol, inspired by this thread. >>>>>> >>>>>> I propose to adopt a new design principle for Bundle Security Protoc= ol: >>>>>> the >>>>>> routing element of a bundle protocol agent should never need to insp= ect a >>>>>> bundle=B9s BSP extension blocks in order to select the node(s) to fo= rward >>>>>> the >>>>>> bundle to. >>>>>> >>>>>> That is, BSP should provide security, not dictate routes. >>>>>> >>>>>> My rationale for proposing this principle is that I believe it would= : >>>>>> >>>>>> =B7 Simplify BSP, thereby reducing the incidence of bugs and= making >>>>>> Bundle Security significantly less expensive to implement and sustai= n. >>>>>> >>>>>> =B7 Broaden the scope of BSP deployment by eliminating its >>>>>> dependence >>>>>> on specific, BSP-aware routing implementations, thereby increasing t= he >>>>>> overall security of DTN. >>>>>> >>>>>> =B7 Reduce the cost of developing and improving routing >>>>>> implementations >>>>>> by removing any requirement that they be BSP-aware, and broaden the = scope >>>>>> of >>>>>> deployment of non-BSP-aware routing implementations by enabling them= to be >>>>>> used in environments requiring arbitrarily powerful security. There= by, >>>>>> improve DTN operational performance. >>>>>> >>>>>> Here's how I would apply this principle: >>>>>> >>>>>> 1. Eliminate security sources and security destinations from a= ll BSP >>>>>> blocks. The security source of a BSP block would always be the bund= le=B9s >>>>>> source. The security destination of a BSP block would always be the >>>>>> bundle=B9s >>>>>> destination. >>>>>> >>>>>> 2. Add a new Administrative Record type for Bundle-in-Bundle >>>>>> encapsulation. >>>>>> >>>>>> 3. When additional security must be applied to a bundle on som= e >>>>>> segment >>>>>> of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>>> Encapsulation Administrative Record that is the payload of a new bun= dle >>>>>> whose >>>>>> source is the security source of the path segment and whose destinat= ion is >>>>>> the security destination of the path segment. Apply the additional = bundle >>>>>> transmission security measures to the encapsulating bundle: encrypt = its >>>>>> payload (the Administrative Record, containing the encapsulated bund= le), >>>>>> encrypt extension blocks as copied from the encapsulated bundle, etc= . >>>>>> Then >>>>>> forward the encapsulating bundle. >>>>>> >>>>>> 4. When route service uncertainty forces a bundle to be routed= over >>>>>> multiple parallel additionally secured segments of its end-to-end pa= th, >>>>>> encapsulate it as above but within multiple different encapsulating >>>>>> bundles, >>>>>> one for each of the parallel segments, and forward all of them. >>>>>> >>>>>> 5. At the destination of a bundle, apply all relevant bundle >>>>>> reception >>>>>> security measures and then, if the payload is an encapsulation >>>>>> Administrative >>>>>> Record, extract the encapsulated bundle from the Administrative Reco= rd and >>>>>> simply forward it. >>>>>> >>>>>> I believe this would have the following impacts on DTN security: >>>>>> >>>>>> =B7 No EID references in BSP, simplifying canonicalization. >>>>>> >>>>>> =B7 PCBs only encrypt payloads, never PIBs or PCBs (encrypti= ng the >>>>>> encapsulated bundle encrypts all three at once), so no correlators i= n BSP. >>>>>> (Except for BABs, no bundle ever has more than one occurrence of any= type >>>>>> of >>>>>> BSP block. And there will never be more than two BABs, one immediat= ely >>>>>> following the primary block and one that is the final block in the b= undle, >>>>>> so >>>>>> that correlation is structural.) >>>>>> >>>>>> =B7 No delicate =B3replacement=B2 process for unraveling PCB= nesting at >>>>>> the >>>>>> destination. >>>>>> >>>>>> =B7 No possible confusion about the correct order of applica= tion of >>>>>> BSP >>>>>> blocks. >>>>>> >>>>>> =B7 No possible conflict among security destinations of diff= erent >>>>>> BSP >>>>>> blocks. >>>>>> >>>>>> =B7 Security paths can never overlap. >>>>>> >>>>>> =B7 Any routing implementation can always accommodate any se= curity >>>>>> regime: routes that must be followed to ensure security are encoded = into >>>>>> routing information at the forwarding node, not into the bundle. (A >>>>>> little >>>>>> like the late binding principle.) >>>>>> >>>>>> =B7 Any routing environment can always be made arbitrarily s= ecure =AD >>>>>> no >>>>>> need to require specially BSP-aware routing elements. >>>>>> >>>>>> =B7 Ciphersuite design is simplified, so a wider array of us= eful >>>>>> ciphersuites can be developed without imposing bug-prone complexity. >>>>>> Minimizes possible security problems. >>>>>> >>>>>> As an example of how I think this could work, see the attached diagr= am: >>>>>> >>>>>> 1. Node A is sending a bundle to node K. Nodes A, B, J, and K= are >>>>>> within the low-risk =B3W=B2 security region; nodes C and G are gatew= ays >>>>>> between >>>>>> region W and the more hazardous region X; node D is another node in = X; >>>>>> nodes >>>>>> E and F are gateways between region X and even more hazardous region= Y; >>>>>> nodes >>>>>> H and I are gateways between X and hazardous region Z. >>>>>> >>>>>> 2. At A the bundle is simply forwarded to B. >>>>>> >>>>>> 3. At B the routing element realizes that the bundle has to tr= averse >>>>>> region X in order to get to K, so it forwards the bundle to C. >>>>>> >>>>>> 4. The routing element at C encapsulates the bundle in an Admi= n >>>>>> Record, >>>>>> creates a new bundle destined for G (the egress from region X) whose >>>>>> source >>>>>> is C and whose payload is that Admin Record, encrypts the payload, >>>>>> attaches a >>>>>> PCB, and forwards the bundle to D. >>>>>> >>>>>> 5. D realizes that the bundle has to traverse region Y in orde= r to >>>>>> get >>>>>> to G, so it forwards the bundle to E. >>>>>> >>>>>> 6. E encapsulates the bundle in an Admin Record, creates a new >>>>>> bundle >>>>>> destined for F (the egress from region Y) whose source is E and whos= e >>>>>> payload >>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and forw= ards >>>>>> the >>>>>> bundle to F. >>>>>> >>>>>> 7. The bundle protocol agent at F receives the bundle, decrypt= s it, >>>>>> and >>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>> administrative element of the application agent at F receives the Ad= min >>>>>> Record, extracts the encapsulated bundle destined for G, and queues = it to >>>>>> be >>>>>> forwarded. The routing element at F sees this bundle and forwards i= t to >>>>>> G. >>>>>> >>>>>> 8. The bundle protocol agent at G receives the bundle, decrypt= s it, >>>>>> and >>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>> administrative element of the application agent at G receives the Ad= min >>>>>> Record, extracts the encapsulated bundle destined for K, and queues = it to >>>>>> be >>>>>> forwarded. The routing element at G sees this bundle, realizes that= the >>>>>> bundle has to traverse region Z in order to get to K, and therefore >>>>>> forwards >>>>>> the bundle to H. >>>>>> >>>>>> 9. H encapsulates the bundle in an Admin Record, creates a new >>>>>> bundle >>>>>> destined for I (the egress from region Z) whose source is H and whos= e >>>>>> payload >>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and forw= ards >>>>>> the >>>>>> bundle to I. >>>>>> >>>>>> 10. The bundle protocol agent at I receives the bundle, decrypts i= t, and >>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>> administrative element of the application agent at I receives the Ad= min >>>>>> Record, extracts the encapsulated bundle destined for K, and queues = it to >>>>>> be >>>>>> forwarded. The routing element at I sees this bundle and forwards i= t to >>>>>> J. >>>>>> >>>>>> 11. At J the bundle is simply forwarded to K. >>>>>> >>>>>> 12. At K the bundle=B9s payload is passed to the application. >>>>>> >>>>>> I think this approach would combine simplicity with quite a lot of >>>>>> operational power, making everything cheaper and safer. >>>>>> >>>>>> So, having now stirred the hornet=B9s nest, I will beat a hasty retr= eat for >>>>>> a >>>>>> week while I am on vacation. I=B9ll try to follow up when I get bac= k. >>>>>> >>>>>> Have a nice Thanksgiving, everybody. >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Love= ll >>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations i= n DTN2 >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>>> >>>>>>> tunneling than I've been in the past. >>>>>> >>>>>> >>>>>> >>>>>> Hi Scott, >>>>>> >>>>>> >>>>>> >>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>> mentioned >>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "fun= ky" to >>>>>> me. There's no indication in the bundle that it's BiB and you need s= ome >>>>>> special EID to perform the decapsulation. Maybe that's just like an >>>>>> assigned >>>>>> port in TCP but we don't yet have such a mechanism. The multiple-bun= dle >>>>>> thing >>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels = could >>>>>> be >>>>>> specially optimized. >>>>>> >>>>>> >>>>>> >>>>>> I need to go back and review all the discussions about BiB -- we wor= ked it >>>>>> quite a bit but the spec never gained enough consensus to move forwa= rd. I >>>>>> think it would be a good idea to revisit it now and get a solid draf= t that >>>>>> has wider support. Maybe the email discussions will help us get ther= e. >>>>>> >>>>>> >>>>>> >>>>>> Thanks.....Peter >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> dtn-security mailing list >>>>>> dtn-security@irtf.org >>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> _______________________________________________ >>>>> dtn-security mailing list >>>>> dtn-security@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> >>>> _______________________________________________ >>>> dtn-security mailing list >>>> dtn-security@irtf.org >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>> >>> >>> _______________________________________________ >>> dtn-security mailing list >>> dtn-security@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-security >>> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security > From william.d.ivancic@nasa.gov Mon Jan 28 11:46:02 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7621F8786 for ; Mon, 28 Jan 2013 11:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxF+Cpv4g0rm for ; Mon, 28 Jan 2013 11:45:58 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 9523A21F87B9 for ; Mon, 28 Jan 2013 11:45:57 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id BABD42D8328; Mon, 28 Jan 2013 13:45:56 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r0SJjuP9011360; Mon, 28 Jan 2013 13:45:56 -0600 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Mon, 28 Jan 2013 13:45:56 -0600 From: "Ivancic, William D. (GRC-RHN0)" To: Angela Hennessy Date: Mon, 28 Jan 2013 13:46:24 -0600 Thread-Topic: [dtn-security] dtn-security Digest, Vol 9, Issue 9 Thread-Index: Ac39jUOImD8eLYagSvSLHKV0Lzi2mQAAuPAS Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-28_03:2013-01-28, 2013-01-28, 1970-01-01 signatures=0 Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 19:46:02 -0000 There must be hundreds (if not thousands) of combinations and permutations. Is there a publically available document that lists what was tested? And, perhaps just as important, what was not? Will ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic > From: Angela Hennessy > Date: Mon, 28 Jan 2013 13:25:39 -0600 > To: "Ivancic, William D. (GRC-RHN0)" > Cc: "dtn-security@irtf.org" > Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 > > Hi Will, > > We had done some work on interoperability testing between DTN2 and > IBR-DTN, which turned up some places where the BSP spec was somewhat > vague (and as a result was implemented differently in DTN2 and > IBR-DTN). I believe we addressed most of these in the proposed errata > list for BSP. We haven't done any interoperability testing with the > ION implementation, since this uses different cryptographic algorithms > for the PIB and PCB ciphersuites. > > thanks, > Angela > > On Mon, Jan 28, 2013 at 10:46 AM, Ivancic, William D. (GRC-RHN0) > wrote: >> Angela, >> >> I believe your group was performing interoperability testing between var= ious >> DTN implementations. If so, Can you summarize the results and perhaps po= int >> to the test plan or any reports. >> >> IMHO, as is, the BSP would be very difficult to achieve full >> interoperability over all option and parameters due to the complexity. >> >> Simplifying would be a good thing, but perhaps premature if the overall >> protocol is to be revised. In other words, is this still research or wi= ll >> there be a move to operational deployment (a minimum of 1000s of agents= ). >> >> Will >> >> ****************************** >> William D. Ivancic >> Phone 216-433-3494 >> Fax 216-433-8705 >> Networking Lab 216-433-2620 >> Mobile 440-503-4892 >> http://roland.grc.nasa.gov/~ivancic >> >> >> >>> From: Angela Hennessy >>> Date: Sun, 27 Jan 2013 15:42:18 -0600 >>> To: "dtn-security@irtf.org" >>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 >>> >>> Hi Ed, >>> >>> I definitely agree that things can get pretty complicated dealing with >>> the security src/dest, and we've run into some issues when >>> implementing them. I think the idea of using bundle-in-bundle >>> encapsulation is an interesting alternative, and I'll be interested to >>> read all the details. >>> >>> >>> thanks, >>> Angela >>> >>> On Sat, Jan 26, 2013 at 9:09 PM, wrote= : >>>> If you have received this digest without all the individual message >>>> attachments you will need to update your digest options in your list >>>> subscription. To do so, go to >>>> >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> >>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>> globally for all the list digests you receive at this point. >>>> >>>> >>>> >>>> Send dtn-security mailing list submissions to >>>> dtn-security@irtf.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> or, via email, send a message with subject or body 'help' to >>>> dtn-security-request@irtf.org >>>> >>>> You can reach the person managing the list at >>>> dtn-security-owner@irtf.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of dtn-security digest..." >>>> >>>> Today's Topics: >>>> >>>> 1. Re: dtn-security Digest, Vol 9, Issue 4 (Stephen Farrell) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Stephen Farrell >>>> To: "Birrane, Edward J." >>>> Cc: "dtn-security@irtf.org" >>>> Date: Sun, 27 Jan 2013 02:08:27 +0000 >>>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 >>>> >>>> >>>> On 27 Jan 2013, at 01:18, "Birrane, Edward J." >>>> wrote: >>>> >>>>> Angela, >>>>> >>>>> I see (at least) two issues independent enough that they should not= be >>>>> conflated. The first is whether simplifying the BSP specification, = to >>>>> omit >>>>> tight routing coupling, is beneficial. The second is the utility of = the >>>>> bundle-in-bundle encapsulation mechanism in a security context. >>>>> >>>>> 1. Simplifying BSP >>>>> What we have found is that the concept of a security destination, >>>>> separate from a bundle destination, places a burden on any routing >>>>> mechanism >>>>> to guarantee delivery through one or more "waypoints" before the bund= le >>>>> reaches its destination. Since routing mechanisms cannot make this >>>>> guarantee in any type of opportunistic network (and may struggle to m= ake >>>>> this guarantee in structured networks) we need to find a way to relax= this >>>>> language and the implementation hurdles it imposes. Removing securit= y >>>>> sources and destinations from the specification and deferring tunneli= ng >>>>> and >>>>> multi-point behavior to some other mechanism (or mechanisms) seems li= ke a >>>>> promising way to go for BSP. >>>>> >>>>> I think most folks on this list agree with the above, but before we = get >>>>> too deeply into specifics surrounding encapsulation, it is probably a= good >>>>> idea to check that assumption. >>>>> >>>>> ---> Do we agree that (provided we can meet necessary use cases) this= is a >>>>> desired simplification of BSP? >>>> >>>> That's neither needed nor necessarily desirable. Just write the draft = that >>>> says how to do it, then ask if people like it. Abstract argument in ad= vance >>>> doesn't seem useful. >>>> >>>> S >>>> >>>>> >>>>> >>>>> 2. Bundle-in-Bundle (BiB) encapsulation >>>>> >>>>> BiB is a useful way to create a tunnel in a network at the BP layer.= With >>>>> any tunneled packet, it should be protected from misuse while in the >>>>> tunnel, >>>>> and encapsulation is a way to do that. IMO, it should be used exactl= y in >>>>> those situations where we need a security destination that is differe= nt >>>>> than >>>>> the bundle destination; i.e. When we need to make a security tunnel. >>>>> >>>>> Actions such as adding a signature to a bundle or encrypting a bundl= e, >>>>> would not require encapsulation if the security destinations remain t= he >>>>> bundle destinations. The only exception here would be BAB, which is t= he >>>>> special case of next-hop neighbors, which would still not require an >>>>> encapsulation, but the security destination would be understood to be= the >>>>> next immediate BP hop which is knowable by the routing subsystem (arg= uably >>>>> the only thing knowable by the routing subsystem). >>>>> >>>>> If we have extension blocks that have security destinations differen= t >>>>> from >>>>> the payload security destinations, then it sounds like we are treatin= g >>>>> extension blocks as "extra" independent payloads and that may cause >>>>> identity >>>>> problems beyond these BSP issues. >>>>> >>>>> It would probably be helpful to specify a concrete use-case surround= ing >>>>> the signing and encrypting of payloads and extension blocks along the >>>>> traversed path of a bundle. Could you propose such a use case? >>>>> >>>>> -Ed >>>>> >>>>> On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" w= rote: >>>>> >>>>>> Hi Scott, >>>>>> >>>>>> I like how this approach simplifies the routing and gets rid of the >>>>>> security src/dest and EID refs. I was a little confused though about >>>>>> how this would work with some of the combinations of security blocks= : >>>>>> >>>>>> If a node just wants to add a signature to a bundle, would this >>>>>> require the bundle to be encapsulated? One of the advantages of BSP = is >>>>>> that non security-aware nodes can still access the payload by just >>>>>> ignoring the PIB block. Wouldn't we lose that feature if the bundle >>>>>> were encapsulated? >>>>>> >>>>>> If a node wants to sign and then encrypt the bundle, does this requi= re >>>>>> the bundle to be encapsulated twice? >>>>>> >>>>>> How would we handle signing/encrypting extension blocks? Would this >>>>>> require a third encapsulation? Wouldn't we still need correlators in >>>>>> case multiple extension blocks are encrypted with the same key, or >>>>>> would we not allow different extension blocks to be encrypted with >>>>>> different keys? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Angela >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 22, 2013 at 6:49 PM, wr= ote: >>>>>>> If you have received this digest without all the individual message >>>>>>> attachments you will need to update your digest options in your lis= t >>>>>>> subscription. To do so, go to >>>>>>> >>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>> >>>>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Ge= t >>>>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>>>> globally for all the list digests you receive at this point. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Send dtn-security mailing list submissions to >>>>>>> dtn-security@irtf.org >>>>>>> >>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>> dtn-security-request@irtf.org >>>>>>> >>>>>>> You can reach the person managing the list at >>>>>>> dtn-security-owner@irtf.org >>>>>>> >>>>>>> When replying, please edit your Subject line so it is more specific >>>>>>> than "Re: Contents of dtn-security digest..." >>>>>>> >>>>>>> Today's Topics: >>>>>>> >>>>>>> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>>> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>>> >>>>>>> To: "Burleigh, Scott C" , >>>>>>> "dtn-security@irtf.org" >>>>>>> Cc: >>>>>>> Date: Tue, 22 Jan 2013 17:19:48 -0600 >>>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security >>>>>>> Destinations >>>>>>> inDTN2 >>>>>>> It looks like basically a good idea to me. >>>>>>> >>>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>>> destinations >>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to ma= ke >>>>>>> the >>>>>>> routing work correctly, and I think what you're proposing here >>>>>>> accomplishes >>>>>>> that in a better way. >>>>>>> >>>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>>> actually >>>>>>> HARD, and *then* circling back to see what could be tweaked in the = BSP, >>>>>>> I >>>>>>> definitely think this proposed change is something that would impro= ve >>>>>>> the >>>>>>> BSP >>>>>>> a bit in the meantime. >>>>>>> >>>>>>> I don't think it can be done in a way that's friendly to the existi= ng >>>>>>> codebase like Stephen suggests shooting for. >>>>>>> >>>>>>> ________________________________ >>>>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org]= On >>>>>>> Behalf >>>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>>> To: dtn-security@irtf.org >>>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinati= ons >>>>>>> inDTN2 >>>>>>> >>>>>>> Hi. Late last September, several of us spun off a sub-thread talki= ng >>>>>>> about >>>>>>> how the processing of bundles with multiple security destinations c= ould >>>>>>> be >>>>>>> handled in DTN implementations. I won=B9t try to recreate all of t= he >>>>>>> arguments >>>>>>> on all sides, but I think we did converge on agreement that the cur= rent >>>>>>> BSP >>>>>>> mechanism for complex, multi-destination security could be difficul= t to >>>>>>> realize in coherent fashion across the network. After puzzling ove= r >>>>>>> this >>>>>>> for >>>>>>> a while, I came up with a concept (below) that I think would be sim= pler, >>>>>>> safer, and even more powerful than the current protocol design. Ho= w do >>>>>>> we >>>>>>> all feel about this? Would it be worthwhile for DTNRG to invest in= a >>>>>>> 6257bis >>>>>>> RFC along these lines? >>>>>>> >>>>>>> Scott >>>>>>> _____________________________________________ >>>>>>> From: Burleigh, Scott C (313B) >>>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinati= ons >>>>>>> in >>>>>>> DTN2 >>>>>>> >>>>>>> >>>>>>> Hi, Peter. At the risk (I know) of getting a lot of people severel= y >>>>>>> ticked >>>>>>> off at me, I am going to offer a modest proposal for improving the >>>>>>> Bundle >>>>>>> Security Protocol, inspired by this thread. >>>>>>> I propose to adopt a new design principle for Bundle Security Proto= col: >>>>>>> the >>>>>>> routing element of a bundle protocol agent should never need to ins= pect >>>>>>> a >>>>>>> bundle=B9s BSP extension blocks in order to select the node(s) to f= orward >>>>>>> the >>>>>>> bundle to. >>>>>>> That is, BSP should provide security, not dictate routes. >>>>>>> My rationale for proposing this principle is that I believe it woul= d: >>>>>>> >>>>>>> Simplify BSP, thereby reducing the incidence of bugs and making Bun= dle >>>>>>> Security significantly less expensive to implement and sustain. >>>>>>> Broaden the scope of BSP deployment by eliminating its dependence o= n >>>>>>> specific, BSP-aware routing implementations, thereby increasing the >>>>>>> overall >>>>>>> security of DTN. >>>>>>> Reduce the cost of developing and improving routing implementations= by >>>>>>> removing any requirement that they be BSP-aware, and broaden the sc= ope >>>>>>> of >>>>>>> deployment of non-BSP-aware routing implementations by enabling the= m to >>>>>>> be >>>>>>> used in environments requiring arbitrarily powerful security. Ther= eby, >>>>>>> improve DTN operational performance. >>>>>>> >>>>>>> Here's how I would apply this principle: >>>>>>> >>>>>>> Eliminate security sources and security destinations from all BSP >>>>>>> blocks. >>>>>>> The security source of a BSP block would always be the bundle=B9s s= ource. >>>>>>> The >>>>>>> security destination of a BSP block would always be the bundle=B9s >>>>>>> destination. >>>>>>> Add a new Administrative Record type for Bundle-in-Bundle encapsula= tion. >>>>>>> When additional security must be applied to a bundle on some segmen= t of >>>>>>> its >>>>>>> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>>>> Encapsulation >>>>>>> Administrative Record that is the payload of a new bundle whose sou= rce >>>>>>> is >>>>>>> the >>>>>>> security source of the path segment and whose destination is the >>>>>>> security >>>>>>> destination of the path segment. Apply the additional bundle >>>>>>> transmission >>>>>>> security measures to the encapsulating bundle: encrypt its payload = (the >>>>>>> Administrative Record, containing the encapsulated bundle), encrypt >>>>>>> extension >>>>>>> blocks as copied from the encapsulated bundle, etc. Then forward t= he >>>>>>> encapsulating bundle. >>>>>>> When route service uncertainty forces a bundle to be routed over >>>>>>> multiple >>>>>>> parallel additionally secured segments of its end-to-end path, >>>>>>> encapsulate >>>>>>> it >>>>>>> as above but within multiple different encapsulating bundles, one f= or >>>>>>> each >>>>>>> of >>>>>>> the parallel segments, and forward all of them. >>>>>>> At the destination of a bundle, apply all relevant bundle reception >>>>>>> security >>>>>>> measures and then, if the payload is an encapsulation Administrativ= e >>>>>>> Record, >>>>>>> extract the encapsulated bundle from the Administrative Record and >>>>>>> simply >>>>>>> forward it. >>>>>>> >>>>>>> I believe this would have the following impacts on DTN security: >>>>>>> >>>>>>> No EID references in BSP, simplifying canonicalization. >>>>>>> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the >>>>>>> encapsulated >>>>>>> bundle encrypts all three at once), so no correlators in BSP. (Exc= ept >>>>>>> for >>>>>>> BABs, no bundle ever has more than one occurrence of any type of BS= P >>>>>>> block. >>>>>>> And there will never be more than two BABs, one immediately followi= ng >>>>>>> the >>>>>>> primary block and one that is the final block in the bundle, so tha= t >>>>>>> correlation is structural.) >>>>>>> No delicate =B3replacement=B2 process for unraveling PCB nesting at= the >>>>>>> destination. >>>>>>> No possible confusion about the correct order of application of BSP >>>>>>> blocks. >>>>>>> No possible conflict among security destinations of different BSP >>>>>>> blocks. >>>>>>> Security paths can never overlap. >>>>>>> Any routing implementation can always accommodate any security regi= me: >>>>>>> routes >>>>>>> that must be followed to ensure security are encoded into routing >>>>>>> information >>>>>>> at the forwarding node, not into the bundle. (A little like the la= te >>>>>>> binding >>>>>>> principle.) >>>>>>> Any routing environment can always be made arbitrarily secure =AD n= o need >>>>>>> to >>>>>>> require specially BSP-aware routing elements. >>>>>>> Ciphersuite design is simplified, so a wider array of useful >>>>>>> ciphersuites >>>>>>> can >>>>>>> be developed without imposing bug-prone complexity. Minimizes poss= ible >>>>>>> security problems. >>>>>>> >>>>>>> As an example of how I think this could work, see the attached diag= ram: >>>>>>> >>>>>>> Node A is sending a bundle to node K. Nodes A, B, J, and K are wit= hin >>>>>>> the >>>>>>> low-risk =B3W=B2 security region; nodes C and G are gateways betwee= n region >>>>>>> W >>>>>>> and >>>>>>> the more hazardous region X; node D is another node in X; nodes E a= nd F >>>>>>> are >>>>>>> gateways between region X and even more hazardous region Y; nodes H= and >>>>>>> I >>>>>>> are >>>>>>> gateways between X and hazardous region Z. >>>>>>> At A the bundle is simply forwarded to B. >>>>>>> At B the routing element realizes that the bundle has to traverse r= egion >>>>>>> X >>>>>>> in >>>>>>> order to get to K, so it forwards the bundle to C. >>>>>>> The routing element at C encapsulates the bundle in an Admin Record= , >>>>>>> creates >>>>>>> a new bundle destined for G (the egress from region X) whose source= is C >>>>>>> and >>>>>>> whose payload is that Admin Record, encrypts the payload, attaches = a >>>>>>> PCB, >>>>>>> and >>>>>>> forwards the bundle to D. >>>>>>> D realizes that the bundle has to traverse region Y in order to get= to >>>>>>> G, >>>>>>> so >>>>>>> it forwards the bundle to E. >>>>>>> E encapsulates the bundle in an Admin Record, creates a new bundle >>>>>>> destined >>>>>>> for F (the egress from region Y) whose source is E and whose payloa= d is >>>>>>> that >>>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards th= e >>>>>>> bundle >>>>>>> to F. >>>>>>> The bundle protocol agent at F receives the bundle, decrypts it, an= d >>>>>>> passes >>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>> administrative >>>>>>> element of the application agent at F receives the Admin Record, >>>>>>> extracts >>>>>>> the >>>>>>> encapsulated bundle destined for G, and queues it to be forwarded. = The >>>>>>> routing element at F sees this bundle and forwards it to G. >>>>>>> The bundle protocol agent at G receives the bundle, decrypts it, an= d >>>>>>> passes >>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>> administrative >>>>>>> element of the application agent at G receives the Admin Record, >>>>>>> extracts >>>>>>> the >>>>>>> encapsulated bundle destined for K, and queues it to be forwarded. = The >>>>>>> routing element at G sees this bundle, realizes that the bundle has= to >>>>>>> traverse region Z in order to get to K, and therefore forwards the >>>>>>> bundle >>>>>>> to >>>>>>> H. >>>>>>> H encapsulates the bundle in an Admin Record, creates a new bundle >>>>>>> destined >>>>>>> for I (the egress from region Z) whose source is H and whose payloa= d is >>>>>>> that >>>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards th= e >>>>>>> bundle >>>>>>> to I. >>>>>>> The bundle protocol agent at I receives the bundle, decrypts it, an= d >>>>>>> passes >>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>> administrative >>>>>>> element of the application agent at I receives the Admin Record, >>>>>>> extracts >>>>>>> the >>>>>>> encapsulated bundle destined for K, and queues it to be forwarded. = The >>>>>>> routing element at I sees this bundle and forwards it to J. >>>>>>> At J the bundle is simply forwarded to K. >>>>>>> At K the bundle=B9s payload is passed to the application. >>>>>>> >>>>>>> I think this approach would combine simplicity with quite a lot of >>>>>>> operational power, making everything cheaper and safer. >>>>>>> So, having now stirred the hornet=B9s nest, I will beat a hasty ret= reat >>>>>>> for >>>>>>> a >>>>>>> week while I am on vacation. I=B9ll try to follow up when I get ba= ck. >>>>>>> Have a nice Thanksgiving, everybody. >>>>>>> Scott >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lov= ell >>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations = in >>>>>>> DTN2 >>>>>>> >>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>>> wrote: >>>>>>> >>>>>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>>>>> tunneling than I've been in the past. >>>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>>> mentioned >>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "fu= nky" >>>>>>> to >>>>>>> me. There's no indication in the bundle that it's BiB and you need = some >>>>>>> special EID to perform the decapsulation. Maybe that's just like an >>>>>>> assigned >>>>>>> port in TCP but we don't yet have such a mechanism. The multiple-bu= ndle >>>>>>> thing >>>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels >>>>>>> could >>>>>>> be >>>>>>> specially optimized. >>>>>>> >>>>>>> I need to go back and review all the discussions about BiB -- we wo= rked >>>>>>> it >>>>>>> quite a bit but the spec never gained enough consensus to move forw= ard. >>>>>>> I >>>>>>> think it would be a good idea to revisit it now and get a solid dra= ft >>>>>>> that >>>>>>> has wider support. Maybe the email discussions will help us get the= re. >>>>>>> >>>>>>> Thanks.....Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>>> >>>>>>> To: "Burleigh, Scott C" , >>>>>>> "dtn-security@irtf.org" >>>>>>> Cc: >>>>>>> Date: Tue, 22 Jan 2013 17:47:47 -0600 >>>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security >>>>>>> Destinations >>>>>>> inDTN2 >>>>>>> Agreed; that makes sense. >>>>>>> >>>>>>> ________________________________ >>>>>>> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>> Sent: Tuesday, January 22, 2013 6:35 PM >>>>>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@irt= f.org >>>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security >>>>>>> Destinations >>>>>>> inDTN2 >>>>>>> >>>>>>> Wes, I agree that some code change would be entailed in implementin= g >>>>>>> this >>>>>>> proposal, but I think a large proportion of the code =AD the genera= l flow >>>>>>> of >>>>>>> processing the extension blocks, the canonicalization, the ciphersu= ites, >>>>>>> really almost everything that would have been implemented to handle= the >>>>>>> simple case of security source/destination being identical to bundl= e >>>>>>> source/destination =AD would be preserved. I suspect that much of = what I >>>>>>> was >>>>>>> proposing here involves removing functionality that most developers >>>>>>> haven=B9t >>>>>>> implemented yet anyway, because of the potential pitfalls. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >>>>>>> [mailto:wesley.m.eddy@nasa.gov] >>>>>>> Sent: Tuesday, January 22, 2013 3:20 PM >>>>>>> To: Burleigh, Scott C (313B); dtn-security@irtf.org >>>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security >>>>>>> Destinations >>>>>>> inDTN2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> It looks like basically a good idea to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>>> destinations >>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to ma= ke >>>>>>> the >>>>>>> routing work correctly, and I think what you're proposing here >>>>>>> accomplishes >>>>>>> that in a better way. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>>> actually >>>>>>> HARD, and *then* circling back to see what could be tweaked in the = BSP, >>>>>>> I >>>>>>> definitely think this proposed change is something that would impro= ve >>>>>>> the >>>>>>> BSP >>>>>>> a bit in the meantime. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don't think it can be done in a way that's friendly to the existi= ng >>>>>>> codebase like Stephen suggests shooting for. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org]= On >>>>>>> Behalf >>>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>>> To: dtn-security@irtf.org >>>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinati= ons >>>>>>> inDTN2 >>>>>>> >>>>>>> Hi. Late last September, several of us spun off a sub-thread talki= ng >>>>>>> about >>>>>>> how the processing of bundles with multiple security destinations c= ould >>>>>>> be >>>>>>> handled in DTN implementations. I won=B9t try to recreate all of t= he >>>>>>> arguments >>>>>>> on all sides, but I think we did converge on agreement that the cur= rent >>>>>>> BSP >>>>>>> mechanism for complex, multi-destination security could be difficul= t to >>>>>>> realize in coherent fashion across the network. After puzzling ove= r >>>>>>> this >>>>>>> for >>>>>>> a while, I came up with a concept (below) that I think would be sim= pler, >>>>>>> safer, and even more powerful than the current protocol design. Ho= w do >>>>>>> we >>>>>>> all feel about this? Would it be worthwhile for DTNRG to invest in= a >>>>>>> 6257bis >>>>>>> RFC along these lines? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> _____________________________________________ >>>>>>> From: Burleigh, Scott C (313B) >>>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinati= ons >>>>>>> in >>>>>>> DTN2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, Peter. At the risk (I know) of getting a lot of people severel= y >>>>>>> ticked >>>>>>> off at me, I am going to offer a modest proposal for improving the >>>>>>> Bundle >>>>>>> Security Protocol, inspired by this thread. >>>>>>> >>>>>>> I propose to adopt a new design principle for Bundle Security Proto= col: >>>>>>> the >>>>>>> routing element of a bundle protocol agent should never need to ins= pect >>>>>>> a >>>>>>> bundle=B9s BSP extension blocks in order to select the node(s) to f= orward >>>>>>> the >>>>>>> bundle to. >>>>>>> >>>>>>> That is, BSP should provide security, not dictate routes. >>>>>>> >>>>>>> My rationale for proposing this principle is that I believe it woul= d: >>>>>>> >>>>>>> =B7 Simplify BSP, thereby reducing the incidence of bugs an= d >>>>>>> making >>>>>>> Bundle Security significantly less expensive to implement and susta= in. >>>>>>> >>>>>>> =B7 Broaden the scope of BSP deployment by eliminating its >>>>>>> dependence >>>>>>> on specific, BSP-aware routing implementations, thereby increasing = the >>>>>>> overall security of DTN. >>>>>>> >>>>>>> =B7 Reduce the cost of developing and improving routing >>>>>>> implementations >>>>>>> by removing any requirement that they be BSP-aware, and broaden the >>>>>>> scope >>>>>>> of >>>>>>> deployment of non-BSP-aware routing implementations by enabling the= m to >>>>>>> be >>>>>>> used in environments requiring arbitrarily powerful security. Ther= eby, >>>>>>> improve DTN operational performance. >>>>>>> >>>>>>> Here's how I would apply this principle: >>>>>>> >>>>>>> 1. Eliminate security sources and security destinations from = all >>>>>>> BSP >>>>>>> blocks. The security source of a BSP block would always be the bun= dle=B9s >>>>>>> source. The security destination of a BSP block would always be th= e >>>>>>> bundle=B9s >>>>>>> destination. >>>>>>> >>>>>>> 2. Add a new Administrative Record type for Bundle-in-Bundle >>>>>>> encapsulation. >>>>>>> >>>>>>> 3. When additional security must be applied to a bundle on so= me >>>>>>> segment >>>>>>> of its end-to-end path, encapsulate the bundle in a Bundle-in-Bundl= e >>>>>>> Encapsulation Administrative Record that is the payload of a new bu= ndle >>>>>>> whose >>>>>>> source is the security source of the path segment and whose destina= tion >>>>>>> is >>>>>>> the security destination of the path segment. Apply the additional >>>>>>> bundle >>>>>>> transmission security measures to the encapsulating bundle: encrypt= its >>>>>>> payload (the Administrative Record, containing the encapsulated bun= dle), >>>>>>> encrypt extension blocks as copied from the encapsulated bundle, et= c. >>>>>>> Then >>>>>>> forward the encapsulating bundle. >>>>>>> >>>>>>> 4. When route service uncertainty forces a bundle to be route= d >>>>>>> over >>>>>>> multiple parallel additionally secured segments of its end-to-end p= ath, >>>>>>> encapsulate it as above but within multiple different encapsulating >>>>>>> bundles, >>>>>>> one for each of the parallel segments, and forward all of them. >>>>>>> >>>>>>> 5. At the destination of a bundle, apply all relevant bundle >>>>>>> reception >>>>>>> security measures and then, if the payload is an encapsulation >>>>>>> Administrative >>>>>>> Record, extract the encapsulated bundle from the Administrative Rec= ord >>>>>>> and >>>>>>> simply forward it. >>>>>>> >>>>>>> I believe this would have the following impacts on DTN security: >>>>>>> >>>>>>> =B7 No EID references in BSP, simplifying canonicalization. >>>>>>> >>>>>>> =B7 PCBs only encrypt payloads, never PIBs or PCBs (encrypt= ing the >>>>>>> encapsulated bundle encrypts all three at once), so no correlators = in >>>>>>> BSP. >>>>>>> (Except for BABs, no bundle ever has more than one occurrence of an= y >>>>>>> type >>>>>>> of >>>>>>> BSP block. And there will never be more than two BABs, one immedia= tely >>>>>>> following the primary block and one that is the final block in the >>>>>>> bundle, >>>>>>> so >>>>>>> that correlation is structural.) >>>>>>> >>>>>>> =B7 No delicate =B3replacement=B2 process for unraveling PC= B nesting >>>>>>> at >>>>>>> the >>>>>>> destination. >>>>>>> >>>>>>> =B7 No possible confusion about the correct order of applic= ation >>>>>>> of >>>>>>> BSP >>>>>>> blocks. >>>>>>> >>>>>>> =B7 No possible conflict among security destinations of dif= ferent >>>>>>> BSP >>>>>>> blocks. >>>>>>> >>>>>>> =B7 Security paths can never overlap. >>>>>>> >>>>>>> =B7 Any routing implementation can always accommodate any s= ecurity >>>>>>> regime: routes that must be followed to ensure security are encoded= into >>>>>>> routing information at the forwarding node, not into the bundle. (= A >>>>>>> little >>>>>>> like the late binding principle.) >>>>>>> >>>>>>> =B7 Any routing environment can always be made arbitrarily = secure >>>>>>> =AD >>>>>>> no >>>>>>> need to require specially BSP-aware routing elements. >>>>>>> >>>>>>> =B7 Ciphersuite design is simplified, so a wider array of u= seful >>>>>>> ciphersuites can be developed without imposing bug-prone complexity= . >>>>>>> Minimizes possible security problems. >>>>>>> >>>>>>> As an example of how I think this could work, see the attached diag= ram: >>>>>>> >>>>>>> 1. Node A is sending a bundle to node K. Nodes A, B, J, and = K are >>>>>>> within the low-risk =B3W=B2 security region; nodes C and G are gate= ways >>>>>>> between >>>>>>> region W and the more hazardous region X; node D is another node in= X; >>>>>>> nodes >>>>>>> E and F are gateways between region X and even more hazardous regio= n Y; >>>>>>> nodes >>>>>>> H and I are gateways between X and hazardous region Z. >>>>>>> >>>>>>> 2. At A the bundle is simply forwarded to B. >>>>>>> >>>>>>> 3. At B the routing element realizes that the bundle has to >>>>>>> traverse >>>>>>> region X in order to get to K, so it forwards the bundle to C. >>>>>>> >>>>>>> 4. The routing element at C encapsulates the bundle in an Adm= in >>>>>>> Record, >>>>>>> creates a new bundle destined for G (the egress from region X) whos= e >>>>>>> source >>>>>>> is C and whose payload is that Admin Record, encrypts the payload, >>>>>>> attaches a >>>>>>> PCB, and forwards the bundle to D. >>>>>>> >>>>>>> 5. D realizes that the bundle has to traverse region Y in ord= er to >>>>>>> get >>>>>>> to G, so it forwards the bundle to E. >>>>>>> >>>>>>> 6. E encapsulates the bundle in an Admin Record, creates a ne= w >>>>>>> bundle >>>>>>> destined for F (the egress from region Y) whose source is E and who= se >>>>>>> payload >>>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and for= wards >>>>>>> the >>>>>>> bundle to F. >>>>>>> >>>>>>> 7. The bundle protocol agent at F receives the bundle, decryp= ts >>>>>>> it, >>>>>>> and >>>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>>> administrative element of the application agent at F receives the A= dmin >>>>>>> Record, extracts the encapsulated bundle destined for G, and queues= it >>>>>>> to >>>>>>> be >>>>>>> forwarded. The routing element at F sees this bundle and forwards = it to >>>>>>> G. >>>>>>> >>>>>>> 8. The bundle protocol agent at G receives the bundle, decryp= ts >>>>>>> it, >>>>>>> and >>>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>>> administrative element of the application agent at G receives the A= dmin >>>>>>> Record, extracts the encapsulated bundle destined for K, and queues= it >>>>>>> to >>>>>>> be >>>>>>> forwarded. The routing element at G sees this bundle, realizes tha= t the >>>>>>> bundle has to traverse region Z in order to get to K, and therefore >>>>>>> forwards >>>>>>> the bundle to H. >>>>>>> >>>>>>> 9. H encapsulates the bundle in an Admin Record, creates a ne= w >>>>>>> bundle >>>>>>> destined for I (the egress from region Z) whose source is H and who= se >>>>>>> payload >>>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and for= wards >>>>>>> the >>>>>>> bundle to I. >>>>>>> >>>>>>> 10. The bundle protocol agent at I receives the bundle, decrypts = it, >>>>>>> and >>>>>>> passes the payload (an Admin Record) to the application agent. The >>>>>>> administrative element of the application agent at I receives the A= dmin >>>>>>> Record, extracts the encapsulated bundle destined for K, and queues= it >>>>>>> to >>>>>>> be >>>>>>> forwarded. The routing element at I sees this bundle and forwards = it to >>>>>>> J. >>>>>>> >>>>>>> 11. At J the bundle is simply forwarded to K. >>>>>>> >>>>>>> 12. At K the bundle=B9s payload is passed to the application. >>>>>>> >>>>>>> I think this approach would combine simplicity with quite a lot of >>>>>>> operational power, making everything cheaper and safer. >>>>>>> >>>>>>> So, having now stirred the hornet=B9s nest, I will beat a hasty ret= reat >>>>>>> for >>>>>>> a >>>>>>> week while I am on vacation. I=B9ll try to follow up when I get ba= ck. >>>>>>> >>>>>>> Have a nice Thanksgiving, everybody. >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lov= ell >>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations = in >>>>>>> DTN2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> In view of which, I've now become a bigger fan of bundle-in-bundle >>>>>>> >>>>>>>> tunneling than I've been in the past. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>>> mentioned >>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "fu= nky" >>>>>>> to >>>>>>> me. There's no indication in the bundle that it's BiB and you need = some >>>>>>> special EID to perform the decapsulation. Maybe that's just like an >>>>>>> assigned >>>>>>> port in TCP but we don't yet have such a mechanism. The multiple-bu= ndle >>>>>>> thing >>>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnels >>>>>>> could >>>>>>> be >>>>>>> specially optimized. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I need to go back and review all the discussions about BiB -- we wo= rked >>>>>>> it >>>>>>> quite a bit but the spec never gained enough consensus to move forw= ard. >>>>>>> I >>>>>>> think it would be a good idea to revisit it now and get a solid dra= ft >>>>>>> that >>>>>>> has wider support. Maybe the email discussions will help us get the= re. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks.....Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dtn-security mailing list >>>>>>> dtn-security@irtf.org >>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>> _______________________________________________ >>>>>> dtn-security mailing list >>>>>> dtn-security@irtf.org >>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>>> _______________________________________________ >>>>> dtn-security mailing list >>>>> dtn-security@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> >>>> >>>> _______________________________________________ >>>> dtn-security mailing list >>>> dtn-security@irtf.org >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>> >>> _______________________________________________ >>> dtn-security mailing list >>> dtn-security@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-security >> From s.shukla@iitp.ac.in Mon Jan 28 22:51:45 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9064021F8A61 for ; Mon, 28 Jan 2013 22:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFFGa1PlAOCH for ; Mon, 28 Jan 2013 22:51:43 -0800 (PST) Received: from magadh.iitp.ac.in (magadh.iitp.ac.in [210.212.18.211]) by ietfa.amsl.com (Postfix) with ESMTP id 956B821F899E for ; Mon, 28 Jan 2013 22:51:38 -0800 (PST) Received: from ashoka.iitp.ac.in (ashoka.iitp.ac.in [172.16.1.11]) by magadh.iitp.ac.in (8.14.2/8.14.2) with ESMTP id r0T70dQQ023878; Tue, 29 Jan 2013 12:30:40 +0530 Received: from [172.16.1.11] (localhost.localdomain [127.0.0.1]) by ashoka.iitp.ac.in (Postfix) with ESMTP id D407A7D634C; Tue, 29 Jan 2013 12:33:22 +0530 (IST) Received: from 172.16.1.10 (SquirrelMail authenticated user s.shukla) by 172.16.1.11 with HTTP; Tue, 29 Jan 2013 12:33:22 +0530 Message-ID: <6fa8535a7c28723e97756d6fff4c1e3c.squirrel@172.16.1.11> In-Reply-To: References: Date: Tue, 29 Jan 2013 12:33:22 +0530 From: s.shukla@iitp.ac.in To: "Ivancic, William D. (GRC-RHN0)" User-Agent: SquirrelMail/ MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new Cc: "dtn-security@irtf.org" , Angela Hennessy Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 06:51:45 -0000 Hi all, I have been working in DTN for adhoc network for past two years.I am not much aware of BiB architecture. If I can get some recent draft on BIB and DTN security, I will be thankful to you all. Shailendra. > There must be hundreds (if not thousands) of combinations and > permutations. > Is there a publically available document that lists what was tested? > And, > perhaps just as important, what was not? > > Will > > ****************************** > William D. Ivancic > Phone 216-433-3494 > Fax 216-433-8705 > Networking Lab 216-433-2620 > Mobile 440-503-4892 > http://roland.grc.nasa.gov/~ivancic > > > >> From: Angela Hennessy >> Date: Mon, 28 Jan 2013 13:25:39 -0600 >> To: "Ivancic, William D. (GRC-RHN0)" >> Cc: "dtn-security@irtf.org" >> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 >> >> Hi Will, >> >> We had done some work on interoperability testing between DTN2 and >> IBR-DTN, which turned up some places where the BSP spec was somewhat >> vague (and as a result was implemented differently in DTN2 and >> IBR-DTN). I believe we addressed most of these in the proposed errata >> list for BSP. We haven't done any interoperability testing with the >> ION implementation, since this uses different cryptographic algorithms >> for the PIB and PCB ciphersuites. >> >> thanks, >> Angela >> >> On Mon, Jan 28, 2013 at 10:46 AM, Ivancic, William D. (GRC-RHN0) >> wrote: >>> Angela, >>> >>> I believe your group was performing interoperability testing between >>> various >>> DTN implementations. If so, Can you summarize the results and perhaps >>> point >>> to the test plan or any reports. >>> >>> IMHO, as is, the BSP would be very difficult to achieve full >>> interoperability over all option and parameters due to the complexity. >>> >>> Simplifying would be a good thing, but perhaps premature if the overall >>> protocol is to be revised. In other words, is this still research or >>> will >>> there be a move to operational deployment (a minimum of 1000s of >>> agents). >>> >>> Will >>> >>> ****************************** >>> William D. Ivancic >>> Phone 216-433-3494 >>> Fax 216-433-8705 >>> Networking Lab 216-433-2620 >>> Mobile 440-503-4892 >>> http://roland.grc.nasa.gov/~ivancic >>> >>> >>> >>>> From: Angela Hennessy >>>> Date: Sun, 27 Jan 2013 15:42:18 -0600 >>>> To: "dtn-security@irtf.org" >>>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 >>>> >>>> Hi Ed, >>>> >>>> I definitely agree that things can get pretty complicated dealing with >>>> the security src/dest, and we've run into some issues when >>>> implementing them. I think the idea of using bundle-in-bundle >>>> encapsulation is an interesting alternative, and I'll be interested to >>>> read all the details. >>>> >>>> >>>> thanks, >>>> Angela >>>> >>>> On Sat, Jan 26, 2013 at 9:09 PM, >>>> wrote: >>>>> If you have received this digest without all the individual message >>>>> attachments you will need to update your digest options in your list >>>>> subscription. To do so, go to >>>>> >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>> globally for all the list digests you receive at this point. >>>>> >>>>> >>>>> >>>>> Send dtn-security mailing list submissions to >>>>> dtn-security@irtf.org >>>>> >>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> or, via email, send a message with subject or body 'help' to >>>>> dtn-security-request@irtf.org >>>>> >>>>> You can reach the person managing the list at >>>>> dtn-security-owner@irtf.org >>>>> >>>>> When replying, please edit your Subject line so it is more specific >>>>> than "Re: Contents of dtn-security digest..." >>>>> >>>>> Today's Topics: >>>>> >>>>> 1. Re: dtn-security Digest, Vol 9, Issue 4 (Stephen Farrell) >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Stephen Farrell >>>>> To: "Birrane, Edward J." >>>>> Cc: "dtn-security@irtf.org" >>>>> Date: Sun, 27 Jan 2013 02:08:27 +0000 >>>>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 >>>>> >>>>> >>>>> On 27 Jan 2013, at 01:18, "Birrane, Edward J." >>>>> >>>>> wrote: >>>>> >>>>>> Angela, >>>>>> >>>>>> I see (at least) two issues independent enough that they should >>>>>> not be >>>>>> conflated. The first is whether simplifying the BSP specification, >>>>>> to >>>>>> omit >>>>>> tight routing coupling, is beneficial. The second is the utility of >>>>>> the >>>>>> bundle-in-bundle encapsulation mechanism in a security context. >>>>>> >>>>>> 1. Simplifying BSP >>>>>> What we have found is that the concept of a security destination, >>>>>> separate from a bundle destination, places a burden on any routing >>>>>> mechanism >>>>>> to guarantee delivery through one or more "waypoints" before the >>>>>> bundle >>>>>> reaches its destination. Since routing mechanisms cannot make this >>>>>> guarantee in any type of opportunistic network (and may struggle to >>>>>> make >>>>>> this guarantee in structured networks) we need to find a way to >>>>>> relax this >>>>>> language and the implementation hurdles it imposes. Removing >>>>>> security >>>>>> sources and destinations from the specification and deferring >>>>>> tunneling >>>>>> and >>>>>> multi-point behavior to some other mechanism (or mechanisms) seems >>>>>> like a >>>>>> promising way to go for BSP. >>>>>> >>>>>> I think most folks on this list agree with the above, but before we >>>>>> get >>>>>> too deeply into specifics surrounding encapsulation, it is probably >>>>>> a good >>>>>> idea to check that assumption. >>>>>> >>>>>> ---> Do we agree that (provided we can meet necessary use cases) >>>>>> this is a >>>>>> desired simplification of BSP? >>>>> >>>>> That's neither needed nor necessarily desirable. Just write the draft >>>>> that >>>>> says how to do it, then ask if people like it. Abstract argument in >>>>> advance >>>>> doesn't seem useful. >>>>> >>>>> S >>>>> >>>>>> >>>>>> >>>>>> 2. Bundle-in-Bundle (BiB) encapsulation >>>>>> >>>>>> BiB is a useful way to create a tunnel in a network at the BP >>>>>> layer. With >>>>>> any tunneled packet, it should be protected from misuse while in the >>>>>> tunnel, >>>>>> and encapsulation is a way to do that. IMO, it should be used >>>>>> exactly in >>>>>> those situations where we need a security destination that is >>>>>> different >>>>>> than >>>>>> the bundle destination; i.e. When we need to make a security tunnel. >>>>>> >>>>>> Actions such as adding a signature to a bundle or encrypting a >>>>>> bundle, >>>>>> would not require encapsulation if the security destinations remain >>>>>> the >>>>>> bundle destinations. The only exception here would be BAB, which is >>>>>> the >>>>>> special case of next-hop neighbors, which would still not require an >>>>>> encapsulation, but the security destination would be understood to >>>>>> be the >>>>>> next immediate BP hop which is knowable by the routing subsystem >>>>>> (arguably >>>>>> the only thing knowable by the routing subsystem). >>>>>> >>>>>> If we have extension blocks that have security destinations >>>>>> different >>>>>> from >>>>>> the payload security destinations, then it sounds like we are >>>>>> treating >>>>>> extension blocks as "extra" independent payloads and that may cause >>>>>> identity >>>>>> problems beyond these BSP issues. >>>>>> >>>>>> It would probably be helpful to specify a concrete use-case >>>>>> surrounding >>>>>> the signing and encrypting of payloads and extension blocks along >>>>>> the >>>>>> traversed path of a bundle. Could you propose such a use case? >>>>>> >>>>>> -Ed >>>>>> >>>>>> On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" >>>>>> wrote: >>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> I like how this approach simplifies the routing and gets rid of the >>>>>>> security src/dest and EID refs. I was a little confused though >>>>>>> about >>>>>>> how this would work with some of the combinations of security >>>>>>> blocks: >>>>>>> >>>>>>> If a node just wants to add a signature to a bundle, would this >>>>>>> require the bundle to be encapsulated? One of the advantages of BSP >>>>>>> is >>>>>>> that non security-aware nodes can still access the payload by just >>>>>>> ignoring the PIB block. Wouldn't we lose that feature if the bundle >>>>>>> were encapsulated? >>>>>>> >>>>>>> If a node wants to sign and then encrypt the bundle, does this >>>>>>> require >>>>>>> the bundle to be encapsulated twice? >>>>>>> >>>>>>> How would we handle signing/encrypting extension blocks? Would this >>>>>>> require a third encapsulation? Wouldn't we still need correlators >>>>>>> in >>>>>>> case multiple extension blocks are encrypted with the same key, or >>>>>>> would we not allow different extension blocks to be encrypted with >>>>>>> different keys? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Angela >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 22, 2013 at 6:49 PM, >>>>>>> wrote: >>>>>>>> If you have received this digest without all the individual >>>>>>>> message >>>>>>>> attachments you will need to update your digest options in your >>>>>>>> list >>>>>>>> subscription. To do so, go to >>>>>>>> >>>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>>> >>>>>>>> Click the 'Unsubscribe or edit options' button, log in, and set >>>>>>>> "Get >>>>>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>>>>> globally for all the list digests you receive at this point. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Send dtn-security mailing list submissions to >>>>>>>> dtn-security@irtf.org >>>>>>>> >>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>>> dtn-security-request@irtf.org >>>>>>>> >>>>>>>> You can reach the person managing the list at >>>>>>>> dtn-security-owner@irtf.org >>>>>>>> >>>>>>>> When replying, please edit your Subject line so it is more >>>>>>>> specific >>>>>>>> than "Re: Contents of dtn-security digest..." >>>>>>>> >>>>>>>> Today's Topics: >>>>>>>> >>>>>>>> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>>>> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>>>> >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>>>> >>>>>>>> To: "Burleigh, Scott C" , >>>>>>>> "dtn-security@irtf.org" >>>>>>>> Cc: >>>>>>>> Date: Tue, 22 Jan 2013 17:19:48 -0600 >>>>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> It looks like basically a good idea to me. >>>>>>>> >>>>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>>>> destinations >>>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to >>>>>>>> make >>>>>>>> the >>>>>>>> routing work correctly, and I think what you're proposing here >>>>>>>> accomplishes >>>>>>>> that in a better way. >>>>>>>> >>>>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>>>> actually >>>>>>>> HARD, and *then* circling back to see what could be tweaked in the >>>>>>>> BSP, >>>>>>>> I >>>>>>>> definitely think this proposed change is something that would >>>>>>>> improve >>>>>>>> the >>>>>>>> BSP >>>>>>>> a bit in the meantime. >>>>>>>> >>>>>>>> I don't think it can be done in a way that's friendly to the >>>>>>>> existing >>>>>>>> codebase like Stephen suggests shooting for. >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: dtn-security-bounces@irtf.org >>>>>>>> [dtn-security-bounces@irtf.org] On >>>>>>>> Behalf >>>>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>>>> To: dtn-security@irtf.org >>>>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> >>>>>>>> Hi. Late last September, several of us spun off a sub-thread >>>>>>>> talking >>>>>>>> about >>>>>>>> how the processing of bundles with multiple security destinations >>>>>>>> could >>>>>>>> be >>>>>>>> handled in DTN implementations. I wonıt try to recreate all of >>>>>>>> the >>>>>>>> arguments >>>>>>>> on all sides, but I think we did converge on agreement that the >>>>>>>> current >>>>>>>> BSP >>>>>>>> mechanism for complex, multi-destination security could be >>>>>>>> difficult to >>>>>>>> realize in coherent fashion across the network. After puzzling >>>>>>>> over >>>>>>>> this >>>>>>>> for >>>>>>>> a while, I came up with a concept (below) that I think would be >>>>>>>> simpler, >>>>>>>> safer, and even more powerful than the current protocol design. >>>>>>>> How do >>>>>>>> we >>>>>>>> all feel about this? Would it be worthwhile for DTNRG to invest >>>>>>>> in a >>>>>>>> 6257bis >>>>>>>> RFC along these lines? >>>>>>>> >>>>>>>> Scott >>>>>>>> _____________________________________________ >>>>>>>> From: Burleigh, Scott C (313B) >>>>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security >>>>>>>> Destinations >>>>>>>> in >>>>>>>> DTN2 >>>>>>>> >>>>>>>> >>>>>>>> Hi, Peter. At the risk (I know) of getting a lot of people >>>>>>>> severely >>>>>>>> ticked >>>>>>>> off at me, I am going to offer a modest proposal for improving the >>>>>>>> Bundle >>>>>>>> Security Protocol, inspired by this thread. >>>>>>>> I propose to adopt a new design principle for Bundle Security >>>>>>>> Protocol: >>>>>>>> the >>>>>>>> routing element of a bundle protocol agent should never need to >>>>>>>> inspect >>>>>>>> a >>>>>>>> bundleıs BSP extension blocks in order to select the node(s) to >>>>>>>> forward >>>>>>>> the >>>>>>>> bundle to. >>>>>>>> That is, BSP should provide security, not dictate routes. >>>>>>>> My rationale for proposing this principle is that I believe it >>>>>>>> would: >>>>>>>> >>>>>>>> Simplify BSP, thereby reducing the incidence of bugs and making >>>>>>>> Bundle >>>>>>>> Security significantly less expensive to implement and sustain. >>>>>>>> Broaden the scope of BSP deployment by eliminating its dependence >>>>>>>> on >>>>>>>> specific, BSP-aware routing implementations, thereby increasing >>>>>>>> the >>>>>>>> overall >>>>>>>> security of DTN. >>>>>>>> Reduce the cost of developing and improving routing >>>>>>>> implementations by >>>>>>>> removing any requirement that they be BSP-aware, and broaden the >>>>>>>> scope >>>>>>>> of >>>>>>>> deployment of non-BSP-aware routing implementations by enabling >>>>>>>> them to >>>>>>>> be >>>>>>>> used in environments requiring arbitrarily powerful security. >>>>>>>> Thereby, >>>>>>>> improve DTN operational performance. >>>>>>>> >>>>>>>> Here's how I would apply this principle: >>>>>>>> >>>>>>>> Eliminate security sources and security destinations from all BSP >>>>>>>> blocks. >>>>>>>> The security source of a BSP block would always be the bundleıs >>>>>>>> source. >>>>>>>> The >>>>>>>> security destination of a BSP block would always be the bundleıs >>>>>>>> destination. >>>>>>>> Add a new Administrative Record type for Bundle-in-Bundle >>>>>>>> encapsulation. >>>>>>>> When additional security must be applied to a bundle on some >>>>>>>> segment of >>>>>>>> its >>>>>>>> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>>>>> Encapsulation >>>>>>>> Administrative Record that is the payload of a new bundle whose >>>>>>>> source >>>>>>>> is >>>>>>>> the >>>>>>>> security source of the path segment and whose destination is the >>>>>>>> security >>>>>>>> destination of the path segment. Apply the additional bundle >>>>>>>> transmission >>>>>>>> security measures to the encapsulating bundle: encrypt its payload >>>>>>>> (the >>>>>>>> Administrative Record, containing the encapsulated bundle), >>>>>>>> encrypt >>>>>>>> extension >>>>>>>> blocks as copied from the encapsulated bundle, etc. Then forward >>>>>>>> the >>>>>>>> encapsulating bundle. >>>>>>>> When route service uncertainty forces a bundle to be routed over >>>>>>>> multiple >>>>>>>> parallel additionally secured segments of its end-to-end path, >>>>>>>> encapsulate >>>>>>>> it >>>>>>>> as above but within multiple different encapsulating bundles, one >>>>>>>> for >>>>>>>> each >>>>>>>> of >>>>>>>> the parallel segments, and forward all of them. >>>>>>>> At the destination of a bundle, apply all relevant bundle >>>>>>>> reception >>>>>>>> security >>>>>>>> measures and then, if the payload is an encapsulation >>>>>>>> Administrative >>>>>>>> Record, >>>>>>>> extract the encapsulated bundle from the Administrative Record and >>>>>>>> simply >>>>>>>> forward it. >>>>>>>> >>>>>>>> I believe this would have the following impacts on DTN security: >>>>>>>> >>>>>>>> No EID references in BSP, simplifying canonicalization. >>>>>>>> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the >>>>>>>> encapsulated >>>>>>>> bundle encrypts all three at once), so no correlators in BSP. >>>>>>>> (Except >>>>>>>> for >>>>>>>> BABs, no bundle ever has more than one occurrence of any type of >>>>>>>> BSP >>>>>>>> block. >>>>>>>> And there will never be more than two BABs, one immediately >>>>>>>> following >>>>>>>> the >>>>>>>> primary block and one that is the final block in the bundle, so >>>>>>>> that >>>>>>>> correlation is structural.) >>>>>>>> No delicate ³replacement² process for unraveling PCB nesting at >>>>>>>> the >>>>>>>> destination. >>>>>>>> No possible confusion about the correct order of application of >>>>>>>> BSP >>>>>>>> blocks. >>>>>>>> No possible conflict among security destinations of different BSP >>>>>>>> blocks. >>>>>>>> Security paths can never overlap. >>>>>>>> Any routing implementation can always accommodate any security >>>>>>>> regime: >>>>>>>> routes >>>>>>>> that must be followed to ensure security are encoded into routing >>>>>>>> information >>>>>>>> at the forwarding node, not into the bundle. (A little like the >>>>>>>> late >>>>>>>> binding >>>>>>>> principle.) >>>>>>>> Any routing environment can always be made arbitrarily secure ­ no >>>>>>>> need >>>>>>>> to >>>>>>>> require specially BSP-aware routing elements. >>>>>>>> Ciphersuite design is simplified, so a wider array of useful >>>>>>>> ciphersuites >>>>>>>> can >>>>>>>> be developed without imposing bug-prone complexity. Minimizes >>>>>>>> possible >>>>>>>> security problems. >>>>>>>> >>>>>>>> As an example of how I think this could work, see the attached >>>>>>>> diagram: >>>>>>>> >>>>>>>> Node A is sending a bundle to node K. Nodes A, B, J, and K are >>>>>>>> within >>>>>>>> the >>>>>>>> low-risk ³W² security region; nodes C and G are gateways between >>>>>>>> region >>>>>>>> W >>>>>>>> and >>>>>>>> the more hazardous region X; node D is another node in X; nodes E >>>>>>>> and F >>>>>>>> are >>>>>>>> gateways between region X and even more hazardous region Y; nodes >>>>>>>> H and >>>>>>>> I >>>>>>>> are >>>>>>>> gateways between X and hazardous region Z. >>>>>>>> At A the bundle is simply forwarded to B. >>>>>>>> At B the routing element realizes that the bundle has to traverse >>>>>>>> region >>>>>>>> X >>>>>>>> in >>>>>>>> order to get to K, so it forwards the bundle to C. >>>>>>>> The routing element at C encapsulates the bundle in an Admin >>>>>>>> Record, >>>>>>>> creates >>>>>>>> a new bundle destined for G (the egress from region X) whose >>>>>>>> source is C >>>>>>>> and >>>>>>>> whose payload is that Admin Record, encrypts the payload, attaches >>>>>>>> a >>>>>>>> PCB, >>>>>>>> and >>>>>>>> forwards the bundle to D. >>>>>>>> D realizes that the bundle has to traverse region Y in order to >>>>>>>> get to >>>>>>>> G, >>>>>>>> so >>>>>>>> it forwards the bundle to E. >>>>>>>> E encapsulates the bundle in an Admin Record, creates a new bundle >>>>>>>> destined >>>>>>>> for F (the egress from region Y) whose source is E and whose >>>>>>>> payload is >>>>>>>> that >>>>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards >>>>>>>> the >>>>>>>> bundle >>>>>>>> to F. >>>>>>>> The bundle protocol agent at F receives the bundle, decrypts it, >>>>>>>> and >>>>>>>> passes >>>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>>> administrative >>>>>>>> element of the application agent at F receives the Admin Record, >>>>>>>> extracts >>>>>>>> the >>>>>>>> encapsulated bundle destined for G, and queues it to be forwarded. >>>>>>>> The >>>>>>>> routing element at F sees this bundle and forwards it to G. >>>>>>>> The bundle protocol agent at G receives the bundle, decrypts it, >>>>>>>> and >>>>>>>> passes >>>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>>> administrative >>>>>>>> element of the application agent at G receives the Admin Record, >>>>>>>> extracts >>>>>>>> the >>>>>>>> encapsulated bundle destined for K, and queues it to be forwarded. >>>>>>>> The >>>>>>>> routing element at G sees this bundle, realizes that the bundle >>>>>>>> has to >>>>>>>> traverse region Z in order to get to K, and therefore forwards the >>>>>>>> bundle >>>>>>>> to >>>>>>>> H. >>>>>>>> H encapsulates the bundle in an Admin Record, creates a new bundle >>>>>>>> destined >>>>>>>> for I (the egress from region Z) whose source is H and whose >>>>>>>> payload is >>>>>>>> that >>>>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards >>>>>>>> the >>>>>>>> bundle >>>>>>>> to I. >>>>>>>> The bundle protocol agent at I receives the bundle, decrypts it, >>>>>>>> and >>>>>>>> passes >>>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>>> administrative >>>>>>>> element of the application agent at I receives the Admin Record, >>>>>>>> extracts >>>>>>>> the >>>>>>>> encapsulated bundle destined for K, and queues it to be forwarded. >>>>>>>> The >>>>>>>> routing element at I sees this bundle and forwards it to J. >>>>>>>> At J the bundle is simply forwarded to K. >>>>>>>> At K the bundleıs payload is passed to the application. >>>>>>>> >>>>>>>> I think this approach would combine simplicity with quite a lot of >>>>>>>> operational power, making everything cheaper and safer. >>>>>>>> So, having now stirred the hornetıs nest, I will beat a hasty >>>>>>>> retreat >>>>>>>> for >>>>>>>> a >>>>>>>> week while I am on vacation. Iıll try to follow up when I get >>>>>>>> back. >>>>>>>> Have a nice Thanksgiving, everybody. >>>>>>>> Scott >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter >>>>>>>> Lovell >>>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations >>>>>>>> in >>>>>>>> DTN2 >>>>>>>> >>>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>>>> wrote: >>>>>>>> >>>>>>>>> In view of which, I've now become a bigger fan of >>>>>>>>> bundle-in-bundle >>>>>>>>> tunneling than I've been in the past. >>>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>>>> mentioned >>>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit >>>>>>>> "funky" >>>>>>>> to >>>>>>>> me. There's no indication in the bundle that it's BiB and you need >>>>>>>> some >>>>>>>> special EID to perform the decapsulation. Maybe that's just like >>>>>>>> an >>>>>>>> assigned >>>>>>>> port in TCP but we don't yet have such a mechanism. The >>>>>>>> multiple-bundle >>>>>>>> thing >>>>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>>>> gateway-to-gateway traffic and I think that such heavy-duty >>>>>>>> tunnels >>>>>>>> could >>>>>>>> be >>>>>>>> specially optimized. >>>>>>>> >>>>>>>> I need to go back and review all the discussions about BiB -- we >>>>>>>> worked >>>>>>>> it >>>>>>>> quite a bit but the spec never gained enough consensus to move >>>>>>>> forward. >>>>>>>> I >>>>>>>> think it would be a good idea to revisit it now and get a solid >>>>>>>> draft >>>>>>>> that >>>>>>>> has wider support. Maybe the email discussions will help us get >>>>>>>> there. >>>>>>>> >>>>>>>> Thanks.....Peter >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>>>> >>>>>>>> To: "Burleigh, Scott C" , >>>>>>>> "dtn-security@irtf.org" >>>>>>>> Cc: >>>>>>>> Date: Tue, 22 Jan 2013 17:47:47 -0600 >>>>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> Agreed; that makes sense. >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>>> Sent: Tuesday, January 22, 2013 6:35 PM >>>>>>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; >>>>>>>> dtn-security@irtf.org >>>>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> >>>>>>>> Wes, I agree that some code change would be entailed in >>>>>>>> implementing >>>>>>>> this >>>>>>>> proposal, but I think a large proportion of the code ­ the general >>>>>>>> flow >>>>>>>> of >>>>>>>> processing the extension blocks, the canonicalization, the >>>>>>>> ciphersuites, >>>>>>>> really almost everything that would have been implemented to >>>>>>>> handle the >>>>>>>> simple case of security source/destination being identical to >>>>>>>> bundle >>>>>>>> source/destination ­ would be preserved. I suspect that much of >>>>>>>> what I >>>>>>>> was >>>>>>>> proposing here involves removing functionality that most >>>>>>>> developers >>>>>>>> havenıt >>>>>>>> implemented yet anyway, because of the potential pitfalls. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >>>>>>>> [mailto:wesley.m.eddy@nasa.gov] >>>>>>>> Sent: Tuesday, January 22, 2013 3:20 PM >>>>>>>> To: Burleigh, Scott C (313B); dtn-security@irtf.org >>>>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It looks like basically a good idea to me. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>>>> destinations >>>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to >>>>>>>> make >>>>>>>> the >>>>>>>> routing work correctly, and I think what you're proposing here >>>>>>>> accomplishes >>>>>>>> that in a better way. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>>>> actually >>>>>>>> HARD, and *then* circling back to see what could be tweaked in the >>>>>>>> BSP, >>>>>>>> I >>>>>>>> definitely think this proposed change is something that would >>>>>>>> improve >>>>>>>> the >>>>>>>> BSP >>>>>>>> a bit in the meantime. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I don't think it can be done in a way that's friendly to the >>>>>>>> existing >>>>>>>> codebase like Stephen suggests shooting for. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> >>>>>>>> From: dtn-security-bounces@irtf.org >>>>>>>> [dtn-security-bounces@irtf.org] On >>>>>>>> Behalf >>>>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>>>> To: dtn-security@irtf.org >>>>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> >>>>>>>> Hi. Late last September, several of us spun off a sub-thread >>>>>>>> talking >>>>>>>> about >>>>>>>> how the processing of bundles with multiple security destinations >>>>>>>> could >>>>>>>> be >>>>>>>> handled in DTN implementations. I wonıt try to recreate all of >>>>>>>> the >>>>>>>> arguments >>>>>>>> on all sides, but I think we did converge on agreement that the >>>>>>>> current >>>>>>>> BSP >>>>>>>> mechanism for complex, multi-destination security could be >>>>>>>> difficult to >>>>>>>> realize in coherent fashion across the network. After puzzling >>>>>>>> over >>>>>>>> this >>>>>>>> for >>>>>>>> a while, I came up with a concept (below) that I think would be >>>>>>>> simpler, >>>>>>>> safer, and even more powerful than the current protocol design. >>>>>>>> How do >>>>>>>> we >>>>>>>> all feel about this? Would it be worthwhile for DTNRG to invest >>>>>>>> in a >>>>>>>> 6257bis >>>>>>>> RFC along these lines? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> _____________________________________________ >>>>>>>> From: Burleigh, Scott C (313B) >>>>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security >>>>>>>> Destinations >>>>>>>> in >>>>>>>> DTN2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, Peter. At the risk (I know) of getting a lot of people >>>>>>>> severely >>>>>>>> ticked >>>>>>>> off at me, I am going to offer a modest proposal for improving the >>>>>>>> Bundle >>>>>>>> Security Protocol, inspired by this thread. >>>>>>>> >>>>>>>> I propose to adopt a new design principle for Bundle Security >>>>>>>> Protocol: >>>>>>>> the >>>>>>>> routing element of a bundle protocol agent should never need to >>>>>>>> inspect >>>>>>>> a >>>>>>>> bundleıs BSP extension blocks in order to select the node(s) to >>>>>>>> forward >>>>>>>> the >>>>>>>> bundle to. >>>>>>>> >>>>>>>> That is, BSP should provide security, not dictate routes. >>>>>>>> >>>>>>>> My rationale for proposing this principle is that I believe it >>>>>>>> would: >>>>>>>> >>>>>>>> · Simplify BSP, thereby reducing the incidence of bugs and >>>>>>>> making >>>>>>>> Bundle Security significantly less expensive to implement and >>>>>>>> sustain. >>>>>>>> >>>>>>>> · Broaden the scope of BSP deployment by eliminating its >>>>>>>> dependence >>>>>>>> on specific, BSP-aware routing implementations, thereby increasing >>>>>>>> the >>>>>>>> overall security of DTN. >>>>>>>> >>>>>>>> · Reduce the cost of developing and improving routing >>>>>>>> implementations >>>>>>>> by removing any requirement that they be BSP-aware, and broaden >>>>>>>> the >>>>>>>> scope >>>>>>>> of >>>>>>>> deployment of non-BSP-aware routing implementations by enabling >>>>>>>> them to >>>>>>>> be >>>>>>>> used in environments requiring arbitrarily powerful security. >>>>>>>> Thereby, >>>>>>>> improve DTN operational performance. >>>>>>>> >>>>>>>> Here's how I would apply this principle: >>>>>>>> >>>>>>>> 1. Eliminate security sources and security destinations from >>>>>>>> all >>>>>>>> BSP >>>>>>>> blocks. The security source of a BSP block would always be the >>>>>>>> bundleıs >>>>>>>> source. The security destination of a BSP block would always be >>>>>>>> the >>>>>>>> bundleıs >>>>>>>> destination. >>>>>>>> >>>>>>>> 2. Add a new Administrative Record type for Bundle-in-Bundle >>>>>>>> encapsulation. >>>>>>>> >>>>>>>> 3. When additional security must be applied to a bundle on >>>>>>>> some >>>>>>>> segment >>>>>>>> of its end-to-end path, encapsulate the bundle in a >>>>>>>> Bundle-in-Bundle >>>>>>>> Encapsulation Administrative Record that is the payload of a new >>>>>>>> bundle >>>>>>>> whose >>>>>>>> source is the security source of the path segment and whose >>>>>>>> destination >>>>>>>> is >>>>>>>> the security destination of the path segment. Apply the >>>>>>>> additional >>>>>>>> bundle >>>>>>>> transmission security measures to the encapsulating bundle: >>>>>>>> encrypt its >>>>>>>> payload (the Administrative Record, containing the encapsulated >>>>>>>> bundle), >>>>>>>> encrypt extension blocks as copied from the encapsulated bundle, >>>>>>>> etc. >>>>>>>> Then >>>>>>>> forward the encapsulating bundle. >>>>>>>> >>>>>>>> 4. When route service uncertainty forces a bundle to be >>>>>>>> routed >>>>>>>> over >>>>>>>> multiple parallel additionally secured segments of its end-to-end >>>>>>>> path, >>>>>>>> encapsulate it as above but within multiple different >>>>>>>> encapsulating >>>>>>>> bundles, >>>>>>>> one for each of the parallel segments, and forward all of them. >>>>>>>> >>>>>>>> 5. At the destination of a bundle, apply all relevant bundle >>>>>>>> reception >>>>>>>> security measures and then, if the payload is an encapsulation >>>>>>>> Administrative >>>>>>>> Record, extract the encapsulated bundle from the Administrative >>>>>>>> Record >>>>>>>> and >>>>>>>> simply forward it. >>>>>>>> >>>>>>>> I believe this would have the following impacts on DTN security: >>>>>>>> >>>>>>>> · No EID references in BSP, simplifying canonicalization. >>>>>>>> >>>>>>>> · PCBs only encrypt payloads, never PIBs or PCBs >>>>>>>> (encrypting the >>>>>>>> encapsulated bundle encrypts all three at once), so no correlators >>>>>>>> in >>>>>>>> BSP. >>>>>>>> (Except for BABs, no bundle ever has more than one occurrence of >>>>>>>> any >>>>>>>> type >>>>>>>> of >>>>>>>> BSP block. And there will never be more than two BABs, one >>>>>>>> immediately >>>>>>>> following the primary block and one that is the final block in the >>>>>>>> bundle, >>>>>>>> so >>>>>>>> that correlation is structural.) >>>>>>>> >>>>>>>> · No delicate ³replacement² process for unraveling PCB >>>>>>>> nesting >>>>>>>> at >>>>>>>> the >>>>>>>> destination. >>>>>>>> >>>>>>>> · No possible confusion about the correct order of >>>>>>>> application >>>>>>>> of >>>>>>>> BSP >>>>>>>> blocks. >>>>>>>> >>>>>>>> · No possible conflict among security destinations of >>>>>>>> different >>>>>>>> BSP >>>>>>>> blocks. >>>>>>>> >>>>>>>> · Security paths can never overlap. >>>>>>>> >>>>>>>> · Any routing implementation can always accommodate any >>>>>>>> security >>>>>>>> regime: routes that must be followed to ensure security are >>>>>>>> encoded into >>>>>>>> routing information at the forwarding node, not into the bundle. >>>>>>>> (A >>>>>>>> little >>>>>>>> like the late binding principle.) >>>>>>>> >>>>>>>> · Any routing environment can always be made arbitrarily >>>>>>>> secure >>>>>>>> ­ >>>>>>>> no >>>>>>>> need to require specially BSP-aware routing elements. >>>>>>>> >>>>>>>> · Ciphersuite design is simplified, so a wider array of >>>>>>>> useful >>>>>>>> ciphersuites can be developed without imposing bug-prone >>>>>>>> complexity. >>>>>>>> Minimizes possible security problems. >>>>>>>> >>>>>>>> As an example of how I think this could work, see the attached >>>>>>>> diagram: >>>>>>>> >>>>>>>> 1. Node A is sending a bundle to node K. Nodes A, B, J, and >>>>>>>> K are >>>>>>>> within the low-risk ³W² security region; nodes C and G are >>>>>>>> gateways >>>>>>>> between >>>>>>>> region W and the more hazardous region X; node D is another node >>>>>>>> in X; >>>>>>>> nodes >>>>>>>> E and F are gateways between region X and even more hazardous >>>>>>>> region Y; >>>>>>>> nodes >>>>>>>> H and I are gateways between X and hazardous region Z. >>>>>>>> >>>>>>>> 2. At A the bundle is simply forwarded to B. >>>>>>>> >>>>>>>> 3. At B the routing element realizes that the bundle has to >>>>>>>> traverse >>>>>>>> region X in order to get to K, so it forwards the bundle to C. >>>>>>>> >>>>>>>> 4. The routing element at C encapsulates the bundle in an >>>>>>>> Admin >>>>>>>> Record, >>>>>>>> creates a new bundle destined for G (the egress from region X) >>>>>>>> whose >>>>>>>> source >>>>>>>> is C and whose payload is that Admin Record, encrypts the payload, >>>>>>>> attaches a >>>>>>>> PCB, and forwards the bundle to D. >>>>>>>> >>>>>>>> 5. D realizes that the bundle has to traverse region Y in >>>>>>>> order to >>>>>>>> get >>>>>>>> to G, so it forwards the bundle to E. >>>>>>>> >>>>>>>> 6. E encapsulates the bundle in an Admin Record, creates a >>>>>>>> new >>>>>>>> bundle >>>>>>>> destined for F (the egress from region Y) whose source is E and >>>>>>>> whose >>>>>>>> payload >>>>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and >>>>>>>> forwards >>>>>>>> the >>>>>>>> bundle to F. >>>>>>>> >>>>>>>> 7. The bundle protocol agent at F receives the bundle, >>>>>>>> decrypts >>>>>>>> it, >>>>>>>> and >>>>>>>> passes the payload (an Admin Record) to the application agent. >>>>>>>> The >>>>>>>> administrative element of the application agent at F receives the >>>>>>>> Admin >>>>>>>> Record, extracts the encapsulated bundle destined for G, and >>>>>>>> queues it >>>>>>>> to >>>>>>>> be >>>>>>>> forwarded. The routing element at F sees this bundle and forwards >>>>>>>> it to >>>>>>>> G. >>>>>>>> >>>>>>>> 8. The bundle protocol agent at G receives the bundle, >>>>>>>> decrypts >>>>>>>> it, >>>>>>>> and >>>>>>>> passes the payload (an Admin Record) to the application agent. >>>>>>>> The >>>>>>>> administrative element of the application agent at G receives the >>>>>>>> Admin >>>>>>>> Record, extracts the encapsulated bundle destined for K, and >>>>>>>> queues it >>>>>>>> to >>>>>>>> be >>>>>>>> forwarded. The routing element at G sees this bundle, realizes >>>>>>>> that the >>>>>>>> bundle has to traverse region Z in order to get to K, and >>>>>>>> therefore >>>>>>>> forwards >>>>>>>> the bundle to H. >>>>>>>> >>>>>>>> 9. H encapsulates the bundle in an Admin Record, creates a >>>>>>>> new >>>>>>>> bundle >>>>>>>> destined for I (the egress from region Z) whose source is H and >>>>>>>> whose >>>>>>>> payload >>>>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and >>>>>>>> forwards >>>>>>>> the >>>>>>>> bundle to I. >>>>>>>> >>>>>>>> 10. The bundle protocol agent at I receives the bundle, decrypts >>>>>>>> it, >>>>>>>> and >>>>>>>> passes the payload (an Admin Record) to the application agent. >>>>>>>> The >>>>>>>> administrative element of the application agent at I receives the >>>>>>>> Admin >>>>>>>> Record, extracts the encapsulated bundle destined for K, and >>>>>>>> queues it >>>>>>>> to >>>>>>>> be >>>>>>>> forwarded. The routing element at I sees this bundle and forwards >>>>>>>> it to >>>>>>>> J. >>>>>>>> >>>>>>>> 11. At J the bundle is simply forwarded to K. >>>>>>>> >>>>>>>> 12. At K the bundleıs payload is passed to the application. >>>>>>>> >>>>>>>> I think this approach would combine simplicity with quite a lot of >>>>>>>> operational power, making everything cheaper and safer. >>>>>>>> >>>>>>>> So, having now stirred the hornetıs nest, I will beat a hasty >>>>>>>> retreat >>>>>>>> for >>>>>>>> a >>>>>>>> week while I am on vacation. Iıll try to follow up when I get >>>>>>>> back. >>>>>>>> >>>>>>>> Have a nice Thanksgiving, everybody. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter >>>>>>>> Lovell >>>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations >>>>>>>> in >>>>>>>> DTN2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In view of which, I've now become a bigger fan of >>>>>>>>> bundle-in-bundle >>>>>>>> >>>>>>>>> tunneling than I've been in the past. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>>>> mentioned >>>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit >>>>>>>> "funky" >>>>>>>> to >>>>>>>> me. There's no indication in the bundle that it's BiB and you need >>>>>>>> some >>>>>>>> special EID to perform the decapsulation. Maybe that's just like >>>>>>>> an >>>>>>>> assigned >>>>>>>> port in TCP but we don't yet have such a mechanism. The >>>>>>>> multiple-bundle >>>>>>>> thing >>>>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>>>> gateway-to-gateway traffic and I think that such heavy-duty >>>>>>>> tunnels >>>>>>>> could >>>>>>>> be >>>>>>>> specially optimized. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I need to go back and review all the discussions about BiB -- we >>>>>>>> worked >>>>>>>> it >>>>>>>> quite a bit but the spec never gained enough consensus to move >>>>>>>> forward. >>>>>>>> I >>>>>>>> think it would be a good idea to revisit it now and get a solid >>>>>>>> draft >>>>>>>> that >>>>>>>> has wider support. Maybe the email discussions will help us get >>>>>>>> there. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks.....Peter >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dtn-security mailing list >>>>>>>> dtn-security@irtf.org >>>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>> _______________________________________________ >>>>>>> dtn-security mailing list >>>>>>> dtn-security@irtf.org >>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>> >>>>>> _______________________________________________ >>>>>> dtn-security mailing list >>>>>> dtn-security@irtf.org >>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>>> >>>>> _______________________________________________ >>>>> dtn-security mailing list >>>>> dtn-security@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>> _______________________________________________ >>>> dtn-security mailing list >>>> dtn-security@irtf.org >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>> > > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security > ################################################### // Double the Pride,Double the Fall // From ahennes1@gmail.com Tue Jan 29 07:34:39 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C8E21F8923 for ; Tue, 29 Jan 2013 07:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVQTGq3HeZV0 for ; Tue, 29 Jan 2013 07:34:36 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3510A21F88A9 for ; Tue, 29 Jan 2013 07:34:36 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id n1so904371lba.9 for ; Tue, 29 Jan 2013 07:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HUQN4TdxiMo9jv6rFKvhYZ3HjnSXQ1LvfAzw83nDAb8=; b=VsnaTYTcSeHKRze2MF0XM84o7HqtgQZB6prAa1+bZbB+Pge9y6rP2HTGV7mUNAfa56 +ZPrHkKOgxh9dsQpjxissIoqXC6k7muhB8tm4uqKwEQk4vBBr3icSTM+p3CZrXB/yCYA DaSQ3ycu/hN/EC5OmClkm3aWURZCaiPXOHHgps2nrJ8RvUUvkvo2u59xHLa9YFDx5Ojc eUc7zFOBK5ra9vYyQij7SD4OpTCoIMxrvbmCNE2rMDj5jdhWmo2CXuvqqzNxBW9tzUFY qikXWeDIAzWMlAO6lz+XNJ3TmtniY+bEoii+USWSPsfzwI+vtD9B3Ye1fCvlujtMGn52 SWyw== MIME-Version: 1.0 X-Received: by 10.112.40.129 with SMTP id x1mr642419lbk.95.1359473675028; Tue, 29 Jan 2013 07:34:35 -0800 (PST) Sender: ahennes1@gmail.com Received: by 10.112.150.39 with HTTP; Tue, 29 Jan 2013 07:34:34 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Jan 2013 10:34:34 -0500 X-Google-Sender-Auth: YhB1IzlGTg7HJxZczjJ9Ekog3tk Message-ID: From: Angela Hennessy To: "Ivancic, William D. (GRC-RHN0)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 15:34:40 -0000 Hi Will, The work that we did was pretty basic, getting a signature generated by DTN2 to verify correctly in IBR-DTN, and getting the payload to decrypt correctly, etc. I think we were able to get encryption and authentication working together as well. We haven't released the version of DTN2 that interoperates with IBR-DTN, the main difference is the DTN2 implementation of BSP uses the Cryptographic Message Syntax (CMS), which I believe is required in the default ciphersuites. It's used for interoperability, but since neither IBR-DTN nor ION implement it (I assume because it adds quite a bit of overhead), that's something to keep in mind for future drafts. thanks, Angela On Mon, Jan 28, 2013 at 2:46 PM, Ivancic, William D. (GRC-RHN0) wrote: > There must be hundreds (if not thousands) of combinations and permutation= s. > Is there a publically available document that lists what was tested? An= d, > perhaps just as important, what was not? > > Will > > ****************************** > William D. Ivancic > Phone 216-433-3494 > Fax 216-433-8705 > Networking Lab 216-433-2620 > Mobile 440-503-4892 > http://roland.grc.nasa.gov/~ivancic > > > >> From: Angela Hennessy >> Date: Mon, 28 Jan 2013 13:25:39 -0600 >> To: "Ivancic, William D. (GRC-RHN0)" >> Cc: "dtn-security@irtf.org" >> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 >> >> Hi Will, >> >> We had done some work on interoperability testing between DTN2 and >> IBR-DTN, which turned up some places where the BSP spec was somewhat >> vague (and as a result was implemented differently in DTN2 and >> IBR-DTN). I believe we addressed most of these in the proposed errata >> list for BSP. We haven't done any interoperability testing with the >> ION implementation, since this uses different cryptographic algorithms >> for the PIB and PCB ciphersuites. >> >> thanks, >> Angela >> >> On Mon, Jan 28, 2013 at 10:46 AM, Ivancic, William D. (GRC-RHN0) >> wrote: >>> Angela, >>> >>> I believe your group was performing interoperability testing between va= rious >>> DTN implementations. If so, Can you summarize the results and perhaps p= oint >>> to the test plan or any reports. >>> >>> IMHO, as is, the BSP would be very difficult to achieve full >>> interoperability over all option and parameters due to the complexity. >>> >>> Simplifying would be a good thing, but perhaps premature if the overall >>> protocol is to be revised. In other words, is this still research or w= ill >>> there be a move to operational deployment (a minimum of 1000s of agent= s). >>> >>> Will >>> >>> ****************************** >>> William D. Ivancic >>> Phone 216-433-3494 >>> Fax 216-433-8705 >>> Networking Lab 216-433-2620 >>> Mobile 440-503-4892 >>> http://roland.grc.nasa.gov/~ivancic >>> >>> >>> >>>> From: Angela Hennessy >>>> Date: Sun, 27 Jan 2013 15:42:18 -0600 >>>> To: "dtn-security@irtf.org" >>>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 9 >>>> >>>> Hi Ed, >>>> >>>> I definitely agree that things can get pretty complicated dealing with >>>> the security src/dest, and we've run into some issues when >>>> implementing them. I think the idea of using bundle-in-bundle >>>> encapsulation is an interesting alternative, and I'll be interested to >>>> read all the details. >>>> >>>> >>>> thanks, >>>> Angela >>>> >>>> On Sat, Jan 26, 2013 at 9:09 PM, wrot= e: >>>>> If you have received this digest without all the individual message >>>>> attachments you will need to update your digest options in your list >>>>> subscription. To do so, go to >>>>> >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>> globally for all the list digests you receive at this point. >>>>> >>>>> >>>>> >>>>> Send dtn-security mailing list submissions to >>>>> dtn-security@irtf.org >>>>> >>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> or, via email, send a message with subject or body 'help' to >>>>> dtn-security-request@irtf.org >>>>> >>>>> You can reach the person managing the list at >>>>> dtn-security-owner@irtf.org >>>>> >>>>> When replying, please edit your Subject line so it is more specific >>>>> than "Re: Contents of dtn-security digest..." >>>>> >>>>> Today's Topics: >>>>> >>>>> 1. Re: dtn-security Digest, Vol 9, Issue 4 (Stephen Farrell) >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Stephen Farrell >>>>> To: "Birrane, Edward J." >>>>> Cc: "dtn-security@irtf.org" >>>>> Date: Sun, 27 Jan 2013 02:08:27 +0000 >>>>> Subject: Re: [dtn-security] dtn-security Digest, Vol 9, Issue 4 >>>>> >>>>> >>>>> On 27 Jan 2013, at 01:18, "Birrane, Edward J." >>>>> wrote: >>>>> >>>>>> Angela, >>>>>> >>>>>> I see (at least) two issues independent enough that they should no= t be >>>>>> conflated. The first is whether simplifying the BSP specification,= to >>>>>> omit >>>>>> tight routing coupling, is beneficial. The second is the utility of= the >>>>>> bundle-in-bundle encapsulation mechanism in a security context. >>>>>> >>>>>> 1. Simplifying BSP >>>>>> What we have found is that the concept of a security destination, >>>>>> separate from a bundle destination, places a burden on any routing >>>>>> mechanism >>>>>> to guarantee delivery through one or more "waypoints" before the bun= dle >>>>>> reaches its destination. Since routing mechanisms cannot make this >>>>>> guarantee in any type of opportunistic network (and may struggle to = make >>>>>> this guarantee in structured networks) we need to find a way to rela= x this >>>>>> language and the implementation hurdles it imposes. Removing securi= ty >>>>>> sources and destinations from the specification and deferring tunnel= ing >>>>>> and >>>>>> multi-point behavior to some other mechanism (or mechanisms) seems l= ike a >>>>>> promising way to go for BSP. >>>>>> >>>>>> I think most folks on this list agree with the above, but before we= get >>>>>> too deeply into specifics surrounding encapsulation, it is probably = a good >>>>>> idea to check that assumption. >>>>>> >>>>>> ---> Do we agree that (provided we can meet necessary use cases) thi= s is a >>>>>> desired simplification of BSP? >>>>> >>>>> That's neither needed nor necessarily desirable. Just write the draft= that >>>>> says how to do it, then ask if people like it. Abstract argument in a= dvance >>>>> doesn't seem useful. >>>>> >>>>> S >>>>> >>>>>> >>>>>> >>>>>> 2. Bundle-in-Bundle (BiB) encapsulation >>>>>> >>>>>> BiB is a useful way to create a tunnel in a network at the BP layer= . With >>>>>> any tunneled packet, it should be protected from misuse while in the >>>>>> tunnel, >>>>>> and encapsulation is a way to do that. IMO, it should be used exact= ly in >>>>>> those situations where we need a security destination that is differ= ent >>>>>> than >>>>>> the bundle destination; i.e. When we need to make a security tunnel. >>>>>> >>>>>> Actions such as adding a signature to a bundle or encrypting a bund= le, >>>>>> would not require encapsulation if the security destinations remain = the >>>>>> bundle destinations. The only exception here would be BAB, which is = the >>>>>> special case of next-hop neighbors, which would still not require an >>>>>> encapsulation, but the security destination would be understood to b= e the >>>>>> next immediate BP hop which is knowable by the routing subsystem (ar= guably >>>>>> the only thing knowable by the routing subsystem). >>>>>> >>>>>> If we have extension blocks that have security destinations differe= nt >>>>>> from >>>>>> the payload security destinations, then it sounds like we are treati= ng >>>>>> extension blocks as "extra" independent payloads and that may cause >>>>>> identity >>>>>> problems beyond these BSP issues. >>>>>> >>>>>> It would probably be helpful to specify a concrete use-case surroun= ding >>>>>> the signing and encrypting of payloads and extension blocks along th= e >>>>>> traversed path of a bundle. Could you propose such a use case? >>>>>> >>>>>> -Ed >>>>>> >>>>>> On 1/23/13 1:03 PM, "ahennes1@math.umd.edu" = wrote: >>>>>> >>>>>>> Hi Scott, >>>>>>> >>>>>>> I like how this approach simplifies the routing and gets rid of the >>>>>>> security src/dest and EID refs. I was a little confused though abou= t >>>>>>> how this would work with some of the combinations of security block= s: >>>>>>> >>>>>>> If a node just wants to add a signature to a bundle, would this >>>>>>> require the bundle to be encapsulated? One of the advantages of BSP= is >>>>>>> that non security-aware nodes can still access the payload by just >>>>>>> ignoring the PIB block. Wouldn't we lose that feature if the bundle >>>>>>> were encapsulated? >>>>>>> >>>>>>> If a node wants to sign and then encrypt the bundle, does this requ= ire >>>>>>> the bundle to be encapsulated twice? >>>>>>> >>>>>>> How would we handle signing/encrypting extension blocks? Would this >>>>>>> require a third encapsulation? Wouldn't we still need correlators i= n >>>>>>> case multiple extension blocks are encrypted with the same key, or >>>>>>> would we not allow different extension blocks to be encrypted with >>>>>>> different keys? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Angela >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 22, 2013 at 6:49 PM, w= rote: >>>>>>>> If you have received this digest without all the individual messag= e >>>>>>>> attachments you will need to update your digest options in your li= st >>>>>>>> subscription. To do so, go to >>>>>>>> >>>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>>> >>>>>>>> Click the 'Unsubscribe or edit options' button, log in, and set "G= et >>>>>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>>>>> globally for all the list digests you receive at this point. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Send dtn-security mailing list submissions to >>>>>>>> dtn-security@irtf.org >>>>>>>> >>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>>> dtn-security-request@irtf.org >>>>>>>> >>>>>>>> You can reach the person managing the list at >>>>>>>> dtn-security-owner@irtf.org >>>>>>>> >>>>>>>> When replying, please edit your Subject line so it is more specifi= c >>>>>>>> than "Re: Contents of dtn-security digest..." >>>>>>>> >>>>>>>> Today's Topics: >>>>>>>> >>>>>>>> 1. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>>>> 2. Re: FW: Re(19): Implementing Security Destinations inDTN2 >>>>>>>> (Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]) >>>>>>>> >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>>>> >>>>>>>> To: "Burleigh, Scott C" , >>>>>>>> "dtn-security@irtf.org" >>>>>>>> Cc: >>>>>>>> Date: Tue, 22 Jan 2013 17:19:48 -0600 >>>>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> It looks like basically a good idea to me. >>>>>>>> >>>>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>>>> destinations >>>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to m= ake >>>>>>>> the >>>>>>>> routing work correctly, and I think what you're proposing here >>>>>>>> accomplishes >>>>>>>> that in a better way. >>>>>>>> >>>>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>>>> actually >>>>>>>> HARD, and *then* circling back to see what could be tweaked in the= BSP, >>>>>>>> I >>>>>>>> definitely think this proposed change is something that would impr= ove >>>>>>>> the >>>>>>>> BSP >>>>>>>> a bit in the meantime. >>>>>>>> >>>>>>>> I don't think it can be done in a way that's friendly to the exist= ing >>>>>>>> codebase like Stephen suggests shooting for. >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org= ] On >>>>>>>> Behalf >>>>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>>>> To: dtn-security@irtf.org >>>>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinat= ions >>>>>>>> inDTN2 >>>>>>>> >>>>>>>> Hi. Late last September, several of us spun off a sub-thread talk= ing >>>>>>>> about >>>>>>>> how the processing of bundles with multiple security destinations = could >>>>>>>> be >>>>>>>> handled in DTN implementations. I won=B9t try to recreate all of = the >>>>>>>> arguments >>>>>>>> on all sides, but I think we did converge on agreement that the cu= rrent >>>>>>>> BSP >>>>>>>> mechanism for complex, multi-destination security could be difficu= lt to >>>>>>>> realize in coherent fashion across the network. After puzzling ov= er >>>>>>>> this >>>>>>>> for >>>>>>>> a while, I came up with a concept (below) that I think would be si= mpler, >>>>>>>> safer, and even more powerful than the current protocol design. H= ow do >>>>>>>> we >>>>>>>> all feel about this? Would it be worthwhile for DTNRG to invest i= n a >>>>>>>> 6257bis >>>>>>>> RFC along these lines? >>>>>>>> >>>>>>>> Scott >>>>>>>> _____________________________________________ >>>>>>>> From: Burleigh, Scott C (313B) >>>>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinat= ions >>>>>>>> in >>>>>>>> DTN2 >>>>>>>> >>>>>>>> >>>>>>>> Hi, Peter. At the risk (I know) of getting a lot of people severe= ly >>>>>>>> ticked >>>>>>>> off at me, I am going to offer a modest proposal for improving the >>>>>>>> Bundle >>>>>>>> Security Protocol, inspired by this thread. >>>>>>>> I propose to adopt a new design principle for Bundle Security Prot= ocol: >>>>>>>> the >>>>>>>> routing element of a bundle protocol agent should never need to in= spect >>>>>>>> a >>>>>>>> bundle=B9s BSP extension blocks in order to select the node(s) to = forward >>>>>>>> the >>>>>>>> bundle to. >>>>>>>> That is, BSP should provide security, not dictate routes. >>>>>>>> My rationale for proposing this principle is that I believe it wou= ld: >>>>>>>> >>>>>>>> Simplify BSP, thereby reducing the incidence of bugs and making Bu= ndle >>>>>>>> Security significantly less expensive to implement and sustain. >>>>>>>> Broaden the scope of BSP deployment by eliminating its dependence = on >>>>>>>> specific, BSP-aware routing implementations, thereby increasing th= e >>>>>>>> overall >>>>>>>> security of DTN. >>>>>>>> Reduce the cost of developing and improving routing implementation= s by >>>>>>>> removing any requirement that they be BSP-aware, and broaden the s= cope >>>>>>>> of >>>>>>>> deployment of non-BSP-aware routing implementations by enabling th= em to >>>>>>>> be >>>>>>>> used in environments requiring arbitrarily powerful security. The= reby, >>>>>>>> improve DTN operational performance. >>>>>>>> >>>>>>>> Here's how I would apply this principle: >>>>>>>> >>>>>>>> Eliminate security sources and security destinations from all BSP >>>>>>>> blocks. >>>>>>>> The security source of a BSP block would always be the bundle=B9s = source. >>>>>>>> The >>>>>>>> security destination of a BSP block would always be the bundle=B9s >>>>>>>> destination. >>>>>>>> Add a new Administrative Record type for Bundle-in-Bundle encapsul= ation. >>>>>>>> When additional security must be applied to a bundle on some segme= nt of >>>>>>>> its >>>>>>>> end-to-end path, encapsulate the bundle in a Bundle-in-Bundle >>>>>>>> Encapsulation >>>>>>>> Administrative Record that is the payload of a new bundle whose so= urce >>>>>>>> is >>>>>>>> the >>>>>>>> security source of the path segment and whose destination is the >>>>>>>> security >>>>>>>> destination of the path segment. Apply the additional bundle >>>>>>>> transmission >>>>>>>> security measures to the encapsulating bundle: encrypt its payload= (the >>>>>>>> Administrative Record, containing the encapsulated bundle), encryp= t >>>>>>>> extension >>>>>>>> blocks as copied from the encapsulated bundle, etc. Then forward = the >>>>>>>> encapsulating bundle. >>>>>>>> When route service uncertainty forces a bundle to be routed over >>>>>>>> multiple >>>>>>>> parallel additionally secured segments of its end-to-end path, >>>>>>>> encapsulate >>>>>>>> it >>>>>>>> as above but within multiple different encapsulating bundles, one = for >>>>>>>> each >>>>>>>> of >>>>>>>> the parallel segments, and forward all of them. >>>>>>>> At the destination of a bundle, apply all relevant bundle receptio= n >>>>>>>> security >>>>>>>> measures and then, if the payload is an encapsulation Administrati= ve >>>>>>>> Record, >>>>>>>> extract the encapsulated bundle from the Administrative Record and >>>>>>>> simply >>>>>>>> forward it. >>>>>>>> >>>>>>>> I believe this would have the following impacts on DTN security: >>>>>>>> >>>>>>>> No EID references in BSP, simplifying canonicalization. >>>>>>>> PCBs only encrypt payloads, never PIBs or PCBs (encrypting the >>>>>>>> encapsulated >>>>>>>> bundle encrypts all three at once), so no correlators in BSP. (Ex= cept >>>>>>>> for >>>>>>>> BABs, no bundle ever has more than one occurrence of any type of B= SP >>>>>>>> block. >>>>>>>> And there will never be more than two BABs, one immediately follow= ing >>>>>>>> the >>>>>>>> primary block and one that is the final block in the bundle, so th= at >>>>>>>> correlation is structural.) >>>>>>>> No delicate =B3replacement=B2 process for unraveling PCB nesting a= t the >>>>>>>> destination. >>>>>>>> No possible confusion about the correct order of application of BS= P >>>>>>>> blocks. >>>>>>>> No possible conflict among security destinations of different BSP >>>>>>>> blocks. >>>>>>>> Security paths can never overlap. >>>>>>>> Any routing implementation can always accommodate any security reg= ime: >>>>>>>> routes >>>>>>>> that must be followed to ensure security are encoded into routing >>>>>>>> information >>>>>>>> at the forwarding node, not into the bundle. (A little like the l= ate >>>>>>>> binding >>>>>>>> principle.) >>>>>>>> Any routing environment can always be made arbitrarily secure =AD = no need >>>>>>>> to >>>>>>>> require specially BSP-aware routing elements. >>>>>>>> Ciphersuite design is simplified, so a wider array of useful >>>>>>>> ciphersuites >>>>>>>> can >>>>>>>> be developed without imposing bug-prone complexity. Minimizes pos= sible >>>>>>>> security problems. >>>>>>>> >>>>>>>> As an example of how I think this could work, see the attached dia= gram: >>>>>>>> >>>>>>>> Node A is sending a bundle to node K. Nodes A, B, J, and K are wi= thin >>>>>>>> the >>>>>>>> low-risk =B3W=B2 security region; nodes C and G are gateways betwe= en region >>>>>>>> W >>>>>>>> and >>>>>>>> the more hazardous region X; node D is another node in X; nodes E = and F >>>>>>>> are >>>>>>>> gateways between region X and even more hazardous region Y; nodes = H and >>>>>>>> I >>>>>>>> are >>>>>>>> gateways between X and hazardous region Z. >>>>>>>> At A the bundle is simply forwarded to B. >>>>>>>> At B the routing element realizes that the bundle has to traverse = region >>>>>>>> X >>>>>>>> in >>>>>>>> order to get to K, so it forwards the bundle to C. >>>>>>>> The routing element at C encapsulates the bundle in an Admin Recor= d, >>>>>>>> creates >>>>>>>> a new bundle destined for G (the egress from region X) whose sourc= e is C >>>>>>>> and >>>>>>>> whose payload is that Admin Record, encrypts the payload, attaches= a >>>>>>>> PCB, >>>>>>>> and >>>>>>>> forwards the bundle to D. >>>>>>>> D realizes that the bundle has to traverse region Y in order to ge= t to >>>>>>>> G, >>>>>>>> so >>>>>>>> it forwards the bundle to E. >>>>>>>> E encapsulates the bundle in an Admin Record, creates a new bundle >>>>>>>> destined >>>>>>>> for F (the egress from region Y) whose source is E and whose paylo= ad is >>>>>>>> that >>>>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards t= he >>>>>>>> bundle >>>>>>>> to F. >>>>>>>> The bundle protocol agent at F receives the bundle, decrypts it, a= nd >>>>>>>> passes >>>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>>> administrative >>>>>>>> element of the application agent at F receives the Admin Record, >>>>>>>> extracts >>>>>>>> the >>>>>>>> encapsulated bundle destined for G, and queues it to be forwarded.= The >>>>>>>> routing element at F sees this bundle and forwards it to G. >>>>>>>> The bundle protocol agent at G receives the bundle, decrypts it, a= nd >>>>>>>> passes >>>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>>> administrative >>>>>>>> element of the application agent at G receives the Admin Record, >>>>>>>> extracts >>>>>>>> the >>>>>>>> encapsulated bundle destined for K, and queues it to be forwarded.= The >>>>>>>> routing element at G sees this bundle, realizes that the bundle ha= s to >>>>>>>> traverse region Z in order to get to K, and therefore forwards the >>>>>>>> bundle >>>>>>>> to >>>>>>>> H. >>>>>>>> H encapsulates the bundle in an Admin Record, creates a new bundle >>>>>>>> destined >>>>>>>> for I (the egress from region Z) whose source is H and whose paylo= ad is >>>>>>>> that >>>>>>>> Admin Record, encrypts the payload, attaches a PCB, and forwards t= he >>>>>>>> bundle >>>>>>>> to I. >>>>>>>> The bundle protocol agent at I receives the bundle, decrypts it, a= nd >>>>>>>> passes >>>>>>>> the payload (an Admin Record) to the application agent. The >>>>>>>> administrative >>>>>>>> element of the application agent at I receives the Admin Record, >>>>>>>> extracts >>>>>>>> the >>>>>>>> encapsulated bundle destined for K, and queues it to be forwarded.= The >>>>>>>> routing element at I sees this bundle and forwards it to J. >>>>>>>> At J the bundle is simply forwarded to K. >>>>>>>> At K the bundle=B9s payload is passed to the application. >>>>>>>> >>>>>>>> I think this approach would combine simplicity with quite a lot of >>>>>>>> operational power, making everything cheaper and safer. >>>>>>>> So, having now stirred the hornet=B9s nest, I will beat a hasty re= treat >>>>>>>> for >>>>>>>> a >>>>>>>> week while I am on vacation. I=B9ll try to follow up when I get b= ack. >>>>>>>> Have a nice Thanksgiving, everybody. >>>>>>>> Scott >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lo= vell >>>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations= in >>>>>>>> DTN2 >>>>>>>> >>>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>>>> wrote: >>>>>>>> >>>>>>>>> In view of which, I've now become a bigger fan of bundle-in-bundl= e >>>>>>>>> tunneling than I've been in the past. >>>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>>>> mentioned >>>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "f= unky" >>>>>>>> to >>>>>>>> me. There's no indication in the bundle that it's BiB and you need= some >>>>>>>> special EID to perform the decapsulation. Maybe that's just like a= n >>>>>>>> assigned >>>>>>>> port in TCP but we don't yet have such a mechanism. The multiple-b= undle >>>>>>>> thing >>>>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnel= s >>>>>>>> could >>>>>>>> be >>>>>>>> specially optimized. >>>>>>>> >>>>>>>> I need to go back and review all the discussions about BiB -- we w= orked >>>>>>>> it >>>>>>>> quite a bit but the spec never gained enough consensus to move for= ward. >>>>>>>> I >>>>>>>> think it would be a good idea to revisit it now and get a solid dr= aft >>>>>>>> that >>>>>>>> has wider support. Maybe the email discussions will help us get th= ere. >>>>>>>> >>>>>>>> Thanks.....Peter >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" >>>>>>>> >>>>>>>> To: "Burleigh, Scott C" , >>>>>>>> "dtn-security@irtf.org" >>>>>>>> Cc: >>>>>>>> Date: Tue, 22 Jan 2013 17:47:47 -0600 >>>>>>>> Subject: Re: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> Agreed; that makes sense. >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>>> Sent: Tuesday, January 22, 2013 6:35 PM >>>>>>>> To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; dtn-security@ir= tf.org >>>>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> >>>>>>>> Wes, I agree that some code change would be entailed in implementi= ng >>>>>>>> this >>>>>>>> proposal, but I think a large proportion of the code =AD the gener= al flow >>>>>>>> of >>>>>>>> processing the extension blocks, the canonicalization, the ciphers= uites, >>>>>>>> really almost everything that would have been implemented to handl= e the >>>>>>>> simple case of security source/destination being identical to bund= le >>>>>>>> source/destination =AD would be preserved. I suspect that much of= what I >>>>>>>> was >>>>>>>> proposing here involves removing functionality that most developer= s >>>>>>>> haven=B9t >>>>>>>> implemented yet anyway, because of the potential pitfalls. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] >>>>>>>> [mailto:wesley.m.eddy@nasa.gov] >>>>>>>> Sent: Tuesday, January 22, 2013 3:20 PM >>>>>>>> To: Burleigh, Scott C (313B); dtn-security@irtf.org >>>>>>>> Subject: RE: [dtn-security] FW: Re(19): Implementing Security >>>>>>>> Destinations >>>>>>>> inDTN2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It looks like basically a good idea to me. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I recall sometime in 2006 or 2007ish pointing out that security >>>>>>>> destinations >>>>>>>> needed to work more like IPsec tunnel-mode endpoints in order to m= ake >>>>>>>> the >>>>>>>> routing work correctly, and I think what you're proposing here >>>>>>>> accomplishes >>>>>>>> that in a better way. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Though I think cycles would be better spent on KMP issues that are >>>>>>>> actually >>>>>>>> HARD, and *then* circling back to see what could be tweaked in the= BSP, >>>>>>>> I >>>>>>>> definitely think this proposed change is something that would impr= ove >>>>>>>> the >>>>>>>> BSP >>>>>>>> a bit in the meantime. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I don't think it can be done in a way that's friendly to the exist= ing >>>>>>>> codebase like Stephen suggests shooting for. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> >>>>>>>> From: dtn-security-bounces@irtf.org [dtn-security-bounces@irtf.org= ] On >>>>>>>> Behalf >>>>>>>> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov] >>>>>>>> Sent: Tuesday, January 22, 2013 5:37 PM >>>>>>>> To: dtn-security@irtf.org >>>>>>>> Subject: [dtn-security] FW: Re(19): Implementing Security Destinat= ions >>>>>>>> inDTN2 >>>>>>>> >>>>>>>> Hi. Late last September, several of us spun off a sub-thread talk= ing >>>>>>>> about >>>>>>>> how the processing of bundles with multiple security destinations = could >>>>>>>> be >>>>>>>> handled in DTN implementations. I won=B9t try to recreate all of = the >>>>>>>> arguments >>>>>>>> on all sides, but I think we did converge on agreement that the cu= rrent >>>>>>>> BSP >>>>>>>> mechanism for complex, multi-destination security could be difficu= lt to >>>>>>>> realize in coherent fashion across the network. After puzzling ov= er >>>>>>>> this >>>>>>>> for >>>>>>>> a while, I came up with a concept (below) that I think would be si= mpler, >>>>>>>> safer, and even more powerful than the current protocol design. H= ow do >>>>>>>> we >>>>>>>> all feel about this? Would it be worthwhile for DTNRG to invest i= n a >>>>>>>> 6257bis >>>>>>>> RFC along these lines? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> _____________________________________________ >>>>>>>> From: Burleigh, Scott C (313B) >>>>>>>> Sent: Friday, November 16, 2012 5:05 PM >>>>>>>> To: 'Peter Lovell'; ahennes1@math.umd.edu >>>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss >>>>>>>> Subject: RE: Re(19): [dtn-security] Implementing Security Destinat= ions >>>>>>>> in >>>>>>>> DTN2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, Peter. At the risk (I know) of getting a lot of people severe= ly >>>>>>>> ticked >>>>>>>> off at me, I am going to offer a modest proposal for improving the >>>>>>>> Bundle >>>>>>>> Security Protocol, inspired by this thread. >>>>>>>> >>>>>>>> I propose to adopt a new design principle for Bundle Security Prot= ocol: >>>>>>>> the >>>>>>>> routing element of a bundle protocol agent should never need to in= spect >>>>>>>> a >>>>>>>> bundle=B9s BSP extension blocks in order to select the node(s) to = forward >>>>>>>> the >>>>>>>> bundle to. >>>>>>>> >>>>>>>> That is, BSP should provide security, not dictate routes. >>>>>>>> >>>>>>>> My rationale for proposing this principle is that I believe it wou= ld: >>>>>>>> >>>>>>>> =B7 Simplify BSP, thereby reducing the incidence of bugs a= nd >>>>>>>> making >>>>>>>> Bundle Security significantly less expensive to implement and sust= ain. >>>>>>>> >>>>>>>> =B7 Broaden the scope of BSP deployment by eliminating its >>>>>>>> dependence >>>>>>>> on specific, BSP-aware routing implementations, thereby increasing= the >>>>>>>> overall security of DTN. >>>>>>>> >>>>>>>> =B7 Reduce the cost of developing and improving routing >>>>>>>> implementations >>>>>>>> by removing any requirement that they be BSP-aware, and broaden th= e >>>>>>>> scope >>>>>>>> of >>>>>>>> deployment of non-BSP-aware routing implementations by enabling th= em to >>>>>>>> be >>>>>>>> used in environments requiring arbitrarily powerful security. The= reby, >>>>>>>> improve DTN operational performance. >>>>>>>> >>>>>>>> Here's how I would apply this principle: >>>>>>>> >>>>>>>> 1. Eliminate security sources and security destinations from= all >>>>>>>> BSP >>>>>>>> blocks. The security source of a BSP block would always be the bu= ndle=B9s >>>>>>>> source. The security destination of a BSP block would always be t= he >>>>>>>> bundle=B9s >>>>>>>> destination. >>>>>>>> >>>>>>>> 2. Add a new Administrative Record type for Bundle-in-Bundle >>>>>>>> encapsulation. >>>>>>>> >>>>>>>> 3. When additional security must be applied to a bundle on s= ome >>>>>>>> segment >>>>>>>> of its end-to-end path, encapsulate the bundle in a Bundle-in-Bund= le >>>>>>>> Encapsulation Administrative Record that is the payload of a new b= undle >>>>>>>> whose >>>>>>>> source is the security source of the path segment and whose destin= ation >>>>>>>> is >>>>>>>> the security destination of the path segment. Apply the additiona= l >>>>>>>> bundle >>>>>>>> transmission security measures to the encapsulating bundle: encryp= t its >>>>>>>> payload (the Administrative Record, containing the encapsulated bu= ndle), >>>>>>>> encrypt extension blocks as copied from the encapsulated bundle, e= tc. >>>>>>>> Then >>>>>>>> forward the encapsulating bundle. >>>>>>>> >>>>>>>> 4. When route service uncertainty forces a bundle to be rout= ed >>>>>>>> over >>>>>>>> multiple parallel additionally secured segments of its end-to-end = path, >>>>>>>> encapsulate it as above but within multiple different encapsulatin= g >>>>>>>> bundles, >>>>>>>> one for each of the parallel segments, and forward all of them. >>>>>>>> >>>>>>>> 5. At the destination of a bundle, apply all relevant bundle >>>>>>>> reception >>>>>>>> security measures and then, if the payload is an encapsulation >>>>>>>> Administrative >>>>>>>> Record, extract the encapsulated bundle from the Administrative Re= cord >>>>>>>> and >>>>>>>> simply forward it. >>>>>>>> >>>>>>>> I believe this would have the following impacts on DTN security: >>>>>>>> >>>>>>>> =B7 No EID references in BSP, simplifying canonicalization= . >>>>>>>> >>>>>>>> =B7 PCBs only encrypt payloads, never PIBs or PCBs (encryp= ting the >>>>>>>> encapsulated bundle encrypts all three at once), so no correlators= in >>>>>>>> BSP. >>>>>>>> (Except for BABs, no bundle ever has more than one occurrence of a= ny >>>>>>>> type >>>>>>>> of >>>>>>>> BSP block. And there will never be more than two BABs, one immedi= ately >>>>>>>> following the primary block and one that is the final block in the >>>>>>>> bundle, >>>>>>>> so >>>>>>>> that correlation is structural.) >>>>>>>> >>>>>>>> =B7 No delicate =B3replacement=B2 process for unraveling P= CB nesting >>>>>>>> at >>>>>>>> the >>>>>>>> destination. >>>>>>>> >>>>>>>> =B7 No possible confusion about the correct order of appli= cation >>>>>>>> of >>>>>>>> BSP >>>>>>>> blocks. >>>>>>>> >>>>>>>> =B7 No possible conflict among security destinations of di= fferent >>>>>>>> BSP >>>>>>>> blocks. >>>>>>>> >>>>>>>> =B7 Security paths can never overlap. >>>>>>>> >>>>>>>> =B7 Any routing implementation can always accommodate any = security >>>>>>>> regime: routes that must be followed to ensure security are encode= d into >>>>>>>> routing information at the forwarding node, not into the bundle. = (A >>>>>>>> little >>>>>>>> like the late binding principle.) >>>>>>>> >>>>>>>> =B7 Any routing environment can always be made arbitrarily= secure >>>>>>>> =AD >>>>>>>> no >>>>>>>> need to require specially BSP-aware routing elements. >>>>>>>> >>>>>>>> =B7 Ciphersuite design is simplified, so a wider array of = useful >>>>>>>> ciphersuites can be developed without imposing bug-prone complexit= y. >>>>>>>> Minimizes possible security problems. >>>>>>>> >>>>>>>> As an example of how I think this could work, see the attached dia= gram: >>>>>>>> >>>>>>>> 1. Node A is sending a bundle to node K. Nodes A, B, J, and= K are >>>>>>>> within the low-risk =B3W=B2 security region; nodes C and G are gat= eways >>>>>>>> between >>>>>>>> region W and the more hazardous region X; node D is another node i= n X; >>>>>>>> nodes >>>>>>>> E and F are gateways between region X and even more hazardous regi= on Y; >>>>>>>> nodes >>>>>>>> H and I are gateways between X and hazardous region Z. >>>>>>>> >>>>>>>> 2. At A the bundle is simply forwarded to B. >>>>>>>> >>>>>>>> 3. At B the routing element realizes that the bundle has to >>>>>>>> traverse >>>>>>>> region X in order to get to K, so it forwards the bundle to C. >>>>>>>> >>>>>>>> 4. The routing element at C encapsulates the bundle in an Ad= min >>>>>>>> Record, >>>>>>>> creates a new bundle destined for G (the egress from region X) who= se >>>>>>>> source >>>>>>>> is C and whose payload is that Admin Record, encrypts the payload, >>>>>>>> attaches a >>>>>>>> PCB, and forwards the bundle to D. >>>>>>>> >>>>>>>> 5. D realizes that the bundle has to traverse region Y in or= der to >>>>>>>> get >>>>>>>> to G, so it forwards the bundle to E. >>>>>>>> >>>>>>>> 6. E encapsulates the bundle in an Admin Record, creates a n= ew >>>>>>>> bundle >>>>>>>> destined for F (the egress from region Y) whose source is E and wh= ose >>>>>>>> payload >>>>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and fo= rwards >>>>>>>> the >>>>>>>> bundle to F. >>>>>>>> >>>>>>>> 7. The bundle protocol agent at F receives the bundle, decry= pts >>>>>>>> it, >>>>>>>> and >>>>>>>> passes the payload (an Admin Record) to the application agent. Th= e >>>>>>>> administrative element of the application agent at F receives the = Admin >>>>>>>> Record, extracts the encapsulated bundle destined for G, and queue= s it >>>>>>>> to >>>>>>>> be >>>>>>>> forwarded. The routing element at F sees this bundle and forwards= it to >>>>>>>> G. >>>>>>>> >>>>>>>> 8. The bundle protocol agent at G receives the bundle, decry= pts >>>>>>>> it, >>>>>>>> and >>>>>>>> passes the payload (an Admin Record) to the application agent. Th= e >>>>>>>> administrative element of the application agent at G receives the = Admin >>>>>>>> Record, extracts the encapsulated bundle destined for K, and queue= s it >>>>>>>> to >>>>>>>> be >>>>>>>> forwarded. The routing element at G sees this bundle, realizes th= at the >>>>>>>> bundle has to traverse region Z in order to get to K, and therefor= e >>>>>>>> forwards >>>>>>>> the bundle to H. >>>>>>>> >>>>>>>> 9. H encapsulates the bundle in an Admin Record, creates a n= ew >>>>>>>> bundle >>>>>>>> destined for I (the egress from region Z) whose source is H and wh= ose >>>>>>>> payload >>>>>>>> is that Admin Record, encrypts the payload, attaches a PCB, and fo= rwards >>>>>>>> the >>>>>>>> bundle to I. >>>>>>>> >>>>>>>> 10. The bundle protocol agent at I receives the bundle, decrypts= it, >>>>>>>> and >>>>>>>> passes the payload (an Admin Record) to the application agent. Th= e >>>>>>>> administrative element of the application agent at I receives the = Admin >>>>>>>> Record, extracts the encapsulated bundle destined for K, and queue= s it >>>>>>>> to >>>>>>>> be >>>>>>>> forwarded. The routing element at I sees this bundle and forwards= it to >>>>>>>> J. >>>>>>>> >>>>>>>> 11. At J the bundle is simply forwarded to K. >>>>>>>> >>>>>>>> 12. At K the bundle=B9s payload is passed to the application. >>>>>>>> >>>>>>>> I think this approach would combine simplicity with quite a lot of >>>>>>>> operational power, making everything cheaper and safer. >>>>>>>> >>>>>>>> So, having now stirred the hornet=B9s nest, I will beat a hasty re= treat >>>>>>>> for >>>>>>>> a >>>>>>>> week while I am on vacation. I=B9ll try to follow up when I get b= ack. >>>>>>>> >>>>>>>> Have a nice Thanksgiving, everybody. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Peter Lovell [mailto:plovell@mac.com] >>>>>>>> Sent: Monday, October 22, 2012 1:28 PM >>>>>>>> To: Burleigh, Scott C (313B); ahennes1@math.umd.edu >>>>>>>> Cc: Amy Alford; Cherita.Corbett@jhuapl.edu; Howard Weiss; Peter Lo= vell >>>>>>>> Subject: Re(19): [dtn-security] Implementing Security Destinations= in >>>>>>>> DTN2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Oct 24, 2012, Burleigh, Scott C (313B) >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In view of which, I've now become a bigger fan of bundle-in-bundl= e >>>>>>>> >>>>>>>>> tunneling than I've been in the past. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I agree. I'm also a big fan, for a bunch of reasons. However, as I >>>>>>>> mentioned >>>>>>>> to Angela, the current [i.e. latest, expired] draft seems a bit "f= unky" >>>>>>>> to >>>>>>>> me. There's no indication in the bundle that it's BiB and you need= some >>>>>>>> special EID to perform the decapsulation. Maybe that's just like a= n >>>>>>>> assigned >>>>>>>> port in TCP but we don't yet have such a mechanism. The multiple-b= undle >>>>>>>> thing >>>>>>>> is OK, I guess, but I don't see much use for it other than volume >>>>>>>> gateway-to-gateway traffic and I think that such heavy-duty tunnel= s >>>>>>>> could >>>>>>>> be >>>>>>>> specially optimized. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I need to go back and review all the discussions about BiB -- we w= orked >>>>>>>> it >>>>>>>> quite a bit but the spec never gained enough consensus to move for= ward. >>>>>>>> I >>>>>>>> think it would be a good idea to revisit it now and get a solid dr= aft >>>>>>>> that >>>>>>>> has wider support. Maybe the email discussions will help us get th= ere. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks.....Peter >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> dtn-security mailing list >>>>>>>> dtn-security@irtf.org >>>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>>> _______________________________________________ >>>>>>> dtn-security mailing list >>>>>>> dtn-security@irtf.org >>>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>>> >>>>>> _______________________________________________ >>>>>> dtn-security mailing list >>>>>> dtn-security@irtf.org >>>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>>> >>>>> _______________________________________________ >>>>> dtn-security mailing list >>>>> dtn-security@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/dtn-security >>>>> >>>> _______________________________________________ >>>> dtn-security mailing list >>>> dtn-security@irtf.org >>>> https://www.irtf.org/mailman/listinfo/dtn-security >>> >