Re: [dtn] DTN addressing, routing, and ownership

[Brian Sipos <[e-mail]>]

Scott,
Since DTN is quite asynchronous compared to other transports, it makes sense that most protocols would not follow a strict request--reply paradigm and, if necessary, have some notion of a protocol-level reply-to EID.

The point about the bundle source is more confusing to me now. I think part of my confusion is lack of realistic examples or historical use, so these are not merely theoretical questions. Is there a reason why BPbis changed from RFC5050 to have a requirement about source _node ID_ instead of more general endpoint ID?
And are the current implementations which allow a source general EID expected to continue to do so? In that case what's the benefit of BPbis requiring more specific behavior?
________________________________
From: Burleigh, Scott C (US 312B) <[e-mail]>
Sent: Friday, July 3, 2020 15:53
To: Brian Sipos <[e-mail]>; Rick Taylor <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: DTN addressing, routing, and ownership


Hi, Brian.  Good point about the admin record flag in the primary block, this does give the implementation an opportunity to intercept misdirected administrative records.



Your point about reply-to EIDs is also well taken.  It is true that the source of every bundle is a node, and bpbis draft differs from RDFC 5050 in requiring that the source EID of an outgoing bundle identify the source node (except for anonymous bundles).  Forming the destination EID is always the responsibility of the application (even in the case of administrative records, as the source of an administrative record is the administrative element of the application agent – an application).



But at least in the ipn scheme, it would actually be fine for the source EID to have a service number other than zero; the node ID of the source node could always be formed simply by replacing the source EID service number with zero.  That would be one way to solve your conundrum, and in fact the ION implementation of BPv7 operates in this way.



I guess another mechanism would be to assume (or require) that service numbers be symmetrical/bidirectional so that the destination EID service number could be used as the return EID service number.  But that seems unnecessarily restrictive and I suspect it would raise more issues that we haven’t thought of yet.



Scott



From: Brian Sipos <[e-mail]>
Sent: Wednesday, July 1, 2020 7:50 PM
To: Burleigh, Scott C (US 312B) <[e-mail]>; Rick Taylor <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: DTN addressing, routing, and ownership



Scott,

Regardless of the phrasing, I believe that requirements about the use of the Node ID to exchange admin. records would avoid confusion for agent implementers. Some informative text about the purpose of a Node ID and its relationship to the Source of generated bundles would also make crystal clear what I was confused about.

The one difference between your port/socket example and BP is that because BP gives an explicit admin. record flag this situation is detectable by the BP agent before the data ever makes it to the overlaying application(s).



I still do have one conundrum now that I believe I understand the Source ID parameter: Since outgoing bundles are marked with the Node ID of the source and not a service-specific EID from the source, there is no concept of a "return EID" for replying to a bundle with a bundle. Unlike UDP/IP, where the source port number provides a return path for a packet, or SMTP, where each message includes an RFC5322 From or Reply-To address. Without an explicit return EID, then a dictionary of well-known dtn-scheme service names (and ipn-scheme service numbers) is mandatory.



When I receive a bundle from Node ID "dtn://nodeB/bp" to my EID at "dtn://nodeA/xyz", which is for Future-Protocol-1, how do I know what EID implements Future-Protocol-1 on "nodeB"? Maybe it's "dtn://nodeB/efg". Unless the application payload data itself contains an explicit return EID, I will need to construct an EID from the Node ID. Is the expectation to have an application-data-specific reply-to EID? Or is EID construction from an application the expected mode?

________________________________

From: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 1, 2020 10:03
To: Brian Sipos <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DTN addressing, routing, and ownership



I think we’re thinking along the same lines, Brian.  The source EID of any bundle containing an administrative record should likewise be one of the source node’s node IDs (or ideally – I believe – the node’s [sole] node ID).



I think the Internet may once again serve as a model for answering your question.  When an email arrives at a socket bound to port 156, I expect SQL Server simply discards it as invalid SQL Server data, right?  It’s up to the sender to address the bundle correctly.



Scott



From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 1, 2020 6:48 AM
To: Rick Taylor <[e-mail]<mailto:[e-mail]>>; Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: DTN addressing, routing, and ownership



Rick and Scott,

I actually don't see any problem now in the normative text in either BPbis or the current CL uses of "Node ID".

What I didn't pick up on are the secondary concerns of "how do I choose a Node ID?" and "what traffic is destined for that Node ID?" in BPbis Section 4.1.5.2. "Node ID" or elsewhere.

I had just assumed that the Node ID was just chosen from one of the Endpoints serviced by the node. In fact the Node ID is actually be separated on purpose from normal service EIDs.



This does bring up another point which I don't see addressed in Section 5.1.. "Generation of Administrative Records" or elsewhere: What is supposed to be the Source node ID of administrative-record bundles. I had earlier assumed they would match the Destination EID of the bundle which generated the Status Report (i.e. the status would be "coming from" the service EID). But looking at it now I realize the Source node ID of all bundles is *always* the singleton Node ID of the BP agent generating the bundle (admin or not).



Maybe some text in 4.1.5.2 similar to:

The Node ID is (MUST BE?) the Endpoint ID used as the (primary block) Source for all bundles originating from the node.

The Node ID is (SHOULD BE?) the endpoint ID with which the BP agent normally receives administrative bundles from other nodes. A Node ID is (SHOULD BE?) the destination EID of all administrative-record bundles.

Also related to this: what does a BP agent do when an administrative-record bundle is received on a normal service EID? Is that a valid situation? Does it still get processed with some internal warning?



________________________________

From: Rick Taylor <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 1, 2020 04:17
To: Burleigh, Scott C (US 312B) <scott.c.burleigh=[e-mail]<mailto:scott.c.burleigh=[e-mail]>>; Brian Sipos <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DTN addressing, routing, and ownership



Hi All,



Sorry for the top-post and my silence for the last months of COVID-19.



I have a concern that we have two node naming schemes (ipn + dtn) and neither is particularly well defined at the moment for historical reasons.  Looking forwards to a future interoperable DTN ‘Internet’, multiple schemes seems to require some kind of translation layer and I have had some long off-list conversations with Scott about such a topic – but we discussed ideas rather than concrete suggestions ready for drafts.



I wonder if a simple way forward for TCP-CL may be to keep the exact details of the “per-node administrative endpoint-id” as loose as possible in the CL specifications, i.e. requiring one exists, and defining how it shall be used for authentication, but leaving it to some other document (per-scheme perhaps) to define the actual details of the endpoint-id.



My open question is : would this be acceptable for a CL specification, or do the reviewers/authors require the “per-node administrative endpoint-id” defined, and is there sufficient text in BPbis to introduce the concept of a “per-node administrative endpoint-id”?



Cheers,



Rick



From: dtn [mailto:[e-mail]] On Behalf Of Burleigh, Scott C (US 312B)
Sent: 01 July 2020 00:35
To: Brian Sipos; [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] DTN addressing, routing, and ownership



I completely agree, Brian, we need to do a better job of documenting this.  It would also be good to document the corresponding semantics for the “dtn” scheme; that may actually be written down somewhere, but I can’t lay my hands on it right now.



Scott



From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 30, 2020 3:28 PM
To: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: DTN addressing, routing, and ownership



Scott,

Your responses are most helpful!



The piece I was missing is that there _is_ a concept of a per-node administrative endpoint. And that in the absence of any other services on a router-type node, that endpoint would be expected to be 'reachable'. And it makes sense that this is the endpoint to which administrative records would be reported-to.

The language of BPbis Node ID definition [11] now makes more sense in this concrete context. The raw text indicates _what_ a Node ID is but, at least on my reading of it, didn't really indicate or imply that the Node ID is the specific channel for the BP agent itself to exchange bundles.



The unfortunate thing is that neither RFC7116 [12] nor the referenced RFC6260 [13] actually says what IPN service number zero is supposed to actually do or when it should (or should not) be reachable on a node. Nor is RFC7116 referenced by any other documents [14]. I agree that the scope of BPbis, which just prescribes how to generate and process v7 bundles, doesn't need to cover service naming but I don't know if I would have picked up on this kind of detail without your feedback (or some kind of hands-on experience with existing BP tools).



[11] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-25#section-4.1.5...2<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-25#section-4.1.5.2>

[12] https://tools..ietf.org/html/rfc7116#section-3.2.2<https://tools.ietf.org/html/rfc7116#section-3.2.2>

[13] https://tools.ietf.org/html/rfc6260

[14] https://datatracker.ietf.org/doc/rfc7116/referencedby/



________________________________

From: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 30, 2020 13:19
To: Brian Sipos <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DTN addressing, routing, and ownership



Hi, Brian.  More responses in-line below.



Scott



From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 30, 2020 5:30 AM
To: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: DTN addressing, routing, and ownership



Thank you for the response. I want to pose my questions in more concrete terms, so I'll use a few vignettes based on current or proposed DTN protocols. My intent is to figure out how these protocols are actually being used if  possible.



In all cases I run a BP agent with three endpoint IDs for three separate services: "dtn://nodeA/svc1", "dtn://nodeA/svc2", and "dtn://nodeA/svc3".

1.   I use a single TCP CL (v3 or v4 doesn't matter, the same node info is exchanged in either case). I start a CL session (in either direction, contact data is the same) and send my Node ID. The CL requires exactly one Node ID for my side of the session. Which of the EIDs do I use as my Node ID? Or is it some other URI?  These are difficult questions to answer in terms of the dtn URI scheme, as the detailed semantics of that scheme are not (and have never been, AFAIK) standardized anywhere.  In ipn-scheme terms, let’s say you have a node whose node number is 91 that is a member of (singleton) endpoints ipn:91.1, ipn:91.2, and ipn:91.3.  That node is also implicitly a member of endpoint ipn:91.0, the administrative endpoint for that node (per RFC 7116).  The most useful node ID to pass when starting this TCPCL session would be “ipn:91.0”.
For outgoing CL sessions I could use a different EID for different outgoing bundles, but for incoming connections I have to send my Node ID before knowing what bundles may be incoming. Do I just choose one randomly? And then route bundles to the other EIDs as necessary?  No, in this context the right node ID to send is “ipn:91.0”..

2.   I run a DTN IPND node and send out broadcast beacons to my local network. Each beacon holds a single "Canonical EID". Which of the EIDs do I use in the beacon?  Again, I would say the right EID to advertise in this case is “ipn”91.0”.  I will make a somewhat controversial assertion here and claim that BP endpoints are – in practice – functionally equivalent to sockets.  In UDP/IP the destination of a datagram is a socket, not a host; but we route to the host, which delivers the datagram’s content at the socket.  Similarly in DTN the destination of a bundle is an endpoint, not a node; but we route to the node, which delivers the bundle’s application data unit at the endpoint.  So for routing purposes the information that needs to be advertised in a beacon is the node ID, which in this case is the singleton EID “ipn:91.0”.
Do I need to send three beacons for three services? If so, I could run into situations where neighborhood topology is observed to be different for the three services even though they use the same network transports.  I would say no, just as in IP we don’t normally advertise all of the sockets that the host has got open.  Service numbers don’t normally bear on the topology.

3.   For my question of "ownership" it means the same thing as "owning" an email address: I'm able to receive email for an address and send mail for an address. If I can prove to some third-party to be able to do those two things then I can claim to own an address.  I think that’s not really what you mean, though.  There are Internet tools that I can use to generate packets of arbitrary content and to snoop packets including emails; my use of those tools doesn’t demonstrate my ownership of the address.  I think what you really mean is that when a person receives an email for which the sending address is [e-mail]<mailto:[e-mail]>, that person can safely (modulo cyber-security as always) conclude that the sender of the email is Brian Sipos rather than Angela Merkel, because Brian Sipos is the registered owner of that address.  So what matters is the authenticity of the registered association between that name and that address; the integrity of the registry is paramount.
So my question for DTN is: if I can prove to own a Node ID (by proving to receive and send nonce-type bundles), does the network design allow my claim to cover not just the one Node ID URI for that bundle but any URI for that same "node-name".  And I think the answer is the same: your “ownership” of a node ID is an entry in a registry, somewhere, that associates your name with that node ID in a manner that is provably authentic.  If that ownership is established, then I would say that you also “own” (in the same sense) every ipn-scheme endpoint whose node number is the same as that of the node ID that you own.
To put another way: Would a DTN router ever actually make a routing decision based on the service part of an EID? I'm not asking the theoretical question but the practical one.  I guess it might, under the same kinds of circumstances under which an IP router would make a routing decision based on the port number of a socket address.  I don’t know enough about IP to identify all those circumstances; firewalls, I guess.  In DTN we don’t yet have anything like that, as far as I know.
A similar existing situation: To prove that I own an IP address I can use a mechanism like [10], which uses HTTP or TLS on TCP port 80/443. My proof-of-ownership is on a specific TCP port but the thing which I am proving to own is the entire IP address.  Again I would say that “ownership” is a matter of registration.  Currently the only such registry I know of for DTN is the node number assignments managed by nation space agencies under the auspices of the CCSD Space Assigned Numbers Authority.  Other registries are certainly possible, and the procedures for establishing node number ownership might vary wildly among registries.

I understand the Node ID/Endpoint ID theory, but when it comes to figuring out in practice I'm running into this brick wall related to multi-service nodes (which seems like it should be a common enough situation).



[10] https://tools.ietf.org/html/rfc8738





________________________________

From: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]..gov>>
Sent: Tuesday, June 30, 2020 01:03
To: Brian Sipos <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DTN addressing, routing, and ownership



Brian, I will offer a few answers, in-line below, but I am sure others will jump in to correct anything I get wrong.



Scott



From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of Brian Sipos
Sent: Sunday, June 28, 2020 8:05 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [dtn] DTN addressing, routing, and ownership



All,

I've been trying to figure out some details related to DTN addressing which are not covered in detail in the DTN architecture document [1]. My exposure to DTN has been from the protocol definition perspective and not from the historical-use perspective, so any undocumented current practices are probably unknown to me.



My questions are similar to the following:

1.      Are EIDs with identical dtn-scheme "node name" or ipn-scheme "node number" guaranteed to be routed to the same BP agent? How is this guaranteed? What document requires or disallows it?

--A BP agent is a component of a node.  The destination of a bundle is an endpoint, which is defined as a set of nodes but in practice is usually a set containing only a single node, a “singleton endpoint”.  RFC5050 defines the manner in which a bundle is forwarded to the sole occupant of a singleton destination endpoint.  Naturally, any program can be written to do anything one likes, so there are no guarantees.  But an alleged BP node that doesn’t do what RFC5050 (or, soon, BPbis) mandates is non-conformant.

2.      Are bundle routers allocated a well-known dtn-scheme "demux" text or ipn-scheme "service number"? i.e., is a bundle always routed through "dtn://NodeA/router" before it reaches endpoint "dtn://NodeA/svc1"?

--The dtn scheme actually isn’t very thoroughly defined.  There are some standard ipn-scheme service numbers defined by CCSDS, but there are no mandated routing policies associated with any of those numbers.

3.      Must each node run its own router service? Can a router on NodeA deliver bundles to an endpoint service on NodeB? Through what mechanism would this occur?

--“Delivery” of a bundle is defined in RFC5050; it is part of the defined behavior of the bundle protocol agent of a BP node.  The BPA presents to the appropriate application element (within the node’s application agent) the application data unit that is the payload of the bundle.  That application element could then pass the data on to whoever, but that’s outside of the bundle protocol.

4.      Can a single BP agent use convergence layers (CLs) which expose different Node IDs to neighbors? Can my BP agent use TCPCL sessions with local Node ID as "dtn://NodeA/svc1" and "dtn://NodeA/svc2"? Must it only expose the router service to CLs? Or does the CL itself constitute a service (e.g. as "dtn://NodeA/tcpcl")?

--Node IDs don’t have anything to do with convergence-layer adapters; the manner in which a node determines the ID of a neighboring node is completely unrelated to the convergence-layer protocols that will be used for communication between the nodes.

BPbis for Node ID schemes "dtn" [2] and "ipn" [3] has syntax explained but not full semantics. CBHE [4] gives some non-normative explanation of node number vs. service number semantics, but again doesn't dig into much detail about relationship requirements.



--I’d say that’s because the normative semantic issues are addressed by the protocol specifications rather than the scheme definitions.



The reason for all of these questions are two answer security topics such as:

1.      If I get a PKI certificate [5] for my node, do I need to authenticate (i.e. have a subjectAltName for) all possible Node IDs which could be used on my node? Or do I only need to authenticate for one "router" service, which is the only Node ID used by CLAs?

--I think this depends on exactly what the certificate is going to be used for, and I haven’t been following this thread closely enough to understand that.

2.      If I validate that I "own" a single Endpoint ID using a method such as [6], what else can be derived from that EID validation? Can I be said to own the entire dtn "node name" or ipn "node number"? Or can separate BP agents own EIDs with identical node-name/node-number?

--Since endpoints are identified by EIDs and an endpoint is a set of nodes, it’s certainly possible for multiple nodes to be registered in an endpoint identified by a single EID.  It’s not yet clear to me what “ownership” means in this context, though.

3.      When using BPsec [6] as a security acceptor, when I look up implicit keys associated with a security source Node ID must I relate keys to the full URI or can I relate keys to any URI with the same node-name/node-number? Will a security source always be a router service, or some other well-known service on a node?

--We don’t really have a concept of a “router service.”  Sharing a single key among multiple nodes (identified by different singleton endpoint IDs) is always going to be possible, I think, though not necessarily a good idea.

4.      When using a neighbor discovery (ND) protocol such as [8], which Node ID is supposed to be used as the "canonical EID" for each node? Just the router Node ID? Just the CL-based Node IDs? What about endpoint IDs directly delivered by the router on this node?

--Again, we really don’t have a concept of a router service or a router ID.  Nodes are just nodes.  Any node can be the source of a bundle, can be the destination of a bundle, or can forward a bundle that it receives but for which it is not the destination.  In implementation there is a notion of an endpoint that is the destination of all administrative bundles (bundles whose application data units are administrative records) directed toward a given node; the ID of that endpoint would nominally be the “canonical EID” for that node.

My own intuition makes me think that there is such a "router" service which is implicitly present on each node, which is used as the CL "Node ID" or ND "canonical EID", but that doesn't seem to actually be documented anywhere. It looks like there was a similar attempt to clarify DTN services in [9] but I don't see any movement on that after 2012.



Thanks in advance for clarification on any of these points.



[1] https://tools.ietf.org/html/rfc4838

[2] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-24#section-10.7

[3] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-24#section-10.8

[4] https://tools.ietf.org/html/rfc6260#section-2.1

[5] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-21

[6] https://datatracker.ietf.org/doc/html/draft-sipos-acme-dtnnodeid-01

[7] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-22

[8] https://datatracker.ietf.org/doc/html/draft-irtf-dtnrg-ipnd-03

[9] https://datatracker.ietf.org/doc/html/draft-blanchet-dtnrg-bp-application-framework-01