Subject: [dtn] new BIBE I-D

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 21 May 2018 02:39:00 +0000

Hi.  I just now posted a new edition of the Bundle-in-Bundle Encapsulation draft.  It differs from the initial edition mainly in the Custody Transfer mechanism it defines.  Some years of experience with the prototype Aggregate Custody Signal in ION on the International Space Station have convinced the ISS guys that ACS is important and is superior to the baseline custody transfer system originally defined in BIBE, lifted from RFC 5050.  My original thought was simply to add ACS as an option in BIBE, but on closer examination I couldn't spot any scenario in which the original custody transfer mechanism would be more efficient than the aggregated variant.  So the custody transfer procedures in this BIBE draft are now very similar to those of that ACS prototype.  Please speak up if you think this is a mistake.

Scott

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 21 May 2018 09:56:52 +0000 (UTC)

https://tools.ietf.org/html/draft-burleigh-dtn-bibect-01

"  . Moreover, in the event that no single point of egress from an insecure region of network topology can be determined at the moment a bundle is to be encapsulated, multiple copies of the bundle may be encapsulated individually and forwarded to all candidate points of egress."

I've previously raised the issue of multiple tunnel encaps effectively recapitulating source routing, with all the problems that source routing entails. That concern still stands. (June 2017 on this list)

generating BIBE-in-BIBE-in-BIBE... that DoSses and crashes bundle nodes (multiple nodes! with copying!) and allows spoofing of traffic from nodes is inevitable, and the draft needs to address that, by discussion recursion and source routing, and any introduced limits to same.

I don't have a view on whether ACS is a mistake; I see larger errors.

Lloyd Wood
http://sat-net.com/L.Wood/dtn

________________________________
From: "Burleigh, Scott C (312B)" <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Monday, 21 May 2018, 12:39
Subject: [dtn] new BIBE I-D

Scott

_______________________________________________

dtn mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dtn

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 21 May 2018 22:22:24 +0000

I remember this conversation.  Now as then, I think it's better policy to rely on authentication and firewall configuration, rather than routing, to address these kinds of security issues.

Scott

-----Original Message-----
From: Lloyd Wood <[email-masked]> 
Sent: Monday, May 21, 2018 2:57 AM
To: Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] new BIBE I-D

Lloyd Wood

Scott

dtn mailing list

[email-masked]

---

From: [email-masked]
Date: Tue, 22 May 2018 20:02:03 +0000 (UTC)

Scott,
if that's your belief, please put some text in the document about it, so we can tell you where it's wrong.
I haven't discussed routing. I have said that this will cause the same issues that source routing causes - and more. Understanding the comparison requires an understanding of what source routing is and does.
That BIBE apparently requires the invention of bundle firewalls says much about BIBE...

Lloyd WoodLloyd Wood - Delay-Tolerant Networking work
  
|  
|   
|   
|   |    |

   |

  |
|  
|   |  
Lloyd Wood - Delay-Tolerant Networking work

  |   |

  |

  |

On Tuesday, May 22, 2018, 08:22, Burleigh, Scott C (312B) <[email-masked]> wrote:

Scott

-----Original Message-----
From: Lloyd Wood <[email-masked]> 
Sent: Monday, May 21, 2018 2:57 AM
To: Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] new BIBE I-D

Lloyd Wood

Scott

dtn mailing list

[email-masked]