Subject: [dtn] BPbis and CL session identity

From: Brian Sipos <[email-masked]>
Date: Tue, 28 Jul 2020 12:10:50 +0000

All,
One point which was brought up at the last IETF, based on IESG review comments, is:
How should a BP Agent handle a situation where an attempt is made to establish a CL session with one Node ID and the actual session ends up being with a different Node ID?

This situation only apples to CLs which are session-based (or at least allow bidirectional data flow) and which present a BPA's Node ID to the peer. But this is applicable to the TCPCL (both v3 and v4) so should be worked out with some recommendation at least.

  1.  One option is to continue the session and any transfers which would have occurred to the peer BPA. Maybe assuming that the peer is multi-named and presented the "wrong" name for the network being used. Once a transfer begins, the peer BPA still has the opportunity to refuse a bundle because it doesn't like the EIDs in the primary block, etc.
  2.  The other option is for the BPA to terminate the session (with reason Contact Failure) right away. But then what? If there is no change in name-binding or routing information then the next attempt to transmit the bundle is likely to end up in the same situation.

I lean towards #1 just because it allows the BPA to do transfers and work out acceptance/refusal on a per-bundle basis. That behavior is also no different than a UDP CL or similar "fire and forget" CL.

What do current implementations of TCPCLv3 do in this situation?

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 28 Jul 2020 12:54:13 +0000

Brian, I agree.  ION implements option #1 but prints informational messages noting that the node ID asserted by the remote node is different from what was expected.

Scott

From: dtn <[email-masked]> On Behalf Of Brian Sipos
Sent: Tuesday, July 28, 2020 5:11 AM
To: [email-masked]
Subject: [EXTERNAL] [dtn] BPbis and CL session identity

All,