Subject: [dtn-security] FW: Re(19): Implementing Security Destinations in DTN2

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Tue, 22 Jan 2013 22:37:27 +0000

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'; [email-masked]
Cc: Amy Alford; [email-masked]; 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:[email-masked]]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); [email-masked]<mailto:[email-masked]>
Cc: Amy Alford; [email-masked]<mailto:[email-masked]>; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2

On Wed, Oct 24, 2012, Burleigh, Scott C (313B) <[email-masked]<mailto:[email-masked]>> 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Jan 2013 23:08:55 +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:
> _______________________________________________
> dtn-security mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-security
>

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Tue, 22 Jan 2013 23:22:16 +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:[email-masked]] 
Sent: Tuesday, January 22, 2013 3:09 PM
To: Burleigh, Scott C (313B)
Cc: [email-masked]
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.

Cheers,
S.

> To: Burleigh, Scott C (313B); 
> [email-masked]<mailto:[email-masked]>
> Cc: Amy Alford; 
> [email-masked]<mailto:[email-masked]>; Howard 
> Weiss; Peter Lovell

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Jan 2013 23:28:38 +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.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Tue, 22 Jan 2013 23:35:35 +0000

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:[email-masked]]
Sent: Tuesday, January 22, 2013 3:20 PM
To: Burleigh, Scott C (313B); [email-masked]
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: [email-masked]<mailto:[email-masked]> [[email-masked]] On Behalf Of Burleigh, Scott C (313B) [[email-masked]]
Sent: Tuesday, January 22, 2013 5:37 PM
To: [email-masked]<mailto:[email-masked]>
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'; [email-masked]<mailto:[email-masked]>
Cc: Amy Alford; [email-masked]<mailto:[email-masked]>; Howard Weiss
Subject: RE: Re(19): [dtn-security] Implementing Security Destinations in DTN2

-----Original Message-----
From: Peter Lovell [mailto:[email-masked]]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); [email-masked]<mailto:[email-masked]>
Cc: Amy Alford; [email-masked]<mailto:[email-masked]>; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2

Hi Scott,

Thanks.....Peter

---

From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" <[email-masked]>
Date: Tue, 22 Jan 2013 17:19:48 -0600

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Burleigh, Scott C (313B) [[email-masked]]
Sent: Tuesday, January 22, 2013 5:37 PM
To: [email-masked]
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

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:

 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.

 *   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.

 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.
 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:[email-masked]]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); [email-masked]<mailto:[email-masked]>
Cc: Amy Alford; [email-masked]<mailto:[email-masked]>; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2

Hi Scott,

Thanks.....Peter

---

From: "Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]" <[email-masked]>
Date: Tue, 22 Jan 2013 17:47:47 -0600

Agreed; that makes sense.

________________________________
From: Burleigh, Scott C (313B) [[email-masked]]
Sent: Tuesday, January 22, 2013 6:35 PM
To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; [email-masked]
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

Scott

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:[email-masked]]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); [email-masked]<mailto:[email-masked]>
Cc: Amy Alford; [email-masked]<mailto:[email-masked]>; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2

Hi Scott,

Thanks.....Peter

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 23 Jan 2013 12:51:20 -0500

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 blocks) 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 network that may be unknowable.

A simplified approach should remove this coupling 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 encapsulation 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

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]
Sent: Tuesday, January 22, 2013 6:48 PM
To: Burleigh, Scott C; [email-masked]
Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2

To: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]; [email-masked]<mailto:[email-masked]>

Scott

From: Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.] [mailto:[email-masked]]
Sent: Tuesday, January 22, 2013 3:20 PM
To: Burleigh, Scott C (313B); [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2

Scott

-----Original Message-----
From: Peter Lovell [mailto:[email-masked]]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); [email-masked]<mailto:[email-masked]>
Cc: Amy Alford; [email-masked]<mailto:[email-masked]>; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2

Hi Scott,

Thanks.....Peter

---

From: "Pitts, Robert L. (MSFC-EO60)[HOSC SERVICES CONTRACT]" <[email-masked]>
Date: Thu, 24 Jan 2013 07:52:17 -0600

Ed,

                I concur.  Our work at the HOSC indicates that with the routing and security coupling, we may well not have a comprehensive solution in a timely manner if at all.  With the complex systems deployed in space and diverse communications links, a "GRE like" model would resolve many interface/boundary issues.

Lee

From: [email-masked] [mailto:[email-masked]] On Behalf Of Birrane, Edward J.
Sent: Wednesday, January 23, 2013 11:51 AM
To: [email-masked]
Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2

Also agreed.

-Ed

---
Ed Birrane

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eddy, Wesley M. (GRC-MS00)[MTI SYSTEMS, INC.]
Sent: Tuesday, January 22, 2013 6:48 PM
To: Burleigh, Scott C; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-security] FW: Re(19): Implementing Security Destinations inDTN2

Scott

Scott

-----Original Message-----
From: Peter Lovell [mailto:[email-masked]]
Sent: Monday, October 22, 2012 1:28 PM
To: Burleigh, Scott C (313B); [email-masked]<mailto:[email-masked]>
Cc: Amy Alford; [email-masked]<mailto:[email-masked]>; Howard Weiss; Peter Lovell
Subject: Re(19): [dtn-security] Implementing Security Destinations in DTN2

Hi Scott,

Thanks.....Peter